OctoPrint is arguably the ultimate tool for remote 3D printer control and monitoring. Whether you simply want a way to send G-Code to your printer without it being physically connected to your computer or you want to be able to monitor a print from your phone while at work, OctoPrint is what you’re looking for. The core software itself is fantastic, and the community that has sprung up around the development of OctoPrint plugins has done an incredible job expanding the basic functionality into some very impressive new territory.
But all that is on the software side; you still need to run OctoPrint on something. Technically speaking, OctoPrint could run on more or less anything you have lying around the workshop. It’s cross platform and doesn’t need anything more exotic than a free USB port to connect to the printer, and people have run it on everything from disused Windows desktops to cheap Android smartphones. But for many, the true “home” of OctoPrint is the Raspberry Pi.
As I’ve covered previously, the Raspberry Pi does make an exceptional platform for OctoPrint. Given the small size and low energy requirements of the Pi, it’s easy to integrate into your printer. The new Prusa i3 MK3 even includes a header right on the control board where you can plug in a Raspberry Pi Zero.
But while the Raspberry Pi is more than capable of controlling a 3D printer in real-time, there has always been some debate about its suitability for slicing STL files. Even on a desktop computer, it can sometimes be a time consuming chore to take an STL file and process it down to the raw G-Code file that will command the printer’s movements.
In an effort to quantify the slicing performance on the Raspberry Pi, I thought it would be interesting to do a head-to-head slicing comparison between the Pi Zero, the ever popular Pi 3, and the newest Pi 3 B+.
For this test, I used the latest nightly of OctoPi, a pre-built OctoPrint image for the Raspberry Pi; as support for the Raspberry Pi 3 B+ is not currently available in the stable version. OctoPi was installed on a Samsung 32GB Evo Plus Class 10 Micro SDHC card, which was switched between the different Pis so as not to introduce additional variables such as SD performance or software configuration.
For the Cura slicing profile, I set up a generic printer using a 0.4 mm nozzle, 0.2 mm layer height, and a print speed of 40 mm/s. Five 3D models were selected, of increasing geometric complexity. The STLs were sliced on each model Raspberry Pi, and OctoPrint’s built-in slicing timer was used to determine exactly how long the process took.
In other words, the only difference between each slice was the Raspberry Pi hardware itself. The times recorded in this experiment are based solely on the processing capability of each model Pi.
20 mm Cube
We’ll start off small, with a basic 20 mm cube. I generated this STL in OpenSCAD, and it’s about as simplistic a model as they come. Cubes like this are often used during early calibration of a 3D printer, so it seemed appropriate to use it as a starting point for our slicing comparison.
Even this early, we can see how far the Pi Zero is lagging behind its larger siblings. While the nearly 10 seconds it took the Zero to slice the cube is hardly a long time to wait, it’s a troubling sign of things to come given how simple a task this was.
Love it or hate it, “Benchy” has become the de facto test for 3D printers. While a seemingly simplistic model, it actually integrates a number of challenging-to-print design elements such as overhangs and low-slope surfaces. As such, this is a much more realistic representation of a “daily driver” for 3D printing.
The Pi 3 and 3 B+ remain very similar, but it’s increasingly obvious the Zero is fighting above its weight. That said, it still didn’t take a long time to slice #3DBenchy. While the Zero was nearly four times slower than the 3 B+ in this test, 72 seconds is hardly an eternity and is probably “good enough” for many users.
Aria the Dragon
“Aria the Dragon” is an exceptionally popular model on Thingiverse created by Louise Driggers. This is a fairly complex model, and takes us out of the utilitarian types of prints that may be more common for Hackaday readers and firmly into artistic territory.
The gap between the 3 and 3 B+ continues to widen, and things only get worse for the Zero. At nearly 3 minutes, the slicing time for Aria is starting to get annoying.
This model looks suspiciously like a particular hunk of junk from a certain Disney-owned film franchise, but creator Andrew Askedall promises that the similarities are purely coincidental. The Malcon is notable for being printable with no supports (assuming you’ve got a printer up to the task) and has nearly 650 “Makes” on Thingiverse.
Hope you packed a lunch. The 10+ minute slicing time for this model on the Pi Zero is past the point where most people would give up.
Leung Chan created this gorgeous “Moon Lamp”, which packs in so much surface detail that the STL itself weighs in at nearly 50 MB. When lit from inside, the print shows innumerable tiny craters that were modeled from real images of the moon. If this doesn’t convince your friends they need to get a 3D printer, nothing will.
Unfortunately, this marked the end of the road for the Pi Zero. After pegging CPU and RAM usage to maximum for a few minutes, OctoPrint popped up with an error message that slicing had failed. Upon closer examination it looks like the system runs out of space on the swap partition and Cura takes a dive. In theory if you gave the Zero a larger swap partition (OctoPi only allocates 100 MB by default) it might grind its way through, but I wouldn’t recommend it. The model is just too complex for the lowly Zero.
Originally I was going to include the time it took my main computer to slice these models in comparison to the Raspberry Pi, but it quickly became clear that was pointless. Even the Moon Lamp only takes a few seconds on my desktop, and the more simplistic models slice so fast that it might as well be instantaneous. There’s simply no competition between a modern desktop or laptop processor and the comparatively dinky ARM chip used in the Raspberry Pi.
Which is why you should really just slice your models on the computer and send the resulting G-Code to OctoPrint over the network. That’s the intended workflow, and it really does make a lot more sense than forcing the Pi to labor over a task it’s clearly not cut out for. If the results of this test have shown anything, it’s that slicing on the Pi is a time consuming process no matter which model you buy.
To be clear, the usability of OctoPrint is very good no matter which Pi it’s running on. If you slice your STLs on your computer and OctoPrint only has to deal with the G-Code files, it doesn’t matter which Pi you get. The Zero is a bit sluggish when the OctoPrint UI first comes up, but beyond that there’s really no practical difference that I noticed.
But if you really want to use the Pi for slicing, forget the Zero. It just doesn’t have the muscle for slicing complex models. On the other hand, if you’re already using OctoPrint on your Raspberry Pi 3, I’d say stick with what you’ve got. The performance difference between it and the 3 B+ really isn’t worth the upgrade.