TL;DR: I converted my Anycubic Linear Kossel to Klipper.
Using a hacked Chromebook as the host, which is great and I recommend hacking surplus education market Chromebooks for many of hobby projects usually done with an SBC.
Running in containers as a docker-compose project, which works but is dumb and wasteful.
Next I’m going to try to do some systematic performance experiments to it, but that’s for a later post.
Details below.
I wanted to play with Klipper (a hybrid control stack that uses a relatively generic firmware on the printer uC for IO only, and does parsing and motion planning etc. on a host computer) and the nice modern fluidd web front-end for it, with my little old Anycubic Linear Kossel which is known-supported. This was brought about partly by having some un-allocated time for a change, partly by seeing some neat Klipper-based projects, and partly because the aging craptop I’d been using as an OctoPrint server finally finished dying.
I grabbed the older of the used Chromebooks I have around – a Dell Chromebook 11 3189, flashed with a UEFI payload and running normal Arch Linux which I was last playing with Hyprland on – to use as the host part, not just because I already had it, but because this stack is designed to run on a little SBC, and it is my conviction that education market surplus Chromebooks are cheaper, better, easier, and more ecologically sound than SBCs and the associated pile of expensive add-ons for like 90% of tasks people get them for. I’m even using the built-in webcam as the monitoring camera by …sticking the whole laptop on an empty box so it lines up.
I started setting it up, downloaded the klipper package out of the Arch repos, built a firmware image and flashed the Trigorilla board’s Atmega2560 over to Klipper, and loaded up Lukas’ sample config. Then I realized that while Arch has Klipper (with some nicely opinionated packaging choices since upstream is a little goofy) and Fluidd in the repos … the Moonraker API package required for them to talk to each other isn’t packaged (?!) There is only a moonraker-git in the AUR, so I assume at one point it was packaged and something breaking happened, but I haven’t investigated.
Instead of doing the reasonable thing and just building the Moonraker AUR package or installing a better supported OS on the computer, I saw this prind project that runs the whole stack out of a pile of docker containers. Since that seemed easy and likely to offer desirable stability/portability guarantees, I decided to use setting that up as an excuse to refresh on dealing with docker and docker compose.
I generally view containers as 90% “adding an extra layer of complexity to isolate badly designed, un-deployable software,” but that’s kind of what we’re doing here, so it seemed reasonable(-ish), and It’s good to check in on container-land once every once and a while since they’ve become so common.
The only special thing I had to do (which is mentioned way down in the prind README) is cause the printer’s serial device to be assigned GID 20 – which on debian-likes is “dialout” and on Arch is fortunately unused by default, and likewise make whatever webcam I want to use get GID 44 – “video” on debian-likes, also unused by default on Arch. That this is how permissions work through the container boundary is rancid.
That’s straightforward with a couple udev rules on the host like:
=== /etc/udev/rules.d/71-kossel.rules ====
#prind's debian-derived container wants the serial device to belong to dialout with gid=20
ACTION=="add",SUBSYSTEM=="tty",ATTRS{idVendor}=="10c4",ATTRS{idProduct}=="ea60",GROUP="20"
# And cameras need GID=44
ACTION=="add",SUBSYSTEM=="video4linux",ATTRS{idVendor}=="1415",ATTRS{idProduct}=="2000",GROUP="44"
… And with that done it just works. Did the automatic probe calibration, automatic Delta calibration, automatic PID calibration, edited my PrusaSlicer profile to output Klipper-dialect gcode, and printed a part.
It’s not noticeably better (or worse) quality or faster than it was with the Marlin build I had on there – which is not surprising since I sliced with essentially the same profile – but it does sound different with the different control regime.
I have a suitable “Mellow Fly” ADXL345+ RP2040 accelerometer board, and I’ve already rigged up an adapter to mount it to the effector, so I can start figuring out how to push it and/or start studying if any stiffening tricks are worthwhile – one of the main reasons for this project is I’d like to systematically try some schemes for stiffening a kossel.
Now I have 5 containers running, totaling something like 2.5GB, to deploy like 25MB of software, which is absurd. It’s all running on a slightly hacked Chromebook, which is not as absurd as it sounds.
As is often the case with appliance-like computers and/or sophisticated deployments, I should have just installed Debian and the packages I wanted to deploy on the bare hardware, and not looked at as other-than-appliance again for 5 years, instead of touching the complexity fetishist junk, but it’s good enough to play with for now.
