1HCL error on no move

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