Unknown Issue with OctoPi Installation Leads to Broken Scroll Wheel and Fire Hazard
I have an Original Prusa i3 MK3S which I built from a kit about 2 weeks ago and have been happily using to print stuff. I wanted to get octoprint running so that I could send the printer files without juggling an SD card, so I bought a Raspberry Pi Zero W and soldered on the header pins.
I followed these two posts to the letter:
Here's what happened:
- I flashed the PrusaPrint firmware to the RPi, plugged it in, and turned the printer on. The LCD only showed 2 bars across its screen (like in this post), and the printer was unresponsive. First issue: RPi bricks the machine when plugged in.
- I turned off the printer, took out the RPi, and turned the machine back on to check the settings. However, the scroll wheel was now unresponsive - pushing it to click in and out of the first menu item worked, and the reset button also worked, but I couldn't turn it side to side to scroll through the menus. Second issue: RPi broke the scroll wheel.
- The instructions say that the RPi needs a few minutes to boot up, so I figured maybe I just needed to let it sit for a bit. So I plugged it back in to the Prusa, turned it on, and went to google to try and figure out the scroll wheel issue. A few minutes later I smelled fumes, and saw that the hotend was smoking. I turned the machine off, took out the RPi, and turned the machine back on to start the fans to cool things down. I saw on the LCD that there was now a MAXTEMP warning, and the temperature sensor for the hotend was reading about 660 degC (!!!!). Safety issue: RPi with bricked machine activates the hotend with no warning, indication, or temperature protections, creating a massive fire hazard.
Any help solving my two issues (getting RPi working and fixing scroll wheel) would be much appreciated. And if the Prusa team reads this, there's a safety issue here that needs to be addressed (at the very least, with a disclaimer on the OctoPi tutorial).
If it's relevant, here's pictures of the front and back of the RPi. It's not the best soldering job ever but the pins are firmly in there. I'm sure that the pins were connected to the Einsy board correctly. I'll try resoldering in the morning to see if it was a weird connection issue.
I just noticed now turning on the machine without the RPi in that there is still power permanently going to the hotend. So the safety issue is persistent even after removal of the RPi, but at least the audible MAXTEMP alert is sounding now. Something on the Einsy must've gotten fried?
I wonder if this would be under warranty since I was following the official Prusa instructions...
The Pi zero is totally underpowered for task and is most definitely no longer recommended. Get a 3B+ or 4B. The strange power things you're experiencing is possibly because the Mk3 is drawing power for the Pi.
Does the printer run OK with the Pi removed and reflashed?
Update: I noticed that the heated bed is now always on in addition to the hotend. In retrospect, you can see that in the video above.
I've read that the Pi Zero is underpowered, but it's an officially sanctioned add-on and I wouldn't expect these sorts of issues to pop up. And it drawing power doesn't explain why my issues persist after I remove it from the machine.
I tried re-flashing (after unplugging the hotend and heated bed power lines so I don't burn down my room with the machine on), but I get the following error with the latest PrusaSlicer and Firmware even after a reboot and making sure there aren't any other COM port options or programs open that might try to use COM5. This might be a separate issue, or it might be related to what I've been seeing.
avrdude-slic3r -v -p atmega2560 -c wiring -P COM5 -b 115200 -D -U flash:w:0:C:\Users\Scott\Downloads\prusa3d_fw_3_9_0_MK3S (1)\prusa3d_fw_MK3S_3_9_0_3421.hex:i
avrdude-slic3r: Version 6.3-20160220-prusa3d, compiled on Mar 21 2020 at 12:45:57
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
Using Port : COM5
Using Programmer : wiring
Overriding Baud Rate : 115200
avrdude-slic3r: stk500v2_recv(): timeout
avrdude-slic3r: stk500v2_getsync(): timeout communicating with programmer
avrdude-slic3r: Could not open port: COM5
avrdude-slic3r done. Thank you.
[...] I wonder if this would be under warranty since I was following the official Prusa instructions...
IIRC the Prusa warranty covers hardware for unmodified pre-assembled printers. Kits are provided support only. The documentation page you linked to has the following highlighted:
Prusa Research does not assume responsibility, and expressly disclaim liability for loss, injuries or damage
The instructions do work for many people, so clearly something went amiss that likely can't be pinpointed remotely.
Have you tried re-flashing the Mk3 firmware? It sounds like you may have blown the controller board in the printer and will need to replace it.
It's worth noting that the hardware recommendations for Octoprint have changed since the Mk3 was released and the Raspberry Pi Zero -- and indeed anything less than a RPi 3B -- is not recommended.
I was able to re-flash today after a couple tries, but the uncontrolled hotend and bed heating and broken scroll wheel issues are still persisting.
Looking through the warranty info, kits are covered. There is an exception for damage due to "Upgrades or add-ons that are not officially supported." However I don't see how the octopi could be anything other than an "officially" supported add-on. The printer explicitly comes with a connections port for a Pi Zero, I followed the instructions on the Prusa official help page, and used the Prusa-provided octopi firmware. The octopi project in your link does not recommend a Pi Zero, but that appears to be just a performance issue when using a video feed, which I am not doing.
I'll contact support and see what they say.
Update: I had a back-and-forth conversation with the support team over the last few weeks. They agreed that the board was fried, but refused to replace it under warranty, which I'm a little peeved about.
So, I bought a replacement Einsy board, and the printer is back up and running at full capacity. There was no need to replace the LCD/scroll wheel board - the issue there must have been caused by the Einsy.
Anyway, the lesson here is that the Pi Zero compatibility is a piece of crap. I plan on putting in a Pi 4 hooked up via USB cable instead - there's no way that can go wrong, right?
Anyway, the lesson here is that the Pi Zero compatibility is a piece of crap
I agree. It is a disservice to continue publishing that clever, but unwise hack. The creator of the OctoPrint recommends against using a Pi Zero. The connection method is prone to accidental reverse wiring. Something that just barely works and is so easily done incorrectly should not continue to be so prominently featured. This "alternative," in my opinion, should be removed from the online instructions for the good of the community.
My guess here is that since second pin on your Rpi is slightly bent, it went to the wrong hole on J19 socket. That woult most likely be pin 3 (nAC_FAULT). It's directly connected to PE4 pin of atmega MCU and two logical gates (74LVC2G08) controlling heater and bed heating.
Frying any of those might result in symptoms you've described. And sinking RPi current (let's say 150mA) is more than enough to do this (atmega2560 can sink 40mA on PWM pin, 74LVC2G08 can survive 50mA on input)
I would strongly recommend using a Pi3B + or Pi4 with external power supply (5.1V, 3A). The data connection can be established via USB. With this you cannot destroy anything on the Einsy.