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.
Constant Acceleration via trapezoidal calculations
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.
- Grbl ( CNC centric )
Jerk controlled Motion
Closest estimation to mechanical reality
- G2 Core TinyG Firmware
To be able to do trapezoidal 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.
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 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.
- No graphic LCD support, as the firmware on the arduino is “stupid” theres no lcd support implemented and its unlikely that itll be implemented at all. Imo not a big loss if you look at alternatives like Printoid
- As of now no mesh compensation and only experimental support for bed leveling probes, so one might be forced to actually fix the underlying issue instead of compensating for it in software.