Multiple 3D Printers, And One Pi To Rule Them All

If you’ve got a desktop 3D printer, there’s an excellent chance you’ve heard of OctoPrint. This web front-end, usually running on a Raspberry Pi, allows you to monitor and control the printer over the network from any device that has a browser. But what if you’ve got two printers? Or 20? The logistics of each printer getting its own Pi can get uncomfortable in a hurry, which is why [Jay Doscher] has been working on a way to simplify things.

Leveraging the boosted processing power of the Raspberry Pi 4 and some good old fashioned Linux trickery, [Jay] is now controlling multiple printers from a single device. The trick is to run multiple instances of the OctoPrint backend and assign them to virtual network interfaces so they don’t interfere with each other. This takes some custom systemd unit files to get up and running on Raspbian, which he’s been kind enough to include them in the write-up.

But getting multiple copies of OctoPrint running on the Pi is only half the battle. There still needs to be a way to sort out which printer is which. Under normal circumstances, the printers would be assigned random virtual serial ports when the Pi booted. To prevent any confusion, [Jay] explains how you can use custom udev rules to make sure that each printer gets its own unique device node. Even if you aren’t trying to wrangle multiple 3D printers, this is a useful trick should you find yourself struggling to keep track of your USB gadgets.

If you’re wondering why [Jay] needs to have so many 3D printers going at the same time, we hear they’ve been keeping rather busy running off parts for commissioned copies of his popular projects. Something to consider the next time you’re wondering if there’s a way to make a happy buck out of this little hobby of ours, folks.

17 thoughts on “Multiple 3D Printers, And One Pi To Rule Them All

    1. I was thinking exactly that since my home octoprint server is containerised and running on an ARM board. Each octoprint instance can have its own chunk of filesystem, its own serial link, port etc.

  1. Neat, although it has been around for some time. I made a similar system where octopart instances got their own port.
    The problem with many printers is that starting them is easy. stopping a failed print you have to go to the octopart interface. there’s no local control anymore which is super annoying!
    (hoping to be proved wrong now!)

  2. don’t get me wrong, that’s cool… However a nice SPOF.
    My personal preference: buy a dedicated Nano/orange-pi per printer for 15 USD it’s not soo terribly expensive if you have multiple printers…with this you have real redundancy.

    1. I hate acronyms LOL tokens me several Google searches to find out SPOF is Single Point Of Faliure LOL

      That said, a copy of the SD card can be made.once setup is running, so when the Pi kills the card it is easily replaced. I guess having one machine is also more efficient power wise as well.

  3. The easiest way I found years ago was using OctoPi and just use different configuration files pointing which had different printer settings and using different ports. OctoPi.local:5001 OctoPi.local:5002, etc Nothing else special was needed.

  4. There’s a neat project for Kubernetes called KubeSerial. Have a few Pis scattered around your printer room, plug any USB cable in, based on the USB idVendor/idProduct paring it creates a new octopi instance connected to that USB serial port

Leave a Reply to Hans Peter HaastrupCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.