Fire hazard - Frozen temperature + Thermal protection issue

[pillopaolo]

Bug Description

Hi,
A few days ago I melted my extruder and risked a fire, just after upgrading from Marlin 1.1.8 (June 2018) to Marlin 2.0 (March 2020).
I managed to reproduce the issue several times and here below are my findings.

My Configurations

Below relevant parameters from my configuration files (complete files are attached)
configuration.h
#define TEMP_SENSOR_0 1
#define HEATER_0_MAXTEMP 320
#define THERMAL_PROTECTION_HOTENDS
#define TEMP_WINDOW 1
#define TEMP_HYSTERESIS 3
configuration_adv.h
#define THERMAL_PROTECTION_PERIOD 40
#define THERMAL_PROTECTION_HYSTERESIS 4
#define WATCH_TEMP_PERIOD 20
#define WATCH_TEMP_INCREASE 2

Configuration - incident.zip

Steps to Reproduce

This is what happened to me:

1. Temperature setpoint was 305°C.
2. Temperature reading was frozen to the max temperature in the thermistor table, 300°C in my case.
3. Thermal protection did not work properly and heater was continuously powered, at max power.
4. Temperature rose to incredibly high values, most likely > 400-500°C, until plastic parts melted.
5. Luckily warned by a strange smell, I switched my printer off before it could actually catch fire.

Expected behavior:
2. --> Temperature extrapolated above thermistor table max value, as in previous Marlin versions.
3. --> Frozen temperature error.

Actual behavior:
See points 2.-5. above.

Additional Information

Issue A: "Temperature reading is frozen to the max temperature in the thermistor table"
I had no much time to read through the code, but it seems that the current algorithm in temperature.cpp does not extrapolate above the max temperature value in the thermistor table, as previous Marlin versions did.
As a consequence, when real temperature is above 300°C you always read 300°C.
There are no warnings, neither during compiling nor during runtime, if you set HEATER_0_MAXTEMP bigger than the max temperature in the thermistor table.

Issue B: "Thermal protection does not work properly with frozen temperature value"
Apparently the thermal protection, which usually works properly, fails when the temperature is frozen close to setpoint.
Looking at the code in temperature.cpp I see:
...
watch_temp_increase = GTV(WATCH_BED_TEMP_INCREASE, WATCH_TEMP_INCREASE);
watch_temp_target = target - float(watch_temp_increase+GTV(TEMP_BED_HYSTERESIS, TEMP_HYSTERESIS) + 1);
In my case:
watch_temp_increase = 2
watch_temp_target = 305 - (2 + 4 + 1) = 298
...
if (current_temp > watch_temp_target) heated = true;
In my case:
if (300 > 298) heated = true;
...
else if (current_temp < target - (MAX_OVERSHOOT_PID_AUTOTUNE)) ...
In my case:
else if (300 < 305 - 30)
And therefore no heating-failed nor thermal-runaway errors occur.

My suggestions:

Issue A:
a) Extrapolate above the max temperature value in the thermistor table (as in previous Marlin versions); not really a solid solution, but probably better/safer than a temperature freezing.
b) Add a first "dummy" value in the thermistor table, e.g. see thermistor_11.h, to have this extrapolation done anyway by the current algorithm; also not a very solid/nice solution
const short temptable_11[][2] PROGMEM = {
{ OV( 1), 938 },
{ OV( 31), 314 },
c) Probably better, prevent compiling when HEATER_0_MAXTEMP > max thermistor temperature, or have a runtime error when setpoint > max thermistor temperature, etc.

Issue B:
a) Improve current thermal protection logic.
b) Probably better, implement a freeze check (quite common in industry), i.e. printer is halted if temperature reading in Celsius (not raw value!) has the same value (whatever the value is) for more than x seconds.

[pillopaolo]

I see now that change in behavior described in "Issue A" above was introduced by #10882

[boelle]

Lack of Activity
This issue is being closed due to lack of activity. If you have solved the
issue, please let us know how you solved it. If you haven't, please tell us
what else you've tried in the meantime, and possibly this issue will be
reopened.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.