We've set up a fairly intricate Octoprint installation to handle sending to our 3(so far) configured printers. Each Octoprint instance lives in a Docker container on a Linux server. There's some special plumbing in place to allow access to each printer (and camera?) via USB uniquely.
The printers in the shelving unit are hooked up to 192.168.20.35 (aka octoprint.local), whereas the MakerMade (and eventually Delta) are hooked up to 192.168.20.139 (no good hostname yet, sorry). The Creality Ender 3 is a special case, as it is running Klipper, and has a separate Mainsail interface at http://ender3.local
(add full details of how this is set up and administered….)
Links to the instances (only usable on MakerNet):
- PowerSpec i3:octoprint.local:8082
- Prusa i3 MK2S: octoprint.local:8085
- MakerMade 300x: http://192.168.20.139:8086
Monoprice Maker Ultimate:octoprint.local:8081Monoprice MP Select Mini: octoprint.local:8083XYZ DaVinci 1.0 octoprint.local:8084
Adding a new printer: The easiest way is probably to duplicate an existing printer's Docker setup (they're all in /root/) and edit the docker-compose.yml to taste:
- Set your port to map to port 80
- under devices, map your serial port
- (and webcam, if you have one)
- set your volumes, so the instance has persistent storage - we're keeping them all in /fs1
- docker-compose up -d
Using udev to map the serial port to a persistent name:
- edit 99-usb.rules
- udevadm control –reload-rules && udevadm trigger or udevadm control -R && udevadm trigger if the first one gives you grief.
- unplug & replug the printer USB cable
On PopOS, you'll also have to nuke brltty before the above instructions for udev mapping:
- systemctl stop brltty-udev.service
- sudo systemctl mask brltty-udev.service
- systemctl stop brltty.service
- systemctl disable brltty.service
Using mjpeg-streamer for webcam monitoring:
- check out /root/docker/mjpeg-streamer on either machine for a somewhat working docker-compose file
- I tried getting udev to assign /dev/video* to a constant symlink, but had lots of issues. /dev/video0 is *probably* fine for now.