OctoPrint tells me that my printer's firmware lacks mandatory safety features, what does this mean?

Printer: Tronxy X1 (mod. with Ramps 1.4)

Marlin 1.1.9

#define THERMAL_PROTECTION_HOTENDS // Enable thermal protection for all extruders

Via Local Network Cable

Send: M115
Recv: FIRMWARE_NAME:Marlin 1.1.9 (Github) SOURCE_CODE_URL:https://github.com/MarlinFirmware/Marlin PROTOCOL_VERSION:1.0 MACHINE_TYPE: Tronxy X1 EXTRUDER_COUNT:1 UUID:cede2a2f-41a2-4748-9b12-c55c62f367ff
Recv: Cap:SERIAL_XON_XOFF:0
Recv: Cap:EEPROM:0
Recv: Cap:VOLUMETRIC:1
Recv: Cap:AUTOREPORT_TEMP:1
Recv: Cap:PROGRESS:0
Recv: Cap:PRINT_JOB:1
Recv: Cap:AUTOLEVEL:0
Recv: Cap:Z_PROBE:0
Recv: Cap:LEVELING_DATA:1
Recv: Cap:BUILD_PERCENT:0
Recv: Cap:SOFTWARE_POWER:0
Recv: Cap:TOGGLE_LIGHTS:1
Recv: Cap:CASE_LIGHT_BRIGHTNESS:1
Recv: Cap:EMERGENCY_PARSER:0
Recv: Cap:AUTOREPORT_SD_STATUS:0
Recv: Cap:THERMAL_PROTECTION:0

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Your printer's firmware is known to lack mandatory safety features (e.g. thermal runaway protection). This is a fire risk. Learn more at https://faq.octoprint.org/warning-firmware-unsafe !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!


efbe

@efbe your printer is still reporting though that thermal protection is disabled. Might be a flag missing somewhere or a firmware bug, but in any case, this capability says "nope, no thermal runaway protection here" and that's what OctoPrint believes.

edit

Looks like both hotend and bed runaway protection need to be enabled for this flag to report 1:

Maybe that needs a firmware adjustment so that the bed is only taken into account if a bed is even configured? Not sure...

I don't have a heated bed, but I'll try and let You Know

Fred

I’ve skipped wall of text...
Any news about M33 fio? For M3d and with iMe.

Hello, Creality-Support says, that
ender3
has already thermal runaway protection:

my M115:

Send: M115
Recv: FIRMWARE_NAME:Marlin V1; Sprinter/grbl mashup for gen6 FIRMWARE_URL:http://www.mendel-parts.com PROTOCOL_VERSION:1.0 MACHINE_TYPE:www.creality3d.cn EXTRUDER_COUNT:1 UUID:00000000-0000-0000-0000-000000000000
Recv: ok

startup:

Timelapse
Changing monitoring state from "Offline" to "Detecting serial port"
Serial port list: ['/dev/ttyUSB0']
Connecting to: /dev/ttyUSB0
Changing monitoring state from "Detecting serial port" to "Opening serial port"
Connected to: Serial<id=0x699e19f0, open=True>(port='/dev/ttyUSB0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
Starting baud rate detection...
Changing monitoring state from "Opening serial port" to "Detecting baudrate"
Trying baudrate: 115200
Recv: start
Send: N0 M110 N0*125
Changing monitoring state from "Detecting baudrate" to "Operational"
Recv: echo: External Reset
Recv: Marlin 1.0.0
Send: N0 M110 N0*125
Recv: echo: Last Updated: Sep  3 2018 15:45:59 | Author: (Ender3)

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Your printer's firmware is known to lack mandatory safety features (e.g.
thermal runaway protection). This is a fire risk.

Learn more at https://faq.octoprint.org/warning-firmware-unsafe
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Recv: Compiled: Sep  3 2018
Recv: echo: Free Memory: 9679  PlannerBufferBytes: 1232
Recv: echo:Hardcoded Default Settings Loaded
Recv: echo:SD init fail
Recv: echo:SD init fail
Recv: ok
Recv: ok
Send: N1 M115*39
Send: N2 M21*18
Recv: FIRMWARE_NAME:Marlin V1; Sprinter/grbl mashup for gen6 FIRMWARE_URL:http://www.mendel-parts.com PROTOCOL_VERSION:1.0 MACHINE_TYPE:www.creality3d.cn EXTRUDER_COUNT:1 UUID:00000000-0000-0000-0000-000000000000
Recv: ok

Regards
Michel

@ing-michel have you actually verified this through a test? (e.g. disconnecting the thermistor, issuing a heat command, see if it errors)

The problem is, the info that your version of the firmware produces is identical to the one that was reported as not protected. In the face of conflicting info about thermal runaway protection in printers I'd rather err on the side of caution unless I have evidence that the printer firmware is in fact safe.

Hi, I've an Anycubic i3 Mega and the octoprint web interface says that warning. I searched a lot over the internet and tested my printer too, here there are some results.

First of all I installed the last firmware, v 1.1.2_03 according to the official site (here), mine is the second one "2.Mega.hex_V1.1.2_03Version(20180315)". First one is for the new model i3 mega-s.

Anyway I noticed that from the information on the printer's LCD it shows version 1.1.0 yet. So I sent an email message to the anycubic support and also asked for the thermal runaway issue, here it is the answer:


So it looks like they fixed and enabled the thermal protecion runaway, also LCD shows normally 1.1.0 after the update, so all looks ok. I personally checked that on GitHub the configuration.h page (of 1.1.1, online version) Anycubic i3 Mega Github v1.1.1.

After that I connect my printer to Octoprint and see in the terminal the log:

Changing monitoring state from "Offline" to "Detecting serial port"
Serial port list: ['/dev/ttyUSB0']
Connecting to: /dev/ttyUSB0
Changing monitoring state from "Detecting serial port" to "Opening serial port"
Connected to: Serial<id=0x615da090, open=True>(port='/dev/ttyUSB0', baudrate=250000, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
Changing monitoring state from "Opening serial port" to "Connecting"
Send: N0 M110 N0*125
Recv: start
Send: N0 M110 N0*125
Recv: echo:V1.1.2
Recv:  1.1.0-RC8
Recv: 
Recv: echo: Last Updated: 2016-12-06 12:00 | Author: (Jolly, xxxxxxxx.CO.)

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Your printer's firmware is known to lack mandatory safety features (e.g.
thermal runaway protection). This is a fire risk.

Learn more at https://faq.octoprint.org/warning-firmware-unsafe
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Recv: Compiled: Mar 15 2018
Recv: echo: Free Memory: 3109  PlannerBufferBytes: 1168
Recv: echo:Hardcoded Default Settings Loaded
Recv: echo:Steps per unit:
Recv: echo:  M92 X80.00 Y80.00 Z400.00 E92.60
Recv: echo:Maximum feedrates (mm/s):
Recv: echo:  M203 X500.00 Y500.00 Z6.00 E60.00
Recv: echo:Maximum Acceleration (mm/s2):
Recv: echo:  M201 X3000 Y2000 Z60 E10000
Recv: echo:Accelerations: P=printing, R=retract and T=travel
Recv: echo:  M204 P3000.00 R3000.00 T3000.00
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)
Recv: echo:  M205 S0.00 T0.00 B20000 X10.00 Y10.00 Z0.40 E5.00
Recv: echo:Home offset (mm)
Recv: echo:  M206 X0.00 Y0.00 Z0.00
Recv: echo:Z2 Endstop adjustment (mm):
Recv: echo:  M666 Z0.00
Recv: echo:Material heatup parameters:
Recv: echo:  M145 S0 H180 B70 F0
Recv:   M145 S1 H240 B110 F0
Recv: echo:PID settings:
Recv: echo:  M301 P16.43 I1.04 D61.37
Recv: echo:Filament settings: Disabled
Recv: echo:  M200 D1.75
Recv: echo:  M200 D0
Recv: echo:SD card ok
Recv: ok
Changing monitoring state from "Connecting" to "Operational"
Send: N0 M110 N0*125
Recv: �ok

It shows both 1.1.0 and 1.1.2 versions but also Compiled: Mar 15 2018 so, according to the email, the update was uploaded successfully. Here the detailed part:

Recv: echo:V1.1.2
Recv:  1.1.0-RC8
Recv: 
Recv: echo: Last Updated: 2016-12-06 12:00 | Author: (Jolly, xxxxxxxx.CO.)

[...]

Recv: Compiled: Mar 15 2018

I also send a M115 command and here is the respond:

Send: M115
Recv: FIRMWARE_NAME:Marlin 1.1.0-RC8 (Github) SOURCE_CODE_URL:https://github.com/MarlinFirmware/Marlin PROTOCOL_VERSION:1.0 MACHINE_TYPE:3D Printer EXTRUDER_COUNT:1 UUID:cede2a2f-41a2-4748-9b12-c55c62f367ff

Not satisfied yet I decided to run a test and try to unplug the thermistor while the hotend is heating. Result: the printer does not show any message but it stop heating the hotend, so there is the protection. Also, when reconnecting the thermistor it does not restart heating, it just stops.

I filmed all and uploaded on Youtube: https://youtu.be/cNhUoWn4B30.

As the printer report in the terminal echo:V1.1.2 I think we can exclude the thermal runaway problem for this firmware/printer, that's right @foosel?

2 Likes

Thank you! That looks indeed promising! I'll adjust the implementation accordingly.

I'm glad that vendors are apparently now fixing up their firmwares, that's good! Might have to find a way though to make the checks configurable/downloadable then though, so they can be updated without having to push a new release :wink:

edit

As a side note, I just love the inconsistency in this output... Version 1.1.2, but M115 reports some generic Marlin version 1.1.0-RC8. Last compiled in March 2018 but Author line states last updated in late 2016. If they could just provide some consistent info here it would be less of a bloody nightmare to parse. I'll now have to add an actual state machine just to extract both author & version and be able to react, when all I would need with a properly maintained M115 response is read the already parsed information from that :expressionless:

1 Like

In Anycubic i3 Mega I also want to mention that it has apparently the maxtemp and mintemp feature enabled too, for both hotend and bed, according to the source code in GitHub:

// The minimal temperature defines the temperature below which the heater will not be enabled It is used
// to check that the wiring to the thermistor is not broken.
// Otherwise this would lead to the heater being powered on all the time.
#define HEATER_0_MINTEMP 5
#define HEATER_1_MINTEMP 5
#define HEATER_2_MINTEMP 5
#define HEATER_3_MINTEMP 5
#define BED_MINTEMP 5

// When temperature exceeds max temp, your heater will be switched off.
// This feature exists to protect your hotend from overheating accidentally, but *NOT* from thermistor short/failure!
// You should use MINTEMP for thermistor short/failure protection.
#define HEATER_0_MAXTEMP 285
#define HEATER_1_MAXTEMP 275
#define HEATER_2_MAXTEMP 275
#define HEATER_3_MAXTEMP 275
#define BED_MAXTEMP 150

edit:

I tested these features too, the MINTEMP feature by unplugging the thermistor and the MAXTEMP shorting out the thermistor's pins. Both these tests gave T0 senser abnormal message on LCD. When shorting out the pins, printer kicks in the cooling fan at maximum speed, that's adds a security level, I think that even at full heating power the hotend would not pass 285°C with the fan on.

Note: Display shows messages because it's not connected via USB to Octoprint.

Here is the proof: https://youtu.be/SMpFcDjTzcE

Hope that's helpful.

Hello all. I've seen reference to the Monoprice Mini v.2...

What about we keepers of the Monoprice Mini v.1? What firmware can I push. I understand the v.1 & v.2 have "different" controllers.

Monoprice is like a turnip, trying to get information from. UGG

Thank you! JLH

How can I check if my craftbot+ has thermal runway protection?

Sending M115 through the Octoprint terminal should give back some lines of information, also about the thermal protection:
Auswahl_258

Not necessarily. That's a fairly new capability report, and I doubt that a lot of vendors have already merged that (or ever will for that matter :roll_eyes:)

In which case there are two options. Getting a hold of the exact firmware source installed on the machine (good luck on verifying that) and checking that or the experimental approach. Powering the printer down, disconnecting the thermistor, powering up, heating up, checking that throws an error (and quickly shutting off things if it doesn't). If it doesn't there's no thermal runaway protection. If it does, there is.

Sorry to side track but I feel like we ought to sort out the lack of thermal runaway protection aswell before any fires occur https://discourse.octoprint.org/t/octoprint-tells-me-that-my-printers-firmware-lacks-mandatory-safety-features-what-does-this-mean/350

Hello, (I'm new to printing!) I've just setup my Anycubic Chiron (latest firmware 1.3.0) and connected it to OctoPrint (1.3.10 / OctoPi 0.16.0) via AUTO/AUTO which works fine and produces no warnings.
I wanted to try decrease the connection time by specifying the Baudrate manually to 250000 - it connects but gives me the scary red thermal Printer Safety Warning:


So does this firmware lack the safety feature set or should I be using AUTO instead (does the AUTO setting connect in a more reliable manner or something)?
Thanks for any advice!

Edit:
thermal_warning.log (4.6 KB)

This has nothing to do with the baudrate you connect. Whether your printer's firmware has thermal runaway protection or not isn't determined by connection parameters but whether whoever build the firmware build that into it.

Your firmware's "Author" string hints at it being an unprotected firmware as also found on older stock Anycubic Megas. Chances are thus high that it doesn't have thermal runaway protection.

You should look into replacing that firmware either with a safe updated from your vendor - if one exists - or a stock current Marlin or Repetier.

Thank you for the information! This was just the firmware it shipped with so I shall contact Anycubic and investigate some more! :slight_smile:

I Updated to the newest version of Octoprint too, 1.3.11. But I still have the waring. Why still I have it? Anycubic team said the printer has all safety feature enabled (see first post)

Thanks @foosel

It doesn't matter what version of OctoPrint you have. The warning exists because the printer firmware doesn't have the thermal runaway code.

Quoting @BerndJM:
Sending M115 through the Octoprint terminal should give back some lines of information, also about the thermal protection:
Auswahl_258

You can post the output of the M115 command if you wish.

As I mentioned before, according to the manufacturer, in version 1.1.2 they enabled all the feature version:

As a proof i personally checked:

I also checked in the source code, and personally the MINTEMP e MAXTEMP features, here:

And @foosel finally said:

By the way the newest version of the firmware (1.1.2) shows both, the latest and the previous one:

So I think all the safety warning are solved in this firmware version.

P.S. I now checked there is a new official version: 1.1.3, I will try to understand what is the changelog and tell you