Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Thermal Runaway Protection with 5A variant #1

Closed
Loc-Deu opened this issue Jan 4, 2020 · 30 comments
Closed

Thermal Runaway Protection with 5A variant #1

Loc-Deu opened this issue Jan 4, 2020 · 30 comments
Labels
documentation Improvements or additions to documentation good first issue Good for newcomers

Comments

@Loc-Deu
Copy link

Loc-Deu commented Jan 4, 2020

Hello,

nice Project! :)

Im getting a Thermal Runaway Protection error with the 5A Firmware.
Im not sure if this only belongs to the 5A, or something else.

Firmware:
119r05 and 119r06

Steps to reproduce:
Cold Printer
Start an Print on the SD Card
Target Temp on Display for Bed 55°C
It heats up, afer reaching the target Temp, it heats the Nozzle (Target 210°C)
While heating the Nozle my Bedtemp falls under 37°C, the Nozzle is at this time still heating at around 160°C
Printer stops with Thermal Runaway Protection on the Display

When slowly heating the Nozzle in 5°C steps the Warning doesnt apear and i can Print.

@tclupper
Copy link

tclupper commented Jan 4, 2020

I have been testing the firmware for the author (I have an old and new mini delta). I had a similar issue and he recommended the following custom g-code in Prusa Slicer to fix it. I have not had any issues since implementing it:

G28
; set and wait on hot end temperature (Set nozzle to just below PLA melting point)
M104 S150 T0
M109 S150 T0
; set and wait on bed temperature
M140 S[first_layer_bed_temperature]
M190 S[first_layer_bed_temperature]
; set and wait on hot end temperature (Finish raising the hot-end temp to set value)
M104 S[first_layer_temperature] T0
M109 S[first_layer_temperature] T0
; home axes, probe/adjust z-offset, and pause 4s
 G29 P0
G0 X0 Y0 Z60
G4 S4
; extrude a strip outside of the perimeter
G92 E0
G1 X-54 Y0 Z0.32 F2700
G3 X0 Y-54 I54 E20 F900
G92 E0

@aegean-odyssey
Copy link
Owner

Yes, the "thermal runaway" results from a limitation of the -05Alimit variant of the firmware.

Since the firmware gives priority to heating the nozzle (hotend), it does not maintain the bed temperature while it heats the nozzle (e.g if the nozzle PID control loop demands 80% of the power, the bed will receive a maximum of 20% of the power regardless what its PID control dictates). If Marlin cannot control the temperature (in this case the bed temperature) within a certain time period, it faults signalling the "thermal runaway" condition. Heating the nozzle first can avoid the situation where there is insufficient (remaining) power to heat the bed.

The starting G-code that @tclupper offers does just that -- thanks, @tclupper!

Early on, I adjusted the Marlin thermal runaway timeouts to allow heating the nozzle to 230°C and the bed to 70°C without triggering the "thermal runaway" condition. To test, I heated both the nozzle and bed, then waited for the nozzle and bed to reach temperature -- thinking back, I'm not sure I paid much attention to the initial nozzle and bed temperatures. The G-code:

M104 S230 T0  ; set the hotend temperature to 230°C
M140 S70      ; set the bed temperature to 70°C
M109 S230 T0  ; wait for the hotend temperature
M190 S70      ; wait for the bed temperature

I'll be sure to update the G-code in the example models, and in the PrusaSlicer-settings repository.

Perhaps there is a better way to limit the power in the -05Alimit firmware variant, but for now I'll consider the issue closed.

Thank you for the bug report and for giving the firmware a try.

@aegean-odyssey aegean-odyssey added documentation Improvements or additions to documentation good first issue Good for newcomers labels Jan 7, 2020
@aegean-odyssey aegean-odyssey pinned this issue Jan 7, 2020
@aegean-odyssey aegean-odyssey unpinned this issue Jan 7, 2020
@aegean-odyssey aegean-odyssey pinned this issue Jan 7, 2020
@aegean-odyssey aegean-odyssey unpinned this issue Jan 7, 2020
@aegean-odyssey
Copy link
Owner

On second thought, let's leave this issue open for now.

It contains @tclupper's useful information and GitHub displays open issues more prominently.

@aegean-odyssey aegean-odyssey reopened this Jan 7, 2020
@Loc-Deu
Copy link
Author

Loc-Deu commented Jan 7, 2020

Hello,

thanks for the help. I´d just testet, but had an Problem with Cura and the generated Startscript.
Cura adds by itselfe temperatursettings at the start before the custom Startcode.
I had to change the G-Code to the following.
My Printtemp for Bed is 55°C.

G28
; set and wait on hot end temperature (Set nozzle to just below PLA melting point)
M104 S155 T0
M109 S155 T0
; set and wait on bed temperature
M140 S55
M190 S55
; set and wait on hot end temperature (Finish raising the hot-end temp to set value)
M104 S{material_print_temperature} ;Start heating extruder
M140 S{material_bed_temperature} ;Start heating bed
M109 S{material_print_temperature} ;Wait for extruder to reach temp before proceeding
M190 S{material_bed_temperature} ;Wait for bed to reach temp before proceeding
; home axes, probe/adjust z-offset, and pause 4s
G29 P0
G0 X0 Y0 Z60
G4 S4
; extrude a strip outside of the perimeter
G92 E0
G1 X-54 Y0 Z0.32 F2700
G3 X0 Y-54 I54 E20 F900
G92 E0

Now its working for me and cura. :)
The {material_print_temperature} supresses the cura codegeneration at start.
maybe i can skip one of the M104 or M140 with this code, but its working.

@aegean-odyssey
Copy link
Owner

Thanks @Loc-Deu!

I've added your modifications to the wiki.

@Jaxtheripper
Copy link

Hi Aegean,

I've been trying to print from Simplify 3D with the following start code:

G28
; set and wait on hot end temperature (Set nozzle to just below PLA melting point)
M104 S155 T0
M109 S155 T0
; set and wait on bed temperature
M140 S50
M190 S50
; set and wait on hot end temperature (Finish raising the hot-end temp to set value)
M104 S[extruder0_temperature] ;Start heating extruder
M140 S[bed0_temperature] ;Start heating bed
M109 S[extruder0_temperature] ;Wait for extruder to reach temp before proceeding
M190 S[bed0_temperature] ;Wait for bed to reach temp before proceeding
; home axes, probe/adjust z-offset, and pause 4s
G29 P0
G0 X0 Y0 Z60 F3600 ; [DV: added feedrate]
G4 S4
; extrude a strip outside of the perimeter
G92 E0
G1 X-50 Y0 Z0.32 F2700
G3 X0 Y-50 I50 E20 F900
G92 E0

I can't get through a print without being stopped by thermal runway at this point i'm wondering if i missed something.

I flashed the 5A firmware, M502 then M500, ran the auto calibrate, set the offset then M500 again.

The longest a print has stayed on for is about 30 mins but a few have failed before that all from thermal runway, any advice?

Thanks for everything you have done so far!

@aegean-odyssey
Copy link
Owner

It looks like you are heating both the hotend and bed, and waiting for two to reach temperature; resulting in a thermal run-away error. I think some typos have crept into your gcode.

Here are a few corrections:

G28
; set and wait on hot end temperature (Set nozzle to just below PLA melting point)
M104 S155 T0
M140 S155 T0  ;** ###NOT### M109 S155 T0
; set and wait on bed temperature
M109 S50      ;** ###NOT### M140 S50
M190 S50
;** ###UNNECESSARY### (duplicate of above)
;** ;;; set and wait on hot end temperature (Finish raising the hot-end temp to set value)
;** M104 S[extruder0_temperature] ;Start heating extruder
;** M140 S[bed0_temperature] ;Start heating bed
;** M109 S[extruder0_temperature] ;Wait for extruder to reach temp before proceeding
;** M190 S[bed0_temperature] ;Wait for bed to reach temp before proceeding
; home axes, probe/adjust z-offset, and pause 4s
G29 P0
G0 X0 Y0 Z60 F3600 ; [DV: added feedrate]
G4 S4
; extrude a strip outside of the perimeter
G92 E0
G1 X-50 Y0 Z0.32 F2700
G3 X0 Y-50 I50 E20 F900
G92 E0

I think this start-up code should work.

@Jaxtheripper
Copy link

G28
; set and wait on hot end temperature (Set nozzle to just below PLA melting point)
M104 S205 T0
M140 S205 T0
; set and wait on bed temperature
M109 S50
M190 S50
; home axes, probe/adjust z-offset, and pause 4s
G29 P0
G0 X0 Y0 Z60 F3600 ; [DV: added feedrate]
G4 S4
; extrude a strip outside of the perimeter
G92 E0
G1 X-50 Y0 Z0.32 F2700
G3 X0 Y-50 I50 E20 F900
G92 E0

Just tried the above and got bed thermal runaway before the nozzle even heated.

I'm confused, I copied the gcode from above and change the syntax to work with simplify thinking the function of this code was to heat the nozzle first to 155, then heat the bed to 50, then finish heating the nozzle to print temp, then finish heating the bed in that order to prevent the thermal runaway, is this correct?

The unnecessary code from above finishes heating to print temp without that it would have stayed at 155 had i not changed it to 205, I had to uncheck 'Wait for temperature to stabilize...' in simplify for the first lot of code i posted to work or it would have gone to temp first then back down to 155.

@aegean-odyssey
Copy link
Owner

Oh my, I botched it. I apologize. Let me try again.

Your original code is indeed correct. I confused my gcodes. The strategy to avoid the thermal run-away error is to use the basic sequence:

  • set the hotend temperature
  • wait for the hotend temperature
  • set the bed temperature
  • wait for the bed temperature

The original startup code has two such sections; the first acts like a generic warm-up, and the second section sets the desired temperatures. BUT if you notice in the original startup, the second section does not adhere to our strategy. It seems that the first, warm-up alters the (remaining) heat-up time enough to avoid the run-away error in the second section. Really, though, one section should be all that is necessary.

Also, I'm guessing that you chose [extruder0_temperature] and [bed0_temperature] in your startup gcode as the temperature "place-holders" that Simplify 3D requires. If these are correct, then replacing the hard-coded temperatures with the place-holders should work as well.

For now, though, let's stick to the hard-coded temperatures:

G28
; set and wait on hot end temperature (Set nozzle to just below PLA melting point)
M104 S205 T0  ; or M104 S[extruder0_temperature] T0
M109 S205 T0  ; or M109 S[extruder0_temperature] TO
; set and wait on bed temperature
M140 S50  ; or M140 S[bed0_temperature]
M190 S50  ; or M190 S[bed0_temperature]
; home axes, probe/adjust z-offset, and pause 4s
G29 P0
G0 X0 Y0 Z60 F3600 ; [DV: added feedrate]
G4 S4
; extrude a strip outside of the perimeter
G92 E0
G1 X-50 Y0 Z0.32 F2700
G3 X0 Y-50 I50 E20 F900
G92 E0

Really this time, the above gcode should work. If it doesn't, we'll need to look at any gcode that might be running before this gcode.

Again, I apologize for making a mess of your issue.

@Jaxtheripper
Copy link

No apologies necessary, this is a still work in progress after all and once again thanks for your hard work, time spent and troubleshooting!

My first thought was to replace the hard coded temps with those after the correction but like you I chose to test with the hard coded ones. Alas bed thermal runaway again.

I also tested with the temp section taken out of the starting code completely and 'Wait for temperature controller to stabilize before beginning build' box on the temp section of Simplify checked instead and the same thing happened.

I have a 120mm fan and tl smoothers installed is there any chance they are an extra power sap or something?

Thanks for the responses by the way I'm dying to get this running again now, need something to play with while my CR-10 does bigger things.

@aegean-odyssey
Copy link
Owner

Reading back through your report, you mention that the printer begins printing and at some point the process stops with a thermal run-away error. If this is the case, I'm pretty sure the issue is NOT the startup g-code. The thermal run-away error in this case would occur because the machine is unable to maintain or measure the hotend or bed temperature. With the temperatures that you indicate in your report (205°C and 50°C) this should not be an issue.

So I'm wondering:

  • Is Simplify 3D changing the bed or nozzle temperature during the print?
  • Are the temperatures "bouncing" around during the print?
  • Are the heating elements and thermistors stock parts?

Your thought that your modifications may be consuming more power; the TL smoothers likely draw power -- power better spent on the bed and hotend. You can try to print without them. Ringing type of artifacts don't seem to be a big issue with this little printer. And with linear advance 1.5, the motion seems even more gentle.

Also, you mention a fan -- is it possible that the fan is cooling the bed? If this is the case, the cooling effect could be triggering the thermal run-away. What happens (my hypothesis) is the bed cools and the firmware tries to adjust -- BUT only with power not needed to keep the hotend at its set temperature. The firmware drives only one heater at a time and the hot-end always takes precedence. The bed, then, does not get enough power to maintain its temperature in a timely fashion and a thermal run-away error ensues. Something like this could be happening on your machine.

Here with the 12v 5A power supply, I have seen thermal run-away during the print when trying to ratchet up the bed temperature (>60°C) and nozzle temperature (230°C), that is, the bed temperature drops and the firmware cannot restore it, which leads to a thermal run-away error. Otherwise the machine does an ok job at maintaining its temperatures despite the firmware constaints when using a 12v 5A power supply.

@Jaxtheripper
Copy link

Just tried with the smoothers disconnected, same issue, then again with the fan disconnected (so back to stock hardware) and the same happened again.

The print usually starts laying down material then the temperature for both the bed and nozzle immediately start dropping and stops with thermal runaway before say the 5th layer, I suppose the bed is just the first to trigger the runaway. The one time it did get about half an hour into a print was with the smoothers in use. I have watched more or less every print and only seen it recover from a temperature drop once but it still failed a minute or so later. Only about 3 or 4 prints have made it past the 5th layer.

The nozzle and bed temps are a constant 205 and 50 throughout the print and the numbers do not fluctuate, until they start going down of course. As for the fan cooling the bed, the runaway happens with stock and 120mm so its anyones guess.

I assume if I were to buy the 10A power supply I could run with no problems and have all the upgrades I want installed? I only used the upgrades I have now because I had them lying around and heard they reduce the noise rather than for the print quality by the way. The fan does, not so sure about the smoothers. Of course I'd like to avoid buying a new power supply if I can.

@aegean-odyssey
Copy link
Owner

The 10A firmware will drive both the heated bed and the hotend at the same time. This is the only difference between the two firmware. But from what you describe, I'm not sure more power is the answer.

By the way, good troubleshooting. You've eliminated pretty much all of the variables. Is the nozzle temperature more or less maintained and the bed temperature drops? If so, then more power may be the answer. The '5A' firmware will strive to maintain the nozzle temperature; I would expect the nozzle temperature to oscillate around the set point, and the bed temperature oscillate but trend down. This would be a sign of not enough power.

Other possibilities? I'm a bit at a loss. Maybe the temperature control is working against us. If you're up for it, I'd try tuning the PID (temperature control) parameters. It's an automatic process using g-code, M303 with the U1 parameter (also see M301, M304). The firmware's default values came from a couple of autotune runs on my machine -- not much validation of their "correctness". I suggest this because I believe the 60w power adapter should be sufficient to maintain 205°C and 50°C temperatures. I think something else is going on.

Please report back. You have the dubious distinction of being the first here to report such a problem -- I'm sure your "trail blazing" will be helpful to others.

@PurpleHullPeas
Copy link

Unless something has changed in recent Marlin releases, I thought the PID autotuning algorithm calibrates the values based on the heater receiving constant power. I don't think autotuned values would work well in a situation where the power alternates between the hot end and the heated bed. Dennis Brown in the Facebook Group did some manual control tuning for the stock firmware, which also does not power both heaters at the same time. You could try using Dennis's values from this Thingiverse link. There is also a link to his research post there. https://www.thingiverse.com/thing:3892011

It is also worth mentioning that stock 5A PSU failures are semi-common amongst users in the Facebook Group, so it could just be a bad or dieing PSU.

@aegean-odyssey
Copy link
Owner

Thank you for your comments, @PurpleHullPeas. I agree. The power limiting "hack" that's in the "5A" firmware introduces a non-linear element into the control loop. That's why I would't put much stock in the autotune values as being "optimal". The (successful) autotune process does find a way though to heat the components to their target values. Control-wise, printing doesn't demand too much performance out of the PID loop, so I think it's ok.

Very good point about the power supply; if the 60-watt power supply is subpar and not able to actually deliver 60-watts, then a thermal run-away error is a likely result. In this case, it may be that the power supply is unable to continuously deliver its rated power.

Thanks for the insight. One of the project's goals is to reduce frustration with using the Monoprice Mini Delta printer. The more specific the solutions we find to these types of issues, the closer we get to the goal. I appreciate your help.

@Jaxtheripper
Copy link

Well, tried a PID autotune on both hotend and bed then ran a print with the usual result, then used the values from @PurpleHullPeas thingiverse link and ran a print and again the same result. I then moved the printer into a different room and reran the autotune and tried again and of course the same.

I have no idea how to test the power supply but I have a crap multimeter and could google how to test if you think it is worth it?

Otherwise what are my options? Revert to stock firmware or buy 10A power supply?

Thanks again for the time and attention.

@PurpleHullPeas
Copy link

Reverting to stock firmware is a good idea. That would show whether or not it is a hardware problem. You could also try the stock firmware default PID values on Marlin, but I don't have those on-hand.

@Jaxtheripper
Copy link

In my reluctance to revert, inability to find the stock PID values and general stubbornness I got out an old universal laptop power supply which is rated higher than the stock power supply (24V 6A 90W) and tried that, still no. Shouldn't this rule out power supply? I think the chances of them both being bad is unlikely. Ideas or Info?

Just for a bit of extra info the led readout on the new power brick is 15.4v.

@aegean-odyssey
Copy link
Owner

Hmm, you should really stick to the design voltage of 12v. The 60-watt supply should be 12v @ 5A, and the 120-watt supply should be 12v @ 10A. Over voltage is likely hard on (and damaging to) the equipment. I recall when examining the controller board that the MOSFETs switching the heating elements were rated for a current of 7.5A, I think. I don't know what the voltage limits are. All fans are 12v, etc. -- so you really shouldn't power it with more than a 12v supply.

If your 24v power brick is reading 15v (open-circuit) then something is not right, and the power supply may not have survived your experiment. If the voltage is 15v while using the printer, then hopefully it's because some kind of over-voltage protection is working on the printer. (15v @ 6A is roughly a 90 watt draw on the power supply; something is drawing more current than it should)

If you can try the stock firmware, it will give the definitive answer for is it a hardware issue or not. I suspect that there is something amiss with the hardware.

@PurpleHullPeas
Copy link

I would also add that if you are testing it with the same file, corrupt gcode is also a possibility. This is especially possible if using the stock SD card, as it is prone to failure.

@see3d
Copy link

see3d commented Jul 12, 2020

Just to add another dimension to this conversation. I have a 10A PS that has been running M4MPMD in my machine for over a year. I am about to try out 1.1.x today, so reading up on the issues. I was recently having the thermal runaway resets when I tried to make a production run of parts and I did not let the head cool down enough before restarting the next print. There does seem to be some internal settings in the Marlin thermal error checking that can be a problem depending on the operating circumstances.

I also noticed that while printing PETG at 140C (bed 50C), the hot end was slowly losing its ability to hold the temperature as the print speed increased. I was printing vase mode, so filament flow was continuous and temperature went from 240C to 220C before I slowed everything down. However, raising the power supply to 13V (very safe for the board, the fans only ran marginally faster), had a fantastic effect on hot end performance. It had no problem keeping up, and took half the time to get up to temperature. The opposite could be true. The stock power supply can have the voltage sag under load. A small drop can have a big effect on hot end and bed performance. (Dennis Brown)

@aegean-odyssey
Copy link
Owner

Very interesting, @see3d. I need to open up my printer and collect part numbers of the MOSFETs, etc. to get a better sense of what some of the design limits are for the controller board. From your experience, though, there may be a more optimal "beefier" supply option other than the 12v@10A power adapter. I'll have to peruse some datasheets and mull over your numbers. Perhaps there is a better way to supply and control the power to the nozzle and bed. Thank you for providing the full details.

Still curious to hear about @Jaxtheripper's resolution to the issue.

@see3d
Copy link

see3d commented Jul 13, 2020

@aegean-odyssey. A few more details. I am aware of another user running the MPMD with an 18V PS for quite a while now (posted about it in the MPMD FB page). It may be capable of running at 24V, but I would be cautious about the heat from the 3.3V regulator and initial current to the 12V heaters. 13V worked so well that I do not see any reason to push it higher. I am actually running on a 12V 10A PS. It is just that there is a trim pot for the output voltage. 13V is about a high as the trim pot will let it go. I do not plan on going back to 12V.

@aegean-odyssey
Copy link
Owner

aegean-odyssey commented Jul 13, 2020

Thanks for the update. I'm not sure putting 18v on the controller board is a good idea. As you mention, the 3.3v supply input may be taxed; the 12v fans will be taxed; and the MOSFETs for the hot end and the bed heater have heat dissipation limits and possibly gate-source voltage limits. I think there's also "fly-back" considerations when switching inductive loads (i.e. the stepper motors). The 13v/12v difference, being less than 10% above, should be perfectly acceptable. I think we have classic Ohm's law at work here, V = I·R; increased V increases I which puts more power, V·I, into more or less constant R (the heating element).

@Jaxtheripper
Copy link

@aegean-odyssey I think I have a faulty or broken thermistor, tried both stock and your firmware with multiple PID tunings and still cant get through a print.

@PurpleHullPeas
Copy link

@Jaxtheripper If you're on stock, make sure you send M502 to use the stock PID settings. PID autotuned will not produce good results on stock because the firmware was modified to only deliver power to the bed or nozzle, not both at the same time.

@aegean-odyssey
Copy link
Owner

@Jaxtheripper, thanks for the update. Please feel free to report any findings or resolutions.

Also, I updated the wiki to include a note with the startup g-code that you modified for Simplify 3D. I'm sure others will find it useful.

@rauldelga
Copy link

Hello. I'm running into the same issue. 05A. I've ran the recommended start gcode. It's hit or miss when it happens, i can't find a pattern. I did notice that if i preheat using the LCD, everything goes well. But if I print from gcode using the above recommendation, the bed thermal runaway will occur. Has any resolution been found? I did M502 to restore defaults.

On stock firmware, i never received this error if that matters. For now i'm just gambling on every print. Thank you.

@aegean-odyssey
Copy link
Owner

It's a very definite limitation of the 05A firmware: so as to not demand more power than the 60W (12V@5A) power supply can deliver, the firmware does not allow both the hotend and the bed heater switches to be "on" at the same time. It implements a simple rule: the hotend has priority -- so if the hotend's PID control demands 100% of the power, the heated bed receives 0% regardless of what its PID control demands. This is pretty much the situation while the nozzle is pre-heating. AND, since Marlin's PID control is unaware of the constraint, Marlin's safety features interpret the slowly heating bed as a problem.

It's possible that in your case the PID control is not as efficient as it could be. Auto-tuning the PID parameters may improve the pre-heating process enough to avoid the thermal runaway conditions. Please take a look at (closed) issue #31 for discussion and a solution that may work for you.

Thank you for giving the firmware a try. Please report back any findings. I'm sure it will help us figure out how to get the most out of the printer with its "factory equipment".

@aegean-odyssey
Copy link
Owner

moved to FAQ

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

7 participants