Navigation

    Duet3D Logo

    Duet3D

    • Register
    • Login
    • Search
    • Categories
    • Tags
    • Documentation
    • Order

    Could do with some help with sensorless homing on a CoreXY

    Tuning and tweaking
    6
    41
    3021
    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.
    • deckingman
      deckingman last edited by

      I now have my 6th and 7th axes installed to my CoreXYUV. Not sure what to call these other axes - they do the opposite of X and Y so maybe 1/X and 1/Y or X^-1 and Y^-1?

      All gantries are moving in the correct directions when commanded to do so but I'm trying to use stall detection to home these additional axes independently of XYUV without much luck. Has anyone succeeded in getting stall detection/sensor less homing to work on a CoreXY and if so, could you share your settings please?

      Alternatively, take a gander of what I've tacked on to the beginning of my homex.g which is as follows, and tell me what I've got wrong.....

      G91; relative
      M584 X6 Y9 ; temporarily map drives 6 and 9 to XY
      M906 X200 Y200; set motor currents low
      M915 P6:9 S0 R0; configure stall detection
      M574 X1 Y1 S3; configure end stop switches for stall detection

      G1 X-400 F3000; do a long X move at 3000mm/min
      M574 X1 Y1 S1; put end stop switches back

      then I remap drives and continue with "normal" X and U homing which all works as it should.

      Everything moves as it should but when the axis reaches the hard stop, it continues to grind away and the belts jump teeth. If I set the motor current any lower the gantry won't move. Any higher and the tooth jumping thing gets more violent and is likely to do physical damage. It doesn't seem to matter what I set the S parameter to. The Wiki says values less that -10 not recommended but I've gone lower than this with no change to the behaviour.

      The drivers 6 and 9 are on the Duex5 (obviously).

      Software info as follows:

      Firmware Name: RepRapFirmware for Duet 2 WiFi/Ethernet
      Firmware Electronics: Duet Ethernet 1.0 or 1.01 + DueX5
      Firmware Version: 2.01(RTOS) (2018-07-26b2)
      Web Interface Version: 1.22.3

      Thanks in advance

      Oh and the motors 59Ncm @2Amp which I normally run at 1800mA. Could that have bearing?

      Ian
      https://somei3deas.wordpress.com/
      https://www.youtube.com/c/deckingman/

      1 Reply Last reply Reply Quote 0
      • deckingman
        deckingman last edited by deckingman

        Additional info if this helps. Just ran M122 after homing x as per the above code.

        Drivers 6 and 9 show SG min/max of 0/0. I'm sure that must mean something to someone cleverer than I.

        Further edit - on close inspection, the belts don't jump as I thought - it's just the motors vibrating loudly and violently.

        Ian
        https://somei3deas.wordpress.com/
        https://www.youtube.com/c/deckingman/

        1 Reply Last reply Reply Quote 0
        • sigxcpu
          sigxcpu last edited by

          This is my homex.g (Y is the same). My problems were that it was detecting stall upon starting b/c of high acceleration and the solution was to reduce acceleration during homing (hence the set_accel.g macro to restore).
          Not your problem, but maybe you get some inspiration.

          M400					; make sure everything has stopped before we make changes
          M915 P0:1 S3 F0 R0			; configure stall detection
          M574 X1 Y1 S3				; set endstops to use motor stall
          M913 X50 Y50				; reduce motor current to 50% to prevent belts slipping
          M201 X500				; reduce acceleration to avoid false triggering
          G91					; use relative positioning
          					; X or Y is homed at this point, now home the other axis
          G1 S1 X-325 F4000		      	; move towards axis minimum 
          G1 X22                      		; move away from home
          M400                  			; make sure everything has stopped before we reset the motor currents
          M913 X100 Y100 				; motor currents back to 100%
          G90                   			; back to absolute positioning
          G92 X0
          M574 X1 Y1 S1
          M98 Pset_accel.g			; restore acceleration values
          
          deckingman 1 Reply Last reply Reply Quote 0
          • deckingman
            deckingman @sigxcpu last edited by

            @sigxcpu Thanks for sharing. Nothing leaps out at me though.

            Ian
            https://somei3deas.wordpress.com/
            https://www.youtube.com/c/deckingman/

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

              Check that the homing move speed and steps/mm together give a high enough full steps per second speed to be above the stall detection threshold steps/second.

              You could call the additional axes A and B instead of mapping the motors to X and Y.

              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

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

                @dc42 Thanks.

                My steps per mm and pulley are exactly as the example in the wiki which indicates that the speed should be at least 2400mm/min and I'm using 3000. Just tried 4,000 to no avail.

                On the drive mapping, once homing is complete, I need to map these axes to X and Y in any case. So for printing it becomes M584 X0:3:6 Y1:4:9 Z2 E5:7:8

                Ian
                https://somei3deas.wordpress.com/
                https://www.youtube.com/c/deckingman/

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

                  I've just checked the code, and stall detection isn't handled properly for CoreXYUV kinematics. When you home X, it only checks for a stall on the X motor, and when you home Y it only checks for a stall on the Y motor. I'll fix this in the next build. If you home X and Y simultaneously, it ought to stop the movement when either motor stalls.

                  Meanwhile, you could switch the machine to CoreXY mode, home the new axes, then switch to CoreXYUV and home the rest.

                  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

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

                    @dc42 Brilliant! Thanks David. Glad to know that this wasn't a case of senility on my part.☺️

                    Ian
                    https://somei3deas.wordpress.com/
                    https://www.youtube.com/c/deckingman/

                    1 Reply Last reply Reply Quote 0
                    • deckingman
                      deckingman last edited by

                      OK, I've tried temporarily setting CoreXY mode but unfortunately I still don't seem to be getting any detection of motor stall. I do now get an error message saying that homing has failed which is a step in the right direction. I also tried moving X and Y simultaneously but when X reaches the physical stop both motors simply vibrate alarmingly until the remainder of the move completes.

                      I've tried reducing acceleration and increasing speed. Current homex.g now looks like this:

                      M669 K1; coreXY mode - reason temporary firmware bug
                      G91; relative
                      M584 X6 Y9; temporarily map dynamic load gantry steppers to X and Y
                      M906 X200 Y200; reduce motor currents
                      M201 X400 Y400; reduce accelerations
                      M915 P6:9 S0 R0; configure stall detection
                      M574 X1 Y1 S3; configure end stop switch for stall detection
                      G1 X-400 F4000; do a long slow move to x min - tried doing G1 X-400 Y-400 F400 but no difference
                      M574 X1 S1; configure end stop switch back to where it was
                      M669 K8 ; put kinematics back to CoreXYUV
                      M201 X1000 Y1000 ; put accelerations back to 1000

                      M122 reports SG values for D6 and D9 but they are highly variable. After the last homeX I have SG min/max of 0/52 for drive 6 and 0/46 for drive 9.

                      If it helps, motor specs as follows:

                      Voltage (VOC) 2.80
                      Amps/Phase (2.00
                      Resistance/Phase (Ohms @25degC) 1.4+_ 10%
                      Inductance/Phase(mH@1KHz) 3.00+_20%
                      Holding Torque (Nm) 0.59
                      Step angle 1.8
                      Rotor Inertia (g-cm) 82.00

                      Ian
                      https://somei3deas.wordpress.com/
                      https://www.youtube.com/c/deckingman/

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

                        From the datasheet:

                        Due to the dependency of the stallGuard2 value SG from motor-specific characteristics and application specific demands on load and velocity the easiest way to tune the stallGuard2 threshold SGT for a specific motor type and operating conditions is interactive tuning in the actual application.
                        The procedure is:

                        1. Operate the motor at a reasonable velocity for your application and monitor SG.
                        2. Apply slowly increasing mechanical load to the motor. If the motor stalls before SG reaches zero, decrease SGT. If SG reaches zero before the motor stalls, increase SGT. A good SGT starting value is zero. SGT is signed, so it can have negative or positive values.
                        3. The optimum setting is reached when SG is between 0 and 400 at increasing load shortly before the motor stalls, and SG increases by 100 or more without load. SGT in most cases can be tuned together with the motion velocity in a way that SG goes to zero when the motor stalls and the stall output SG_TST is asserted. This indicates that a step has been lost.

                        I'm wondering whether the back emf of those motors is too low at the very low motor current you are using, but I understand why you don't want to use a higher current.

                        HTH David

                        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

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

                          @dc42 said in Could do with some help with sensorless homing on a CoreXY:

                          ................................
                          I'm wondering whether the back emf of those motors is too low at the very low motor current you are using, but I understand why you don't want to use a higher current.

                          HTH David

                          Hmm. Well I think there is a real risk of some physical damage happening if I try and increase the current.

                          Maybe sensor less homing isn't an option with these motors and I have to come up with a plan B.

                          Any ideas? I do have a couple of spare estop connectors on the Duex5 and I could fit a couple of switches easy enough.

                          Ian
                          https://somei3deas.wordpress.com/
                          https://www.youtube.com/c/deckingman/

                          1 Reply Last reply Reply Quote 0
                          • deckingman
                            deckingman last edited by

                            As a temporary solution, I've made use of M291 in my homing files to prompt me to move the load cancelling gantry to the appropriate position. Along with reducing motor currents, this will hopefully be enough to prevent anything nasty happening - at least until I can come up with a better plan.

                            Ian
                            https://somei3deas.wordpress.com/
                            https://www.youtube.com/c/deckingman/

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

                              You could define the two additional motors as axes A and B while homing them, allowing you to use endstop inputs 5 and 6 aka E2 and E3 assuming there is no W axis.

                              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

                              deckingman 2 Replies Last reply Reply Quote 0
                              • deckingman
                                deckingman @dc42 last edited by

                                @dc42 said in Could do with some help with sensorless homing on a CoreXY:

                                You could define the two additional motors as axes A and B while homing them, allowing you to use endstop inputs 5 and 6 aka E2 and E3 assuming there is no W axis.

                                Thanks. I'll give that a go when I get chance. E2 and E3 are currently used for axes maxima and another switch to trigger an emergency stop, but I can move them to E4 and E5 easily enough.

                                Ian
                                https://somei3deas.wordpress.com/
                                https://www.youtube.com/c/deckingman/

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

                                  @dc42 OK, so I've hooked up a couple of switches but still not having a great deal of success. I get movement in the X direction for axis A but no movement in the Y direction for axis B. Then after "attempting" to home A and B, my homeall.g file then homes XYU and V as it has always done, but after these have been homed, no movement in the X direction is possible for any of the gantries. Homeall. g normally moves to the centre of the bed for Z probing but after doing XYU and V., it only moves in the Y direction. However, movement in Y works fine for all 3 gantries.

                                  It's likely that I have missed or configured something incorrectly but after a few hours, I still can't find my mistake.

                                  My annotated homeall.g is as follows:

                                  ; homeall.g
                                  ; called to home all axes
                                  ; Use This for Dynamic Load Gantry - mapping is different*

                                  ; start by warming the hot end so that any oozed filamnt is molten

                                  TO; select a tool - any one will do
                                  M104 S140; heat to 140 but don't wait

                                  ;********** COMMANDS FROM HERE ADDED FOR UPPERMOST (3RD) GANTRY ********

                                  M584 X0:3:6 Y1:4:9 Z2 U10 V11 E5:7:8 P3; make sure mapping is as per config.g to start with

                                  M906 X400 U400 Y400 V400 Z1200 ; reduce motor currents

                                  M584 A6 B9 P7; create A and B axes for upper gantry

                                  M574 A1 B1 S1 ; create end stops E2 and E3 for the new A and B axis

                                  M350 A16 B16 ; configure microstepping for A and B
                                  M92 A80 B80 ; configure steps per mm for A and B
                                  M566 A600 B600; inst speed change
                                  M203 A50000 B50000; max speed
                                  M201 A1000 B1000; accel
                                  M208 A0 B0 S1; axes minima
                                  M208 A380 B380 S0 axes maxima

                                  G91 ; set to use relative coordinates

                                  G1 A-380 B-380 F4800 S1 ; move fairly quickly until one of other end stop switches triggers

                                  G1 A-380 S1 ; course home A

                                  G1 A10 F600 ; move back a few mm slowly

                                  G1 A-380 F360 S1 ; fine home A

                                  G1 B-380 F4800 S1; course home B

                                  G1 B10 F600 ; move back a few mm

                                  G1 B-380 F360 S1 ; fine home B

                                  ; *****DURING THE ABOVE, THERE IS "A" axis MOVEMENT IN THE X DIRECTION
                                  ; *****BUT NO "B" axis MOVEMENT IN THE Y DIRECTION
                                  ; ***** AND THE A(X) AXIS SEEMS TO BE IS LOOKING FOR THE B(Y) ENDSTOP

                                  ; END OF ADDITIONAL COMMANDS*

                                  M584 X0 U3 Y1 V4 P5; temporarily map drives to U and V axes - have to map both axes even thought only U is being used due to both motors being employed per axis

                                  G91 ; set to use relative coordinates

                                  G1 Z5 F600 ; move bed down 5 mm

                                  G1 X-380 U-380 Y-380 V-380 F4800 S1; move all 4 axes fairly quickly until one or other triggers a switch

                                  G1 X-380 U-380 F4800 S1; now move just X and U fairly quickly left until one or other triggers a switch

                                  G1 X-380 S1; course home X
                                  G1 U-380 S1; course home U

                                  G1 X10 U10 F600 ; Go back a few mm

                                  G1 X-380 U-380 F360 S1; Move slowly to X and U axis endstops once more and stop when one triggers

                                  G1 X-380 F360 S1 ; fine home X
                                  G1 U-380 F360 S1 ; fine home U

                                  G1 Y-380 V-380 F4800 S1; now move Y and V fairly quickly left until one or other triggers a switch

                                  G1 Y-380 S1; course home Y
                                  G1 V-380 S1; course home V

                                  G1 Y10 V10 F600; Go back a few mm

                                  G1 Y-380 V-380 F360 S1; Move slowly to Y and V axis endstops once more and stop when one triggers

                                  G1 Y-380 F360 S1 ; fine home Y
                                  G1 V-380 F360 S1 ; fine home V

                                  M584 X0:3:6 Y1:4:9 Z2 U10 V11 E5:7:8 P7; add dynamic gantry to XY ; map all 3 gantries to X and Y

                                  G90; set to absolute coordinates

                                  ; ******* FROM THIS POINT ON, NO MOVEMENT IN THE X DIRECTION IS POSSIBLE
                                  ; ******* JUST NOTHING HAPPENS WHEN ANY X MOVE IS ASKED FOR
                                  ; ******* THIS APPLIES TO ALL 3 GANTRIES
                                  ; ******* BUT Y DIRECTIONS MOVES WORK FINE FOR ALL 3 GANTRIES AS DOES Z
                                  ;******** THIS BEHAVIOUR PERSIST AFTER HOMING AND THE MACHINE HAS TO BE RESET.

                                  G1 X180 Y180 F12000; move all 3 gantries to more or less the centre of the bed

                                  ; **** AS STATED ABOVE, THE X DIRECTION COORDINATE NO LONGER HAPPENS

                                  M109 S140 ; continue heating bed to 140 but this time wait

                                  G30

                                  G91 ;relative
                                  G1 Z5 F300
                                  G90 ; back to absolute

                                  M906 X1800 U1800 Y1800 V1800 Z1800 ; set motor currents back to defaults

                                  M104 S0; set hot end temp back to zero

                                  Ian
                                  https://somei3deas.wordpress.com/
                                  https://www.youtube.com/c/deckingman/

                                  1 Reply Last reply Reply Quote 0
                                  • deckingman
                                    deckingman last edited by deckingman

                                    Above post deleted - me being stupid.

                                    Edit. Post restored, I'm still probably stupid but not for the reasons I thought.

                                    Ian
                                    https://somei3deas.wordpress.com/
                                    https://www.youtube.com/c/deckingman/

                                    1 Reply Last reply Reply Quote 0
                                    • deckingman
                                      deckingman last edited by

                                      Also tried sensor less homing as above with motor currents set to 500mA but still no stall detected. At a bit of a loss as to what to try next.

                                      Ian
                                      https://somei3deas.wordpress.com/
                                      https://www.youtube.com/c/deckingman/

                                      1 Reply Last reply Reply Quote 0
                                      • wilriker
                                        wilriker Moderator last edited by

                                        This is just a shot in the dark but it feels odd to me that

                                        M584 X0:3:6 Y1:4:9 Z2 U10 V11 E5:7:8 P3; make sure mapping is as per config.g to start with
                                        [...]
                                        M584 A6 B9 P7; create A and B axes for upper gantry
                                        M574 A1 B1 S1 ; create end stops E2 and E3 for the new A and B axis
                                        

                                        this would work as intended. I mean the part where you first do the axes definition and then reassign drives to other axes and assume that E2 and E3 match to these axes. I looked into the source code and even though I did not understand everything I found I think you need to define the new axes in the right order in one command. Something like the following might be more correct:

                                        M584 X0:3 Y1:4 A6 B9 Z2 U10 V11 E5:7:8 P3
                                        

                                        I think it needs to be done like this because parsing M584 does not really care about the letters being in strict XYZUVWABC order anymore but the order they are given is more or less responsible for the endstop-mapping. So in your current setup the endstops would be mapped to U and V.

                                        At least something to try.

                                        Manuel
                                        Duet 3 6HC (v0.6) with RPi 4B on a custom Cartesian
                                        with probably always latest firmware/DWC (incl. betas or self-compiled)
                                        My Tool Collection

                                        deckingman 1 Reply Last reply Reply Quote 0
                                        • deckingman
                                          deckingman @wilriker last edited by

                                          @wilriker Thanks for that. It makes sense so I'll give it a try.

                                          Ian
                                          https://somei3deas.wordpress.com/
                                          https://www.youtube.com/c/deckingman/

                                          1 Reply Last reply Reply Quote 0
                                          • deckingman
                                            deckingman last edited by

                                            OK, so I've tried @wilriker's suggestion. Essentially, I've moved the creation of the A and B axes to config.g. So I have in config-g:

                                            M584 X0:3 Y1:4 Z2 A6 B9 U10 V11 E5:7:8 P3;

                                            followed by:

                                            M574 Z0 S0 ; Define active low and unused microswitches
                                            M574 X1 Y1 S1 ; Define active high microswitches
                                            M574 U1 V1 S1 ; active high switches for when temporary U and V axes are employed during homing the upper XY
                                            M574 A1 B1 S1;

                                            Then I've set all the other axis related parameters for all 7 axes (M350, M92, M566, M203. M201 etc).

                                            After which I remap drives thus:
                                            M584 X0:3:6 Y1:4:9 Z2 U10 V11 E5:7:8 P3; Remap A and B to X and Y

                                            Then I've simplified the start of homeall.g so that it starts with this:

                                            M584 X0:3:6 Y1:4:9 Z2 U10 V11 E5:7:8 P3; make sure mapping is as per config.g to start with

                                            M906 X400 U400 Y400 V400 Z1200 ; reduce motor currents

                                            M584 A6 B9 P7 ; RE-Map A and B

                                            G91 ; set to use relative coordinates

                                            ;G1 A-380 F4800 S1 ; course home X

                                            ;G1 A10 F600 ; move back a few mm slowly

                                            ;G1 A-380 F360 S1 ; fine home A

                                            G1 B-380 F4800 S1; course home B

                                            G1 B10 F600 ; move back a few mm

                                            G1 B-380 F360 S1 ; fine home B

                                            This has helped in as much as at the end of homing, all axes now move in both the X and Y directions. However, homing A and B does not work and I've figured out the reason why. Basically I get diagonal movement when asking for pure X or pure Y moves. This was masked in my earlier attempts at homing A and B because I started with a diagonal move in any case. I've now taken that out.

                                            So it seems that when I create A and B in config.g, they are created as Cartesian axes and only move one motor, rather than CoreXY which requires both motors to be moved. Also, A (X) still seems to be looking at B(Y) end stop - actually I think (but can't be sure) that both axes look at the same end stop - I'll check that.

                                            Late thought. I've just noticed that I create U and V before A and B so that might be the end stop issue. I'll swap and report back.....

                                            Ian
                                            https://somei3deas.wordpress.com/
                                            https://www.youtube.com/c/deckingman/

                                            1 Reply Last reply Reply Quote 0
                                            • deckingman
                                              deckingman last edited by

                                              Latest update. Creating axis in the correct order seems to have fixed the end stop recognition issue. So this in config.g works

                                              M584 X0:3 Y1:4 Z2 U10 V11 A6 B9 E5:7:8 P3;

                                              All I'm left with now is that the A and B axes move diagonally using a single motor, rather than in X and Y using both motors. i.e Cartesian rather than CoreXY kinematics. So close....

                                              Ian
                                              https://somei3deas.wordpress.com/
                                              https://www.youtube.com/c/deckingman/

                                              wilriker 1 Reply Last reply Reply Quote 0
                                              • wilriker
                                                wilriker Moderator @deckingman last edited by

                                                @deckingman What happens if you swap

                                                M584 X0:3 Y1:4 Z2 U10 V11 A6 B9 E5:7:8 P3
                                                

                                                by

                                                M584 X0:3 Y1:4 Z2 A6 B9 U10 V11 E5:7:8 P3
                                                

                                                (A and B defined before U and V)? Will this make the extruder gantry act as Cartesian and have the counter-weight gantry move correctly?

                                                Manuel
                                                Duet 3 6HC (v0.6) with RPi 4B on a custom Cartesian
                                                with probably always latest firmware/DWC (incl. betas or self-compiled)
                                                My Tool Collection

                                                deckingman 1 Reply Last reply Reply Quote 0
                                                • deckingman
                                                  deckingman @wilriker last edited by deckingman

                                                  @wilriker That's what had at first - see post one before my last timed at 10:41. I still had the Cartesian axis movement (for A and B) but also, the endstop switches weren't being acted on correctly.

                                                  Edit. The extruder gantry (U and V) still acted correctly as CoreXY.

                                                  2nd Edit It's kind of coming back to this thread https://forum.duet3d.com/topic/6677/corexyuvwa

                                                  Do you think making the axes W and A rather than A and B would help? It used to be necessary to create them in that order but I believe that later firmware doesn't care. Just wondering if there is something in the firmware left over from how it used to be that shouldn't be there.....

                                                  Ian
                                                  https://somei3deas.wordpress.com/
                                                  https://www.youtube.com/c/deckingman/

                                                  wilriker 1 Reply Last reply Reply Quote 0
                                                  • wilriker
                                                    wilriker Moderator @deckingman last edited by

                                                    @deckingman Honestly, I checked the source code again and I have no clue how an endstop is assigned to an axis at all. I found the code where the endstop is setup per axis but I have yet to find the place where it looks for a specific endstop for a given axis.

                                                    Anyway, while I am hunting this part down (and I have an idea where to look for) I have another question: I have something in the back of my mind, but not sure anymore. Do you switch at any point (after homing) to CoreXY mode? Also once you assigned all three steppers to X/Y do they move correctly i.e. A/B also act like CoreXY kinematics?

                                                    Manuel
                                                    Duet 3 6HC (v0.6) with RPi 4B on a custom Cartesian
                                                    with probably always latest firmware/DWC (incl. betas or self-compiled)
                                                    My Tool Collection

                                                    JoergS5 deckingman 2 Replies Last reply Reply Quote 0
                                                    • JoergS5
                                                      JoergS5 @wilriker last edited by JoergS5

                                                      @wilriker An endstop code is in Movement\Kinematics\CoreBaseKinematics.cpp

                                                      If the drive is shared, in CoreXYKinematics.cpp the method DriveIsShared returns true, which is evaluated in the CoreBase file.

                                                      The OnHomingSwitchTriggered method is called from Movement\DDA.cpp line 1595 in the v2-dev branch. It is called when an endstop is hit.

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