If OctoPrint 1.3.7 or later is showing you this message in your sidebar
it means that it detected a firmware running on your printer that is known to lack or have broken implementations of mandatory safety features such as thermal runaway protection.
It currently does this for the following firmwares:
Anet A8 stock firmware (identified through firmware name ANET_A8_*)
Any firmware implementing the THERMAL_PROTECTION capability report and reporting this capability as disabled (identified through capability report line Cap:THERMAL_PROTECTION:0)
Due to a lack of identifiable signatures it cannot detect the following printers, which also are known to have thermal runaway protection disabled:
Printers lacking these mandatory safety features are known to cause fires, e.g. 1, 2, 3.
A lack of thermal runaway protection means that should the heating cartridge or the thermistor detach from the hotend, the firmware will not be able to detect this and continue to heat up your heating cartridge until it might cause something to catch fire.
Don't become a part of the statistic, update your printer to a safe firmware, such as the current versions of Marlin or Repetier, make sure that all safety features are enabled, install a smoke alarm, have a fire extinguisher on hand and don't leave your running printer unattended (not even the expensive ones).
Note
If you want this message gone, fix the underlying safety issue. If that isn't an option for whatever reason (or you believe that the message is displayed erroneously), you can disable the bundled "Printer Safety Check" plugin, which is responsible for this message. Be advised though that you are actively ignoring an actual safety issue with your printer this way.
It's your own responsibility to keep your printer safe.
You can help make 3d printing safer!
If you know of a printer being sold whose stock firmware doesn't have thermal runaway or other safety features enabled, please help getting it reported here and ideally detected by the plugin. Post a reply and share the printer make and model, firmware link and ideally - if you have access to one - the output of OctoPrint connecting to it, including the M115 request and the printer's response to it.
Also, if you know that a more recent version of the firmware mentioned above has been fixed by the vendor but is still being identified as unsafe by OctoPrint, please provide the necessary data to identify it as well so the plugin can be adjusted accordingly - printer make and model, firmware link and the output of OctoPrint connecting to it, including the M115 request and the printer's response to it.
A user reported this showed up for his Smoothie-powered printer.
Smoothie has runaway detection so that'd be incorrect.
Or I misanderstood the user ? ( also possible at this point )
Found the commit, this is specific to a machine, will see if user has that one.
Note that if the machine is Smoothie-powered you can detect if it's using safety features by using the config-get command on the appropirate config options.
So will this change tell me my printer lacks safety features? I use an old version of Marlin that doesn't have any of this nonsense. I simply use heaters that cannot catch fire even if they are on 100%.
Well that was my point : you can detect this via serial. It's not strictly necessary, you can do it the way you do it now ( detect firmware versions pretty much ), but it'd be even better to detect if the users have actually disabled the runaway protection ( which you can do in smoothie with the config-get command, over serial )
Of course it would be, but there's absolutely no way to do this across firmware variants and there's also no way to change that retroactively since most people don't ever update their printer's firmware. Heck, it's already pretty impossible to even detect firmware variants or rather subvariants - every vendor Marlin, no matter how much it was modified and made quirky, is just "Marlin 1.0".
Actually it's specific to the firmware's own identification in FIRMWARE_NAME (as returned by M115). This will only trigger if the firmware outputs something along the lines of FIRMWARE_NAME:ANET_A8_20160525 anet3d.com, with the important bit being FIRMWARE_NAME:ANET_A8_. Which neither Marlin nor Repetier nor Smoothieware nor whatever else should really ever do unless intentionally modified to do it.
No. It can only identify known problematic firmware variants identifiable as explained above (and only if I get enough info on them in the first place). There's no way to query these kind of features from firmware that works cross variant and in fact Smoothieware is the only firmware that I now know to even allow querying this configuration detail. Heck, most firmware out there doesn't even yet support capability reporting and likely never will, and that's relevant to the actual communication and not just a configuration detail of the blackbox on the other hand of the serial line.
I'm trying the best I can here, I'm aware that it's sub optimal since it's basically a blacklist based approach and not a definitive check, but my hands are bound by the interface limitations I have to work with.
I already went through that source in this context and I remember it not looking like it was the actual firmware used on the printers when compared to the serial.logs provided in that ticket. I don't know what that source is, but I'm fairly sure it isn't the one of the actual firmware used on the printers.
If the actual firmware definitely has thermal runaway protection disabled it is identifiable - the M115 response is ridiculously non conforming to how it should look like but in this case that actually makes things easier:
2018-01-12 11:46:06,864 - Send: N1 M115*39
2018-01-12 11:46:06,870 - Recv: ok ZWLF make it.Date:Dec 19 2017 Time:20:47:53
What is shared there - judging by the code - would identify as a Marlin 1.1.0-RC8, machine name 3D Printer and source URL https://github.com/MarlinFirmware/Marlin. So about as generic and indistinguishable from an upstream safe version as can be.
Thanks for the feedback. The source code you've looked at is related to version 1 and 2 of the anycubic i3 mega. They started to sell a new version of the printer in January with a different board and a different firmware and this is where you worked on the serial issue (previous board is a trigorilla and new one is based on chitu).
They did not release firmware source for the newer version yet.
The printer hardware revision prior to January are using the firmware here : https://github.com/ANYCUBIC-3D/I3-MEGA. (based on Marlin 1.1.0-RC8 as you mentioned)
That being said, for anycubic hw v1 and v2 (prior to January) the thermal runaway if not active and this cannot be detected easily. I've made some awareness posts on facebook groups to ask users to change their settings/firmwares to enable it again.
Note for those who want to change original firmware, uncomment these lines in the configuration file :
//#define THERMAL_PROTECTION_HOTENDS // Enable thermal protection for all extruders
//#define THERMAL_PROTECTION_BED // Enable thermal protection for the heated bed
Thanks again to help users to avoid burning their house
**Jolly, xxxxxxxx.CO** is the Anycubic developer reference in the source. The new firmware developped by the community (and that have thermal runaway enabled will have a different Author ...
This would not be a M115 test anymore but a test a serial connection time.
If it isn't already implemented, could OctoPrint be set up with thermal overrun protection? Just in case it isn't possible, or easy for the user to change the firmware on their end. Just a little extra redundancy. Firmware thermal overrun should always be active if at all possible.
No. This is something that needs to be done in the firmware. Doing it via data provided by firmware on the serial interface is tricky if not impossible and also not something I would like people to rely on. This is really something that needs to be done by the entity that actually has physical access to the sensors and signal lanes in question and that's the firmware.
Here is what the terminal shows, when i connect to my CR10-S.
I got the latest revision i guess.
Rounded glass bed, isolated on the underside, new Z-Leadscrew couplers with red"plastic/rubber".
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=0x7434e270, open=True>(port='/dev/ttyUSB0', baudrate=115200, 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: External Reset
Recv: Marlin
Recv: echo: Last Updated: 2015-12-01 12:00 | Author: (CR-10Slanguage)
Recv: Compiled: Dec 5 2017
Recv: echo: Free Memory: 1204 PlannerBufferBytes: 1232
Recv: echo:Hardcoded Default Settings Loaded
Recv: echo:Steps per unit:
Recv: echo: M92 X80.00 Y80.00 Z400.00 E93.00
Recv: echo:Maximum feedrates (mm/s):
Recv: echo: M203 X300.00 Y300.00 Z5.00 E25.00
Recv: echo:Maximum Acceleration (mm/s2):
Recv: echo: M201 X1000 Y1000 Z100 E5000
Recv: echo:Accelerations: P=printing, R=retract and T=travel
Recv: echo: M204 P500.00 R500.00 T1000.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 X20.00 Z0.40 E5.00
Recv: echo:Home offset (mm):
Recv: echo: M206 X0.00 Y0.00 Z0.00
Recv: echo:Material heatup parameters:
Recv: echo: M145 M0 H185 B0 F0
Recv: echo: M145 M1 H240 B0 F0
Recv: echo:PID settings:
Recv: echo: M301 P22.20 I1.08 D114.00 C100.00 L20
Recv: echo:Filament settings: Disabled
Recv: echo: M200 D3.00
Recv: echo: M200 D0
Recv: echo:SD card ok
Recv: Init power off infomation.
Recv: size:
Recv: 591
Recv: init valid:
Recv: 0
Recv: 0
Recv: ok
Changing monitoring state from 'Connecting' to 'Operational'
Send: N0 M110 N0*125
Recv: ok
Send: N1 M115*39
Recv: FIRMWARE_NAME:Marlin 1.1.0 From Archive SOURCE_CODE_URL:http:// ... PROTOCOL_VERSION:1.0 MACHINE_TYPE:www.cxsw3d.com EXTRUDER_COUNT:1 UUID:00000000-0000-0000-0000-000000000000
Recv: ok
Send: M20
Recv: Begin file list
Recv: CAT~1.GCO
Recv: /CR-10E~1/CAT~1.GCO
Recv: echo:Cannot open subdir
Recv: WIN7����
Recv: Error:MINTEMP triggered, system stopped! Heater_ID: 0
Changing monitoring state from 'Operational' to 'Error: MINTEMP triggered, system stopped! Heater_ID: 0
'
Recv: Error:MINTEMP triggered, system stopped! Heater_ID: bed
Recv: \x0c�start
Recv: echo:Marlin
Recv: echo: Last Updated: 2015-12-01 12:00 | Author: (CR-10Slanguage)
Recv: Compiled: Dec 5 2017
Recv: echo: Free Memory: 1204 PlannerBufferBytes: 1232
Recv: echo:Hardcoded Default Settings Loaded
Recv: echo:Steps per unit:
Recv: echo: M92 X80.00 Y80.00 Z400.00 E93.00
Recv: echo:Maximum feedrates (mm/s):
Recv: echo: M203 X300.00 Y300.00 Z5.00 E25.00
Recv: echo:Maximum Acceleration (mm/s2):
Recv: echo: M201 X1000 Y1000 Z100 E5000
Recv: echo:Accelerations: P=printing, R=retract and T=travel
Recv: echo: M204 P500.00 R500.00 T1000.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 X20.00 Z0.40 E5.00
Recv: echo:Home offset (mm):
Recv: echo: M206 X0.00 Y0.00 Z0.00
Recv: echo:Material heatup parameters:
Recv: echo: M145 M0 H185 B0 F0
Recv: echo: M145 M1 H240 B0 F0
Recv: echo:PID settings:
Recv: echo: M301 P22.20 I1.08 D114.00 C100.00 L20
Recv: echo:Filament settings: Disabled
Recv: echo: M200 D3.00
Recv: echo: M200 D0
Recv: echo:SD card ok
Recv: Init power off infomation.
Recv: size:
Recv: 591
Recv: init valid:
Recv: 0
Recv: 0
Did you mean Monoprice Select Mini or Monoprice Maker Select? Maker Select I know for sure has thermal runaway problems but I wasn't sure about Mini Select.
Note
You can help make 3d printing safer!
