Thermal runaway after latest firmware upgrade

Get Help
1

I have a Anet a8 running octoprint on raspberry pi. Just lately I have had an issue that after printing approximately 15-20 minutes Octoprint shuts down my print for a bed thermal runaway. I have checked all my hardware external MOSFET, Thermistor, and connections and all are fine. I also tried printing a file that I printed just prior to this problem with the same results. I can set a Temperature on the bed without loading a print and it will stay just fine. I even left it that way for an hour and didn't have a problem.

I disconnected the Pi and printed from SD card keeping an eye on the temperatures and the Printer printed just fine and the temps stayed constant.

Here is a screen shot of the temperature graph at the time of shutdown.

Inkedthermal%20runaway_LI
Inkedthermal runaway_LI.jpg1164×584 113 KB

I am running the Latest version

2018-11-16 02:35:56,809 - octoprint.environment - INFO - Detected environment is Python 2.7.13 under Linux (linux2). Details:
|  hardware:
|    cores: 4
|    freq: 1200.0
|    ram: 918192128
|  os:
|    id: linux
|    platform: linux2
|  plugins:
|    octopi_support:
|      model: 3B
|      revision: a22082
|      version: 0.15.1
|  python:
|    pip: 9.0.3
|    version: 2.7.13
|    virtualenv: /home/pi/oprint
2018-11-16 02:35:56,821 - octoprint.server - INFO - Reset webasset folder /home/pi/.octoprint/generated/webassets...
2018-11-16 02:35:56,839 - octoprint.server - INFO - Reset webasset folder /home/pi/.octoprint/generated/.webassets-cache...
2018-11-16 02:35:57,115 - octoprint.server - INFO - Shutting down intermediary server...
2018-11-16 02:35:57,589 - octoprint.server - INFO - Intermediary server shut down
2018-11-16 02:35:57,592 - octoprint.events - INFO - Processing startup event, this is our first event
2018-11-16 02:35:57,593 - octoprint.events - INFO - Adding 0 events to queue that were held back before startup event
2018-11-16 02:35:57,595 - octoprint.filemanager - INFO - Adding backlog items from all storage types to analysis queue...
2018-11-16 02:35:57,609 - octoprint.filemanager - INFO - Added 0 items from storage type "local" to analysis queue
2018-11-16 02:35:57,768 - octoprint.util.comm - INFO - Changing monitoring state from "Offline" to "Detecting serial port"
2018-11-16 02:35:57,795 - octoprint.plugins.discovery - INFO - Registered OctoPrint instance on octopi for _http._tcp
2018-11-16 02:35:57,807 - octoprint.util.comm - INFO - Changing monitoring state from "Detecting serial port" to "Opening serial port"
2018-11-16 02:35:57,810 - octoprint.util.comm - INFO - Changing monitoring state from "Opening serial port" to "Detecting baudrate"
2018-11-16 02:35:57,813 - octoprint.plugins.discovery - INFO - Registered OctoPrint instance on octopi for _octoprint._tcp
2018-11-16 02:35:57,819 - octoprint.plugins.discovery - INFO - Registered OctoPrint instance on octopi for SSDP
2018-11-16 02:35:57,828 - octoprint.server - INFO - Listening on http://127.0.0.1:5000
2018-11-16 02:35:57,926 - octoprint.util.connectivity_checker - INFO - Connectivity changed from offline to online
2018-11-16 02:35:58,248 - octoprint.server.preemptive_cache - INFO - Preemptively caching / (ui _default) for {'query_string': 'l10n=en', 'path': '/', 'base_url': 'http://wildvortexprint.asuscomm.com/'}
2018-11-16 02:35:58,820 - octoprint.util.comm - INFO - M110 detected, setting current line number to 0
2018-11-16 02:35:58,835 - octoprint.plugins.pluginmanager - INFO - Loaded plugin repository data from https://plugins.octoprint.org/plugins.json
2018-11-16 02:35:58,917 - octoprint.plugins.pluginmanager - INFO - Loaded plugin repository data from https://plugins.octoprint.org/plugins.json
2018-11-16 02:36:00,151 - octoprint.server.util.sockjs - INFO - New connection from client: ::ffff:192.168.1.1
2018-11-16 02:36:00,408 - octoprint.plugins.pluginmanager - INFO - Loaded plugin notices data from https://plugins.octoprint.org/notices.json
2018-11-16 02:36:00,655 - octoprint.plugins.pluginmanager - INFO - Loaded plugin notices data from https://plugins.octoprint.org/notices.json
2018-11-16 02:36:02,376 - octoprint.server.util.sockjs - INFO - New connection from client: ::ffff:192.168.1.1
2018-11-16 02:36:21,178 - octoprint.util.comm - INFO - M110 detected, setting current line number to 0
2018-11-16 02:36:22,074 - octoprint.server.preemptive_cache - INFO - ... done in 23.83s
2018-11-16 02:36:22,075 - octoprint.server.preemptive_cache - INFO - Preemptively caching / (ui _default) for {'query_string': 'l10n=en', 'path': '/', 'base_url': 'http://97.82.200.220/'}
2018-11-16 02:36:22,385 - octoprint.util.comm - INFO - M110 detected, setting current line number to 0
2018-11-16 02:36:23,455 - octoprint.util.comm - INFO - M110 detected, setting current line number to 0
2018-11-16 02:36:24,769 - octoprint.util.comm - INFO - M110 detected, setting current line number to 0
2018-11-16 02:36:26,096 - octoprint.util.comm - INFO - M110 detected, setting current line number to 0
2018-11-16 02:36:26,741 - octoprint.util.comm - INFO - Changing monitoring state from "Detecting baudrate" to "Operational"
2018-11-16 02:36:26,747 - octoprint.util.comm - INFO - M110 detected, setting current line number to 0
2018-11-16 02:36:26,759 - octoprint.plugins.firmwareupdater - INFO - Got CONNECTED event
2018-11-16 02:36:26,762 - octoprint.plugins.firmwareupdater - INFO - Run postflash flag is not set
2018-11-16 02:36:26,927 - octoprint.util.comm - INFO - Printer reports firmware name "Marlin 1.1.8 (Github)"
2018-11-16 02:36:26,942 - octoprint.util.comm - INFO - Firmware states that it supports temperature autoreporting
2018-11-16 02:36:26,983 - octoprint.util.comm - INFO - Firmware states that it supports temperature autoreporting
2018-11-16 02:36:27,002 - octoprint.util.comm - INFO - Firmware states that it supports temperature autoreporting
2018-11-16 02:36:29,124 - octoprint.server.preemptive_cache - INFO - ... done in 7.05s
2018-11-16 02:39:53,379 - octoprint.util.comm - INFO - Changing monitoring state from "Operational" to "Printing"
2018-11-16 02:39:53,396 - octoprint.util.comm - INFO - M110 detected, setting current line number to 0
2018-11-16 02:50:50,334 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2018-11-16 02:55:04,324 - octoprint.util.comm - WARNING - Received an error from the printer's firmware: Thermal Runaway, system stopped! Heater_ID: bed
| Last lines in terminal:
| Send: N4597 G1 X55.403 Y87.859 E11.2320*82
| Recv: ok
| Send: N4598 G1 X59.470 Y91.926 E11.4580*81
| Recv: ok
| Send: N4599 G1 X59.903 Y91.723 E11.4768*86
| Recv: ok
| Send: N4600 G1 X55.836 Y87.656 E11.7027*85
| Recv: ok
| Send: N4601 G1 X56.269 Y87.453 E11.7215*83
| Recv: ok
| Send: N4602 G1 X60.337 Y91.520 E11.9475*83
| Recv: ok
| Send: N4603 G1 X60.770 Y91.317 E11.9663*82
| Recv: ok
| Send: N4604 G1 X56.703 Y87.250 E12.1923*81
| Recv: ok
| Send: N4605 G1 X57.136 Y87.046 E12.2111*94
| Recv: ok
| Send: N4606 G1 X61.203 Y91.114 E12.4371*94
| Recv: Error:Thermal Runaway, system stopped! Heater_ID: bed
2018-11-16 02:55:04,326 - octoprint.util.comm - INFO - Changing monitoring state from "Printing" to "Error: Thermal Runaway, system stopped! Heater_ID: bed"

Hope this is helpful, I can't make a whole lot of sense of it exceptThe thermal runaway erors and G1 positioning.

Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, octoprint.log, serial.log or output on terminal tab, ...)

2

That's your printer's firmware saying it can't maintain the temperature of the bed, so octoprint shuts down all activity.

The heaters are on, but the temperature is decreasing, so the printer thinks either the sensor has come loose or the power delivery has failed in some way.

I disconnected the Pi and printed from SD card keeping an eye on the temperatures and the Printer printed just fine and the temps stayed constant.

Was it the same file? I've had thermal runaway issues when the print head stops just above the sensor on the bed, so the cooling fan cools that one particular spot off and the printer freaks out about it.

Since you said you just updated the firmware, are you using any sort of PID control on the bed now? Maybe that needs tuning?

3

Yes, it was the same file. I printed once more and was able to get through a print that was giving me trouble yesterday. I get a great even wave on the graph for a while then it goes crazy. Might be the controller but I use an external MOSFET to heat my bed. When I bypass that and go directly to the controller board I get the same thing.

4

Double and triple check all connections to the bed, mosfet and board, and at the power supply as well. Looking at the graph, the temperature of the bed is dropping slowly before it triggers. Either the power supply is taking a dump and can't keep up, there are some bad, loose, crusty connections, or the bed thermistor has come out of it's hole and is getting hit by a draft cooling it down.
Looking at the graph, I would also suggest a pid tune for bed and extruder. WAY too many fluctuations.

1 Like
5

Yes, believe that even though I have upgraded the power supply from a 240W to a 350W I am almost sure now that the PSU can't keep up now that there is cooler weather. Ambient temperature is atleast 5°F cooler. Plan on building an enclosure.

Onto the second part you mentioned, didn't know you could PID tune the controller. Can you explain how? Not like my quads entirely I am sure.

6

I added a foam door to the front of my printer and it really helps to control the temperature inside the box.

7

The Anet a8 is totally open. I have 1 in. Foam board enough to build a total enclosure. Will use a glass door but may change after if it is not enough

8

I have run the same print at 70C bed temp and have no problems I do believe that the lower ambient temperature is the culprit. I assume that possibly the power supply is going or was never any good to begin with.

9

I actually did this for a while and put an extra Raspberry Pi 3B inside the print volume with a PiSense Hat to display the temperature so that I can see it from the webcam:

The extra Raspberry Pi 3B running inside the print volume keeps everything around 90-100 degrees Fahrenheit and helps with adhesion since I don't have a heated bed. I no longer have any problems with part curling, for what it's worth. I deduced that curling was caused by inconsistent air temperatures within the print volume so boxing things in helped.

10

Guess I should have asked if you are running Marlin or stock... Marlin supports PID tune, stock doesn't

11

I am running Marlin. Now I know how to search the topic. Thanks

12

I tried auto tune on the bed and kept getting an error. Went into my editor to look at Marlin config.h file and see that bed PID tuning is off. Is there any way to turn this on without reflashing Marlin?

13

Nope, it's by default commented out, so that part of the code was never compiled into the hex file that actually gets uploaded.

14

That I knew. Just wasn't sure if it could be turned on without a new flash. Hope that this flash goes better than the first time. Took 2 weeks to fix a bad flash. Board was almost bricked.

15

You should backup your flash memory before making the attempt. In theory, you could upload that back to the board. More talk...

16

Ok, how is that done or is easily searchable online?

17

Follow the link I provided. That's me talking about the process.

18

Yah, I notice that link after I sent that.

19

So, I assume that this part is what I am really looking for

avrdude -c avrispmkII -P /dev/cu.usbmodem14201 -b 115200 -p ATmega2560 -U flash:r:backup_flash.bin:r

and I don't need a FTDI programmer?

20

Begin with an...

avrdude -c avrispmkII -P /dev/cu.usbmodem14201 -b 115200 -p ATmega2560 -v

...and see if it's happy first. Use your existing serial cable. If you move the USB plug to a different outlet on your computer, don't be surprised if that /dev/cu.usbmodem14201 changes to /dev/cu.usbmodem14101 or similar. This device name is what I see on my MacBook Air if I plug it in on the left or right side.

Your device name might be different of course. Plug the cable in with the printer powered and on your workstation, run the command ls -l /dev/cu.usb* to see a list of devices in your case.