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

safety
firmware-specific

#6

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.


#7

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%.


#8

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 )


#9

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.


#10

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.


#11

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 :slight_smile:


#12

@Systemic I've also added this information to the OP.


#13

I've found a serial.log of the original firmware on which we can make a test.

 2018-02-22 16:56:12,678 - Recv: V1.1.1
 2018-02-22 16:56:12,680 - Recv:  1.1.0-RC8
 2018-02-22 16:56:12,682 - Recv:
 2018-02-22 16:56:12,688 - Recv: echo: Last Updated: 2016-12-06 12:00 | Author: (**Jolly, xxxxxxxx.CO.**)

**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.


#14

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.

Thank you for your hard work!


#15

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.


#16

Just changed the plugin a bit and added detection of this author to the maintenance branch. So OctoPrint 1.3.8 will also detect the Anycubic and put out warnings.


#17

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

#18

Here is the dedicated M115 Command:

Send: M115
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

#19

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.


#20

@BigBjoern Awesome. That's actually something to work with and I'll add identification of that for OctoPrint 1.3.8

@Catloaf Yes, I definitely mean the Mini. Good point about the Maker Select though, added to the OP.


#21

Well you monitor the temperature and graph it, so you could have a configurable maximum and configurable action. That could stop the print and turn the heaters off and on machines with power control on the GPIO could switch the power off.

Another possible action would be to reverse the filament out of the extruder.


#22

And what is that supposed to help when the thermistor reads environmental temperatures due to having fallen out of the hotend, or due to the heater cartridge having fallen out of the hotend? Or when there isn't an active serial connection to begin with?

Temperature control and monitoring of any kind is the responsibility of the firmware, or better yet, hardware safety measures. A serial client is too far away from the action to be able to reliably intervene if things go down the wrong road.

And honestly, I really don't want to build in half measures that people will then use as an excuse to not flash a safe firmware. Next thing is that this will (predictably) fail in a scenario that could have easily be prevented by existing firmware and people blame me for their laziness with regards to securing their printer. No thanks.


#23

Are you still looking for the fabrikator mini response.
I got the old one, made from orange acrylic from hobbyking.
Is that the one you are looking for.


#24

@BigBjoern Right now not the response per se, but rather the information whether that printer is affected or not. I know that what is sold as "Fabrikator Mini II" is actually a Malyan M100 (it reports itself as such), and considering that at least the Malyan M200 and the M150 are known to not have thermal runaway protection I'm very suspicious of Malyan M100 (aka the Fabrikator Mini II, maybe also the first gen Mini, an M115 response would be able to tell) and Malyan M300 (aka the Monoprice Mini Delta).


#25

Ok.
I don't have the M100.
I only have this one.
SY400|500x366SY400