1HCL error on no move

HighFreq

I had my z axis motors set a little on the low side for power, as a result today on a homing move only 3 out of 4 axis moved and the gantry was bent.
I was stunned by the fact that the 1HCL conneced in closed loop didn't throw an error since it knew the motor didn't move and the other 3 moved.
Is there something to configure to have an error whenever the board detect a non movement when there should be one?

T3P3Tony

@highfreq if you had them in closed loop mode then an event should have been generated:

https://docs.duet3d.com/en/User_manual/RepRapFirmware/Events

dc42

@highfreq what firmware versions are you running on the main board and on the 1HCL ?

HighFreq

@dc42

Firmware:

Duet EXP1HCL firmware version 3.4.1 (2022-06-01 21:14:32)

RepRapFirmware for Duet 3 MB6HC version 3.4.1 (2022-06-01 21:09:01) running on Duet 3 MB6HC v1.01 or later (SBC mode)

No event were generated when 1 axis of the 4 z axis didn't move.
They are all working in closed loop.
If an axis with an encoder in closed loop attached doesn't move when it should i think the machine should throw an error and stop.
As it is now the 3 working axis keep on going and the gantry gets badly bent.

What i mean is really basic control, if an axis should move and the encoder says it is not than stop the machine and throw an error, why doesn't do it?

Thanks

dc42

@highfreq I will re-test the event generation from the 1HCL and the event handling when the requested movement is not achieved.

HighFreq

@dc42 Thank you very much, will look forward to your findings. An option to immediately stop the machine on error would be great.

HighFreq

@dc42 Did you have a chance to test it?

HighFreq

@dc42 can you please let me know if you tested the feature on the 1HCL?

I am asking because sometimes it happens that 1 out of 4 of my z axis do not start and duet doesn't realize and keeps going bending my gantry.

dc42

@highfreq this is on my list to investigate tomorrow.

HighFreq

@dc42 great, thank you very much!!

dc42

@highfreq I have tested this using firmware 3.4.3rc3. I suspect this issue you are having is to do with the error thresholds set in the M569.1 command E parameter. These are not well documented. In particular, they currently default to zero, which means don't report failures to maintain position.

If I set them to nonzero values (for example E0.5:1.0) then I find that failures to maintain position are reported as expected.

The units of the E parameter are full motor steps. You will need to experiment to determine what are the lowest values you can use without spurious errors being reported.

I will update the documentation.

HighFreq

@dc42 Thank you very much, will test.

dc42

@highfreq I'm sorry it has taken me so long to investigate this. We have a lot of development ongoing, some of it hardware redesign to work around component shortages.

HighFreq

@dc42 Do i need to update to 3.4.3 rc3 ??? Or it should work on 3.4.1 stable?

dc42

@highfreq AFAIR there is nothing in 3.4.2 that would change that behaviour from 3.4.1.

HighFreq

@dc42 we investigated a little in the direction you pointed us and solved the problem. It wasn't reporting alerts on position errors, now it does and we can handle them and do what we need when it happens.

Thank you very much.