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

    1HCL Brake delay

    Scheduled Pinned Locked Moved
    Using Duet Controllers
    3
    25
    783
    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.
    • T3P3Tonyundefined
      T3P3Tony administrators @HighFreq
      last edited by T3P3Tony

      @highfreq if it works it would be a standard routine, at least until we change the firmware, on my machine with 1HCLs I only switch to closed loop mode after homing (which is done in open loop mode) so they are configured in config.g as open loop motors. The homing, tuning then switch to closed loop switch to closed loop and then tune, is handled in the homing files.

      www.duet3d.com

      HighFrequndefined 1 Reply Last reply Reply Quote 0
      • HighFrequndefined
        HighFreq @T3P3Tony
        last edited by

        @t3p3tony Ok, will try to close loop before homing, if it doesn't work will try to home in open than close and see if it'll work.

        thanks

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

          @highfreq i realised i got the order wrong in my previous comment because you have to be in closed loop mode to tune. either way the idea is to have the motors energised before switching to closed loop.

          www.duet3d.com

          HighFrequndefined 1 Reply Last reply Reply Quote 0
          • HighFrequndefined
            HighFreq @T3P3Tony
            last edited by HighFreq

            @t3p3tony we tested all all suggestion and still does it once every about 10 starts.
            In open loop it doesn't do it, when in closed loop there seems to be a delay between brake release and motor energize even if motor has been already energized using the method you adviced.

            For what i can see when it switches to closed loop there is a little bit of time where the brake is open and the motor not yet powered/energized.

            It does it without tuning too, it is the switch to closed loop itself that has something wrong.

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

              @highfreq thanks for reporting this. I will see if Ican reproduce it (my setup on X and Y does not have brakes)

              www.duet3d.com

              HighFrequndefined 1 Reply Last reply Reply Quote 0
              • HighFrequndefined
                HighFreq @T3P3Tony
                last edited by HighFreq

                @t3p3tony Our does it on z axis and has 4 motors, the gantry weights about 100kg, not easy to reproduce i guess.
                If you have any more suggestions or test to make please let know.

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

                  @highfreq I will look at the control signals coming from the board using a scope and see the timing between them 😄

                  www.duet3d.com

                  HighFrequndefined 1 Reply Last reply Reply Quote -1
                  • HighFrequndefined
                    HighFreq @T3P3Tony
                    last edited by

                    @t3p3tony This morning it did it in open loop too. Not as often as in closed loop but it does it in open too.

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

                      @highfreq it sounds to me that there are two issues:

                      1. When the motor is already energised and you switch from open loop to closed loop mode ready to perform tuning, there is a current drop that causes position to be lost if the motor is under load.
                      2. When you first energise the motor using M17 in open loop mode, occasionally there is a short delay between brake release and energising the motor.

                      Is this correct?

                      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

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

                        @dc42 From my point of view is difficult to make a distinction, all i see is that both in open and closed loop sometimes one or two of the z motors fall by about 100mm.
                        But your statements are correct, on those two occasions is when it happens.

                        We monitored the power output from power source and there isn't any voltage sag to justify what happens, so we think is a firmware related issue.

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

                          @highfreq I've built a version of the EXP1HCL firmware that adds a 50ms delay between enabling the driver and disengaging the brake when M17 is used, and a 100ms delay between engaging the brake and disabling the driver when M18 is used. Here it is:

                          Duet3Firmware_EXP1HCL.bin

                          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

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

                            @dc42 thanks, we tested but still have the same problem at random times. maybe it needs a bit more delay?

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

                              @highfreq when are these "random times" when the gantry drops: are they when you enable the motors, or when you disable them; or both?

                              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

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

                                @dc42 when we enable them.

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

                                  @highfreq I notice from the config.g file in your other thread that you enable the Z motor (and hence disable the brake) using a M17 Z E command in config.g. I think the problem may be that when this command is executed, the supply voltage has not been high enough and the EXP1HCL not running for for long enough for the motor driver to have finished initialising. Therefore, please try one of the following:

                                  • Either move the M17 Z command and the Z motor tuning commands to the start of the Z homing sequence;
                                  • Or insert a G4 delay command in config.g immediately before the M17 Z command. One or two seconds should be sufficient.

                                  If the driver has finished initialising by the time the M17 command is executed then I would not expect to need any delay between enabling the driver and releasing the brake, because the motor phases should be energised almost instantly whereas the brake will take a significant amount of time to release. It's different when powering down the motor because of the time that the brake takes to engage.

                                  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

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

                                    @dc42 will try and let you know.

                                    thank you.

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