Hotend thermistor malfunction behavior

[clefranc]

I'm using a 500°C thermistor that came with a Pico hotend, the official temperature table has the lower value at 25°C (not 0°C as expected).

The main reason why it doesn't goes to 0°C lays in the specification of this particular thermistor: at room temperature its resistance is too high to be detected by my RUMBA board. If I set the 1023 temp table entry to 0, it triggers a MINTEMP error. So I set them to 25.

Now the protection discussion.

First test: The thermistor is disconnected prior printing (or completely detached from hotend)

1. Current temperature 25°C...
2. Send a M104 T0 S230...
3. The heater start heating...
4. After 40 seconds, the message "Heating failed" is displayed, then target temperature is set to 0°C.

This is the expected behavior.

Second test: The thermistor fail during a print (or completely detach from hotend)

1. The target temperature is reached, say 230°C...
2. I disconnect the thermistor, the new reading is instantly 25°C...
3. The heater try to keep the target temperature unsuccessfully...
4. After 40 seconds, nothing, no message or heater shutdown...
5. After 2 minutes, the protection is still not kicking.
6. Reconnected the themistor, got a MAXTEMP at +400°C.

What went wrong with the second test? I've redone it multiple time at 50°C with the same result (reconnect after 60 seconds).

In my configurations, I think I'm using full protection:

#define THERMAL_RUNAWAY_PROTECTION_PERIOD 40 //in seconds
#define THERMAL_RUNAWAY_PROTECTION_HYSTERESIS 4 // in degree Celsius
#define THERMAL_RUNAWAY_PROTECTION_BED_PERIOD 120 //in seconds
#define THERMAL_RUNAWAY_PROTECTION_BED_HYSTERESIS 4 // in degree Celsius
#define WATCH_TEMP_PERIOD 40000 //40 seconds
#define WATCH_TEMP_INCREASE 10  //Heat up at least 10 degree in 20 seconds

[thinkyhead]

@clefranc Thermal protection should definitely be smarter about a detached thermistor. I can see why (logically) it doesn't throw "MAXTEMP" until the temperature registers high. But it should throw something as soon as the thermistor detaches. In fact, I would argue any rapid jump or drop in temperature should throw an error instantly, disable the heaters, and trigger a thermal alarm (with audio feedback coming soon).

[clefranc]

@thinkyhead I totally agree, sorry I've nothing to add to the discussion.

#1778
#1509

[ntoff]

But it should throw something as soon as the thermistor detaches.

Mine, using an old version of Marlin, shows error mintemp when the thermistor is detached. I haven't actually tried it while the printer is on and heating though but I know it won't start heating until you attach it again and give it the M999 command.

I'll go test it later tonight and see what the old version does, and test against the latest version when it's already at temperature.

edit: oh never mind I misread it as becoming electrically disconnected rather than just falling out of the heater block. Either way I'm running 100% metal hot ends so I doubt I'll fry anything significant by pulling the thermistor out of the heater

[nophead]

Yes Marlin would normally give a MINTEMP error as soon as the thermistor is disconnected because open circuit corresponds to a very low temperature. The problem in this case is the thermistor table starts at 25, so it can never return a value lower than that.

Because thermistor responses are logarithmic I don't think a 500C range is practical with the normal circuit.

[Wurstnase]

Afaik Marlin doesn't compare the temperature. It tests the raw_value. This should return 0 if there is nothing connected. Independed of the thermistor_table, or?

[nophead]

The raw value would be 1023 with nothing connected.

[nophead]

But the OP says he gets 1023 at room temp, so MINTEMP can never work in this case. It needs to be handled by THERMAL_RUNAWAY_PROTECTION.

[Wurstnase]

Or something like
if (heater_active && temperature_raw >= 1022) trigger MINTEMP;
Maybe with a 10 second delay, so this can go outside the MINTEMP-area.

[nophead]

Yes basically if the heater is on full power and the temperature does not rise within some timeout it must be a fault. THERMAL_RUNAWAY_PROTECTION should handle this but doesn't.

[nophead]

Similarly if the heater is off and the temperature does not fall within some timeout that is also a fault.

[Wurstnase]

That's right because:

      case TRStable:
        // If the temperature is over the target (-hysteresis) restart the timer
        if (temperature >= tr_target_temperature[heater_index] - hysteresis_degc)
          *timer = millis();
          // If the timer goes too long without a reset, trigger shutdown
        else if (millis() > *timer + period_seconds * 1000UL)
          *state = TRRunaway;
        break;

It only test that the heater is not above the temperature, not below.
Or, not... This should work... hmmm...

[AnHardt]

There seems to be an other problem.
In the ISR, we take 16 samples of every ADC and sum them up. To check for open or shorted thermistors, we then check the raw values against 0 respectively 16383. This leaves no room for any noise an the ADCs,, so in a real system it's unlikely the errors are triggered.

Ohhh, even worse. 16 * 1023 == 16368 but 16383 == 16 * 1024-1. We check against a value we can never reach.

[Wurstnase]

Ohhh, even worse. 16 * 1023 == 16368 but 16383 == 16 * 1024-1. We check against a value we can never reach.

There is a TEMP_MIN/MAX_ROUTINE which handle that.

[nophead]

Yes I think it converts the specified MIN and MAX temperatures to raw values for the interrupt to check. But that won't work if they are outside the range of the table.

I think THERMAL_RUNAWAY_PROTECTION should work like this:

if(heater is full on)
     if(state != FULL_ON) {
           state = FULL_ON;
           timer = now();
           initial_temp = current_temp();
    }
    else 
          if(now() - timer > MAX_LATENCY && current_temp() <= initial_temp)
                 error(...); // on but not heating
else
     if(heater is off)
         if(state != OFF) {
              state = OFF;
              timer = now();
              initial_temp = max(current_temp(), MAX_ROOM_TEMP);
         }
         else 
               if(now() - timer > MAX_LATENCY && current_temp() >= initial_temp)
                    error(...); // off but no cooling
     else
          state = ON;   // on but not full power so can't infer anything about the temperature change

[AnHardt]

Sorry for the wrong alarm.
Indeed the maxttemp_raw[], minttemp_raw[] arrays are set up by the values mentioned above. But then the TEMP_MIN/MAX_ROUTINE macros narrow the range down to the values needed to match the HEATER_X_MIN/MAXTEMP values from Configuration.h.
Grep couldn't find this due to the macros. Sorry.

[nophead]

Yes the recent addition of macros with token pasting to repeat code makes Marlin even less readable than it was before. That plus Github's broken search makes it very difficult to find what goes on.

[thinkyhead]

I updated the comments on Thermal Runaway Protection to warn that it doesn't catch every condition. For example, if the thermistor is already disconnected when you start the heater, it will not get caught. (For that you must separately enable WATCH_TEMP_PERIOD.) I propose adding more comprehensive high-level protection.

• If the temperature jumps suddenly, THERMAL FAULT
• Use WATCH_TEMP_PERIOD to ensure the temperature is rising, or THERMAL FAULT
• Keep WATCH_TEMP_PERIOD alive as long as the temperature is still rising

Any other conditions worth adding?

[thinkyhead]

I'm proposing #2041 to enable WATCH_TEMP_PERIOD by default and to change its behavior so it throws an error, disables the heaters, and halts the machine in the same way as thermal runaway protection.

[ntoff]

I propose any and all fail safes are enabled by default. Anything that can figure out whether or not the printer has malfunctioned shouldn't really be optional anyway. I don't know why you'd even have the option to disable them in firmware and just allow users to send a gcode to temporarily override it in a test case scenario (like allowing cold extrusions while testing with the hot end removed).

[clefranc]

I also propose to group all the thermal protection in the same section, in one configuration file, either Configuration.h or Configuration_adv.h.

[thinkyhead]

@clefranc @ntoff I agree that a single THERMAL_PROTECTION option in Configuration.h should be good enough, and that the wait times, temperature ranges, etc. should be set in Configuration_adv.h (if they are customizable at all). And the default values should be suitable for all configurations. I will see about expanding on this after merging #2041.

[thinkyhead]

#2055 simplifies enabling thermal protection for hotends and the bed by making them simple switches, with the time and temperature parameters moved to Configuration_adv.h.

[clefranc]

Please continue discussion here: #2066

[thinkyhead]

#2067

[AnHardt]

Continued in #2066, #2067, #2164

[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.