USB Mis-adventures in 3D Printing…

So a few months back at Converge Detroit (https://www.convergeconference.org/) I ended up winning second place in the CTF they run, and I acquired a 3d printer.  Since then, I’ve been doing a lot of tinkering with a Wanhao i3 PLUS and a recent project of mine has been to replace the internals of it entirely with an SKR Mini v1.1(Link here).  It’s been challenging, to say the least- hardware selection and making sure it fits the form factor, learning about how all of it is really wired together, compiling my own firmware to put on the new mainboard, and so on.  It’s been slow going because real life comes first, but it’s been pretty rewarding because every issue has been solvable so far, and every issue has been explainable by either something in code, or something in the physical properties of what is being set up.

That is, until I tried to hook up an OctoPi (https://octoprint.org/) instance to the printer to start troubleshooting some nagging issues I was having with endstops..  The brave little Raspberry Pi refused to enumerate the printer.  Things I tried included (But weren’t limited to)…

  • Scouring dmesg for anything USB-related after clearing it from boot (Plugging and unplugging did nothing)
  • Using lspci, lsusb and so on to watch for weird enumerations and running down anything that didn’t make sense (Again, dead end).
  • Running ls /dev/tty* to see if I could see anything enumerated.  Nada.

Basically, nothing was showing up.  I was flummoxed.  So I started poking around with the SKR Mini and testing it against other ways to access the board.  It turned out I could access the board and send GCode through Pronterface, and similar tools on Windows.  So I figured- could the USB on the Raspberry Pi 4 be the issue?

It turns out the Pi 4 runs off of a Via Labs VL805 chip for USB.  Looking through recent issues for Raspbian as well as issues for the VL805 chip in general it looks like there has been a history of issues similar to this related to the VL805.  To try and isolate the issue further, I tried Octoprint on an older Raspberry Pi 3, which runs off of a Broadcom BCM2835.  It turns out the Raspberry Pi 3 detected the SKR Mini just fine.

So at this point, I have tested across multiple OSes (Running different drivers), and across multiple chipsets.  Everything points to the VL805 being the root cause, which is unfortunate.  I guess I’ll be opening up an issue on their Github over the next few weeks once I get some time.  We’ll see where it goes.