Duet3D Logo Duet3D
    • Tags
    • Documentation
    • Order
    • Register
    • Login

    [3.5 RC1] Toolchanges messing up Z height?

    Scheduled Pinned Locked Moved Unsolved
    Beta Firmware
    3
    8
    395
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • Diamondbackundefined
      Diamondback
      last edited by Diamondback

      Hey,
      very weird problem here... Currently trying to do a 4 tool print on my toolchanger... I carefully calibrated X, Y and Z offsets of all tools to the point where the first layer goes down pretty perfectly.
      Things become weird and when the printer does the second layer... My tool order on the first layer is T0, T1, T2, T3, second layer is T3, T0, T1, T2.

      Everything is fine until the printer switches to T0 on the second layer, at that point it adds like an 0.5-0.7mm offset on the Z axis and keeps printing way too high. Weirdly enough, the T3 (so the first tool being used) on that layer works perfectly fine with the correct Z height.
      While things are going wrong with T0, DWC displays the correct Z height (0.4mm), so I assume something is wrong with the offsets?
      I haven't printed past T0 on the second layer to see what the remaining two tools will do since I don't want to waste even more filament...

      Babystepping is at 0 and is not being touched during the print.

      How do I even start to debug this? Has anyone seen something similar?

      I've attached some images of the issue. Black is T0, beige is T1, green is T2, yellow is T3. All 4 first layers are perfect, second yellow layer is also perfect, second black layer is way too high.
      IMG_20231019_143014.jpg

      IMG_20231019_142329.jpg

      IMG_20231019_142321.jpg

      jp.douarvil 0undefined 1 Reply Last reply Reply Quote 0
      • Diamondbackundefined Diamondback marked this topic as a question
      • Diamondbackundefined
        Diamondback
        last edited by

        This happens every time btw, by now I have 4 of these failed attempts with the same symptoms. Restarted the printer inbetween as well.

        Looks like we someone on the E3D discord server has the same issue:
        https://discord.com/channels/756501859702800426/761238228690403328/1164609195987972097

        gloomyandyundefined 1 Reply Last reply Reply Quote 0
        • gloomyandyundefined
          gloomyandy @Diamondback
          last edited by

          @Diamondback What was the last version that worked correctly? Have you tried going back to that version?

          Diamondbackundefined 2 Replies Last reply Reply Quote 1
          • Diamondbackundefined
            Diamondback @gloomyandy
            last edited by

            @gloomyandy Seems to be new with RC1, I haven't seen such an issue on any of the previous 3.5 betas (b4 is what I used last).

            Gonna roll back to b4 I guess and see...

            1 Reply Last reply Reply Quote 0
            • Diamondbackundefined
              Diamondback @gloomyandy
              last edited by

              @gloomyandy It's working fine on 3.5b4.

              1 Reply Last reply Reply Quote 0
              • jp.douarvil 0undefined
                jp.douarvil 0 @Diamondback
                last edited by

                Hi,

                @Diamondback Does any of your tool change routine (tpre#.g, tfree#.g, tpost#.g) contains G92 command?

                I am also fighting with similar Z axis drift issue. At this point of my investigations it seems like this issue is related to the use of the G92 command, with or without Z argument, in the RRF3.5.0rc1 firmware.

                In my case, the issue occurs quasi-randomly whenever using the G92 command in either a gcode print file or a system macro.
                I say "quasi-randomly" in the sense that not every execution of a G92 triggers the bug, but when the bug occurs printer coherently acts as if the last movement of the Z axis before the G92 command was properly executed but not being tracked ( @dc42 ms.coords[Z_AXIS] variable not updated at some point between the beta4 and rc1 ?), not as if one board had randomly hung, or executed some corrupted data. I say "coherently act" because:

                • on system ①, I am using 2 separated 1HCL boards each controlling 1 of the 2 independent Z axis motors of the printer. From time to time I observed Z axis drift higher than 6mm upon executing a single system macro. Random data corruption or system interrupt on a single board would surely result in randomly tilting the bed left or right, which I do not observe at all
                • on system ②, the 2 independent Z axis motors are controlled by the same 3HC board. "Expectedly" no bed tilt is observed here too. Meaning this issue is probably independent from the board use (i haven't tried to plug both Z motors on the 6HC main board though).
                • both systems ① and ② exhibit the issue with RRF 3.5.0rc1, not with 3.5.0b4 or 3.4.xxx

                @Diamondback Note that I have no intention on hijacking your thread, I am only providing additional info relevant to your problem which I suspect could help RRF developers to quickly find the origin of the problem and come with a solution.

                gloomyandyundefined 1 Reply Last reply Reply Quote 0
                • gloomyandyundefined
                  gloomyandy @jp.douarvil 0
                  last edited by

                  @jp-douarvil-0 I think you should start a new thread and in it post details of the way you are using G92. It is fairly unusual to use G92 during a print.

                  1 Reply Last reply Reply Quote 0
                  • Diamondbackundefined
                    Diamondback
                    last edited by

                    No, i'm not using G92 during my print at all. It's being used for the homing process of the coupler axis once, but that's about it.

                    1 Reply Last reply Reply Quote 0
                    • First post
                      Last post
                    Unless otherwise noted, all forum content is licensed under CC-BY-SA