New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No safety features #67

Open
guysoft opened this Issue Nov 18, 2018 · 10 comments

Comments

Projects
None yet
3 participants
@guysoft
Copy link

guysoft commented Nov 18, 2018

Hey,
Does the firmware have no safety features such as thermal runaway and max-temp?
I see no documentation on that.

@guysoft guysoft changed the title No safty features No safety features Nov 18, 2018

@donovan6000

This comment has been minimized.

Copy link
Owner

donovan6000 commented Nov 19, 2018

iMe will prevent you from setting the extruder's temperature above 285 degrees Celsius.

It will also turn off the fan, led, heater, and motors after 10 minutes of inactivity. The devel branch fixed an issue with this where the command that checks what the temperature is, M105, was resetting the inactivity counter.

@guysoft

This comment has been minimized.

Copy link

guysoft commented Nov 19, 2018

Ok, thats good, but there is no thermal runaway protection.

Here is a printer that burned a house down due to this setting missing:
https://www.thissmarthouse.net/dont-burn-your-house-down-3d-printing-a-cautionary-tale/

Octoprint should add this to the list of insecure frimware:
https://discourse.octoprint.org/t/octoprint-tells-me-that-my-printers-firmware-lacks-mandatory-safety-features-what-does-this-mean/350

Don't get me wrong, I am using your firmware, its great. But this also makes it a fire hazard if its not fixed.

@donovan6000

This comment has been minimized.

Copy link
Owner

donovan6000 commented Nov 20, 2018

Ok, then I agree that iMe should be in the list if insecure firmwares. Can you provide this M115 response to foosel so that she can add it to the list? PROTOCOL:RepRap FIRMWARE_NAME:iMe FIRMWARE_VERSION:00.00.01.26 MACHINE_TYPE:Micro_3D EXTRUDER_COUNT:1 SERIAL_NUMBER:0000000000000000

From my own experience, I can also confirm that the Micro 3D printer's extruder circuity provides very little to mitigate thermal runaway. During iMe's development, I once accidentally heated up the extruder to the point where something in the extruder's enclosure started to smoke. So potentially the Micro 3D printer could experience thermal runaway if the heating element moves out of place or if the firmware crashes while the it's heating the extruder.

@guysoft

This comment has been minimized.

Copy link

guysoft commented Nov 20, 2018

cc @foosel .
I am sick today and my M3D is at work, can confirm then.

@guysoft

This comment has been minimized.

Copy link

guysoft commented Nov 20, 2018

@donovan6000 I think firmware crashes are also possible on Marlin to cause a thermal runaway. The question is if its possible to add it to the firmware?

foosel added a commit to foosel/OctoPrint that referenced this issue Nov 20, 2018

@foosel

This comment has been minimized.

Copy link

foosel commented Nov 20, 2018

Just added detection of this, will be in 1.3.10rc3+

@guysoft

This comment has been minimized.

Copy link

guysoft commented Nov 20, 2018

Happy its known, would be great if we can fix it.
also might be a good idea to warn on stock firmware.

@donovan6000

This comment has been minimized.

Copy link
Owner

donovan6000 commented Nov 24, 2018

What do you think is a good way to detect thermal runaway? It seems like detecting this on the Micro 3D printer is kinda tricky since the printer's heating element is also what is used to measure the extruder's temperature.

If the heating element moves out of place while the extruder is already hot, then the temperature readings would probably increase a bit since the extruder would no longer be acting like a heat sink for the heating element. But the readings would stabilize shorty after that. I've seen temperature readings on the Micro 3D printer continually vary by more than 15 degrees from a set temperature under normal circumstances, so this seems difficult to differentiate thermal runaway from normal behaviour in this case.

We'd also have to account for if the heating element was already moved out of place before we sent the printer a command to start heating up the extruder. In that case, I think the temperature readings would still look normal since the heating element would still gradually heat up, just quicker than usual. This would also be difficulty to differentiate from normal behaviour since each Micro 3D printer has some unique temperature calibration values that are used to determine the extruder's temperature, and this causes the temperature curve when the extruder is heating up to vary from printer to printer. So some printer will already appear to heat up quicker than others.

@guysoft

This comment has been minimized.

Copy link

guysoft commented Nov 25, 2018

@foosel
Stock firmware replies with this:
Recv: ok REPETIER_PROTOCOL:2 FIRMWARE_NAME:Micro3D FIRMWARE_VERSION:2016040401
Its also unsafe (likely much worse than @donovan6000 's firmware , we don't know).

Also, if you have any advice for #67 (comment) (even who might have an answer). That would help!

foosel added a commit to foosel/OctoPrint that referenced this issue Nov 26, 2018

@foosel

This comment has been minimized.

Copy link

foosel commented Nov 26, 2018

I've added the stock firmware to the printer safety plugin as well, will be detected starting with 1.3.10rc3.

I have no advice on the challenge of reliably detecting a thermal runaway here I fear. Other firmwares do it by checking temperature increase against applied power to the heater as far as I know. Too big of an increase with now power -> error. Too little of an increase with power -> error. Sounds like the design of the Micro makes this tricky though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment