Klipper – open-source 3D Printer firmware
klipper3d.org
klipper3d.org
It's an interesting (and somewhat puritanical) approach to embedded systems design that mercilessly evicts functionality out of the microcontroller and into software on a higher-performance computer. The microcontroller executes a pre-planned time-scheduled queue of actions sent down from a process on the heavier-iron machine.
The model has made it very easy to port to a huge range of hardware and to do slick things like synchronize and distribute tasks across many disparate microcontroller nodes.
The "typical" setup before Klipper was Octoprint on a Raspberry Pi and a 8-bit board connected by USB. This setup ran into a lot of space / runtime / etc. issues for implementing advanced algorithms (or simply delta kinematics). Octoprint mostly just passes GCode to the 8-bit board which has to do all calculations.
With Klipper, the've split the workload so that both systems do what they are better at. The faster non-realtime processor does the heavy lifting regarding motion kinematics and the slower realtime controller does the synchronized moves. This allows for additional flexibility as it's much easier to have a modular linux tool and keep the uC firmware common.
I think the uP/uC split is a good alternative to bigger and more expensive boards like the Duet Series of boards.
I still like the idea of a microcontroller doing the low-level work mostly controlled by a higher level microprocessor/SBC but it seems unnecessary?
My shopping list for a new 3D printer now includes some form of Klipper compatibility (or upgradeability), which is harder than it seems given the penchant for cost-cutting and use of custom control boards (many of which now use semi-private forks of Marlin firmware that seldom get published or upgraded).
Klipper is definitely a more streamlined process though.
I also like the "everything is GCode" configuration model. GCode isn't a particularly great language for configuration, but the internal consistency is appreciated. You can play with things in the REPL, and then when you like what you have, commit it to your config file.
I guess the downside is that the Duet boards are more expensive than a Raspberry Pi and an Octopus. On the other hand, not having to maintain a Linux install on your 3D printer is nice. Raspberry Pis are all fun and games until you want to turn the power off. With RRF, you just cut power to the board and you're cleanly shut down. Do that with a Raspberry Pi a few times, and you will be reimaging it.
The codebase is _not_ well written. The fact that it’s written by one person who can’t use commits properly is problematic and leads to long standing unresolved bugs. The documentation is okay but sometimes confusing.
Klipper has much better engineering practices, although their codebase is also a bit messy.
—-
Re: turning off raspberry pis… I’m using a Duet 6hc with the sbc option, eg with a pi, so I don’t think duet gets a point above klipper for that.
My Ender 3 Pro is upgraded with the SRK Mini E3 v2, Creality Sprite hot-end+extruder, and CR-Touch (switched from BLTouch, because BLTouch is too long for Sprite).
I always look there when the "which printer should I get" question pops up in our extended friend group every few months.
OTOH: Since most controllers are some common MCU + stepper drivers, it's possible to write custom configs as well (afaik the configs in the git are just some persons custom config for their printer, submitted via PR). But I definitely would prefer a printer with a "ready to use" config as well :)
Have been using fluidd in a container on a different server as a web-frontend and can recommend it too.
@GP: You can just check google or another search engine of your choice: