Ramblings of an aging IT geek
← Ramblings of an aging IT geek
hardware

the day i flashed klipper and my printer stopped crawling

Moving an ageing 8-bit 3D printer from Marlin to Klipper, why offloading motion planning to a Raspberry Pi roughly doubled my usable print speed, and the pressure advance and input shaping settings that actually mattered.

A 3D printer mid-print in a cluttered workshop

For two years my printer has been gutless and I assumed that was just the price of cheap hardware. It runs an 8-bit ATmega2560, the same chip half the hobbyist printers on the planet are built around, and any time I pushed the speed past about 60mm/s on anything with detail the quality fell apart. Corners rounded off, infill turned ragged, and on a part with lots of short segments the whole machine would stutter and slow as if it were thinking very hard about each move. Which, it turns out, it was.

I'd put it down to the steppers, or the frame, or the belts. The real bottleneck was the brain. So a couple of weekends ago I flashed Klipper, and the same physical printer is now doing things I genuinely didn't think it could.

what was actually slow

The classic firmware on these boards, Marlin, does everything on the printer's own microcontroller: parsing G-code, planning acceleration, computing the step timing, and waggling the pins. On a 16MHz 8-bit chip that's a lot to ask. The maths for working out exactly when to fire each stepper pulse is the expensive bit, and when a model throws thousands of tiny moves at it per second the poor thing can't keep up. So it does the only thing it can: it slows the print down until the planning fits in the time available. That stutter on detailed parts wasn't the motors struggling. It was the firmware running out of CPU.

Klipper splits the job in two. A Raspberry Pi (mine's an aged 3B that was otherwise gathering dust) does all the heavy lifting: it reads the G-code, plans the motion, and pre-computes the exact timing of every single step. The microcontroller on the printer is demoted to a dumb executor that just fires pulses at the times it's told. The Pi has orders of magnitude more compute than the ATmega, so the planning is no longer the limit. The 8-bit board, freed of the thinking, is perfectly capable of just doing.

A workbench with a Raspberry Pi wired to printer electronics

the install was less painful than i expected

You build the firmware on the Pi for your specific board, flash it once over USB, then everything else lives in a single printer.cfg text file. That config is the part I actually like. No more reflashing the board and waiting through a compile every time you want to tweak a value. You edit the file, restart Klipper, and the change is live. Coming from Marlin, where retuning acceleration meant a recompile and a reflash, this alone would have sold me.

The fiddly part was getting the pin assignments and microstepping right for my board, which meant reading the existing Marlin config carefully and translating it. An afternoon's job, mostly cross-referencing. Get one stepper direction backwards and you find out immediately when an axis tries to drive itself into the frame, so home each axis gently the first time.

A word on the architecture, because it's the thing that makes the rest make sense. Klipper talks to the printer over USB at a steady rate, streaming the pre-computed step timings down to the microcontroller, which buffers a little ahead and executes them on its own clock. The Pi doesn't have to hit hard real-time deadlines, which is good, because a general-purpose Linux box running a web interface is hopeless at hard real-time. The microcontroller keeps the timing tight; the Pi just has to keep the buffer fed, which is an easy job. It's a clean split, and once you see it you wonder why the 8-bit board was ever asked to do the planning in the first place. The answer, of course, is that for years there simply wasn't a cheap Linux board to offload it to. The Raspberry Pi changed the economics, and Klipper is what you build once that's true.

the two settings that earned their keep

Once it was moving, two features made the difference between "works" and "why didn't I do this years ago".

Pressure advance. Extrusion has lag: when the nozzle slows for a corner, molten plastic keeps oozing out under residual pressure, so corners bulge and the start of each line is over-extruded. Pressure advance models that pressure and backs the extruder off slightly ahead of deceleration. You tune it with a single test print and one number.

[extruder]
pressure_advance: 0.045
pressure_advance_smooth_time: 0.040

The corners on my parts went from softly rounded to actually sharp. It's the single most visible quality change I've made to this printer, and it costs nothing.

Higher acceleration, sensibly. With the planning no longer the limit I could finally raise the acceleration without the machine choking. The frame is the limit now, not the firmware, which is exactly where the limit should be.

[printer]
max_velocity: 200
max_accel: 2500
square_corner_velocity: 5.0

I worked up to those slowly. Push too far and you get ringing, those ghost echoes of a corner repeated across a flat face, because the frame is resonating. That's a real physical limit and no firmware will wish it away, though Klipper's input shaping can cancel a lot of it if you measure your machine's resonant frequencies. That's a job for another weekend.

was it worth it

A genuine roughly-doubling of usable print speed at equal or better quality, on hardware I already owned, for the cost of a spare Pi and an afternoon. Print times that were three hours are comfortably under two, and the parts look better. There's a quieter benefit too: because the config is a text file and tuning is a restart rather than a reflash, I actually tune things now. Under Marlin the friction of a recompile meant I'd live with "good enough" for months. Under Klipper I'll happily fiddle a number, run a test, and dial it in over a coffee, because the loop is fast enough to be worth closing.

The honest caveat: you now have a Linux box bolted to your printer, with all that implies. The Pi's SD card will die eventually, the network will drop, and you've added a thing that can go wrong. For me that's a trade I'll take all day, because I was never going to buy a new printer to solve a problem that was, all along, a software one. The motors were always fast enough. The firmware just couldn't ask them to be.