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.

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.

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

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.

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.

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.

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

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.