1HCL Brake delay

dc42

@highfreq that looks OK to me. If you are not already using M17 Z in your homing files before you move the Z axis, please try it.

HighFreq

@dc42 it happens while running

M569.6 P1.0 V1 ;polarity and zeroing
M569.6 P2.0 V1
M569.6 P3.0 V1
M569.6 P4.0 V1

is it mandatory to run it at each start?

I think M17 has nothing to do with it, the problem occurs right after switching on, well before the homing of z.

dc42

@highfreq have you tried running M17 Z before that tuning code?

HighFreq

@dc42 tried now, it does the same.

dc42

@highfreq you could try configuring the driver in open loop mode initially, then use M17 to enable it, delay a short while, then switch to closed loop mode to run tuning.

HighFreq

@dc42 you mean as a standard routine when i start the machine or just once?

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.

HighFreq

@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

T3P3Tony

@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.

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.

T3P3Tony

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

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.

T3P3Tony

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

HighFreq

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

dc42

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

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.
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?

HighFreq

@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.

dc42

@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

HighFreq

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

dc42

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

HighFreq

@dc42 when we enable them.