Klipper pt1: Why ?

One key factor that differentiates Klipper from many other firmwares is how it generates actual machine movement from given G-Code.

Instead of implementing cornering speed by using the bresenham algorithm ( basically slapping the extruder around corners ) it analyses upcoming corners on a given toolpath and adjusts acceleration and deceleration via trapezoidal calculations, making machine movement very smooth, allowing for higher print speeds while hugely reducing artefacts like ringing.

A great writeup on how exactly its implemented can be found here ( Klipper is based on the same approach first explored by Chamnit for grbl )

As of now we have three groups of motion planners available to my knowledge:


Unsuitable for machine movement imo.

  • Marlin
  • Repetier
  • Duet

Constant Acceleration via trapezoidal calculations / Virtual junction spline based

Great middleground, this type of toolpath prediction can easily deal with shitty tiny segments most slicers put out for arcs and at least somewhat respects the mechanical abilities of a given movement system.

  • Klipper
  • Smoothieware
  • Replicape
  • Grbl ( CNC centric )

Jerk controlled Motion

Closest estimation to mechanical reality

To be able to do trapezoidal / Virtual junction spline based calculations at the speed needed, the second key factor comes into play, instead of shoehorning calculations into an already overburdened 8bit arduino envelope Klipper relies solely on a Raspberry pi to do kinematic calculations, the typical 8bit Arduino becomes a “Stupid” client for the raspberry. One might even refer to it as the first 64bit quadcore firmware available.

Host – Client based motion enables 8bit Arduinos / Raspberry combos to perform similar to more expensive 32bit boards like Smoothieboard or outright better than Duet f.e. as Duet has the processing power to do proper toolpath prediction but its not implemented in firmware.

This approach is actually fairly old and common in the diy cnc scene, usb / ethernet to lpt buffer bobs removing pulse generation from the host exist since decades.

This has multiple groundbreaking advantages:

  • Pulsing up to 150khz becomes possible on 8Bit arduinos
  • Artefacts like ringing, largely caused by the bresenham algorithm can be completely avoided once Klipper is dialed in
  • High pulsing speeds can lead to higher accels and top speed
  • Dialing in steppers becomes easy and precise, the bresenham algorithm doesnt slam them around causing random stalls anymore, so it becomes possible to fine tune motion systems close to their absolute maximum.



  • Limit graphic LCD support, right now its being worked on, a great alternative with a slick UI is Printoid
  • Limited Bed compensation, as of now only tilt compensation via probing is implemented and no meshed bed compensation, so one might be forced to actually fix the underlying issue instead of compensating for it in software.


Leave a Reply

Your email address will not be published. Required fields are marked *