New and ingeneous ways to kill the duet...
Try 'printing' an STL file (instead of g-code). I won't mention how many times I crashed (and had to reboot) the duet or how many lines I went through in the real g-code file trying to find the problem...
When you think your firmware is idiot-proof, the universe makes a smarter idiot.
Logging this here incase the error is actually related to anything important.
RepRapFirmware for Duet WiFi
Duet WiFi 1.0
WiFi Server Version:
Web Interface Version:
Anyone else have any rather terrible "why would you even do that?" amusing bugs?
Torro last edited by
i rewired the printhead. the printer was on, because i needed the light.
so i cut the complete cable with 24V/5V. fortunately, i just needed a new fuse for the fans...
i don´t know what i was thinking...
Veti last edited by
your firmware is very old.
please consider updating.
bearer last edited by
Try 'printing' an STL file (instead of g-code)
In 2020 it doesn't work, while I'm not familiar with 1.20 firmware I'm surprised the file was accepted. I doubt you'll get other responses than please update and try again, however I'd be interested in taking a look at the contents of the .stl file in question.
zapta last edited by
It is known that the duet is not fool proof by itself and allows gcodes to do stupid and even dangerous things. IIRC one example we had here recently is inverted configuration of the heaters by an extra '!' character that caused the extruder heaters to go to max physical temp (~500C ?).
One way to look at it is to ask a question, I a hacker gets remote access to my machine, can they break the printer or burn my house?
That's the price of being highly customizable and flexible.
bearer last edited by bearer
Gcode will always be able to do dangerous things, especially when the g-code is also the configuration. Even prusa tries to filter out harmful g-code (to their cloud service). I'm curious to see if there is an overlap between an ascii stl file and valid g-code, or if its an binary stl file then what if any strings it contains.
Yeah, I know I'm running a pretty old firmware version. Had some troubles between firmware updates a few years back and found that 1.20 is actually pretty stable. I'm planning to upgrade to 3.0 in the near-ish future, just need the time to translate all the config.g settings.
@TLAS May want to make a stop at 2.05 first before heading up to 3.0.
Any specific reason to stop by 2.05 other than the real-time firmware upgrades? I know my existing g-code file is mostly compatible with 2.05, but I'm really most interested in transitioning to the Duet 3.
I named this printer 'Guinea-Pig' as it's really my test printer before I move things to my development printer. Wanted to upgrade to 3.0 on the duet 2 first to get the syntax of the 3.0 upgrades before making an attempt on the Duet 3 firmware config.
@TLAS There's quite a lot of changes between 1.20 and 2.05 that may impact you. It will just be easier to troubleshoot 3.0 if you already have a handle on the 2.x changes.
If you're planning on starting fresh with all your configs and using the configurator you may not have any issues, but if you want to try keeping your existing config and updating it for 3.0 it could be a different story.
Good point. Incremental debugging is always easier.