Spindle immediately turns off on error

[wackyfrog]

I have configured duet to CNC mode:

M453 C"fan2+exp.heater4" Q1 R1

(I use 'fan2' pin to control spindle power relay, and pin heater4 not for real PWM control, but for the reason that only on / off control cannot be specified).

The problem is that the spindle shuts down immediately if move accidentally goes out of range - on error "G0/G1 target position outside machine limits".
And machine after that doing some movements (i suppose it depends on buffer), instead of stops all movements further.

On this error, no scripts are executed (neither stop.g, nor cancel.g or other).

Due to the fact that the power is cut off, there is a high probability of damage to the cutter. My temporary workaround is to remove the spindle control from the M453 (without C param) and use M42 command to control spindle instead of M3/M5 commands :(. Thus, in the event of an error, the spindle simply remains switched on inside the workpiece.

Is it possible to execute script stop.g on such errors ? It is necessary to somehow find out that the work was interrupted and canceled. An emergency stop in this case would be better than just stopping all job.

Info:
Board: Duet 2 WiFi (2WiFi)
Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.1.1 (2020-05-19b2)
Duet WiFi Server Version: 1.23

[A Former User]

@adegtiar said in Spindle immediately turns off on error:

G0/G1 target position outside machine limits

thats gonna be a problem regardless, why not focus on avoiding it all together?

[wackyfrog]

The main reason - safe machining, and catch all inconsistent operations. I have power outage sensor, connected to spindle and the trigger for it:

if job.file.fileName=null
	echo "KRESS tool has been UNPOWERED."
	T-1
else
	echo "Power lost. Emergency stop."
	M112

When I turn off spindle manually – it is just reports that tool is unpowered. But in case of movement error, the trigger raises after job was canceled and can't catch this for safely up Z axis or for immediately stop all machine (like M112).

Look at the screenshoot: first, the execution of the hob canceled, then the power failure trigger was triggered, and only then an error message appeared.

IMO, in the event of a positioning error, stop everything immediately, but do not execute the remaining commands in the buffer.

[dc42]

Stopping all commands in the buffer could lead to a positioning error. Alternatively, I can have the spindle kept on until the buffer is empty. Would that be acceptable?

[A Former User]

@adegtiar said in Spindle immediately turns off on error:

The main reason - safe machining, and catch all inconsistent operations

Yes, so try to catch it in CAM simulation instead of on the Duet? I.e. avoiding it all together.

[dc42]

Or run it on the Duet in simulation mode?

[wackyfrog]

@dc42 said in Spindle immediately turns off on error:

Stopping all commands in the buffer could lead to a positioning error. Alternatively, I can have the spindle kept on until the buffer is empty. Would that be acceptable?

Yes, this will solve the problem of a broken cutter due to movement with the spindle off.

But, Is it possible to catch the error event to run a script to handle the situation? Is it possible to determine that the last job failed? I would like to determine (inside trigger handler) whether it was done manually (canceled) or as a result of an error ? The trigger fires when machine state is idle.

[dc42]

@adegtiar said in Spindle immediately turns off on error:

But, Is it possible to catch the error event to run a script to handle the situation? Is it possible to determine that the last job failed? I would like to determine (inside trigger handler) whether it was done manually (canceled) or as a result of an error ? The trigger fires when machine state is idle.

I guess I could add a "last job finish status" value to the object model.

[wackyfrog]

@bearer Cam simulations is OK. Out of bounds of coordinates occurred due to the incorrect WCS (a few mm was insufficient).

[wackyfrog]

@dc42 Good idea! But in order to correctly interpret when it happened (just) or a long time ago, it would be good to either reset this status on request (for example, after processing inside a trigger) or so that the last status has the time of the event, how long ago it happened at the time of its reading. Just for example:

if {job.lastPrintStatus='some failure code'} && {job.lastPrintStatusAge < 10} ; react if it is a 'fresh' event, not older 10 seconds (or a couple seconds  would be enough for process)
     echo "Last recent job failed";

; proposition for event age value
; if this code executes just after error event
echo {job.lastPrintStatusAge} ; will be 0 sec
G4 S1.0
echo {job.lastPrintStatusAge} ; will be 1 sec
G4 S10.0
echo {job.lastPrintStatusAge} ; will be 11 sec

[rzi]

Maybe a parameter to the M453 command to set if it should be affected by an error or not.

[wackyfrog]

@dc42 Hi, David! Any progress ?

[dc42]

Not yet, but it's on the list for possible inclusion in the 3.2 release.