How should the firmware respond to a heater fault?
-
Continued my a dig around and thought to check the 1.20 release notes on the following link.
https://github.com/dc42/RepRapFirmware/blob/dev/WHATS_NEW.md
This has the comment:
"When a heater fault occurs, the print is now paused and all heaters are turned off except bed and chamber heaters. After a timeout period, the print is cancelled, all remaining heaters are turned off, and the firmware attempts to turn the power off as if M81 had been received."
I am guessing this timeout value is the timeout mentioned to cancel a print:
"Heater fault timeout to cancelling print is now configurable (M570 S parameter, in minutes)"
Why does the gcode reference refer to the M570 as the time in seconds the heater has to reach a set temperature before a fault was raised in seconds? From the release notes I was expecting M570 to be time in minutes after a fault before a build is cancelled and M81 called?
https://duet3d.dozuki.com/Wiki/Gcode#Section_M570_Configure_heater_fault_detection
-
I like the sequence.
-
Something i would like:
The Error message is not very clear..had 1 week ago a heater fault every large print. Bed shut off ( thats bad because i use a Ultrabase so the print popped off when bed is cold) but i cant tell where exactly was the problem..would be fine if you can read the temp chart because..if temp dropped 100° within a sec its clearly the thermistor..if temp drops more slowly its the heater cartridge.
Btw..that black plugs on Smart effector sucks. only small chance to get a faulty pin out of the plug housing. Wished we had there the other plugs too
-
@barracuda72 Step 3 would leave bed ON, therefore covering your use case.
In general I would replace the step 6 by a "Macro" (something like on heaterfault0.g). This macro could include the actions as described on M81 or be configured by the user to its preferences.
It is not the same a heater fault on the Bed than a heater fault on the nozzle. The basic security steps could cover any failure modes, but a macro associated to the heaters would be the more flexible option and would give room for improvements without further code changes required. Something like the Toolchange macros for each defined tool. -
I like the idea of replacing the sequence of steps with a macro or macros. That is in line with the general RepRepFirmware philosophy. We can have the current behaving in the macro(s) as a default so no change is noticed unless someone wants to change their macros.
(also p.s. zombie thread revival!)
-
@t3p3tony said in How should the firmware respond to a heater fault?:
(also p.s. zombie thread revival!)
Ish. I was asking about the current implementation of the feature as it isn't clear from the release notes and the release notes don't tally with the duet g-code documentation.
-
@t3p3tony
replacing the sequence with a macro could be dangerous:
Assuming a faulty / detached thermistor, if someone made an incorrect / empty heaterfault.g file, which would not turn off the faulty and eventually all heaters, it would quite probably cause a fire ... IMHO some safety features should never be modified by mere mortals / end users...Plus if I'm correct quite a few functionality is missing to implement this .... the gcode would have to receive props (variables / constants) for this (describing the faulty heater) and accept variables / constants as parameters to be able to turn only the faulty heater off... and there is the problem of the timeout also to turn all heaters off at the end... This timeout should be able to be interrupted and not execute the code to turn all heaters off, if the heater fault is cleared....
So:
Function defining
variable handling
variable passing
reference passing
conditional execution ( if ... else )
loops, (iteration ... it is not structly required, but its absence makes the code ugly)function heaterfault (*heaterFault, faultyHeater, allHeaters) {
heater_off(faultyHeater);
cnt = 3600;
while (cnt -- > 0 && *heaterfault == true) {
sleep 1;
};
if (*heaterfault == true) {
for (heater, allHeaters) {
heater_off(heater);
};
};
};The code is very incomplete, it just serves to illustrate he scope of the task...
-
possibly we can get part of the way by having a macro for a heater fault on each heater, but i take you point about a user misconfiguring it. its a trade off between usability in some cases against people misconfiguring something where the defaults are sensible.
-
Can some one please clear up my question regarding the difference between the release notes and the wiki?!
Regards safetys I can't see why it shouldn't be simple. Safe as possible by default with the option to opt out if required. Make this clear in the release notes and we should only have a few months of posts questioning why things aren't working like the recent no move before homing!
-
@t3p3tony
My opinion is that the end user should never have the freedom to set his/her equipment and consequently his/her house on fire however neglegant / short sighted he/she may be. -
My take on it, would be that any heater fault detected, should imediately re-set the printer thereby disabling all sources of heat generation i.e. bed & heater cartriges and motors.
My own recent experience of a Simplify3D remote USB print failing, hours into the print, the hot end heater stopped, but the bed & motors carried on as if nothing had happened.
I realise that being remotely driven the Web interface would not know about the print, but the Duet board had detected & raised the problem, but to my mind, didn't cleanly shut down the printer.
2 penneth
-
@dr_ju_ju said in How should the firmware respond to a heater fault?:
My take on it, would be that any heater fault detected, should imediately re-set the printer thereby disabling all sources of heat generation i.e. bed & heater cartriges and motors.
If a mosfet fails open (e.g. heater on) then a controller reset will not prevent heating - what you ideally want is a digital IO to a kill switch, cutting the mains power.
