I have several 3D printers, and I’ve always been satisfied with using either Repetier or Marlin on all of them. There are a few other firmware versions that could run on my hardware, but those two have been all I’ve needed. Sure, it was painful for a while having to juggle features to fit the firmware image onto the smaller microcontroller boards. Now that Marlin supports big 32-bit boards however, that hasn’t been a problem. But recently, I’ve been on a program to switch everything to Klipper.
In this post, I’ll tell you why I did it and give you some data about why you might consider it, too.
The Landscape
Marlin is written in C and burned into a 3D printer’s flash memory. It does a lot. It receives G-code commands, interprets them, and translates them to meaningful actions on the hardware. Modern versions handle automatic transformations to account for lumpy beds, input shaping to reduce shaking, and linear advance to produce better prints.
It might seem simple to control a 3D printer, but there are lots of little details to take into account. For example, if you are moving the head between two XY coordinates and you expect a certain flow rate, then you have to figure out how fast to turn the steppers to get the right amount of plastic out over that time. You also may have to retract before you start a move, make sure temperatures are stable, and transform the actual coordinates based on bed leveling data. There’s a lot going on.
Klipper does the exact same job, but it does it differently. On the 3D printer board is a tiny piece of software that does very little. It’s a bit like a device driver for the printer. All by itself, it does nothing. But it can handle very basic commands that describe how to move the machine.
All the rest of the processing you expect to happen now runs on some Linux computer. That is very often a Raspberry Pi, but it could be a spare laptop, your desktop computer, or anything that will run a reasonable Linux install. Several vendors even sell single-board computers with touchscreens made specifically for running this part of Klipper.
However, even though a screen is nice, you don’t really need it. I’ll talk about that more later.
The Problem
Historically, Klipper was a way to break out of the limitations of using tiny 8-bit controller boards with limited memory. These days, you can get plenty of powerful 3D printer controller boards, so that isn’t as much of an issue as it used to be.
Instead, I have another problem. The build. One of my printers is a custom printer that doesn’t really match any other printer in the world. So, I have to build my own version of Marlin. That’s actually not very hard to do. However, there are two things that are very annoying. First, you have to flash the firmware. The printer uses DFU, and I have brought out the “bootload” switch, but it is still a pain, and I possibly will brick the printer if I make a mistake. A recoverable brick, but still.
But the real problem is keeping my version of Marlin up to date with the official version. The version I have running now is old enough to not have some of the cool features, so I would have to merge the mainline in with my fork. Can it be done? Of course. But it’s awkward, and the longer you wait, the worse it gets.
For a recent 3D printing class I sometimes teach, I picked up two cheap printers that had great support for Klipper, so they were my guinea pigs before I attempted to switch over to the custom printer.
I should note that Klipper, I think, appeals to people who like tweaking settings and editing configuration files. Since you’re reading Hackaday, there’s a good chance that describes you. But if you despise opening a Bash shell and entering text, you might think about avoiding Klipper. While the UIs do a good job of protecting you from most of this, there’s going to be times when you’ll need to get your hands dirty.
Is Klipper the Solution?
You do have to flash a small program over to your board to run Klipper, but once you do it, you very likely will never do it again. If you are dissatisfied, you can flash Marlin back and there’s no harm done. Just make sure you can get your hands on a stock firmware image for your printer before you start making any changes. In my case, I do have the ability to go back to Marlin if I ever wanted to. But at this point, the only reason I’d make the switch back was if I planned on selling the machine to a beginner.
After that one flash, all the other setups for anything you want to do are done through Linux, mostly through a simple configuration file. There are also web-based and touchscreen-based GUIs, but everything is really in a file. The code, too, is mostly in Python, so making a change or adding something is relatively simple, especially if you are comfortable with Linux. The hardware stub and a small part of the host is in C, however.
If you aren’t comfortable with Linux, the user interfaces will help. You can even use them to edit your configuration files in your browser, so it is possible to have no idea how to use Linux and still get by.
Klipper Architecture
I was going to draw a diagram of the Klipper architecture, but [Sineos] beat me to it, so I borrowed this one from the Klipper discourse group’s documentation.
The final red block is the host, and that’s where all the real processing occurs. It reads G-code and worries about bed level, temperature, and so on. One of the key features is that you control it with macros, which could look like G-code or something else.
Custom G-Code
For example, suppose you want to create a new G-code, say G12345. As far as I know, that’s not a legal G-code. But you can define a macro named G12345 and make it do whatever you want. You can also define macros for real G-codes if you want. So, defining G28 would allow you to take over how the printer homes itself.
You can also have a macro named HACKADAY_LOGO or FILAMENT_CHANGE and stick those in your G code to make Klipper do anything you want. You can even do programming language constructions like for loops and if/then/else in your macros.
Klipper is almost completely concerned with reading input codes and spitting out basic movements. A lot of system management falls to Moonraker, which talks to Klipper for you and communicates with the Web, MQTT, Home Automation, and more. A configuration file is also used to set up Moonraker. So for example, if you want a text message when your print is complete, Moonraker can do that. It also can keep your system up to date.
User Interfaces
It also communicates with user interfaces. For example, if you have a touch screen, it also talks to the system via Moonraker. However, the user interface is usually a web browser viewing pages provided by Fluidd or Mainsail. In fact, you can run both on different ports and use either one you like at any time. The browser doesn’t have to be on the machine you have Klipper on, by the way. In that way, it is like OctoPrint, which you can also use if you like.
OctoPrint has many features but can be heavy to run. For whatever reason, most people seem to run Fluidd or Mainsail, even though it is possible to use OctoPrint and benefit from its many plugins and features. Moonraker can even be made to mimic OctoPrint — so slicers that know how to send jobs to Octoprint can also send jobs to Klipper.
Here’s a look at part of Fluidd’s main page (you can, of course, configure and theme it):
The Next Trick… Juggling!
I mentioned earlier that Klipper can control multiple boards. Some new bed sensors, for example, are their own computers, and Klipper can talk to them directly.
For another example. Suppose you have a board with lots of stepper drivers, and you decide to build a printer with four extruders. Later, you decide you want filament run-out sensors for each one, but your board doesn’t have enough input ports. No problem! Just get a second cheap board, flash it with the stub firmware, and tell Klipper about it. There’s no reason those sensors have to be on the same board as the other electronics. If you are running on a Raspberry Pi, there may be times when you want the Pi to not only run the main Klipper code but also host I/O devices, and that’s the function of that bottom block.
Next Steps
In the next installment, I’ll tell you more about how you can get started and a few things to look out for. If you already use Klipper, let us know your favorite tricks in the comments.
We covered Klipper way back in 2017, and it has come a long way since then. Of course, there are other ways to speed up your 3D prints.
I’ve had switching to Klipper on my to-do list for years. It only hasn’t happened yet because ahead of it in the list are hardware changes that are taking me time to design parts for.
I was disappointed to learn that Klipper has been turning away from Octoprint. I know there are alternative remoting solutions for Klipper but I’ve been enjoying Octoprint for years now, contributing to the Patreon and I like environments that can be customized with plugins.
But I’ll still give it a try one of these days.
I initially was nervous about losing my various OctoPrint plugins – but I’ve not missed them. Things are different, of course, and it’s possible that with Klipper I’m just working with Klipper rather than using OctoPrint to add things to Marlin.
Also, Klipper with Fluidd seems to run better on the smaller rpi units than OctoPrint. Though over time I’m shifting to rpi4 simply for the better WiFi upload speed.
I use an old x86 netbook to run klipper+octoprint setup. Even has a jolly-wrencher on the lid.
That diagram needs to include Fluidd and Octoprint and a web browser and stuff, too!
That’s the user interfaces including fluid-padd etc
Of course, I do not use OctoPrint with Klipper – OP is bloated, errorprone and slow, like building and flashing Marlin (both were abandoned when I switched to Klipper for all my printers 5 years or so ago). Mainsail and Fluidd are streamlined and fast (I prefer Mainsail, but there is little difference). Yes, there is a short learning curve (assuming you are skilled in Marlin’s features), just as with Marlin, but on the plus side it is extremely fast to iterate through the trial and error (compared to Marlin). And updating is still a peach (Moonraker + Pi), even when you have to build/flash multiple targets (Klipper for Pi + CAN-toolhead).
i feel like the strongest motivation for this — limited processing power on the printer controller board itself — has pretty much fallen away as ‘smoothieboard’ 32-bit arm has become so prevalent. so i don’t really understand the advantage. you can more or less do numerically difficult operations directly on the printer. and you can use a pretty convenient C environment on the printer too, without bending over backwards to accept the small size of the computer.
of course, maybe i’m just not properly appreciating the more complicated transformations people want to do these days. it just seems to me, hacking some C code on the PC isn’t intrinsically any easier than hacking some C code that runs on embedded arm.
but i use Marlin and i see a huge problem there. it’s been (thankfully) the better part of a decade since i last looked at the Marlin source…but it was painful. clearly, the development model is that someone would fork it, hack it just enough to work with their personal printer, and then someone else would fork that fork, and on and on. no overarching ‘software engineering’ plan of any kind. so maybe it’s not so much that running on the PC is good but that any de-novo implementation would be a step up from Marlin. simply being architected at all is an improvement, regardless of which architecture it is. (but surely someone has come along and ‘cleaned up’ Marlin since a decade ago?)
luckily it’s all academic to me because for reasons unknown, the arduino atmega board on my printer stopped accepting new firmware over USB. so i am stuck where i’m at until i make the decision to buy a smoothieboard or similar :)
Marlin still have its place, specially on printers targeted for beginners.
That being said, Klipper is just much more versatile, both for users and developers – I’m still waiting for Marlin to support the RP2040 microcontroller, something Klipper added not long after launch in 2021. It also give more freedom to choose your controller board, as it separates the firmware compilation (targeting a microcontroller) from the configuration of the firmware itself (done with a configuration text file). This have the effect of making it possible to use whatever pin you have available to do things not intended originally.
Give Klipper a chance, it can run even on the original Raspberry Pi from 2012 (granted, it doesn’t have the processing power to do some tasks like calculating the input shaping settings, but you could do that with a newer one and just let the old apply those settings later).
Not flashing over usb (serial) sounds like the bootloader is bricked. It’s possible to reflash the bootloader using another arduino using the icsp sketch but honestly it’s probably a better use of your time/money to just upgrade to a 32 bit board.
Smoothieboard is ok, but you should check out some of BigTreeTech’s boards. 56V motor support, 8 motor channels, replaceable drivers, a variety of Cortex M series CPUs to run either Klipper or Marlin, some boards can piggyback Pi modules directly, etc. Some really cool options.
Once you use Klipper you’ll unlikely go back to Marlin. I won’t! One huge advantage is that many configuration options that are either compile-time or buried within NVRAM in Marlin are set by configuration files in Klipper. It makes re-configuring printers so easy. Want to add custom buttons or macros? Easy. Want to add new hardware (sensors, screens, different drivers etc.)? Easy. Want to add a camera? Easy. Want to monitor your printers from any machine on your home network? Easy.
Separating Klipper onto a PC-like host allows the board firmware to be simplified to do the things it needs to do well – servicing the hardware. Running real-time operations (soft or hard) in firmware whilst simultaneously doing higher-level operations is non-trivial, and whilst Marlin does a pretty decent job overall, it has its limitations. Many people that switch to Klipper find a significant decrease in print times even when using similar speed settings, evidence that many printer boards are struggling to keep up.
You’re not wrong about the development ecosystem. My switch to Klipper was motivated by general frustration trying to find a Marlin build with the feature-set I wanted. It all seemed very fragmented.
wow! the price is right for these bigtreetech boards! thanks for saving me the search if/when i decide to upgrade :)
There are also boards out there which directly integrate a big enough Arm core to run Linux and Klipper without adding a Raspberry Pi, like the Makerbase SKIPR.
The development process of Klipper is a lot easier, since all high-level stuff is done in Python. This may not directly influence ordinary users, but it definitively makes a difference if you are looking for advanced features, because someone might have implemented that for you in Klipper.
Its worth noting that whilst you can hook up a display to the raspi running klipper and have KlipperScreen running on it, you can also have it run on a remote device with X11 forwarding. This works surprisingly well with pretty much any old Android tablet. I’m using an old 7″ Fire tablet which my kids long abandoned and its perfect, and completely wireless.
The official docs cover how to set it up:
https://klipperscreen.readthedocs.io/en/latest/Android/
So, Klipper is a sort of equivalent for LinuxCNC combined with an motion controller such as Remora
https://github.com/scottalford75/Remora
Remora is (as far as I understand) controlled from LinuxCNC in a “servo thread” and it receives a command every ms, and Remora calculates stepper motor pulses and timing from that. on a uC (“standard” 3D printer PCB’s are common with Remora.
I have never used a CNC printer yet, because my main goal is aluminium and steel and I want a higher accuracy, so I built my own CNC machine. For now I’m controlling it with GRBL, but I do have interest in LinuxCNC. I am also interested in how this can be combined with a 3D printer head to do 3D printing (Mechanical stuff is no problem), but I’m mostly lost in which software to use. What software do you put in a uC if you manly want CNC milling, but also want some 3D printing every now and then?
That looks like the ideal situation to use Reprapfirmware, specially the Duet 3 family of boards.
Smoothieware has long had the Mill/Laser/3d printer thing handled. It is GRBL based like Marlin and some others.
V2 Firmware even has some experimental lathe functions too.
Wiki has recently been migrated to Github so it has lost most of the pictures at the moment…but the info is there.
I am biased since I work on the project directly…but it has been stable at milling and printing for many years.
I think Smoothieware still doesn’t have even basic functions needed for CNC usage, like a pause button that acts immediately. LinuxCNC is much more usable, because you can also do feed rate override and other settings with immediate effect. Having several seconds of delay in pause is unacceptable, and the immediate abort (with possible loss of position) is a poor substitute.
There are a few ways to do this. Some stop immediately and stop the job. Pause takes the queue is empty. If you edit the config so your buffer size is smaller (IIRC using “planner_queue_size”) you can make the pause faster too.
https://smoothieware.github.io/smoothieware-website-v1/stopping-smoothie.html
LinuxCNC is not the same as smoothie…just like klipper is not the same. They are more like hosts with control as opposed to a MCU based gcode interpreter. LinuxCNC and such are great…lots of dev work done and from what I have seen quite advanced…but the use case is different.
It does seem though that a few people have complained about the stop button issue…for years the advice has been to either use abort or to make the buffer smaller. The issue relates to the block structure from what I know of it (which is only what I was told). Not sure how many who have had issue with this have tested the fix…but it seems to be one of the few “problems” brought up.
So, like a WinModem?
I have found that my stock Ender 3, with Cura and Octoprint, is just fine. But I enjoyed reading about Klipper. Thanks.
I upgraded my Ender 3 with Klipper years ago and would never go back. I was amazed that once everything was setup and tuned the printer was considerably faster, quieter and the prints were even slightly better quality. Granted 32bit mainboards have closed the gap, but there are so many other reasons why once learned Klipper is just a better way to run a 3d printer (at least in my view).
I think one of the real problems with people starting with Klipper is if you want to upgrade your system with a print server and don’t know Octoprint looks easy, where Klipper/Fluid seems similar in terms of a learning curve to compiling/flashing Marlin for the first time. It isn’t though it does still require quite some work, but if you might want to add any other upgrades to your system your likely to have to tackle the problem one way or the other. Put the time into Klipper and once you pass the setup hurdle and see how easy it becomes to configure things and how smooth the printer runs Octoprint becomes kind of redundant, Cura barely notices the difference, and there’s a paradigm shift in the way you approach considering addons like a BLtouch.
Like you, I also used an Ender 3, Marlin, Cura, and Octoprint. I moved to Klipper a couple years ago, with a mainsail as the web UI, KlipperScreen for the touch UI, and MoonRaker for the modbile monitor of prints. It is well worth the time put in to make the change. The increase in print speed alone is incredible. Not to mention making changes on the fly in easy to use config files instead of compiling and flashing Marlin every time you want to make a change…
Yes, in the sense the big cpu tells the small cpu what to do in some custom scheme. I put Klipper on a mini pc to drive an ender 3, first time with klipper and it was tricky.
Use a pi because the process is better documented.
And use this script (menu driven) https://github.com/dw-0/kiauh
To install
Yes use KIAUH to assist you with the install; as well, the community has a lot of experience with a Pi as the Klipper host.
When I got first printer in my hand, I turned it to Klipper as the first thing. And I don’t regret. Updating is easy, it has nice GUI and any change to the printer is just about modifying text config file :)
It has also well written wiki, working forum and useful features e.g. for calibrating input shaper (vibrations) using accelerometer (yeah, the thing which Prusa printers got just now :) )
Might I give a huge thank you to Kevin O’Connor for all his work with Klipper. That is, not just developing Klipper and keeping it up to date and including new sensor and the like – but especially in responding calmly and patiently to the thousands of queries from the user community. Again many thanks, Kevin.
Having come to Klipper via Repetier and GRBL, I am impressed with the way Kevin O’Connor has separated out the various functions and the multitude of sensors used in the 3D printing implementations now. Also, Klipper enables you to use the smaller pieces of hardware, RPI Zero W and the like, plus the small Arduino’s and the like, to run machines like drawbots, sand drawing bots and all manner of wire bending machinery.
I am progressing through using Klipper, a RPI Zero W, and Arduino Uno plus 2 stepper drivers and a servo as the firmware in this https://www.scribd.com/document/518471675/DrawBotAssemblyUserGuideV3.
At the end of this project, there will hopefully be a generic Klipper implementation for a 2D system which can be used for other systems – well, that is the intention,
The only thing I regret after sticking a Raspberry Pi 3B with Mainsail OS into my Ender 5 pro is that I waited far too long to do it.
It‘s just so much better than anything else!
Since I started using Klipper as firmware for my 3D printer, I have been very pleased with the increase in print quality and speed. Klipper’s performance optimizations have significantly improved my printing experience, especially when working with complex models. Also, Klipper’s flexibility and scalability allow me to customize the firmware as needed.
Recently I found some necessary electronic components on http://www.dhsic.com which are very important for maintaining and upgrading my 3D printer. The site offers a wide selection of electronic components, from integrated circuits to connectors. I particularly like their clear categorization and easy-to-use search function, which makes finding the right part very simple.
If your printer is atmega2560 based, you can have Marlin and Klipper installed on the same printer, I actually uses Marlin quite a lot still now that I can.
https://storepeter.dk/3d-printer/install-klipper-on-your-old-3d-printer-and-still-keep-marlin
Klipper is just another item to break in the chain, SD card corruption, booting time..
Stick with MCUs.
You can leave the pi on, and a good sd card should last a long time. You can also use a usd drive instead of the sd
You have SD card corruption even with MCU (because it’s still the way how you transfer it to printer). In most cases it’s even worse (reading from SDcard by MCU is more sensitive to speed and errors).
You can run klipper on any PC or RPi with SSD these days. That will not fail for years :)
I went from running marlin on all my machines to klipper after tinkering and having to swap out boards that would stall across mnay machines. This was also when I was running a marlin board on a delta machine and the 8bit math wasn’t sufficient for square roots and other calculations. Ended up ditching that machine but got a few ender 5’s which I modified to Mercury one machines.
Nowadays, I won’t touch a piece of 3d printing hardware I can’t have control of the board and connect it to a Raspberry Pi and run klipper. The ability to quickly save configs and transfer between printers without the need for a compile/flash and customer debuggers is a huge boon.
The fact that klipper runs as a process on a linux machine, means any failure doesn’t lock me out of a bootloop and require some sort of in circuit debugging to reflash. I have all the tools I run in linux like htop, kill, and dmesg incase things break.
I’ve even been able to run multiple instance of klipper and run two or more printers at the same time, running at 100 mm/s all running their own version of a web interface with fluiddd. Even if this means I connect to an old desktop to do all the running, I can also use the same machien remotely to monitor and set other configurations/manage machines from a single node. This is ontop of the multi board control per machine for things like the newer hotend/extruder/motor controllers and accelerometer for vibration tuning.
In 2024, Marlin in my opinion is stone age tech.