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

    [3.6.0-rc.2] Z-probe hits bed and U not moving running Mesh

    Scheduled Pinned Locked Moved Solved
    Tuning and tweaking
    mesh z-probe
    3
    16
    618
    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.
    • tcamguilundefined
      tcamguil @droftarts
      last edited by

      @droftarts, I have quickly tested a few things with the following handmade heightmap.

      heightmap_X.csv

      RepRapFirmware height map file v2 generated at 2025-04-08 11:22, min error -0.041, max error 0.001, mean -0.020, deviation 0.020
      axis0,axis1,min0,max0,min1,max1,radius,spacing0,spacing1,num0,num1
      X,Y,0.00,250.00,0.00,300.00,-1.00,249.97,299.97,2,2
       -4.000,  4.000
       -4.000,  4.000
      

      heightmap_U.csv (the points are rotated to match the probing order)

      RepRapFirmware height map file v2 generated at 2025-04-08 11:22, min error -0.041, max error 0.001, mean -0.020, deviation 0.020
      axis0,axis1,min0,max0,min1,max1,radius,spacing0,spacing1,num0,num1
      Y,U,0.00,250.00,0.00,300.00,-1.00,249.97,299.97,2,2
        4.000,  4.000
       -4.000, -4.000  
      

      here are my results

      With heightmap_X active,

      • If no tool is active the heightmap is applied on G1 moves using the G1 Xaaa command but not the G1 Uaaa command.
      • If T0 (connected to X motor) is active the heightmap is applied on G1 moves using the G1 Xaaa command but not the G1 Uaaa command.
      • If T1 (connected to U motor) is active the heightmap is applied on moves using the G1 Xaaa command but not the G1 Uaaa command.

      With heightmap_U active,

      • If no tool is active the heightmap is applied on G1 moves using the G1 Uaaa command but not the G1 Xaaa command.
      • If T0 (connected to X motor) is active the heightmap is applied on G1 moves using the G1 Uaaa command but not the G1 Xaaa command.
      • If T1 (connected to U motor) is active the heightmap is applied on both moves using the G1 Uaaa command and the G1 Xaaa command.

      I hope this can help you diagnose the issue.

      On the other hand do you have an idea about what could be causing the toolboard to fail to detect the status change of the klicky thus attempting to push it through the bed?

      @tcamguil said in [3.6.0-rc.2] Z-probe hits bed and U not moving running Mesh:

      The first one is that during the G29 calibration the machine will sometimes fail to detect the "status change" of the Z-probe and will go all the way down breaking the Z-probe before generating a "Error: G29: Probe was not triggered during probing move" message.
      I have tried increasing the Z lift to 0.5mm in between two probes without success. H2:0.25 => H2:0.5
      I also tried to increase the recovery time to 0.5s thinking the Z-probe "status" was not updated in time. R0.0 => R0.5

      droftartsundefined 1 Reply Last reply Reply Quote 0
      • droftartsundefined
        droftarts administrators @tcamguil
        last edited by

        @tcamguil said in [3.6.0-rc.2] Z-probe hits bed and U not moving running Mesh:

        On the other hand do you have an idea about what could be causing the toolboard to fail to detect the status change of the klicky thus attempting to push it through the bed?

        I'd guess it's looking for a response from the wrong probe. Are you using G29 with a K parameter? Also check that any deployprobe#.g, retractprobe#.g and tool change macros (tpre#.g, tpost#.g and tfree#.g) are all numbered appropriately for the correct tool and probe. If you leave off the number (the #), that macro will be running for ALL probes/tools.

        For the heightmaps, @dc42 is looking into this. However, to me it looks like the order of the axes are incorrect when doing a mesh bed on the tool with U mapped to X, because it is listing the Y axis before U, when it should be U first. Can you post your full config.g, so I can see how you've set up your tools?

        I also think the mesh is being applied correctly (though not in the correct order), ie a mesh that has been made on the XY axes affects the XY axes but not U, and a mesh made on the UY axes affects the X when U is mapped to it, and UY axes. You generally wouldn't command a U axis move during a job, so this seems sensible.

        Ian

        Bed-slinger - Mini5+ WiFi/1LC | RRP Fisher v1 - D2 WiFi | Polargraph - D2 WiFi | TronXY X5S - 6HC/Roto | CNC router - 6HC | Tractus3D T1250 - D2 Eth

        tcamguilundefined 1 Reply Last reply Reply Quote 0
        • tcamguilundefined
          tcamguil @droftarts
          last edited by

          @droftarts
          After hours of trying to debug this issue here are the three files left on my printer
          Empty_printer.JPG

          config.g
          homeall.g
          mesh.g

          @droftarts said in [3.6.0-rc.2] Z-probe hits bed and U not moving running Mesh:

          I'd guess it's looking for a response from the wrong probe. Are you using G29 with a K parameter? Also check that any deployprobe#.g, retractprobe#.g and tool change macros (tpre#.g, tpost#.g and tfree#.g) are all numbered appropriately for the correct tool and probe. If you leave off the number (the #), that macro will be running for ALL probes/tools.

          G29 is using K1. I don't use / don't like using the deployprobe/retractprobe pair as it has a tendency to pickup/drop the probe too frequently when running a full machine calibration. tfree-tpre-tpost macros are all correctly numbered

          @droftarts said in [3.6.0-rc.2] Z-probe hits bed and U not moving running Mesh:

          For the heightmaps, @dc42 is looking into this. However, to me it looks like the order of the axes are incorrect when doing a mesh bed on the tool with U mapped to X, because it is listing the Y axis before U, when it should be U first. Can you post your full config.g, so I can see how you've set up your tools?

          For the heightmap I suppose the machine is configuring the mesh in the order of the axes in the firmware (ie: XYZUVWABC...) so it will select Y then U when calibrating, I may be wrong here but it seems logical to me maybe the firmware is selecting Y as both the first axis and the default Y axis (I could not quite understand how the mesh is working under the hood).

          @droftarts said in [3.6.0-rc.2] Z-probe hits bed and U not moving running Mesh:

          I also think the mesh is being applied correctly (though not in the correct order), ie a mesh that has been made on the XY axes affects the XY axes but not U, and a mesh made on the UY axes affects the X when U is mapped to it, and UY axes. You generally wouldn't command a U axis move during a job, so this seems sensible.

          That is also my point of view I think the Heightmap is correctly applied, Both toolheads were applying the compensation while the XY heightmap was active.
          The fact that the Heightmap is rotated when displayed on the DWC is an old issue as is the points being meshed and saved in the "wrong" order. It was for me just a quirk of the Firmware (the spacing has to be declared backwards Y then U).

          dc42undefined 1 Reply Last reply Reply Quote 0
          • dc42undefined
            dc42 administrators @tcamguil
            last edited by

            @tcamguil please try the 3.6.0-rc.2+1firmware from https://www.dropbox.com/scl/fo/kj7gwwzxg5lhe26twph5z/AAdwkPCTYi6bcogLmIIIup4?rlkey=8oo6z5il7wzk2u5b7qpykf3qv&dl=0. Let us know if you are able to generate the correct heightmap for the U/Y tool.

            Duet WiFi hardware designer and firmware engineer
            Please do not ask me for Duet support via PM or email, use the forum
            http://www.escher3d.com, https://miscsolutions.wordpress.com

            tcamguilundefined 1 Reply Last reply Reply Quote 0
            • tcamguilundefined
              tcamguil @dc42
              last edited by

              @dc42
              The good news is the points seems to be taken in the "right" order now.
              But the toolhead connected to the U motor needs to be active while the mesh is running for the U axis to move.
              Which was not needed for RRF3.6.0-rc1 and before.
              The points are being recorded in the right order in the heightmap file.

              But the Klicky triggering was not detected again about midway through the second mesh calibration breaking it.

              dc42undefined 2 Replies Last reply Reply Quote 0
              • dc42undefined
                dc42 administrators @tcamguil
                last edited by

                @tcamguil as a workaround to the U motor not moving unless the toolhead is active, try executing a short G1 U move before probing.

                I can't think of any reason why the klicky triggering would not be detected other than a wiring issue, e.g. a bad crimp connection that causes a bad connection at some UY locations but not others.

                Duet WiFi hardware designer and firmware engineer
                Please do not ask me for Duet support via PM or email, use the forum
                http://www.escher3d.com, https://miscsolutions.wordpress.com

                tcamguilundefined 1 Reply Last reply Reply Quote 0
                • dc42undefined
                  dc42 administrators @tcamguil
                  last edited by

                  @tcamguil I believe I have fixed the issue of the U axis not moving. Please try the 3.6.0-rc.2+2 firmware at https://www.dropbox.com/scl/fo/nlkfneaas1osgtdw37s17/AIS_H0KSAKCmfYSjSRTSOAE?rlkey=ad4omnq36zkdz3wl8i7kthqqt&dl=0.

                  Duet WiFi hardware designer and firmware engineer
                  Please do not ask me for Duet support via PM or email, use the forum
                  http://www.escher3d.com, https://miscsolutions.wordpress.com

                  1 Reply Last reply Reply Quote 0
                  • tcamguilundefined
                    tcamguil @dc42
                    last edited by

                    @dc42, it is working now. Thank you for the quick update.

                    I guess it could be a bad connection.But why does it happens at random points on the buildplate. And why can't I reproduce the issue on RRF 3.6.0-RC.1 or before. Could it be an issue with the debouncer ?

                    I switched to a NO sensor and the issue is now flipped the error is now "Error: G29: Probe already triggered before probing move started". and the Z-probe status is stuck in the triggered state until I trigger/un trigger it manually.

                    dc42undefined 1 Reply Last reply Reply Quote 0
                    • dc42undefined
                      dc42 administrators @tcamguil
                      last edited by

                      @tcamguil regarding the Klicky probe not triggering, please try the updated 3.6 tool board firmware at https://www.dropbox.com/scl/fo/vyin5beexljdndp3c00ln/AE6qWXcANSDo40ffsEaRZI4?rlkey=5kc28a1jbr7hu4l90w5shovh1&dl=0.

                      Duet WiFi hardware designer and firmware engineer
                      Please do not ask me for Duet support via PM or email, use the forum
                      http://www.escher3d.com, https://miscsolutions.wordpress.com

                      tcamguilundefined 1 Reply Last reply Reply Quote 0
                      • tcamguilundefined
                        tcamguil @dc42
                        last edited by

                        @dc42 thank you very much.

                        I was able to run multiple consecutive meshes an increasing probing speeds without issues.
                        I think this solves the last of my issues.

                        dc42undefined 1 Reply Last reply Reply Quote 0
                        • dc42undefined
                          dc42 administrators @tcamguil
                          last edited by

                          @tcamguil thanks for confirming this.

                          Duet WiFi hardware designer and firmware engineer
                          Please do not ask me for Duet support via PM or email, use the forum
                          http://www.escher3d.com, https://miscsolutions.wordpress.com

                          1 Reply Last reply Reply Quote 0
                          • dc42undefined dc42 has marked this topic as solved
                          • First post
                            Last post
                          Unless otherwise noted, all forum content is licensed under CC-BY-SA