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

    6XD not moving the steppers unless I re-send M569 command

    Scheduled Pinned Locked Moved Solved
    Duet Hardware and wiring
    3
    13
    303
    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.
    • ComedianTF2undefined
      ComedianTF2 @T3P3Tony
      last edited by

      This post is deleted!
      1 Reply Last reply Reply Quote 0
      • ComedianTF2undefined
        ComedianTF2 @ComedianTF2
        last edited by

        After further testing, it seems that sending a small move command, after which sending the M569 command seems to enable them reliably.

        At the bottom of the config.g I've added a M98 command calling for motor_enable.g, with the contents below

        M98 P"motor_enable.g" ; enable motor at boot

        M564 H0 S0					; allow unhomed moves + moves out of min/max area. Only for testing. Remove later on
        G91 						; relative moves
        G1 X0.1 					; move 0.1mmm
        G1 Y0.1 					; move 0.1mmm
        G1 Z0.1						; move 0.1mmm
        M569 P0 S0 R1 T2:2:5:2.5	; X axis, Drive 0, active high enable, 2us minimum step pulse, 2 us minimum step interval, 5us DIR setup time and 5us hold time
        M569 P1 S0 R1 T2:2:5:2.5	; Y axis
        M569 P2 S0 R1 T2:2:5:2.5	; Z axis
        M564 H1 S1 				; re-enable safety stuff
        
        T3P3Tonyundefined 1 Reply Last reply Reply Quote 0
        • T3P3Tonyundefined
          T3P3Tony administrators @ComedianTF2
          last edited by

          @ComedianTF2 which version of firmware are you running?

          I am not sure if this is something strange about how those motors behave or an issue with firmware.

          www.duet3d.com

          ComedianTF2undefined 1 Reply Last reply Reply Quote 0
          • ComedianTF2undefined
            ComedianTF2 @T3P3Tony
            last edited by

            @T3P3Tony it's on 3.5.4

            T3P3Tonyundefined droftartsundefined 2 Replies Last reply Reply Quote 0
            • T3P3Tonyundefined
              T3P3Tony administrators @ComedianTF2
              last edited by

              @ComedianTF2 do you have access to a scope or logic analyser? It would be good to understand if the enable and step lines are behaving as expected after the first M569, i.e it's an issue with those drivers, or not

              www.duet3d.com

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

                @ComedianTF2 The M569 command shouldn't enable the drivers, only configure them. Only sending M17, or sending a motor move, should enable the driver. You should be able to send M569 commands as often as you like after running config.g, and the driver should not enable. At least, that's what happens on the Mini 5+ I have here. Unfortunately I don't have a 6XD to test. You can send M569 P0 to check how the each driver output on the 6XD is configured.

                How have you wired the stepper driver? I assume you have wired the EN+ from the driver to +5V on the 6XD, and EN- to D0 EN- on the 6XD, as shown here https://docs.duet3d.com/Duet3D_hardware/Duet_3_family/Duet_3_Mainboard_6XD_Hardware_Overview#connecting-external-motor-drivers. How is the 'Driver Enable Polarity' (En_Pol) jumper set?

                In the table, it says

                Drive initial time 2 - - s

                The 'Drive initial time' of 2 seconds might be the reason that enable appears to be delayed. Try sending M17, wait 2 seconds, then a move. The manual also says:

                The 4-28V signal level is used for protection of pulse, direction and enable.

                It's possible that it's not reliably picking up the enable signal, which is 5V from the 6XD. Check your wiring. If you disconnect the enable wires, the driver should be enable at power on, and be enabled the whole time, which might be easier.

                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

                ComedianTF2undefined 1 Reply Last reply Reply Quote 0
                • ComedianTF2undefined
                  ComedianTF2 @droftarts
                  last edited by

                  @T3P3Tony

                  I will be able to check that in January, once I'm back from holidays

                  @droftarts

                  Same, will test it out in January once I'm back. The wiring I've done per the guide you've shown. I had missed the driver enable polarity jumper, so that's quite likely the issue there.

                  With re-sending the commands we were able to get the printer up and running, and the printer has completed a successful print, though hopefully we won't need to use the driver_enable.g file I used before with the fixes recommended.

                  Thanks both for the help, I'll enjoy the Christmas break for now and get back to it in Jan

                  T3P3Tonyundefined 1 Reply Last reply Reply Quote 0
                  • T3P3Tonyundefined
                    T3P3Tony administrators @ComedianTF2
                    last edited by

                    @ComedianTF2 do you have an update on this?

                    www.duet3d.com

                    ComedianTF2undefined 1 Reply Last reply Reply Quote 0
                    • ComedianTF2undefined
                      ComedianTF2 @T3P3Tony
                      last edited by

                      @T3P3Tony @droftarts

                      The 'Driver Enable Polarity' (En_Pol) jumper was on the left position, set to GND

                      Flipping the M569 R value from R1 to R0 fixed the issue. I think that by re-sending the M569 values, it basically sent the drive enable command to 0, which then allowed things to work.

                      Thanks for the support, I read the post and thought I had tested the R value inversion, but for some reason I must have done that testing incorrectly before, which caused me to not look at it properly until now.

                      T3P3Tonyundefined 1 Reply Last reply Reply Quote 1
                      • T3P3Tonyundefined
                        T3P3Tony administrators @ComedianTF2
                        last edited by

                        @ComedianTF2 glad you have resolved it.

                        www.duet3d.com

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