1HCL Brake delay

HighFreq

I am having a problem with 1HCL. Between brake release and power to the z axis it takes few tenths of a second wich are enough for my axis to go down few cm. Is there a way to not have any delay between brake release and power apply to motors? Or even better apply power than release the brakes.

dc42

@highfreq I am surprised that you are experiencing a problem when powering up the machine, because the motors should energise immediately whereas the brake is mechanical and so takes some time to release. Are you using the M17 command to power up the Z motors?

We are aware then when M18 is used to turn the motors off it may take the brake a little while to engage, so we are looking at introducing a delay in RRF 3.5.

HighFreq

@dc42 this is my config for z axis:

; Output ports
M950 P5 C"io5.out" Q0
M950 P6 C"io6.out" Q0
M950 P7 C"io7.out" Q0
M950 P8 C"io8.out" Q0

; Z Encoders
;M569.1 P1.0 T2 C5 R150 I20000 D0.9
M569.1 P1.0 T2 C5 R100 I8000 D0.1;PID asse Z
M569.1 P2.0 T2 C5 R100 I8000 D0.1
M569.1 P3.0 T2 C5 R100 I8000 D0.1
M569.1 P4.0 T2 C5 R100 I8000 D0.1

; Drives
M569 P1.0 D4 S0 ;direzione e closed loop asse Z
M569 P2.0 D4 S0
M569 P3.0 D4 S0
M569 P4.0 D4 S0
M569 P1 S0 T2:2:0:0 ; asse Y
M569 P0 S0 ; asse X
M569 P10.1 S1 ; extruder motor
;M917 Z0 ;riduzione di corrente a motore fermo per asse
M584 X0 Y1 Z1.0:2.0:3.0:4.0 E10.1 ;mappa driver per ogni asse
M350 Z16 I1 ; configure microstepping with interpolation
M92 X200 Y200 Z320 E224.6 ; set steps per mm
M566 X10000 Y10000 Z60.00 U120.00 ; set maximum instantaneous speed changes (mm/min)
M203 X60000 Y60000 Z5000 U9000 ; set maximum speeds (mm/min)
M201 X10000 Y10000 Z200 U250.00 ; set accelerations (mm/s^2)
M906 Z6000 E2500 ; set motor currents (mA)
M84 S0 ; Disable motor idle current reduction

; Brakes
M569.7 P1.0 C"out1"
M569.7 P2.0 C"out1"
M569.7 P3.0 C"out1"
M569.7 P4.0 C"out1"

; Tuning
M569.6 P1.0 V1 ;polarity and zeroing
M569.6 P2.0 V1
M569.6 P3.0 V1
M569.6 P4.0 V1
;M569.6 P1.0 V2 ;spi encoder calibration
;M569.6 P2.0 V2
;M569.6 P3.0 V2
;M569.6 P4.0 V2

; Axis Limits
M208 X0:1000 Y0:1000 Z0:1500

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