Heater Fault handling improvements

OwenD

@wdenker said in Heater Fault handling improvements:

@t3p3tony correct it paused for a limited time and then the print is gone. It just needs to stay paused indefinitely. I think the time limit is like 5-10 minutes but I'm only checking the printers once every 5-6 hours.

An indefinite pause, is in my mind a dangerous situation when you have a heater fault.
If you're getting heater faults then essentially you have a tuning or hardware problem (if caused by a fan).
However, it's not hard to implement some code to notify you of a fault and allow you to act before RRF shuts off the printer.
Something like this in daemon.g should work.
If you want it to run at intervals less than 10 seconds, put the whole thing a while true loop.

;create a global to stare how meany heaters are in error state
if !exists(global.HeaterErrorCount)
	global HeaterErrorCount=0
else
	set global.HeaterErrorCount==0
	
; loop through al heaters and check state for fault
while iterations < #heat.heaters
	if heat.heaters[iterations].state=="fault"
		set global.HeaterErrorCount==global.HeaterErrorCount+1
		
;if any heater is in error state, sound an alarm	
if global.HeaterErrorCount>0		
	M42 P6 S1 ; turn on GPIO connected to alarm relay
	; do some more code to send a text, flash a light or whatever
else
	M42 P6 S0 ; turn off GPIO connected to alarm relay

You could also investigate BtnCmd and the other plugins which have the ability to use HTTP Post, or MQTT to send you a notification.

wdenker

@owend I don't see how an indefinite pause would be dangerous the heater is turned off that has faulted. Which gives me time to fix the issue at hand and continue where it left off.

OwenD

@wdenker
We'll have to agree to disagree...
The reason I see it as a dangerous move is that you have no way of knowing what caused the fault code, or how serious it is. Especially in the five hour timeframe you quote.
For example, if it's a heater runaway, then in it's possible the heater can't be shut down.
That's why RRF also calls M81.
Now if you have a thermal fuse and other hardware safety features, perhaps you can take the risk.
In any case, if the above code doesn't allow you to react in the timeout allowed before forced shutdown then you'll need to continue arguing the case for a configurable option to ignore the fault.

wdenker

@owend of it was stuck on because of a hardware fault shutting down the board wouldn't resolve it either.

OwenD

@wdenker said in Heater Fault handling improvements:

@owend of it was stuck on because of a hardware fault shutting down the board wouldn't resolve it either.

M81 is called to allow the power supply to the heater(s) to be turned off.
So if your system is configured with proper safety in mind, then yes, it will resolve the problem in most cases.
I guess frozen duet would be the exception, but then you wouldn't have a heater fault problem either

wdenker

@owend so when I say pause I mean after the heater is turned off. So that I can repair the issue and then bring temp back and continue. The only thing I don't like about the current setup is that it times out after so long to where you can't recover.

T3P3Tony

@wdenker what is your M570 command set to?
https://duet3d.dozuki.com/Wiki/M570
You can use the S parameter to set a number of minutes between a heater fault and the subsequent cancellation (and power off)

Snnn Integer timeout in minutes (can be set to 0) for print to be cancelled after heater fault (Firmware 1.20 and later). If the S parameter timeout occurs (which only happens if a SD print is in progress), RRF will also try to turn off power via the PS_ON pin.

wdenker

@t3p3tony I don't have one didn't even realize I could configure that. How new is this?

T3P3Tony

@wdenker its been around in some form since RRF 1.14

zapta

@t3p3tony said in Heater Fault handling improvements:

@wdenker its been around in some form since RRF 1.14

That's only 2.16 versions ago.