Klipper – open-source 3D Printer firmware(klipper3d.org)
klipper3d.org
Klipper – open-source 3D Printer firmware
https://www.klipper3d.org/
29 comments
I've followed this project for a longer time and I see less of the puritanical approach.
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.
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.
If any it is less relevant now because of the 32 bit printer boards...
3D printers are becoming extraordinarily inexpensive. When you can get a decent 3D printer for a couple hundred dollars, it’s more important than ever to have firmware with impressive functionality that can run in the cheapest of microcontrollers.
that's why FluidNC is so great: https://github.com/bdring/FluidNC
Designed specifically for teh ESP32, it's a ground-up rewrite of grbl for ESP32. I've replaced all my various firmwares across devices (not my printers- those run prusa firmware) I build or use (microscopes, CNCs, various stages).
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?
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?
Why doesn't Marlin feature such resonance compensation then, except for "it has not been built yet"? I suppose Klipper does offload heavy computation to a multi-core Raspberry Pi as opposed to a single-core STM32F1 running at 32MHz generally.
I can wholeheartedly recommend it if you have an older printer - I recently upgraded my ancient Prusa clone to it, and it’s as if I got a completely new printer: https://taoofmac.com/space/blog/2022/07/09/1230
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).
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).
I run klipper on all my printers and the worst-case scenario to get klipper comparability is a mainboard swap ($50-ish), but most are “if the controller is supported, just make a printer.cfg file”.
With recent lack of Raspberry Pi boards I've been looking for alternatives to run Klipper. I happen to have two Beaglebone Black boards that could control my two printers over USB. Unfortunately, all of the Beaglebone Black support is assuming the printer is directly wired into the SBC GPIOs. I'm not creating a custom printer, only trying to control an existing one. Another complication is the only way to install Klipper and it's components is to build it one's self - no packages, only Python's pip. Doing so quickly eats up all of the Beaglebone's eMMC storage, making the device inoperable. Kind of bizzare that a Klipper install would require ~4G of space. I suppose the next step is to try and create an image using Yocto with everything pre-installed. It's a lot of hoops to jump through.
I think the best part of Klipper is that the settings are a single config file. No need to reflash or compile anything. I had such a struggle making BlTouch work with the original Ender 3 and gave up because of the whole process of changing one line, compile, pop SD card out, turn on printer and repeat. I manage to make it worth with Klipper since I can try everything without even getting up to touch the printer.
I'm right there with you, though I struggled through making Marlin work with bltouch. I must have put in 60-80 hours getting that going. Most of it was the struggle of just not knowing what it looked like to get it working and not understanding that I needed to put in some start gcode to Cura. But the obtuseness of the Marlin config definitely didn't help.
Klipper is definitely a more streamlined process though.
Klipper is definitely a more streamlined process though.
SAME. No one tells you about the M420 command. Worse of all, the original Ender 3 does not have a config EEPROM so it saves the settings on the SD card. Sometimes I’m not 100% sure if the bed mesh is even saved/loaded. Klipper took away all the doubt. Too bad RPi4 are still so hard to find or I would tell all my friends to change to Klipper.
The software (firmware) is great but the community especially over on Discord leaves a lot to be desired. They have this sanctimonious holier-than-thou attitude towards beginners and anyone dared to question their approach. Check out Thomas Sanladerer's saga with them, it's quite eye-opening.
I use RepRapFirmware for all of my 3D printer builds now. Along with the Duet boards, it's really a very pleasant experience. The documentation is extremely good, the forums are nice, and the codebase is well written.
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.
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.
I also use RRF on a Duet, and have poked through their codebase a number of times.
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.
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.
A couple weeks ago I went through and revamped my Ender 3 Pro (modified) including switching over to Klipper, and it's a joy! So nice to have just a text config file that I can modify with "vi" on the Raspberry Pi and tell the printer to reload, rather than having to build Marlin in VSCode and move the firmware around on SD card. Working great!
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).
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).
Am I missing something, or is there no list of supported printers/hardware on that page?
I usually check the git for an example config: https://github.com/Klipper3d/klipper/tree/master/config
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 :)
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 :)
I am hoping to use Klipper on an old Prusa i2 which I am converting to a printer plotter. The software/hardware will probably simply be an Rpi driving an Arduino Uno. Any wisdom/experience available?
After that I hope to have my MPCNC (as a CNC router) running Klipper with a better Arduino board.
Glad to see this getting traction. Marlin was getting long in the tooth, and Klipper is a nice upgrade for every non-Prusa printer I've got. We're even starting to see it supplied by the manufacturer in some cases, e.g. the FLSUN V400.
What is wrong with Merlin? It's older but that could mean they have more features and ironed out more bugs.
The math used in each system to control the rate of flow is very different, I believe Klipper's approach gives a much nicer finish. On top of that, Klipper can also compensate for the resonant frequency of the physical frame+substrate of the printer to minimize artifacts and patterns in the final print. You can tune Klipper as much or as little as you want.
Can recommend. Quick and painless to get it going.
Have been using fluidd in a container on a different server as a web-frontend and can recommend it too.
Have been using fluidd in a container on a different server as a web-frontend and can recommend it too.
I would love to see this concept being generalized to allow for control of CNC mills and other stuff. Not just the 3D printers.
What's missing for the control of a CNC mill? Klipper doesn't force you to use a hotend.
Seems people are doing that: https://forum.v1engineering.com/t/klipper-possible/21924/13
@GP: You can just check google or another search engine of your choice:
https://www.google.com/search?q=klipper+mpcnc
https://www.google.com/search?q=klipper+cnc
@GP: You can just check google or another search engine of your choice:
https://www.google.com/search?q=klipper+mpcnc
https://www.google.com/search?q=klipper+cnc
Kipper is nice. Still waiting for someone to build a firmware on top of embedded_hal in rust, though :/
I thought it was going to be an open source clippy at first. I am kind of upset.
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.