Starting at firmware version 1.15, RepRapFirmware monitors the heater temperatures to check that they are behaving as expected. The purpose is to detect situations that might pose a fire hazard, such as a thermistor becoming detached mechanically from the heater block or bed, or a heater cartridge falling out. The downside of having this protection is that the firmware may mistakenly think there is a heater fault in certain situations such as excessive electrical noise picked up by a temperature sensor.
There are a range of reasons why a heater fault could occur however in all these cases the heater is shut down and a heater fault is raised:
How heater faults are handled after the heater is shutdown changed in RRF 3.4.0 with the introduction of the event system:
A mis-wired or failing temperature sensor can present as an out-of-spec reading, frequently an open circuit/short circuit reading. For example if the temperature sensor wire is breaking in a cable chain.
RRF allows and ignores a small number1 of out-of-spec readings (including apparent open and short circuit readings) from temperature sensors before it registers an error, shuts down the heater and raises a heater fault. This is managed by the heater control task on the board that the heater is connected to.
After the immediate action of raising a fault and shutting down the heater, what happens next depends of the firmware version (see event system section above).
Notes:
RRF prior to 3.5.0b1: Out-of-spec readings raise a heater fault in approximately 2s (6 readings), irrespective of M570 settings. RRF 3.5.0b1 and later: the M570 Rn command can be used to set the number of consecutive out-of-spec readings allowed before a fault is raised. The default is 3 readings which guarantees that a fault will be raised within one second of a sensor becoming disconnected or shorted. Using R0 will result in a heater fault being raised immediately when a sensor delivers an out-of-spec reading, but will make the system more likely to report spurious failures if the sensor or its wiring is subjected to electrical interference or ESD.
Multiple, short, out-of-spec readings of less than the limit referenced in point 1 are accumulated by the heater model and will also cause a fault if frequent enough. How many short out-of-spec readings in a given period of time cause a fault depends on the specific parameters of the heater model.
If the error is a partial short/open circuit that indicates as a higher temperature than M143 limits but not as an open or short circuit then this protection could apply, however the heater model protection would also apply as this partial short/open circuit would still be anomalous. Fully open/short circuits over the time limit will always cause a fault regardless of M143 settings.
The message in this case is "temperature rising much more slowly than the expected x.xC/sec". This fault occurs if the rate of temperature increase is less than 75% of the value expected from the heater model defined by M307 and this condition persists for more than 5 seconds by default. In firmware version 1.15d and later an additional margin of 0.25C/sec is allowed. To avoid these faults:
The message in this case is "temperature excursion too large" or "temperature excursion exceeded XX.XC". This fault occurs if the temperature came to within 2.5C of the setpoint temperature, but subsequently departed from the setpoint temperature by more than 15C for more than 5 seconds (defaults). To avoid these faults:
M303 is used to tune heaters. You may receive the message "Auto tune cancelled because temperature is not increasing" while running M303. This happens when the temperature has not increased by at least 3C within 30 seconds + the configured dead time of the heater. It can occur on a bed heater with a large thermal mass and a weak heater. To avoid these faults:
M307 H0 D60 before sending the M303 tuning command will increase the heater 0 dead time to 60 seconds.From RepRapFrimware v3.4 errors can be reported and handled through the Event System. For heater faults, the following Heater Fault Types are returned to the heater event:
| Heater fault type code | Heater fault type | Returned string |
|---|---|---|
| 0 | failedToReadSensor | "failed to read sensor: " the sensor error message will be appended |
| 1 | temperatureRisingTooSlowly | "temperature rising too slowly: expected ... measured ..." will be appended |
| 2 | exceededAllowedExcursion | "exceeded allowed temperature excursion: target ... actual ..." will be appended |
| 3 | monitorTriggered | "monitor ... was triggered" will be appended |
| 4 | heaterFaultTypeLimit | "unknown error: " this is used if the parameter is not a valid heater fault type |
Do not simply reset a heater fault without understanding why it occured.
M562 resets temperature faults. Send M562 P# where # is the heater number. In recent firmware version you can send M562 with no parameters to reset all heaters that are in the fault state.
In DWC you can click on the heater with a fault and it will promt you with a warning message, to reset the fault.
The M143 gcode limits temp to a preconfigured limit. A Heater Fault error occurs if temp is above this limit. Set it in config.g.
The default is 290C.