My experience with Klipper

[David O Smith]

Hi Andy and Whitney,

Thank you for the podcast.  I am a few episodes behind, but I wanted to throw some information into the ring about my experience with Klipper. I believe this can help a lot in getting past the notion that the exclusive purpose of Klipper is to print faster.

In 2019 I bought a Creality Ender 3 Pro.  It was printing okay, but I noticed my aluminum bed was a little concave, so if I tried to print something larger than 40 or 50 mm then I had 1st layer adhesion problems.  I did some research and decided to purchase a BLTouch to attempt to compensate for the issue.  It turned out, however, that the controller board for the Ender 3 Pro had an Atmega 1284 MCU, which has very limited memory.  In order to implement the BLTouch I had to disable other features until I could get the code small enough to flash to the board.  I lost SD card and the display functionalities.  I was trying to avoid spending more money on an upgraded board until I was sure I was full in.

I don't remember how I stumbled across it, but I found Klipper, and the thing that was incredible about it was it offloaded all of the work from the controller board MCU to the Raspberry Pi.  The Pi would handle the math and all the machine kinematics, figure out the specific stepper step timing using a lookahead queue, and send a simple message with the pin changes and MCU clock time for the change into a buffer on the MCU over USB. The USB to serial communication speed is much faster than the speed of any machine operations.  Not only did this enable me to use the BLTouch without losing the display, but I soon found a lot of other helpful features, like the ability to create my own custom G-Codes, change the display menus easily, and store and use variables and user prompts easily.  I believe the early beginning intent of Klipper was to get more power out of the 8-bit MCUs then they were currently capable of on their own.  Using Klipper also meant that any configuration changes I made did not require flashing anything to the MCU again. The configuration is just a file on the Raspberry Pi, and all that is required is to issue a simple command that causes the Klipper instance on the Raspberry Pi to load the new config settings into ram.

This was all happening as the 32-bit boards were just becoming available and affordable, so they weren't broadly used yet.  I recall there even being some discussions on YouTube channels on if the upgrade was worth the cost.  As they became more prominent more developers implemented new Controller Board configurations into the Klipper ecosystem.  The 32-bit controllers may not need the processing power of the Pi any more, but the flexibility and constant development going into Klipper has been a huge benefit as well.

I believe that the reason a lot of users talk about speed with Klipper is because it has become much more popular lately as an easy to implement flexible system that you can build a machine around, and the machines are far improved from where we were in 2019.  The need to add functionality to a limited program flash 8-bit MCU is not as significant anymore.  Klipper is now available for a large selection of MCUs, and any time another board comes on the scene that an interested developer wants to implement they can pull request firmware code for the low level implementation for that MCU without having to worry about any of the higher level klipper functionality.  In fact, the actual controller board itself isn't incredibly important (you configure the board pinout in your Klipper configuration file), it is mostly whether or not the actual MCU on the controller board has been added to the Klipper repo that determines if it is likely to work.

The best way to see a list of well implemented controller boards is to look in the example configs file on the GitHub repo: https://github.com/Klipper3d/klipper/tree/master/config

There are example configuration files there for both specific controller boards and full unmodified machines.  There are a few of the controller boards where you do have to jump through a few more hoops to flash the Klipper firmware to the MCU, but that only needs to be done once to start, then maybe occasionally later if a major release of Klipper needs to add some new low level functionality and you want to update.

One of the other valuable functions that Klipper provides is the ability to use multiple control boards for the same machine.  I did end up upgrading my control board, but if I want to experiment with additional steppers for something like a multi-material project I can add the old Ender 3 Control Board into the system and use those steppers drivers in tandem with the main control board.  I can also implement any number of sensors, LED drivers, switches, servos, etc. just by adding them to my Klipper config file with either a pin from the control board or the Raspberry Pi, (or even just a regular vanilla Arduino).  It is fairly trivial to have "custom g-codes" with variables to control LEDs that can show machine state, hot end temp, etc.

I will, however, admit that there are certainly reasons one would not want to use Klipper.  I am sold on it, but would never claim it to be the tool for everyone.  If your machine setup is well tuned and you are getting incredible prints then switching ecosystems would probably not be ideal.  There are times where someone attempts to transition from Marlin or some other firmware and they are unable to get certain functions to work correctly that they didn't have a problem with before.  Sometimes it is hard to nail down if it is a configuration issue, a quirk with settings from the slicer that the 2 firmwares respond to differently, or perhaps some unknown bug inside Klipper.  The active developers on Klipper have always been phenomenal at helping as much as possible, and when Klipper transitioned to using Discord for community discussion the ability to get help has grown.

It is hard to maintain a list of working control boards, as no one developer has access to them all.  However, there is firmware available for a number of atsam, avr, arm, stm32, and some other architectures of MCU.  The official Klipper documentation contains the information for MCUs in the Bootloaders section.

There are a lot of features that are really hard to show the value of until they have been tried personally.  The ability to have an interactive manual bed leveling setup, probing and storing bed meshes (even the possibility to store multiple bed meshes, though I am not sure on the application of for this).  The ability to store the machine state, do some other function like move the head for a time-lapse, or make a manual filament change, then restore the machine state to pick up where left off.  Also, the flexibility and creativity you can use with the custom g-codes is really hard to describe until you dive in and use it to add something or solve some problem.  You can also intercept most g-codes from the slicer and tweak them before sending them on to the printer.

The Command Templates page gives a good insight into the possibilities of the custom Klipper config options.

One last thought, in episode 415 the question was asked why the Raspberry Pi itself wasn't used directly to drive the stepper drivers.  I don't know if it would actually be an issue, but the advantage of a MCU over a computer processor, in this scenario, is that it programmatically step driven (they don't multitask naturally).  It can be difficult on a computer processor like a Pi to give exact specific timing to events, as it is running a lot of processes in the background, some of which have priority, so the processor is constantly delegating amounts of time to different tasks, typically outside of the control of a developer.  The Klipper Firmware on an MCU sets up interrupts to happen at specific, well defined times so the stepper pulses are much more precise.  So with Klipper we get the processing power and computational benefits from the Pi, and the precise, timing specific benefits from a dedicated MCU.

(As a side note from the same episode, the newer Raspberry Pis, maybe starting with 3, automatically throttle their processor if they overheat, so performance will suffer severely, but you are unlikely to damage the board if it isn't properly ventilated).

Thank you again for the podcast,

David