E1 Thermal Runaway
BackwardEcho opened this issue · 12 comments
I am experiencing some thermal runway errors with my printer as it starts to print. I'm gonna check my hotend to see if anything jostled around as I caught the printer from being almost dropped by the back of my chair before I for sure say anything else. I get temp readouts any other time, but it seems to stop after a print starts.
Aside from physically checking it, should I look for anything else? I am running 119r14 and just about finished resetting the settings after a m502 (do I need to do that when updating the firmware from an older version?)
Well... I flashed back to r13 and got further than before. Gotta redial my Z offset now...
But I guess it was software based, either by doing a weird combo of menu operations that it didn't like or r14 simply was bugged for me.
Unless you want me to test something, I think I'll stay on r13 for now.
Hmm, doesn't sound like a firmware issue, though the settings (stored in flash memory) may be scrambled during a firmware update. If you've been printing successfully with 119r13, then 119r14 should work -- pretty much only the bed tapping was changed.
Thermal run-away is a known limitation with the printer. The printer's 60-watt power adapter is just adequate; it cannot supply sufficient current to heat the nozzle and the bed at the same time. The -05Alimit firmware, compiled specifically for the stock 60-watt power adapter, enforces the one (nozzle or bed) heater at a time rule giving priority to the nozzle. This may cause the bed to heat very slowly (or not at all). The priority scheme is rather simple, handled at a low-level in the firmware, and the Marlin safety code (i.e., thermal run-away monitor) isn't aware of it. So if the bed heats too slowly, a thermal run-away error may occur -- eventhough everything is technically working correctly.
Issue #1 talks about this limitation and offers some work-arounds for the thermal run-away condition.
Of course, thermal run-away is triggered by genuine faults on the printer as well -- bad connection, bad component, incorrect settings, ... I suspect your issue is somewhere in this list. I'm thinking dislodged, bad, or broken connection, or a settings issue.
Issues #39, #31, #4 are not the same issue, but the solutions may be helpful.
Again, if you've success with 119r13, then 119r14 should work. Hopefully the problem is (perhaps inadvertently) fixed and your printer will get back to working. Please report any findings.
I am running the 10a variant though, SM0001-ACfan-10Alimt specifically. I was able to preheat the bed and nozzle to temp but for some reason it just died after starting a print.
Ok. The -10Alimit firmware variant does not limit the power consumption of the printer. On the plus side, with this firmware the printer can heat the bed and nozzle together. On the downside, if the power supply cannot supply sufficient power (for whatever reason), then the printer may "fault". One way to rule out this scenario as the problem is to try the -05Alimit firmware with the 120-watt power supply. If things work, then it is likely the power supply is not meeting the demands placed on it with the -10Alimit firmware. Not the final answer, but we will have narrowed the possibilities considerably. Though, if you're using a 120-watt power adapter with the -10Alimit firmware, I don't think that this is the problem -- not enough power would lead to a "brownout" type of situation and I would expect the machine/firmware to go "belly up"; more of a crash as opposed to Marlin's controlled fault handling.
It is confusing to me that 119r13 works for you and 119r14 does not -- and that something is tripping Marlin's fault handling. So, some questions:
-
What the target hotend and bed temperatures for the test print?
-
Are you printing via a host, like Octoprint or Pronterface?
-
For your tests, printing the same G-code works in
119r13but not119r14? -
Does the auto-calibration procedure complete successfully with
119r14? -
Does the
-05Alimitfirmware work?
Hopefully some bit of information will offer a clue and point us in the right direction.
I am using a 12v 10A 120-watt power supply, so it shouldn't be in sufficient power for this. Would Marlin's fault handling allow a print to be cancelled? When the error triggered the printer would just stay in place attempting to cancel (as shown by "Cancelling...") and would need to be rebooted to respond, of which I have used the led button to do so a couple of times.
-
215 / 50
-
via SD card mostly, tried once with Cura's usb connection but the same happened. It also stopped accurately reporting the hotend temp when the error triggered.
-
I believe I used the same gcode, I use the stock sd card that came with my printer for firmware flashing while using a newer and Kingston branded for printing, and I don't think I resliced it in between firmware flashes.
-
I believe it did. I got the "Check CALIBRAT" text a couple of times when I ran the auto-calibration in sequence.
-
Did not test since I have the larger power supply. I guess I can try since I haven't been messing too much with setting calibration yet. I assume you want me to try
119r14 -05Alimit?
Nothing seems unusual or suspect. I'm inclined to agree with you, power is not likely the problem.
One thing to note, though, when the printer faults, is the LED flashing red (and requires a button press to continue)? If so, then the printer is being deliberately stopped by the Marlin firmware -- which may point to an equipment problem, bad connection, bad component, etc.
Could you check and repair the SD card with a disk utility? The firmware does not do a whole lot of checking when reading from the SD card, nor is it terribly graceful when encountering SD card errors. I think trouble reading the SD card during the print could cause the behavior you describe.
After it happened, I took apart my hotend to see if a wire came loose there. I then took a look inside the printer and didn't see anything out of the ordinary there. If it was a hardware fault wouldn't 119r13 have caught the same issue?
<edit : yes, I saw the red flashing light.
Windows didn't find any issue with the card using Error Checking in the Tools tab under Properties for the card.
Yes, I agree with you -- I would think 119r13 and 119r14 would share problems.
Any message on the display with the LED is flashing red? -- something like "STOP" or "Thermal runaway". The flashing red occurs in three situations, thermal run-away (e.g. a wild temperature reading or temperature target not reached in a appropriate time frame), motion problem (e.g. something interfering with motion), or emergency stop G-code (M112).
One way in which the two firmware versions differ is that 119r14 is a bit more "aggressive" with it's initial tapping motion. It's a stretch, but a mechanical problem, such a bad connection, could present differently, I guess.
The printer here has logged many, many hours with119r14 (-05Alimit), and it's hard to see how the -10Alimit would act differently. I'll look more closely at the changes from 119r13 to 119r14 -- perhaps you're the first to be using the -10Alimit variant of 119r14.
If you could, please try 119r14 -05Alimit firmware. If it works for you and the -10Alimit does not, then it's likely I broke something in the firmware.
Ok, I will do that... tomorrow. I need to go to bed soon for work then I am off for 2 days.
... I don't know what to tell you...
I tried the -05Alimit version and that triggered, probably due to the bed losing temp when the target was 50.
I went back to the -10Alimit and now it's not triggering... same gcode...
The only difference I can think of when flashing the firmware is that this time I had a SD card extender in the middle where before the card went directly into the slot.
Man... I don't know how to feel about this printer....
Thank you for running the test. Not entirely conclusive, but helpful. As luck would have it, in issue #42 there is confirmation that the 119r14 -10Alimit does/can work.
It's possible that the update process was somehow buggered, but that kind of problem usually causes a very low-level fault indicated with a solid (not flashing) red LED.
I really think that there is a bad connection somewhere; the thermistor connections being at the top of my suspect list. A wild temperature reading (from a shorted or open sensor connection) would trigger a fault almost immediately and likely before the temperature reading is registered on the display. The firmware ignores the bed switches when printing, but a false trigger from the optical endstops would also probably abort the print.
Hang in there -- I know it's frustrating. If it's any consolation, I've been using the machine heavily for the past two months and I am pleased with how well it prints and how "frustration-free" it's become. Really fun. Enough so, that I picked up another "open box" MP Mini Delta from Monoprice to continue experimenting. My first three months with the printer, though, were so disappointing that I eventually took up this firmware project looking for solutions.
Please report any findings. I am sure your experience will be helpful to others. Don't give up on the printer just yet.
I don't plan to give up on it, but it is annoying as hell when something decides to quit only for it to fix for no reason. Knowing what caused it to work would be nice. There was no absurd temperature reading: it would get up to temp, hold, start the print, and then slowly just drop. The read out would get to 211 and then stop reporting, which was when the error would trigger.
I plan to make this thing as frustration free for me as I can. I just fought with my Tronxy X5SA-400 for a few months not knowing what was causing it to jam (it was a stupid low temp), but in the process of finding the issue I metaphorically beat it into the ground with everything I could think of. So now it starts nicely and is easy to deal with.