@Systemic I've also added this information to the OP.
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.
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!
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.
1 Like
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.
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
1 Like
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
1 Like
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.
1 Like
@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.
1 Like
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.
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.
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.
@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).
It is no replacement for firmware checks but you cannot rely on firmware for safety. It would need to be written to strict standards and run on multiple redundant systems to be classed as safe. A single fault, such as a shorted MOSFET will cause a fire if the heater is powerful enough and they only way to make it safe is to have a second means of turning it off. Switching the power supply off using an independent computer provides that.
When the firmware outputs the power with the temperatures OctoPrint could also detect thermistor faults. Then you have multiple redundant systems that won't become dangerous due to s single fault.
The Wanhao Duplicator i3 Plus does not have thermal runaway protection; its Marlin firmware is derived from Marlin from around 9th Feb 2014, I believe. This pre-dates the introduction of thermal runaway protection in Marlin in June/July 2014. I haven't checked for sure but it's likely the same for the i3.
You can find the stock firmware for the Wanhao Duplicator i3 and the Wanhao Duplicator i3 Plus (amongst others) on Gary Chen's (Wanhao general manager) GitHub.
I arrived at the 9th Feb 2014 date by comparing the archive for the i3 Plus with the Marlin history on GitHub.
I was just wondering, everything I've searched says that octoprint supports Anet a8 stock firmware but I can't find anywhere that it says it supports Merlin, not on the Github, or anywhere else. So does it fully support Merlin?
-Link: (https://github.com/foosel/OctoPrint/wiki/Supported-Printers)
You are looking for "Marlin", not "Merlin" 
And yes, Marlin is supported. OctoPrint wouldn't really work with a lot of printers if it didn't support Marlin.
Thank you and my apologies on the misspelling.
Fair enough, firmware should definitely be the first line of defense. Considering how people are, it is likely that at least a few people would just use the Pi protection as the only safety feature. I would still like it if it were available as a secondary line of defense, but I can respect your reasoning for not adding it.
I appreciate you taking the time to respond, and your hard work on this great software! I hope you have a great day! 