1HCL Brake delay

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.

dc42

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

HighFreq

@dc42 will try and let you know.

thank you.