Detect constant tip temperature when in heating mode and stop after a short while

[gdonval]

This is a Feature Request

• I have

  • [x] Searched previous issues
  • [x] This is in this firmware, not vendor "offical" firmware
  • [x] This is not a bug in the vendor bootloader (aka DFU)
  • [x] I have checked this is not already covered in the docs in /Documentation

• What is the current behavior?

If, for whatever reason (most likely hardware failure, like fried op amp), the reported tip temperature is spurious and stays low, the iron will heat like there is no tomorrow.

• What is the expected behavior?

The iron should not dangerously overheat ever. If something fishy is going on (like "staying" at 23°C for 10s while heating at 65W), the iron should go into safe mode (i.e. shut down the tip) and report the error to the user.

Different tips have different thermal behaviour so just checking that steady state has been reached in X seconds is probably not a good idea. In terms of PID parameters, P should decrease at a reasonable pace at first: if it stays big and constant (i.e. D is very small), there is a problem. When P is small enough, we are at temperature.

• What is the motivation / use case for changing the behavior?

The current behaviour is dangerous and defeats most of the other safety measures in place (sleep mode, etc.) because from the iron's perspective, the tip is and stays cold while it's almost melting in real life.

• What are you running:

  • Firmware Version: 2.14
  • PCB Version: 5
  • Power Supply: PinePower Desktop (USB-C, 65W, 20V, ~3A)

[ssl-3]

I came here to make this suggestion, having found a related complaint in the Pine forums: https://forum.pine64.org/showthread.php?tid=13585

I would like to add that this problem has been solved in the Marlin 3D printer firmware with their "thermal runaway protection" system. Marlin is capable of detecting slower-than-sane heating, as well, which also catches the failure modes where the sensor is working but is poorly-coupled to the heater itself.

Perhaps some ideas or code could be borrowed from there.

It seems like a preventable failure mode and there's certainly plenty of CPU grunt available to make it work.

[Ralim]

I've put a rough punt at a catch for this into #993. If you have a unit that can replicate this, can you please test?

I came here to make this suggestion, having found a related complaint in the Pine forums: https://forum.pine64.org/showthread.php?tid=13585

I would like to add that this problem has been solved in the Marlin 3D printer firmware with their "thermal runaway protection" system. Marlin is capable of detecting slower-than-sane heating, as well, which also catches the failure modes where the sensor is working but is poorly-coupled to the heater itself.

Perhaps some ideas or code could be borrowed from there.

You are most welcome to open a PR bringing across the logic if you would like. Last I looked at Marlin it was a moderately dodgy Arduino sketch that had this annoying feature where it would kill my bed heater as it didnt heat fast enough, that I spent an hour patching out 🤣 . But naah its good firmware but also not the nicest to extract logic from.

It seems like a preventable failure mode and there's certainly plenty of CPU grunt available to make it work.

Absolutely, but I'm not paid anything to work on this firmware remember, so the amount features is proportional to my free time and willpower :)