Intended behaviour of stall detection during motion
-
Hi,
I am using RRF 3.4.2RC2 on a Duet MB 6HC.
I am using homing switches for homing, but would like to detect a stall with stallguard (M915) while moving on a cartesian XY.I expected the motion to stop as soon as a stall is detected,
but my experience is that many stalls are reported in a collision (with echo in driver-stall.g),
but the driver continues to drive to the target position (rattles strongly until the position counter reaches the target position).Is this intended behavior? Wouldn't it be good to stop in the middle of the movement as soon as a stall is detected (because obviously something went really wrong and position is lost anyway)?
-
@wiego you need to use the events system to tell it what to do
https://docs.duet3d.com/en/User_manual/RepRapFirmware/Events -
@jay_s_uk thanks for the link, I understand it better now.
Nevertheless, as far as I understand it, the current movement is not and cannot be stopped by using these events.
It seems that the current movement continues to the end (even if it stalls and it clatters) because there is no command that can be executed in a macro/event (driver-stall.g) that stops the current movement in the middle, correct?
I want to stop the motion as soon as a stall is detected to avoid further damage.What is needed here is something like "M122 XY" that can be called in drive-stall.g that stops the current motion, ideally unhomes the drive and doesn't restart the board.
Or do you have any idea how to accomplish that with current features?
-
@wiego you could add segmentation to the moves using M669 (S and T values e.g. S1 T1). That will make pausing almost instantaneous rather than when the long move has completed.
-
@wiego If your aim is to avoid damage, then perhaps calling "emergency stop" M112 would be the best action, I think that should stop the current movement?
