Unsolved need help configuring stall detection please

[benecito]

Anyone any ideas? Help would be greatly appreciated!

[jay_s_uk]

@benecito see here https://docs.duet3d.com/en/User_manual/RepRapFirmware/CAN_limitations
Stalls of expansion board motors cannot be used for homing. We expect to remove this restriction in firmware 3.6.

[benecito]

@jay_s_uk I'm not trying to use it for homing. I am trying to implement a background stall detection to prevent crashes.

[jay_s_uk]

@benecito have you checked with M915 to make sure those parameters are being set?
Could also try using the axis name rather than the driver number

[benecito]

@jay_s_uk I did and it should be working. At least I don't see anything obvious.

M915
Driver 0.0: stall threshold -50, steps/sec 200, coolstep f, action on stall: run macro
Driver 0.1: stall threshold -50, steps/sec 200, coolstep f, action on stall: run macro
Driver 0.2: stall threshold -50, steps/sec 200, coolstep f, action on stall: run macro
Driver 0.3: stall threshold -50, steps/sec 200, coolstep f, action on stall: run macro
Driver 0.4: stall threshold 1, steps/sec 200, coolstep 0, action on stall: none
Driver 0.5: stall threshold 1, steps/sec 200, coolstep 0, action on stall: none
Driver 0.6: stall threshold 1, steps/sec 200, coolstep 0, action on stall: none

[dc42]

@benecito currently stall detection other than homing is only activated when running a job from SD card. I think you may be printing via USB - is that correct?

This policy was already changed in RRF 3.5.0-beta.4 to allow stalls to be detected at all times. Have you tried that version?

We've made the same change to RRF 3.4.6.

[benecito]

@dc42 Is this documented anywhere? I will try it running 3.5.5-beta.4 ASAP and report back

[benecito]

@dc42 just tried it and yes it works. But am I getting it right, that there is no way to terminate / pause / whatever the current move?

Trying to figure out what we can do so we can start developing a plan how we are going to implement it.
Also is it possible to use "regular" homing and stall homing together so we can end a homing move should the head i.e crash into a print or so?

[dc42]

@benecito no I don't think it was mentioned in the main documentation. We'll correct that.

[benecito]

@dc42 so basically there is neither a way to i.e. abort a longer printing move on a stall nor a way to i.e. cancel a failing homing move?

In my opinion this is 7 would be one of the main benefits of stall detection. Are there any plans to change this behavior or is it even possible?

[dc42]

@benecito as I said before we changed the behaviour already, in both the 3.4 and 3.5 branch source code. The published 3.4.6-rc1 release already contains this change. I can also provide you with a 3.5.0-beta4+ build containing the change if you wish.

[benecito]

@dc42 Then I'm sorry, I got your answer wrong.
a 3.5.0-beta4+ build (for SBC) would be great so we can continue working on it and get it just right for the 3.5.0 stable.

[dc42]

@benecito please try the new Duet 3 Mini firmware at https://www.dropbox.com/scl/fo/sj9kuloenbp6e70asnxue/h?rlkey=upykfuquc574l61deqwo94xr3&dl=0. Caution, this firmware has undergone minimal testing.

[benecito]

@dc42 Thanks! I just installed it and I can still see the event being created but still looking for a way to cancel the current move except for an emergency stop, which I think is a bit radical in that case. M99 exits the driver-stall.g file but not the homing routine.

[dc42]

@benecito I'm sorry, there isn't yet a mechanism to cancel the current move other than emergency stop. We have "feed hold" on our list to implement in RRF 3.6.

[benecito]

@dc42 thats a bit unfortunate but we'll try to make something work for now.
Will feed hold work with external (USB) printing?