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

    4x Z motors moving different amounts for one Z command

    Scheduled Pinned Locked Moved Solved
    Duet Hardware and wiring
    4
    13
    333
    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.
    • jay_s_ukundefined
      jay_s_uk @michaelr123
      last edited by

      @michaelr123 i guess it doesn't like Z being spread across boards.
      My advice would be move all the Z to the 6HC and move either the X or Y to the 3HC

      Owns various duet boards and is the main wiki maintainer for the Teamgloomy LPC/STM32 port of RRF. Assume I'm running whatever the latest beta/stable build is

      michaelr123undefined 1 Reply Last reply Reply Quote 0
      • michaelr123undefined
        michaelr123 @jay_s_uk
        last edited by michaelr123

        @jay_s_uk

        Problem is that I’ve got 4x motors on the x and y for an awd setup. I don’t want to run into the same issue on my gentry system either.

        Here’s an idea, what if I do 2x X motors on the 6HC and 2x Y motors on the 3HC? Then keep all the z motors together on the 6HC?

        Any body that’s done an AWD setup have any input here?

        jay_s_ukundefined 1 Reply Last reply Reply Quote 0
        • jay_s_ukundefined
          jay_s_uk @michaelr123
          last edited by

          @michaelr123 that's what I said. Move either the X or Y to the 3HC.
          I've done 4WD but I was running a board with 8 driver sockets and only needed 1 z

          Owns various duet boards and is the main wiki maintainer for the Teamgloomy LPC/STM32 port of RRF. Assume I'm running whatever the latest beta/stable build is

          michaelr123undefined 1 Reply Last reply Reply Quote 1
          • michaelr123undefined
            michaelr123 @jay_s_uk
            last edited by michaelr123

            @jay_s_uk

            Seems to be working well now, thanks for the recommendation!

            Unfortunately, sensorless homing isn't working now. I can home to Y no problem, but when I home to X it will not trigger as an endstop. If I turn on R1 parameter it's definitely reading that motors are stalling. Is there any chance I have the X and Y motors flipped and backwards or something like that and the sensorless endstop is looking for stalls on the wrong motors? Or does S4 on a corexy look at all the X and Y motors?

            ; Endstops
            M574 X1 S4 ; setting up sensorless homing
            M574 Y1 S4 ; setting up sensorless homing
            M915 X Y R0 F0 S3

            jay_s_ukundefined 1 Reply Last reply Reply Quote 0
            • Phaedruxundefined
              Phaedrux Moderator
              last edited by

              Firmware version?
              Can you post your full config and homing file?

              Z-Bot CoreXY Build | Thingiverse Profile

              michaelr123undefined 1 Reply Last reply Reply Quote 0
              • michaelr123undefined
                michaelr123 @Phaedrux
                last edited by michaelr123

                @Phaedrux

                3.4.6 all the way through.

                Yep can do:

                homey.g homex.g config.g

                1 Reply Last reply Reply Quote 0
                • jay_s_ukundefined
                  jay_s_uk @michaelr123
                  last edited by

                  @michaelr123 I don't think sensor less works with expansion boards yet
                  https://docs.duet3d.com/en/User_manual/RepRapFirmware/CAN_limitations#temporary-limitations

                  Owns various duet boards and is the main wiki maintainer for the Teamgloomy LPC/STM32 port of RRF. Assume I'm running whatever the latest beta/stable build is

                  michaelr123undefined 1 Reply Last reply Reply Quote 0
                  • michaelr123undefined
                    michaelr123 @jay_s_uk
                    last edited by

                    @jay_s_uk

                    ahhh that's definitely what it is. So the motors on the expansion board aren't being red as an endstop... Any chance 3.5 is adding that feature?

                    Might have to using one wire on the gantry for endstops after all...

                    jay_s_ukundefined 1 Reply Last reply Reply Quote 0
                    • jay_s_ukundefined
                      jay_s_uk @michaelr123
                      last edited by

                      @michaelr123 looks like it's planned for 3.6

                      Owns various duet boards and is the main wiki maintainer for the Teamgloomy LPC/STM32 port of RRF. Assume I'm running whatever the latest beta/stable build is

                      michaelr123undefined 2 Replies Last reply Reply Quote 0
                      • michaelr123undefined
                        michaelr123 @jay_s_uk
                        last edited by

                        @jay_s_uk

                        Gotcha,

                        I tried moving 2 z motors back to the HC3 so I could get the 4 XY motors on the 6HC. Sensorless homing works great and after power cycling the board I'm not getting the weird behavior where one set of of Z motors moves at a different rate than the other two. It's definitely something going on over the CAN connection as I saw 2 motors display the weird behavior instead of just the one.

                        I'll keep running it this way so I can avoid the extra wire 🙂

                        1 Reply Last reply Reply Quote 0
                        • michaelr123undefined
                          michaelr123 @jay_s_uk
                          last edited by

                          @jay_s_uk

                          Update on this, it seems like anytime you change config code that affects the endstops or the drive mapping you get this weird behavior when you just run the config file. If you completely reset the board or power cycle it everything behaves just fine.

                          Long story short you can run 4x Z motors split across a can connection, but you need to fully power cycle between config updates.

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

                            @michaelr123 Remember that running config.g does not reset things back to the default state before you run it. So anything that you do not explicitly set in the config.g will just keep whatever setting it may have had before you ran the config.g. Some commands may also not execute correctly (for instance if you had already assigned a pin in the old config.g, it may not be free if you try to use it for some other purpose in the new config.g). Personally I always reset things when making changes to config.g, just to be sure.

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