OctoPrint et al

So, my main reason for wanting to get a Canvas Hub was to have easy one-click print support that works with the Palette; after playing with Slic3r a bunch last night I then realized I also wanted OctoPrint for its print queue functionality to decouple the print process from Slic3r (which turns out to be rather unstable at times, at least on the Mac). But it turns out that Palette’s OctoPrint plugins work with plain ol' OctoPrint, too. So I looked into building an OctoPrint node… and then realized I was overcomplicating things, since OctoPrint doesn’t actually need dedicated hardware1 — it just needs to be on a computer that’s physically close to the printer and has multiple USB ports available.

My desktop computer is physically close to the printer and has multiple USB ports available.

So I looked to see if OctoPrint runs on macOS, and yes, it does; there’s nothing Linux- or ARM-specific about it, as it’s all written in Python. The macOS-specific guide is an okay starting point, but I saw a few things that could be a bit simpler, so here’s what I settled on.

(Also note that these directions should also work for Linux and even Windows users! There’s no reason to build an OctoPrint hardware node if you already have a computer that lives nearby your printer!)

Python version management

First, homebrew no longer ships Python 2, although macOS apparently still comes with it (despite Apple’s warning to the contrary). OctoPrint works with Python 3 now, but if you really want to run 2 for some reason (and you really shouldn’t!), use pyenv, which is installable via homebrew. For example, to run under Python 2.7, do:

pyenv install 2.7.17
pyenv local 2.7.17

But I’d also recommend pyenv for any Python version management stuff; homebrew’s Python stuff is okay and all, but there’s still a lot of good reasons to just have your own self-managed Python versions.2

pyenv will also automatically install pip and virtualenv for you, and since those live in the pyenv sandbox you can also pip install pipenv with no worries about hecking things up system-wide.

Running from git/development

I use pipenv instead of virtualenv but that’s mostly a matter of preference. I also prefer a local editable pip install instead of running setup.py directly, as it does a nicer job of handling dependencies and so on IMO.

The instructions on the git repo itself work with macOS as well, and there’s no need to do anything special for macOS except maybe installing pyobjc, which I haven’t had to do yet.

For a virtualenv setup, do this (from your git workspace directory):

# setup the environment and install octoprint
virtualenv venv
venv/bin/pip install -e .

# start octoprint
venv/bin/octoprint serve

and if using pipenv, do:

# setup the environment and install octoprint
pipenv install -e .

# start octoprint
pipenv run octoprint serve

The installation instructions suggested installing pyobjc as well (venv/bin/pip install pyobjc or pipenv install pyobjc); I didn’t do that and it seems to be working fine, but maybe it’s needed for some of the functionality I’m not using yet.

Anyway, after all this, you can point a browser to http://octoprint.lvh.me:5000 (I like using lvh.me to keep my password manager happy) and you’ll have a running OctoPrint.

Upgrading is as simple as doing a git pull.

Running from release

If you want to run a release build it’s even easier! First, make a directory to hold your environment (e.g. ~/OctoPrint or the like) and cd into it. And then if you want a specific Python version, do the pyenv thing to select it.

Next, for virtualenv, it’s:

virtualenv venv
venv/bin/pip install octoprint

venv/bin/octoprint serve

and for pipenv it’s:

pipenv install octoprint
pipenv run octoprint serve

If you ever want to upgrade releases, you can either do venv/bin/pip --upgrade octoprint or pipenv upgrade (which will also upgrade everything else, which is one of many reasons why I like pipenv).

Configuration stuff

Note that OctoPrint itself keeps its configuration files in ~/Library/Application Support/OctoPrint — your environment directory is purely for holding your environment (if using virtualenv) or lockfile (if using pipenv).

Also, like many Python things (including Publ) it defaults to port 5000 for its server. See the OctoPrint configuration documentation for information on changing that. (The short version: edit ~/Library/Applciation Support/OctoPrint/config.yaml and then add something like port: 8765 to the server section, and now your instance will run at http://octoprint.lvh.me:8765.)

Also if you want to do the external routing stuff (so that Canvas can submit directly to your OctoPrint instance) you’ll probably need to do some rejiggering with your home router. It might also be nice to set that up using a vhost-based fronting server for various reasons (mostly, using a vhost adds an additional layer of obscurity rather than making it obviously exposed to the world). For that use case I prefer to use UNIX domain (i.e. file-based) sockets instead of open TCP ports, but OctoPrint itself doesn’t seem to expose that as a configuration option and it isn’t clear if its particular choice of fronting server (Tornado) does either. This merits further exploration… later.

What’s next?

I need to see if macOS-hosted OctoPrint is compatible with the Palette plugins; I don’t see why it wouldn’t be.

I’d also like to get a camera set up. I’ve tried a few different approaches but it turns out OctoPrint really wants it to be a streaming server and not, like, a one-shot webcam CGI or whatever. And setting up your own private compatible streaming server is surprisingly difficult for some reason. Or at least exceptionally poorly-documented for macOS.

  1. I am, incidentally, getting pretty fed up with this general tendency to see every multiprocess or hardware problem as needing a dedicated microcontroller/embedded system/VM and all of its implied physical/operational overhead. But that’s a rant for another time. 

  2. This is also getting rather out-of-scope for this blog entry, but the short version is: if homebrew updates your Python version, all of your environments break, because they’re now pointing at nonexistent Python binaries, even for patch releases. Also, every now and then, the latest-and-greatest Python versions end up breaking things (pygame doesn’t work on 3.8, for example, and it won’t for the forseeable future for reasons), so you don’t really want to rely on homebrew keeping your required version of the interpreter around. 

    pyenv also makes it pretty simple to experiment with alternate Python implementations, too, in case you want to try out PyPy or Jython or whatever, although I haven’t seen a lot of this being supported in the greater Python community for whatever reason.


Before commenting, please read the comment policy.

Avatars provided via Libravatar