M915 stall detection for emergency stop? And emergency stop.

gratgrat27

Hi,

My configuration is a duet2 board with rep-rap 3.3 on a workbeeZ1+.
I'm trying for a while to have an emergency stop that is not waiting for buffered moves to finish, AND offers a resurect file generation (or at least stop index of SD file interupted)

Could M915 does that ? After what I red I understand that it won't be efficient at high speeds, and not necessary reliable, not sure if the stop comes before or after the buffered moves.

More in details, because I sometime run 24h roughings and more for finishings (you can see my creations at BoisEtReliefs on etsy if you like!), I had spindle stop, coal used, wire cutted, etc leading the workbee moving 3mm deep with ½ inch tool not turning... and that for 30 minutes the first time, the nightmare.

I now use a real time current check arduino module with trigger T1 to pause but the buffered moves take sometimes long time before the stop especially for the 1m straight cut of the beginning of some creations, and I recently broke a tool.
So if M915 is instantaneous, and offers a saving point it would be gold for me!
By the way, is it possible to use trigger T0 (instantaneous M112 stop) and create a resurect file, or any restarting point save?

Otherwise I will go for a dedicated relay on power supply associated with the arduino module.

Thanks a lot.
Alex

jay_s_uk

@gratgrat27 add segmentation
M669 S1 T1 or similar. That will break long moves up, allowing you to pause etc a lot quicker

gratgrat27

Oh that's a really good tip thank a lot Jay

gratgrat27

Well I tried adding M669 S0.1 in the user setting file but nothing changed.

T parameter sets the minimum segment length and I want to reduce it so I didn't use it.

gloomyandy

@gratgrat27 Did you try the settings that Jay suggested? Unfortunately I think you need a later version of RRF to have M669 with no parameters to report the current segmentation settings, which would be useful to check what is actually being set.

gratgrat27

M669 did gave me the actual settings.

The segmentation matrix has not been modified by M669 S0.1, nether by M669 S0.1 T1
In case the value was not acceptable, I also tried M669 S2 T2 that also had no effect.

Any idea of a better place for the command?
Should I update to RRF 3.5?

gloomyandy

@gratgrat27 Please post the output from running M669 without parameters after you have set M669 S1 T1.

gratgrat27

I had that matrix;

jay_s_uk

@gratgrat27 we aren't changing the matrix so those numbers in the output have nothing to do with it
Segmentation was added in 3.3 but it looks like you can't check it until 3.4

gloomyandy

@gratgrat27 Yep as Jay said, this tells you nothing. Later versions of RRF will include output of the form:

"2 segments/sec, min. segment length 1.5 mm"

Which will show you what (if anything) has been configured.

gratgrat27

@gloomyandy
ok i get that. I will update my firmware soon.

And how does that cut the segments?
In your example; "2 segments/sec, min. segment length 1.5 mm" are shorter segment than 1.5 mm kept or is it ignoring shorter moves?

droftarts

@gratgrat27 It depends to speed. Slow moves are more likely to be cut into segments by time, faster moves will be cut up by segment length. To calculate the number of segments in a move, the calculation is:
number_of_segments = min(moveLength/T_parameter, moveDuration/S_parameter)
This is rounded to the nearest integer and with a minimum of 1.

Ian

gratgrat27

@gloomyandy I now updated my firmware, M122 confirms with :
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.5.4 (2024-11-24 10:43:42) running on Duet Ethernet 1.02 or later

M669 answer is unchanged though;
Kinematics is Cartesian, no segmentation, modified matrix:
1.00 0 0 0
0 1.00 0 1.00
0 0 1.00 0

Thanks you again

Phaedrux

Have you set M669 S1 T1 in config.g first?