Getting the error:

Thermal Runaway, system stopped! Heater_ID: bed

Which causes octoprint to panic and disconnect my printer.

This happens maybe 10 minutes after starting a print, after everything is warmed up and the actual printing starts.

Happens almost every time.

However, when I reset the ramps board and reconnect, I can leave the printer idling at full bed temp (90C) for hours and hours with no issues.

This problem also didn't start until I updated my firmware (I wanted better bed autoleveling, as the older version of marlin I was using didn't have all the new algorithms)

So....I'm guessing this is a firmware issue. Trouble is, not sure what settings to tweak to fix this.

Is there a way to disable thermal runaway protection? Or what else could I try?

Quote
foul_owl
Getting the error:

Thermal Runaway, system stopped! Heater_ID: bed

Which causes octoprint to panic and disconnect my printer.

This happens maybe 10 minutes after starting a print, after everything is warmed up and the actual printing starts.

Happens almost every time.

However, when I reset the ramps board and reconnect, I can leave the printer idling at full bed temp (90C) for hours and hours with no issues.

This problem also didn't start until I updated my firmware (I wanted better bed autoleveling, as the older version of marlin I was using didn't have all the new algorithms)

So....I'm guessing this is a firmware issue. Trouble is, not sure what settings to tweak to fix this.

Is there a way to disable thermal runaway protection? Or what else could I try?

Gee, for you it is always a firmware issue ! How are you so sure when so far, it has always been you who screwed things up !!!!

Fact is, be happy the firmware prevents accident like setting the machine and the rest on fire !

And how about posting in the correct subtopic ?

---

"A comical prototype doesn't mean a dumb idea is possible" (Thunderf00t)

Ok....so technically since the printers are mine, every problem is my fault since I own them...I accept that.

But isn't the point of these forums to try and help each other?

Why post if you are just trying to make me feel bad?

Yes, it's likely a firmware misconfiguration, and yes, it's probably my fault also. I have no idea how to fix it since I'm not an expert.

I'm trying to post here so I can learn!

Apologies for the wrong location, this was posted after hours of debugging and I accidentally picked the wrong spot.

Edited 1 time(s). Last edit at 09/27/2018 01:38PM by foul_owl.

I've had thermal runaway errors in exactly the same spot when printing gcode files, and they happen in exactly the same spot multiple times. (Last one was ~3 hours into a print, very annoying) i can compare the aborted parts and they're identical, down to the position of the print head indent from when it got the error.

For whatever reason, re-slicing the object solved the problem.

---

MBot3D Printer
MakerBot clone Kit from Amazon
Added heated bed.

Leadscrew self-built printer (in progress)
Duet Wifi, Precision Piezo parts

Wow....that is crazy, I didn't know that could happen!

I disabled thermal protection for the bed, and the issue went away.

So I was right, it was a firmware issue. All prints are fine, no crazy temp spikes.

There seems to be no fire hazard as the bed can only reach 90C max anyway, if the thermistor falls off it's not going above 90.

Thanks!

Edited 1 time(s). Last edit at 09/27/2018 04:29PM by foul_owl.

I don't know that it was firmware, if it was, then why would re-slicing the object solve it? it's obviously some combination of factors that something isn't handling well, and is causing a problem. I don't know if the problem lies in the slicer, the firmware, or if it's a bug in one tickling a bug in the other. This is the kind of thing that I often think of as a buffer overflow type problem. The printer that this happened on last was running Marlin 1.1.0 RC8 (IIRC) and I've since updated that to 1.1.8 stable.

Then again, maybe it is firmware. In any case, I don't like to keep around gcode files that cause my printer to report an error condition, even if it's a false alarm. Last time, I left all of the settings exactly the same in Slic3r, but I do use random start points, so chances are the gcode won't be exactly the same. In the past, I've changed something, or re-positioned the object, like a 180 degree rotation.

---

MBot3D Printer
MakerBot clone Kit from Amazon
Added heated bed.

Leadscrew self-built printer (in progress)
Duet Wifi, Precision Piezo parts

Quote
foul_owl
There seems to be no fire hazard as the bed can only reach 90C max anyway, if the thermistor falls off it's not going above 90.

thats a false sense of security buddy,,, what will happen is the bed mosfet will ramp up the power to maintain/achieve the required heat... then you have your melt down.

"This problem also didn't start until I updated my firmware (I wanted better bed autoleveling, as the older version of marlin I was using didn't have all the new algorithms)" could well have been those guys love to tinker but you think there be more folks with this issue,, you checked the marlin github.

you checked the leads near the thermistor bead, my spidy senses feels like its either shorting there or you got a loose connection, the fact its stable when not in motion leads me to think its a loose connection somewhere.


PS.
"But isn't the point of these forums to try and help each other?" you absolutely right...

Edited 1 time(s). Last edit at 09/28/2018 03:59AM by jinx.

Quote
jinx

thats a false sense of security buddy,,, what will happen is the bed mosfet will ramp up the power to maintain/achieve the required heat... then you have your melt down.

....

Indeed, it is why security features are implemented but of course if you don't want to be bothered by them, just disable them
Easier than to find out the problem origin but one day a fire will start, someone will get electrocuted.

---

"A comical prototype doesn't mean a dumb idea is possible" (Thunderf00t)

Not sure if anyone is still following this thread but I have a similar issue so I'm hoping...

I am running 3 different printers that are home built I3 clones running Ramps 1.4s with Marin 1.1.7 firmware. I am having thermal runaway errors at exactly the same spot across different printers. I was using an older g-code slice with Cura 3.5 that I've printed 12 to 20 times but the last 7 tries have failed. I have re-sliced the g-code with Cura 3.6 a few times and although it has worked it only works 20% of the time. In fact after re-slicing and rotating the position it still fails in the same location.

Did anyone ever establish if there was an actual fix.

LFG

The fix is simply that that applied power is not heating the bed sufficiently. (the controller works out how much the temperature should change and errors if this is not the case)

many possibilities.
1) you have power issues (check your voltage on the bed is the same as your supply voltage, no losses in cables)
2) the bed pid needs tuned.. [reprap.org]
3) your firmware needs a larger timeouts (look into configuration_adv.h in the THERMAL_PROTECTION_BED section)
4) or you have fans accidentally cooling the bed when they shouldn't. <-- a very common issue
5) you have no insulation around or under the bed, causing it to cool off very easily. Always insulate around the bed.

Edited 1 time(s). Last edit at 01/26/2019 02:28AM by Dust.

Quote
LFG
I am running 3 different printers that are home built I3 clones running Ramps 1.4s with Marin 1.1.7 firmware. I am having thermal runaway errors at exactly the same spot across different printers. I was using an older g-code slice with Cura 3.5 that I've printed 12 to 20 times but the last 7 tries have failed. I have re-sliced the g-code with Cura 3.6 a few times and although it has worked it only works 20% of the time. In fact after re-slicing and rotating the position it still fails in the same location.

Is this thermal runaway of the bed or the hot-end? Especially, if it's the hot-end, I'd be looking at wiring faults. When the hot-end moves to that particular location, it stresses the wiring which shorts or breaks the circuit somehow. The fact that it's intermittent and getting worse also points to some kind of physical process.

Conversely, it may be nothing to do with physical location and perhaps be related to time... something is heating up and eventually that causes a short or break in the circuit.

Odd that it's happening on 3 different printers, but perhaps they're all physically wired in a similar way?

It's a thermal runaway error but its due to something in Cura. I have repeated it numerous times and in numerous ways so I am getting more confident in my diagnosis. If you go back to my previous post I have a temp graph listed there that shows the slow degradation of the hotends ability to regulate temperature.

Basically, it seams to be related to wall thickness. If I set a thickness between 1-mm and 2-mm the nozzle temp goes to pot after only a few layers of the wall. if I change my model to a 3-mm wall then it seams to slice fine and work.

I was trying to upload the g-code for a bad slice last night but eventually the forums file size limit kicked it. So when the slice works the file size is about 4000kb and the print time is around 2-hours but when slicing something too thin I have seen file sizes around 16,000KB and 8+ hour print times. I didn't realize it at the time, but it was these grossly over-sized files that were always failing.

I realize I could just up all my wall sizes to 3-mm, but I am making/designing cases in which I am trying to keep the walls as thin as possible while still incorporating a snap fit connection between the lid and base. The weird thing is the snap fit doesn't give me problems, its the 2-mm wall thickness leading up to it.

LFG

So this is a problem with the hot-end, not the heated bed. And not thermal runway, per se. OK. Whilst many people have more experience, so I could be wrong, I've never seen a case where G-code directly causes loss of temperature control. There are various indirect ways it could happen, some of which I've tried to cover earlier.

I'm kindof surprised that making walls thinner quadruples the print time and file size. Normally thinner walls would reduce file size and print time a little. This sounds like a bug in Cura. Are you running the latest version? Have you tried slicing with something else (e.g. Slic3r)? It might be worth looking at the Gcode file with one of the online Gcode viewers to see if there's something screwy?

I'm wondering if the thinner wall thickness triggers the part-cooling fan to run?

Another thought; is your power supply adequate? Maybe lots of stepper movement is pulling so much current that the heater isn't getting enough, and/or the voltage is sagging significantly below 12V?

I can't find your other post with the graph... can you post a link?

If the above doesn't solve it, maybe you could upload the file as a ZIP to overcome the forum limits; that should be a tenth the size of the Gcode file. Or you could edit the Gcode file with any text editor (that can handle 16MB files) to cut out all the Gcode after the fault occurs.

Moving my discussion to a new thread.