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

    Homing X triggers before reaching endstop

    Scheduled Pinned Locked Moved
    Tuning and tweaking
    5
    14
    234
    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.
    • dc42undefined
      dc42 administrators @sebastianwac
      last edited by

      @sebastianwac :

      1. Please provide your config.g and homex.g files.
      2. Which firmware version are you using?
      3. Which input is the X endstop switch connected to?
      4. Do the X endstop wires run parallel to any stepper motor wires over a significant distance?

      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
      • sebastianwacundefined
        sebastianwac @infiniteloop
        last edited by sebastianwac

        @infiniteloop said in Homing X triggers before reaching endstop:

        Would be good to know whether the move stops due to the endstop being triggered…

        Context (please confirm):

        You are running a 6HC + 1XD in a SBC setup?
        Your config.g is still this here?

        Yes provided hardware setup (6HC + 1XD in SBC configuration) and the config.g you referenced are both correct.
        We verified the switch using a multimeter and it works correctly.
        Also, when we press the switch, the X endstop indicator in DWC lights up green as expected.

        What’s interesting is that when the X axis starts close to the switch, the homing procedure works normally.
        However, if the axis is farther away, we need to run the homing sequence several times before it actually reaches the switch.
        It looks like the system thinks the endstop has been triggered before it actually touches the switch.

        1 Reply Last reply Reply Quote 0
        • fcwiltundefined
          fcwilt @sebastianwac
          last edited by

          @sebastianwac

          Well one possible answer is that the X homing command simply isn't moving as far as you think it is going to move.

          We need to see the actual homing code for X.

          Also, have you verified that the X axis steps-per-mm setting is correct?

          Frederick

          Printers: a E3D MS/TC setup and a RatRig Hybrid. Using Duet 3 hardware running 3.4.6

          sebastianwacundefined 1 Reply Last reply Reply Quote 1
          • sebastianwacundefined
            sebastianwac @fcwilt
            last edited by

            @fcwilt The homing code for the X axis appears to be correct.
            The working area of the machine is X1200Y2300 mm, and in the homing file, the G1 command for X is set to -1205 and Y -2305, which seems appropriate given the dimensions.

            Here is the relevant portion of the homing code for X:

            G91                ; relative positioning
            G1 H2 Z10 F3000    ; lift Z relative to current position
            G1 H1 X-1205 F3000 ; move quickly to X axis endstop and stop there (first pass)
            G1 H2 X5 F3000     ; go back a few mm
            G1 H1 X-1205 F1500 ; move slowly to X axis endstop once more (second pass)
            G1 H2 Z-10 F3000   ; lower Z again
            G90                ; absolute positioning
            

            Is it possible that the cable length (approx. 5 meters) is introducing additional resistance, making the controller interpret the switch as open?
            Or could it be due to electrical noise from nearby signal or motor cables?

            fcwiltundefined infiniteloopundefined dc42undefined 3 Replies Last reply Reply Quote 0
            • fcwiltundefined
              fcwilt @sebastianwac
              last edited by

              @sebastianwac said in Homing X triggers before reaching endstop:

              G91                ; relative positioning
              G1 H2 Z10 F3000    ; lift Z relative to current position
              G1 H1 X-1205 F3000 ; move quickly to X axis endstop and stop there (first pass)
              G1 H2 X5 F3000     ; go back a few mm
              G1 H1 X-1205 F1500 ; move slowly to X axis endstop once more (second pass)
              G1 H2 Z-10 F3000   ; lower Z again
              G90                ; absolute positioning
              

              One small observation. The G1 H2 X5 F3000 command - you don't need H2 since the preceding G1 H1 X-1205 F3000 will have marked the X axis as homed and at the point plain G1 moves will work as expected.

              Is it possible that the cable length (approx. 5 meters) is introducing additional resistance, making the controller interpret the switch as open?
              Or could it be due to electrical noise from nearby signal or motor cables?

              5 meters is a lot. It could be picking up noise.

              Is the wire twisted or shielded? Is the end-stop device a simple switch, like a micro-switch? Is it normally closed? Normally closed is the best as the signal wire is connected to ground, making it resistant to noise.

              Frederick

              Printers: a E3D MS/TC setup and a RatRig Hybrid. Using Duet 3 hardware running 3.4.6

              1 Reply Last reply Reply Quote 0
              • infiniteloopundefined
                infiniteloop @sebastianwac
                last edited by

                @sebastianwac

                Or could it be due to electrical noise from nearby signal or motor cables?

                IMHO, that’s the most plausible scenario. To test, take another cable of similar length and route it as far away from any steppers and wiring harnesses as possible.

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

                  @sebastianwac said in Homing X triggers before reaching endstop:

                  Is it possible that the cable length (approx. 5 meters) is introducing additional resistance, making the controller interpret the switch as open?
                  Or could it be due to electrical noise from nearby signal or motor cables?

                  Did you see my reply of 9 May?

                  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

                  sebastianwacundefined 1 Reply Last reply Reply Quote 0
                  • sebastianwacundefined
                    sebastianwac @dc42
                    last edited by

                    @dc42 @fcwilt @infiniteloop

                    Yes, the endstop wire is shielded, and the switch is a simple normally closed micro-switch, as recommended.

                    I’ve also noticed something very specific:
                    Right after powering on or resetting the controller, homing works perfectly — regardless of the axis position.
                    However, after performing an extrusion (extrude command), homing no longer works properly — the axes stop too early, as if the endstop had already been triggered.

                    Could this behavior be caused by interference from the extruder motor?
                    The endstop wires are routed separately from the extruder motor cables, so they don't share the same path.

                    Would it be possible to reset the extruder driver via G-code after each extrusion or print to prevent this issue?

                    Phaedruxundefined infiniteloopundefined 2 Replies Last reply Reply Quote 0
                    • Phaedruxundefined
                      Phaedrux Moderator @sebastianwac
                      last edited by

                      @sebastianwac said in Homing X triggers before reaching endstop:

                      Would it be possible to reset the extruder driver via G-code after each extrusion or print to prevent this issue?

                      You could test with this. https://docs.duet3d.com/User_manual/Reference/Gcodes#m18-disable-motors

                      Z-Bot CoreXY Build | Thingiverse Profile

                      1 Reply Last reply Reply Quote 0
                      • infiniteloopundefined
                        infiniteloop @sebastianwac
                        last edited by

                        @sebastianwac

                        The endstop wires are routed separately from the extruder motor cables, so they don't share the same path.

                        Just for clarity - how exactly have you wired the X endstop? From my understanding, there are two lines:

                        • line 1 from Pin "io2.in" to endstop
                        • the other line from GND (where exactly do you take it from?) to endstop

                        Am I right with this assumption? Or do you supply 5V instead of GND? If so, where do you pick it up? Are any pull-up or pull-down resistors involved?

                        sebastianwacundefined 1 Reply Last reply Reply Quote 0
                        • sebastianwacundefined
                          sebastianwac @infiniteloop
                          last edited by

                          @infiniteloop
                          Endstop is wired to IN and GND pins of IO_2 connector.

                          @Phaedrux
                          Thanks. I used M84 E0 at start of homing codes and it did the job. Now it is working correctly every time.

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

                            @sebastianwac said in Homing X triggers before reaching endstop:

                            I used M84 E0 at start of homing codes and it did the job. Now it is working correctly every time.

                            That confirms that the issue was caused by interference between the extruder motor cable and the endstop cable. You said they are routed separately, but do they run parallel and close together for an appreciable distance?

                            Using shielded cable for endstop wires offers protection against capacitively coupled interference, but not against inductively coupled interference. You can defend against inductively coupled interference by using twisted pair cable. Preferably, the signal and ground wires of the endstop switch should be connected to the Duet using a single twisted pair; and the stepper motor should be connected to the Duet using two twisted pairs, each motor phase using one pair.

                            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
                            • First post
                              Last post
                            Unless otherwise noted, all forum content is licensed under CC-BY-SA