Thermal Runaway Protection absent on Creality Ender 3

The problem is that it doesn't suffice to know that their current sources are fixed, we need to verify that the stock firmware shipped with printers is fixed and also need to figure out how to detect that newer fixed version.

Just asked my Chinese friend to translate the text following Marlin1.1.6. He says it is "off the power and continue to support company", which did not make much sense even to him in this context.

I just tested my ender 3 purchased in December 2018 by telling it to heat the hot end, then uplugging the hot end thermistor at the main board... This throws an error and turns off the hot end heater so it is fixed in their latest firmware. I did the same test with the heated bed and it doesn't throw an error but it does stop heating.

Octoprint does show it has an issue so I assume it needs to be updated.

OctoPrint 1.3.10 running on OctoPi 0.15.1

I captured the serial.log but don't see a place to upload it here, so putting it inline.

2019-02-17 17:14:27,389 - Send: M503
2019-02-17 17:14:27,483 - Recv: echo:Steps per unit:
2019-02-17 17:14:27,485 - Recv: echo:  M92 X80.00 Y80.00 Z400.00 E93.00
2019-02-17 17:14:27,486 - Recv: echo:Maximum feedrates (mm/s):
2019-02-17 17:14:27,488 - Recv: echo:  M203 X500.00 Y500.00 Z5.00 E25.00
2019-02-17 17:14:27,490 - Recv: echo:Maximum Acceleration (mm/s2):
2019-02-17 17:14:27,492 - Recv: echo:  M201 X500 Y500 Z100 E5000
2019-02-17 17:14:27,494 - Recv: echo:Acceleration: S=acceleration, T=retract acceleration
2019-02-17 17:14:27,496 - Recv: echo:  M204 S4000.00 T500.00
2019-02-17 17:14:27,498 - Recv: echo:Advanced variables: S=Min feedrate (mm/s), T=Min travel feedrate (mm/s), B=minimum segment time (ms), X=maximum XY jerk (mm/s),  Z=maximum Z jerk (mm/s),  E=maximum E jerk (mm/s)
2019-02-17 17:14:27,509 - Recv: echo:  M205 S0.00 T0.00 B20000 X20.00 Z0.40 E5.00
2019-02-17 17:14:27,511 - Recv: echo:Home offset (mm):
2019-02-17 17:14:27,512 - Recv: echo:  M206 X0.00 Y0.00 Z0.00
2019-02-17 17:14:27,514 - Recv: echo:PID settings:
2019-02-17 17:14:27,515 - Recv: echo:   M301 P19.77 I1.23 D79.68
2019-02-17 17:14:32,229 - Send: M115
2019-02-17 17:14:32,263 - Recv: FIRMWARE_NAME:Marlin V1; Sprinter/grbl mashup for gen6 FIRMWARE_URL: PROTOCOL_VERSION:1.0 EXTRUDER_COUNT:1 UUID:00000000-0000-0000-0000-000000000000
2019-02-17 17:16:31,716 - Changing monitoring state from "Operational" to "Offline (Error: SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)' @"
2019-02-17 17:16:31,724 - Connection closed, closing down monitor
2019-02-17 17:16:45,460 - Changing monitoring state from "Offline" to "Detecting serial port"
2019-02-17 17:16:45,485 - Serial port list: ['/dev/ttyUSB0']
2019-02-17 17:16:45,486 - Connecting to: /dev/ttyUSB0
2019-02-17 17:16:45,495 - Changing monitoring state from "Detecting serial port" to "Opening serial port"
2019-02-17 17:16:45,500 - Connected to: Serial(port='/dev/ttyUSB0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
2019-02-17 17:16:45,502 - Starting baud rate detection...
2019-02-17 17:16:45,503 - Changing monitoring state from "Opening serial port" to "Detecting baudrate"
2019-02-17 17:16:46,511 - Trying baudrate: 115200
2019-02-17 17:16:46,525 - Send: N0 M110 N0*125
2019-02-17 17:16:46,530 - Recv: start
2019-02-17 17:16:46,536 - Changing monitoring state from "Detecting baudrate" to "Operational"
2019-02-17 17:16:46,556 - Send: N0 M110 N0*125
2019-02-17 17:16:46,557 - Recv: echo: External Reset
2019-02-17 17:16:46,560 - Recv: Marlin 1.0.0
2019-02-17 17:16:46,564 - Recv: echo: Last Updated: Sep  3 2018 15:45:59 | Author: (Ender3)
2019-02-17 17:16:46,567 - Recv: Compiled: Sep  3 2018
2019-02-17 17:16:46,571 - Recv: echo: Free Memory: 9679  PlannerBufferBytes: 1232
2019-02-17 17:16:46,573 - Recv: echo:Stored settings retrieved
2019-02-17 17:16:47,469 - Recv: echo:SD card ok
2019-02-17 17:16:47,473 - Recv: Init power off infomation.
2019-02-17 17:16:47,475 - Recv: size:
2019-02-17 17:16:47,477 - Recv: 591
2019-02-17 17:16:47,479 - Recv: init valid:
2019-02-17 17:16:47,482 - Recv: 0
2019-02-17 17:16:47,485 - Recv: 0
2019-02-17 17:16:47,570 - Send: N1 M115*39
2019-02-17 17:16:47,575 - Send: N2 M21*18
2019-02-17 17:16:47,622 - Recv: FIRMWARE_NAME:Marlin V1; Sprinter/grbl mashup for gen6 FIRMWARE_URL: PROTOCOL_VERSION:1.0 EXTRUDER_COUNT:1 UUID:00000000-0000-0000-0000-000000000000
2019-02-17 17:16:47,629 - Recv: echo:SD card ok
2019-02-17 17:16:47,631 - Send: M20
2019-02-17 17:16:47,634 - Recv: Init power off infomation.
2019-02-17 17:16:47,655 - Recv: size:
2019-02-17 17:16:47,659 - Recv: 591
2019-02-17 17:16:47,662 - Recv: init valid:
2019-02-17 17:16:47,665 - Recv: 0
2019-02-17 17:16:47,668 - Recv: 0
2019-02-17 17:16:47,674 - Recv: Begin file list
2019-02-17 17:16:47,830 - Recv: /47ACB~1.MOD/TEST/TEST-D~1.GCO
2019-02-17 17:16:47,973 - Recv: End file list
2019-02-17 17:25:05,356 - Recv: Error:0
2019-02-17 17:25:05,382 - Recv: : Extruder switched off. MINTEMP triggered !
2019-02-17 17:25:05,385 - Changing monitoring state from "Operational" to "Error: 0: Extruder switched off. MINTEMP triggered !"
2019-02-17 17:25:05,401 - Changing monitoring state from "Error: 0: Extruder switched off. MINTEMP triggered !" to "Offline (Error: 0: Extruder switched off. MINTEMP triggered !)"
2019-02-17 17:25:05,415 - Connection closed, closing down monitor
1 Like

It seems that in Creality BLtouch version (BLTouch Firmware for Creality V1.1.3 mainboard) is thermal runaway protection switched on. After upgrade in display is Ender 3 Pro and some menu itemsi is more, but all working. And octoprint not companying any more about thermal runaway protection.

Based on the compilation date I'm seeing up there:

2019-02-17 17:16:46,564 - Recv: echo: Last Updated: Sep  3 2018 15:45:59 | Author: (Ender3)

this is the exact same build that was initially reported as unsafe.

So either those initial reports were wrong, or we now have multiple versions of the same firmware out there that are indistinguishable from each other, and some are safe and some aren't. Either way, this is a problem because I honestly don't know now what to do about this.

No, reports is right. I was too optimistic.
I did the experiment, warmed the hotend to 185 degrees and removed the heater wire. The display shows heating but the temperature dropped to less than 60 degrees in two minutes, no error was given.
So, even in the latest Ender 3 BLTOUCH version, thermal runaway protection is not turned on.

I don't see a serial log from a broken firmware above unless the original poster got it to you some other way... the 4 month gap seems to be followed by a post of a serial log from a 2018 printer but no test mentioned, just talking to creality. Is it possible the OP had broken firmware and everyone else posting since has working? What we need is the serial.log output from irvmax assuming his firmware is still stock. It sounds like his printer is behaving properly...unplug and temp drops....

Of course the other question is if there is any way to distinguish the real creality ender 3 from the other vendor ender 3 I have seen recently just from the firmware? I think the use a mks type board so they would look generic.

Perhaps a way to disable the warning if the enduser has tested and verified they are safe... not something as simple as a checkbox but somethin that requires deliberate action like touching a file under the .octoprint directory? I.e. 'touch .octoprint/i_tested_it_is_safe' .... not half so elegant as detecting it from firmware versions, but would let those of us who tested disable the message. And if octoprint detects a firmware version change it could delete it so the user would need to re-touch the file.

Or possibly a test button in the config .... so user hits test.. the pi sends to heat up and flashes for the user to unplug the cable and looks for the error mesage before it will mark a suspect printer safe?

Do we know if the original report was from disconnecting the wire or pulling the thermistor bead out of the block while heating? Is it possible the two actions work differently? I have a spare thermistor i can plug into the board and tuck under the sock the pull out while heating if you want the results of this test.

SO, I went over to the marlin firmware and read what thermal protection actually is..

The test of pulling the wires from the main board is invalid... it will throw a hardware error but that is nothing to do with thermal overload protection.

What should happen if it is enabled is once the hot end is told to heat up if it doesn't either show an increase or hit it in a time the protection will enable and it will turn off the current to the heater. The only way to simulate this and trigger thermal protection is to disconnect the thermistor from the heater block but otherwise leave it fully functional..... From one of the responses above it seems like it should just disable the heater and prevent any new commands to heat it from taking effect.

I'll use my spare thermistor to check this in the stock Ender firmware test this over the weekend and post back results.


  • Thermal Protection provides additional protection to your printer from damage
  • and fire. Marlin always includes safe min and max temperature ranges which
  • protect against a broken or disconnected thermistor wire.
  • The issue: If a thermistor falls out, it will report the much lower
  • temperature of the air in the room, and the the firmware will keep
  • the heater on.
  • The solution: Once the temperature reaches the target, start observing.
  • If the temperature stays too far below the target (hysteresis) for too
  • long (period), the firmware will halt the machine as a safety precaution.
  • If you get false positives for "Thermal Runaway", increase


  • Whenever an M104, M109, or M303 increases the target temperature, the
  • firmware will wait for the WATCH_TEMP_PERIOD to expire. If the temperature
  • hasn't increased by WATCH_TEMP_INCREASE degrees, the machine is halted and
  • requires a hard reset. This test restarts with any M104/M109/M303, but only
  • if the current temperature is far enough below the target for a reliable
  • test.
  • If you get false positives for "Heating failed", increase WATCH_TEMP_PERIOD
  • and/or decrease WATCH_TEMP_INCREASE. WATCH_TEMP_INCREASE should not be set
  • below 2.

I had to know... so I hooked it up tonight and tested.... my conclusion is that it is _not_enabled in this version of firmware.

I stuffed the thermistor under the blanket so it was reading the hot end temp... told it to heat to 100c.... after it hit 50c I pulled it out... The heater went into a runaway and kept heating... I put the thermistor back in and it was at 190 with no signs of stopping. It never threw any sort of error.

The test for unplugging the thermistor hits a different section of the marlin code where it is constantly checking if it reads at least room temperature. This is designed to detect thermistor broken wires or unplugged since a temperature below about 20c would read a very high resistance or an open.

I have attached the complete serial.log for this test so you can examine it if you like.

If you want a repeat of the test or any different test let me know soon, I plan to flash the firmware to enable this critical function over the weekend so I can safely use the ender again.

serial_overload.log (28.4 KB)

Repeated the exact same test on the Tevo Tornado and it did error out and shutdown showing what it should be doing.

tevo_serial_overload.log (4.0 KB)

1 Like

@robbob2112 thanks for testing this. Fairly clear result I'd say.

They can just disable the responsible plugin, the FAQ even informs about that. I don't want to make this more complicated than it needs to be honestly.

I remember that I not only went by the report here but also googled around and found a thread on I think reddit. But I can't find it right now and can't remember how it was tested.

In any case, good pointing out that just pulling the wire doesn't suffice - I thought it used to do that, but either I'm mistaken or that's something that changed over the past couple of years.

断电续打公司 文 = Duàn diàn xù dǎ gōngsī yīngwén
Individually with a few spaces inserted, it's like "Power off, continue to play, company, English"
Without spaces it should be just "Power outage".

Reversing: "power outage" -> 停电

I think what it's trying to say is "This is the Ender-3, Marlin 1.1.6 with runaway protection".

1 Like

Its means - "includes power failure resume".

1 Like

Nice. To me, it's like they forgot to throw in some spaces.

As a native Chinese speaker I have the urge to register and just to say: NO!
斷電續打 (断电续打) means print resuming. 斷電 means power outage, 續打 is the short form of continue printing. Therefore this means "resume printing after power outage", in case like the power cable came loose you can just plug back in and resume printing.
公司 means company, but 斷電續打公司 is kind of meaningless. And as it says, this is nothing related to thermal runaway protection.

1 Like