1.1.0-RC10 hotbed thermal runaway during G29

[Angel996]

I've had this start up script for ages. Printer is working fine, both temp sensors are ok.

I flashed 1.1.0-RC10 and now I'm constantly getting a thermal runaway for bed exactly AFTER G29 is complete. Looks like the termal runaway routine is not aware of G29 running and thinks it's an emergency. I've set WATCH_BED_TEMP_PERIOD to 300, but it did not help. Hotbed is in bang-bang mode, using a relay.

Here is the error msg:

> Error:Thermal Runaway, system stopped! Heater_ID: bed
> [ERROR] Error:Thermal Runaway, system stopped! Heater_ID: bed
> 
> Error:Printer halted. kill() called!
> [ERROR] Error:Printer halted. kill() called!

Here is the script:

M80; on
M84 ; disable motors
M190 S105 ; set/wait for bed temperature
M104 S180 ; set extruder temperature
M190 S110 ; set/wait bed temperature
M104 S200 ; set extruder temperature and start calibrating right away
G21; metric
G91 ; relative
G1 F5000 Z5; raise Z
G90; absolute
G28
G29; run auto leveling
G1 Z0; // go to actual zero
G92 Z0.3; the bigger the value, the closer to the bed
G1 F200 Z10; raise Z
G1 F6000 X60 Y100; move to almost center
G1 F200 Z5; lower Z
M84; disable motors
M109 S230 ; set/wait extruder temperature (prevents bleeding)

Thanks.

[lukeskymuh]

It is the same as in #5698

[Angel996]

I've seen that thread. No, I don't think it's the same, since I am not getting a ERR: MINTEMP BED error message. I am getting a thermal runaway error.

At the moment I don't have a LED on my hotbed, I will install one and update the thread with info on when exactly it does turn off.

[ghost]

That's funny....there is no RC10...yet.

[lukeskymuh]

ERR: MINTEMP BED is what is saying on the display. Your error message is probably in a software. As awork around you might try to set the G28 and G29 before the M190.

[Angel996]

lukeskymuh, it also should report MINTEMP error in Pronterface log, it does not.

Now, here's the weird part. It turns out, thermal runaway is not the CAUSE, it's a consequence. I disabled #define THERMAL_PROTECTION_BED. I get absolutely the SAME effect: while G29 is running, the bed turns off, however it turns back on once the print is started since the printer can resume, for thermal runaway error is not thrown.

Somehow G29 is shutting the bed down. I will keep experimenting and update the thread once I find out the cause.

[manianac]

You should probably upload your configuration files. I can confirm bed temp holds fine with running a 10x10 grid with G29 on a mega2560.

First guess is a memory overflow condition, since disabling thermal protection still triggers it.

[Angel996]

Now, I'm sure this is the same issue. I have another 3D printer. Basically, electonic setup is the same, but endstop polarity and stepper coefficients are different.

With the newer version RC8 I am not able to print at all. The print is aborted at about 1-3% of completion. 3 times in a row printer just stopped. In one case it restarted from the very start (on top of already printed print), the other two times it got in a weird state where it would stop, not get killed, but Pronterface log window would enter an infinite scroll loop that I had to terminate it via Task Manager (Windows 10).

I disabled bed and hot end thermal runaway protection. Now, the print got aborted again with:

Error:Printer halted. kill() called!
[ERROR] Error:Printer halted. kill() called!
Error:MAXTEMP triggered, system stopped! Heater_ID: 0
[ERROR] Error:MAXTEMP triggered, system stopped! Heater_ID: 0

Error:Printer halted. kill() called!
[ERROR] Error:Printer halted. kill() called!

I reset the printer immediately and checked extruder temperature. It was 219 C. MAXTEMP was never reached. HEATER_0_MAXTEMP is set to 250.

I really would like to emphasize the fact that this printer is 100% ok. It's been runing fine for ages too. It was running version 1.0.2.

[Blue-Marlin]

If you use any kind of bed levelling - try to use less than 5x5 points to probe, to make memory problems unlikely. If that works you can increase the number of points again - step by step.

[Angel996]

I am using 3x3 on this printer. And using 2x2 on previous printer which works. I will try right now, thanks.

[Angel996]

Modified to 2 x 2 bed leveling. Got killed again. This time "kill button" that I never pressed.
(I have changed kill() reason strings in source code to know the kill cause.)

Is the board picking up noise from steppers/heaters? But it never used to! Never had such probs with ver 1.0.2.

[ghost]

How about removing the display and try again.

[Angel996]

I have downloaded the RCBugFix version, now the printer runs fine. No sudden reboots, no "KILL BUTTON" occurances, not Pronterface freezes. I used the same config file, just had to update some variable name as compile-time err msg suggested.

[Angel996]

Ok, I've used the RCBugFix version for about 4 hours now. There is still a problem with temperature monitoring. Once I had bed MAXTEMP (although my actual bed is aluminum and it can't possible reach that temp). Also, sometimes I get cold extrusion prevented errors. I had cold temp at 200C, I changed it to 170C (default), now it's much better, but after 3 hours of printing I am still getting it from time to time. Actual extruder temp is around 220C.

[lukeskymuh]

I also get MAXTEMP and MINTEMP all the time. Specially when calling G29. Even when commenting: //#define THERMAL_PROTECTION_BED // Enable thermal protection for the heated bed

[Angel996]

Thermal protection is runaway protection, not min/max temperature check. That's a different feature, evidently.

[billyd60]

I am using a taz 5 with and e3dv6 extruder and I am having similar issues to Angel996. I am not using any sort of bed leveling but I am using lin_advance and firmware retract. Using rcbugfix.

What happens is my extruder will work fine for a few hours of a print and then it will randomly drop several degrees suddenly during a print and then slowly heat back up to temp. Then after a few more hours of this behavior the printer will simply stop printing without an error code. The display appears normal, the bed and extruder remain heated, but the printer will not accept commands. A cold boot is required to get it to respond again.

It almost seems like the code is losing track of the extruder temperature for period of time but reporting an old (good) temperature value, and then suddenly sees the actual temperature has dropped way down and then reports the correct temp on the display and takes action to heat the extruder again. I am not a code guy and I am certain it is not my hardware since this behavior does not occur with prior versions of Marlin. It's almost as though the subroutine controlling the extruder temperature is getting lost or ignored. Eventually it just crashes the printer. Just my theory.

[Angel996]

Yep, exactly the same here. Also had this once when the printer just stalled w/o the error code with bed and extruder heated, Marlin running (heater leds flashing as usual) but host software not being able to send any more commands to it.

Have you tried enabling/disabling #define ENDSTOP_INTERRUPTS_FEATURE? I think it has some effect on these errors.

[billyd60]

No but I will give it a try. I wonder why that has a positive effect?

The really weird part of this is it doesn't seem to happen when I print with PLA and have the part fan on. It's only happening in ABS prints with the part fan off. Which is crazy and makes no sense to me at all.

The other strange part is it sounds like it happens to you early. For me it takes hours of printing before this behavior shows up. Have you redone your pid optimization? Mine were changed quite a bit after installing the latest firmware, which surprised me. After I redid the pids I got less thermal runaway problems (almost never happens now) but the odd extruder issue I described then showed up.

[ghost]

Are you guys sure you have the correct thermistor(s) selected in Marlin?

[Angel996]

Tannoo, well, it's the same type that I used with older versions of Marlin. It's -1. I have makergear hotends on both printers, they came with thermisters.

billyd60, I haven't done PID optimization with new versions of Marlin, however. I'll try it.

[billyd60]

I used the same number I've used in previous versions did they change the thermistor numbering?

[Angel996]

Still having thermal runaway for bed problem. Only on printer which uses bang-bang mode for the bed. Another one using PID mode for the bed runs fine. I have noticed enabling BED_LIMIT_SWITCHING reduces probability of this error to some extent.

Both printers now run RCBugFix version dated Jan 14 2017.

[Grogyan]

I suggest checking your thermistors with a multimeter, it is quite possible that they are damaged

[Angel996]

Grogyan, do you mean the thermistor goes crazy exactly while G29 is running? :)

[Grogyan]

Yes. It is possible the thermistor is partially damaged, and the vibrations during axis movement causes the internal structure of the thermistor to create intermittent connection, or disconnection. Typical glass bead thermistors are notorious for breaking.

[billyd60]

Did you ever redo the pid optimization? That got rid of my thermal runaway problems. For some reason this newer version changed my pids quite a bit, for the bed and extruder. I didn't think that should happen but it did.

I am going to swap out my extruder thermistor because it must be the problem. Just a coincidence I guess that the problem started up when I switched to the newer firmware.

Where do you get the January version of rcbugfix? Or is that just not public?

[Angel996]

Grogyan, it would really be a good idea to read through the entire thing before answering. I have made it quite clear the problem came about ONLY whilte running the G29 command, not while axis movement or printing. Also, disconnection/shorting of thermistor would result in BED_MINTEMP/BED_MAXTEMP error, not in thermal runaway error. Thermal runaway means actual temperature is NOT changing while it should. Thermal runaway is meant to troubleshoot either the FET running the hotbed or thermister falling off and not reading the temperature correctly.

billyd60, I am not using PID mode on that printer. I use bang-bang mode. So, it does not make sense to do PID optimization.

[billyd60]

Sorry missed that

[Grogyan]

You made the assumption that I have not read the entire thread, where as I have. Only two things could be at fault Poor PID, extruder PID, as you aren't using PID on bed Damaged thermistor Having already had experience with thermistors breaking, even with intermittent faults, my attention steers towards this in this case. After that, if redoing extruder PID doesn't fix it, and the thermistor has been replaced on the extruder and bed, there could be a problem with the ISR, unlikely, but possible. IF not problem is identified in the ISR, then the AVR might be defective.

[Sebastianv650]

I'm not shure if your error is related to the one described here earlier. The original problem here was a error message / printer shutdown that happened more or less instantly while the temperature has not significantly changed in reality.
Your problem is a hanging (always 100%) bed heater, that realy heats up your bed while (and that's intresting) the hotend temperature is still maintained by Marlin.

As far as I know, Marlin doesn't make a real difference between hotend and heated bed. Does anybody of the coders here knowing the temperature-code has an idea what could happen here except a very strange hardware failure?

@TAz00 can you repeat that issue with an older RC of Marlin, for example RC7?

[TAz00]

I think the difference is my big bed cant get hot enough to actually trigger the overheat warning, it has never actually stopped, ive just noticed it going up during my initial prints.

Here's a screencap where i told it to hold 45 for the extruder and 40 for the bed, which it does nicely.

*edit
Ive also found that disabling the bed intially, and then turning it on manually midway through the print, leads to the same constantly on runaway.

Configuration.zip
Uploading 20mmX20mmX20mm-hollow.gcode.zip…

[Sebastianv650]

The overheat/mintemp/printer reset was triggered due to wrong temperature readings and not called watchdog (inside the temperature loop), there was no real heat up / cool down involved in the issue described above.
But let's see if someone has an idea what could go on.

[TAz00]

Ahh right, yeah not the same problem as described. Tried RC7 and it's the same, holds temp fine while brimming, then going to constant on when starting the object. I'll try some older version and consider making a new issue.

[Angel996]

Hi, I'm the original poster.

Indeed, the problem is not exactly the same as mine: I really doubt my bed could climb significantly in temperature while G29 is running: at 110 degrees it heats pretty slowly. But it could also be the opposite: I think while G29 is running, bed thermal routine is not running, so the bed heater could be stuck in either state: ON or OFF. So, I think my case if was OFF. Previous poster case it was ON.

[TAz00]

Turns out, my heatsinks for mosfet 9&10 were touching. Sorry for cluttering.

[Anxles]

I see there are some doubts about is it a software and hardware problem. By no meens I am a programmer, I even struggle a little with configuration.h to understand all options. BUT I have same problem with RC8, I didn't try M29 but I have problem sa soon as I start the print. I have CORE XY enabled, printer of my own construction on Megatronics V2 board. everything was OK before but I had to make dual Z stepper for torque on Z axis, and I had to update Marlin for that as the old one didn't support that option for my board, I changed all the relevant settings, uploaded firmware, tested all the axis lcd etc (everything looked fine) the problem started when I tried to make a test print. As soon as it started BED temperature became ERRATIC jumping bewteen 400+ C and some LOW (I didn't notice how much) the jumps were sudden a few hunder degrees )
Long story short I checked the thermistor and connections, Changed to new thermistor and result is the same. After looking here and found people with the same problem, I configured RC6 to same parameters as RC8 and so far for few hours it's printing but still I can see some small and very short temp jumps (I have bed 40x40cm 10mm thick so thermal capacity is huge - by no meens possible any sudden temp, jumps).
Hope this will be resolved soon as options available at RC8 are very interesting and somehow I dont like Repetier firmware :)

[Sebastianv650]

This is already solved in the current RCBugFix branch. Please use this and try again.

[Anxles]

I was trying to find that fix as a while compilation which i just download and configure, but without success, I tried by Github search engine and by google, can You provide a link to complete set of files?

[Sebastianv650]

I'm not sure if i understand your problem. To download the latest code, just click "Code" left to the "issues" tab and switch with the drop down menu to "RCBugFix".

[Anxles]

Just tested Bugfix version, STILL have problem with temperature jumps on the bed, huuge this time: a few thousand degrees, the difference is it's not stopping the print this time.

[Sebastianv650]

Then it might be a different problem. If you also get spikes with rc6, this means it has nothing to do with the interrupts because the change was applied later.

[thinkyhead]

It seems like something is interrupting the ADC sensor reading, causing bad values. I'm not sure why G29 is especially causing this. I would expect it to also be a problem during G28 (especially if Z needs to move far).

[Anxles]

I had the spikes at RC6, but a FEW degrees only and very rare. At RC8 the spikes are huge, often, and every few spikes temperature bars dissapears completly for some miliseconds also which didn,t happen at RC6.

I found another problem which didn't exist on other firmware. I am loosing control of different parts of printer lets say randomly (didn't happen yet during print) After finishing print I am trying to prepare next one and cannot heat the printer, I get wrong readings, cannot reconnect host to the printer (loosing COM connection) restearting host doesn't help. Restarting PC does. I happens only on RCbugfix. I'm not sure if its firmware problem, but it does'nt happen on Regular Marlin.

[Angel996]

Just a small update.

I am building a CO2 laser cutter, so I decided to use Marlin for control. My device does not have any heaters or temp sensors, the temp reading is -15. However, in idle state, sometimes I get the "Heating failed" error and Marlin is killed although I never sent any heater related G-Codes.

[Sebastianv650]

@Angel996 can you try if #5949 fixes your issue on the laser?
Do you still have problems with normal printer since #5829?

[Sebastianv650]

Why you get a temperature reading when there is no temp. sensor - are you sure all sensors are set to 0 and no temperature protection is enabled?

[erikkallen]

I ran into the same issue with the runaway heater, the way I fixed it was to change
#define THERMAL_PROTECTION_PERIOD 40 // Seconds
#define THERMAL_PROTECTION_HYSTERESIS 4 // Degrees Celsius
in Configuration_adv.h the default settings where to strict for my slow heater (the problem in my case was that when both the extruder and the bed where heating up the bed probably reacted a bit slower)
Maybe this helps someone

[mbauer599]

Don't know if this helps anybody, but I was having this same issue during print with my delta. Seemingly random thermal runaways in the middle of prints. Pounded my head against the wall for some time with this and eventually realized that my board was getting to hot (It was under the heat bed, too close I guess). Put a fan on the board and haven't had this issue since.

[gosewski]

I can confirm that the problem with bed sensor thermal runaway exists in Marlin 1.1 and it is strictly software related issue. I had a Marlin 1.0 previously loaded to my Teensy board and there was newer thermal runaway problem. After flashing Marlin 1.1 the problem arised. After several config adjustments there were still random error occurances. I decided to flash back Marlin 1.0 and problem dissapeared. Therefore, my conslusion is that there is saome bug in the Marlin 1.1 code. By the way, the sound (beep) function was much better in Marlin 1.0, at least the frequency of the beep was predictable, what I can not say about Marlin 1.1.

[thinkyhead]

@gosewski — I use heated beds on all my machines and so far I have not seen any thermal runaway with any version of Marlin. Please test with the latest bugfix-1.1.x (and/or bugfix-2.0.x) branch and if you get spurious thermal runaway errors then please post a new issue with all the information requested in the issue template.

The tone player in Marlin 1.1.x is now asynchronous where the tone player in 1.0 was a blocking function. This may have an effect on its frequency on some boards.

[gosewski]

I wrote my last message just to save time and money for all the Marlin users experiencing thermal runaway problems and trying to fix it by replacing thermistors, instaling/replacing fans and doing all other hardware related things.
Regarding tone player, I can’t see any adventages of having not working or badly working asynchoronus one over a very well working synchronous.

[thinkyhead]

How about a well-working asynchronous?

With any luck someone will eventually come along to assist us in resolving your issues.

[gosewski]

Sure, every well-working function is welcome :)
I keep my finger crossed for Marlin firmware. Now I am focused on printing but having more time I’ll try to debug this thermal runaway as I did with Bluetooth function for Teensy.
Cheers,
Greg

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

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

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

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