Thermal Runaway Protection Not working?

Printer: JG Maker Artist-D
Board: MKS Robin Pro
klippy: klippy.zip (1.2 MB)

The klippy.log not really necessary for this question, but included anyway.

HI,

So I apparently accidently changed the inversion on my extruder heater pin. In the temperature section of Mainsail it showed the state as off, but the temperature kept climbing and climbing and I did not notice until I smelt burring of the filament.

If I set my min_temp to 0 and it dips below 0 at anytime klipper shuts down, but apparently as long as the heater is below the max_temp it will let it cook off even though it is off?

I tried to use [verify_heater] and set max_error: 50, but I am thinking that onlyu works when it knows its on.

Is there a safety implementation I over looked for this unique thermal runaway?

To repeat it you only have to invert your extruders heater pin and restart the firmware.

I even did some extra reading here, but found noting for this condition.

Thanks,
/retnel

First off - thank you for the printer.cfg. I wasn’t exactly sure what you meant when you said that you “changed the inversion on my extruder heater pin”. Having the printer.cfg allowed me to understand what happened (ie you had a number of lines with: heater_pin = !PB0). It’s really a useful file, don’t ever think it’s “not really necessary”.

As to your problem, it’s the kind of dumbsh!t thing that we all do from time to and there’s really nothing that can be done to prevent it - if you have inverted the extruder power pin then it will start heating when it is off but the software has no way of “knowing” you accidentally put the bang (“!”) in front of the heater pin so it will try to stop things by ensuring that the pin is “off”, which is actually turning things on.

It’s basically the situation that Captain Kirk tries to get a malevolent computer into.

As for there being a safeguard for this kind of situation, remember:

The only bit of advice I can give you is to closely monitor your printer immediately after and once it’s starting to print following any changes to printer.cfg.

I agree, but we can not always rely on the electronics to be off when we tell it to becasue electronics fail, it is the nature of their existence. Like with coding and all things in this reality.

It is a safety feature and is in Marlin. I assumed that I just did not know what to put in my config, but if not, that is what watchdogs are for. Thermal runaway.

Transistors fail, and you do not always have the option of fail safe or fail secure, that is why protection circuits were invented. Like on lithium batteries.

I did, it was right, then it was not. “I did not change it”, and it only happend on one of my Hotend and not both. That part was already rock solid and something changed it. It was an issue until the next time I started it up after pid tuning. I only did it on E0, and it was the only one that had the inverter removed. Either that or a hacker? If you look at my printer.cfg you will see that E0 is the only one that was pid calibrated. I have 500c heaters, “500c”. Many people do now. That is 400c hotter that boiling water and 100c will remove skin.

The Marlin developers nailed that thermal runaway protection feature down becasue of this kind of stuff. Just becasue someone is not an expert in klipper does not make them a fool. it just makes them someone without experience. But in my experience many coders are usually condescending. That is why if fire them. I give them 3 chances to understand I am paying them to code, and I want it to work for anyone, fool or not.

I am an engineer, and I have done my share of coding and electronics design.

klipper goes into red alert shutdown if I ahve min_temp set to 0, and it drops to -5. Even if all I do is start it up without runnning any gcode. So maybe whatever watchdog that is monitoring min_temp at all times could also be tasked with thermal_runaway: 50? If it climbs over the termal_runaway value… beep, beep, beep, beeeeeeeeep… Where have I heard that before?

Like this when I increase min_temp to 5c and restart the firmware. I do not think a fire will start at -5c, but that is me.


.

Yes, I am trying to unlock the ability for this to be understood much better.

I wish everyone would stop attacking me assuming I am a fool. It is why I pulled my octoprint support and stopped using it.

H-Series_gCode_PostProcessor_V1.8.zip (7.5 KB)

Also, I did not say the printer.cfg was not necessary, I said the klippy.log was. Only for this situation.

I think safety first, safety last, safety always. Just like when I was wearing combat boots.

If the thermal runaway feature is not yet implemented, I would respectfully like to request it. Octoprint did not need to worry about it becasue Marlin was protecting us and our foolish ways.

Respectfully,
/retnel

Since you like quotes:

Looking at the Marlin thermal runaway protection functionality, it would not protect you in this situation but you could not experience this problem in Marlin simply because it doesn’t give users the opportunity to change the true/false logic state of the heater pins.

What you are looking for is thermal protection that analyzes the situation, recognizes that the polarity of the heater control signal is inverted and correctly turn off the heater by generating a true signal on the pin and generating an error message indicating that the heater is working in reverse to the user specified logic.

You ain’t gonna get it simply because there are too many weird corner cases like this on that come up every day or so for the developers to play Whack-A-Mole with. That was the message in the Murphy’s law quote that you apparently took great umbrage in.

Apologies about confusing printer.cfg and klippy.cfg - what’s nice about klippy.cfg is that you can see the effective printer.cfg with all macros and includes present so you can get an idea of what’s actually running there.

1 Like

Nobody is attacking you, but I personally find your posts exceedingly difficult to read and comprehend:

  • A wall of text, mostly unrelated to the issue
  • Mixing up settings and topics
  • Huge amount of assumptions that mostly stem from misinterpretation or not properly reading the documentation
  • Spiced with an attitude that people “shall read” and that you perfectly well know what you are doing, which apparently is not the case

Again, that is my feeling towards your posts and not intended as an offense of any kind.

Now back to the topic of thermal protection

1 Like

I appreciate the help, but the original post was short and provided the necessary information. The wall of text was to explain the fool part by @mykepredko.

Right after being told on another post to stop posing things as “BUGS”. Refrance: manual_stepper. Well, that individual did not read the “I concider” part. So I explain to them why. Becasue reading something and making an immediate assumption without “reading and comprehending what other or saying be fore attack”

It is clearly defined by watching Social Delma on Netflix. Social media has turned everyone into 5-second meme readers of false information. Into I will read this, and understand that.

THAT IS WHY I ASKED IF I MISSED A FEATURE part.

Please read my original post again, before I was called a fool. Implication is the same thing.

I worked in R&D engineering for several companies and I am used to saying things in a way people who are reading and listing will hear.

A fire can start at any temperature being reported by a failed thermistor. That’s the entire point of min_temp.

Then why do it for min_temp? your entire respace is flawed. Seriously, think about it logically. You watch dog for freezing and shut everything down. But you can ignore someone that could burn someone’s home down.

I am sorry, but too bad for stupid punching their Murphy’s ticket like a fool.

1.) One is necessary while printing, and that is the min_temp.
2.) klipper raises an error shutdown even when in idle.
3.) I have a 500c heater, so my max is at 500c so I can use it.
4.) Let me edit the video so you can see it without too many words.

@jakep_82 I only saw this when I was getting ready to upload the video, so please watch the last part please. It would be nice if everyone would care about stuff like this.

I guess the only real way to get anyone to care is to contact companies like Peopoly directly. Then they can talk directly to Kevin O’Connor. If you notice his title on his patron page says “creating Klipper”, and “not” Created. So it is not done yet, and likely never will be. It will continue to grow becasue it can. But if a fire is ever is ever found to be the result of such a missing feature, then you know how the US Government gets down on stuff like that.

I am not the bad guy here. If everyone would stop for a second to try and understand what I am saying then we can move on with the motion feature.

It is also why Kevin does not use his real name on this site. Foosel had one, but she uses the incognito one mostly.

Not sure what you’re saying here. Kevin does use his real name on Discourse, and he responds when he thinks it’s warranted.

I’ve seen your posts here, and I personally don’t have the time or interest to engage further. Good luck.

I guess I wasn’t very good at explaining the situation and my reply. Let’s try it with pictures.

In a normal 3D printer system, the extruder heater block can be characterized with this block diagram:

The “MCU” firmware controls the output of the “Driver Buffer” that sets the temperature of the “Heater Block” using the “Heater Coil” while monitoring the “Heater Block” temperature using data from the “Thermistor”.

Now, let’s say an engineer, let’s call him Frederick Oliver Octavius Lowe, using the same MCU and firmware, Heater Block, Coil and Thermistor, mistakenly puts in an “Inverting Driver Buffer”, changing the block diagram to look like:

In this case the MCU firmare has, as luck would have it, thermal runaway protection which detects that the temperature of the Heater Block does not correspond to the “Heater DO” values and is meets the criteria of a thermal runaway.

The firmware’s response in this situation is to turn off the “Heater DO” but, because the driver is an inverting one the off signal from the MCU will turn the heater driver solidly on.

Fred Lowe isn’t stupid and suspects the heater control is working oppositely to what he expects so after around 50 seconds or so of operation, he changes the target temperature to something greater than the current temperature and, lowe (excuse the pun) and behold, the temperature starts falling.

This is exactly your case, except the error is made in the board configuration file and not be a part error, and is confirmed at 50s in the video you posted. I’m not exactly sure what you expect the thermal runaway code to do in this situation - I guess the firmware will try turning on the Heater DO and wait to see if the temperature falls but there is the case the driving MOSFET is internally shorted so you turn off power to the printer or add a relay in series with the Driver Buffer to act as a redundant part or…?

As I said in my original reply, everybody makes these mistakes and it’s literally impossible to predict what people will do as well as design systems that are absolutely Frederick Oscar Octavious Lowe proof.

As I really do not understand all this ado, I’ll summarize my understanding:

  • min_temp and max_temp can be considered basic safety features.
  • Violating one limit will cause a Klipper shutdown
  • max_temp needs to be set in a way that this temperature can basically be sustained by the hardware indefinitely without any damage
  • min_temp needs to be set so that under specified operating and environmental conditions it is not violated

Rationale:
Either malfunctioning heaters or malfunctioning sensors or misconfigured sensors can (and typically will) cause aberrant temperatures in both positive and negative direction.
The limits will detect such deviation, provide a safe shutdown and notify the operator that something is amiss.

Again, this is a complete misconception. The limits are on hardware level to safeguard against aberrant readings that are leaving the specified operating conditions.

A wrongly configured hardware (i.e. inverted heater pin) is like turning on the cooking plate in the kitchen to full power and then leaving for 3 weeks of vacation. There is nothing and nobody that prevents you from doing it and it is also not needed: It is justified and sane to assume that a turned on cooking plate serves a purpose and it is your responsibility to ensure this.

Likewise with Klipper:

  • Klipper does not “know” if you configured the pins correctly
  • Klipper does not know or care if you heat up for printing, cleaning your nozzle, testing something or you name it
  • Klipper does take care that:
    • No obviously out-of-spec temperature readings occur
    • A set temperature target is a) reached in due time and b) is maintained within specified limits
3 Likes

In this situation, there is nothing the software can reasonably do. The software only has the ability to instruct the hardware to turn off the heater. Unfortunately, if the software has been configured in a way that it does not actually turn the heater off, then it is unable to do so.

We recommend following the steps in Configuration checks - Klipper documentation on any new printer (or any significant change). The step-by-step checks written there are designed to catch issues like those described here.

-Kevin

3 Likes

Sorry, but the title reads:

grafik

And bug in all capital letters.
That is what I was referring to.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.