Hacker News Reader

Comment by zbrozek | Hacker News Reader

Not sure what's happened to make this news now; Klipper has been out and loved by many for quite some time at this point. Regardless, it's nice to see it get some press. I run it on all of my filament printers.

It's an interesting (and somewhat puritanical) approach to embedded systems design that mercilessly evicts functionality out of the microcontroller and into software on a higher-performance computer. The microcontroller executes a pre-planned time-scheduled queue of actions sent down from a process on the heavier-iron machine.

The model has made it very easy to port to a huge range of hardware and to do slick things like synchronize and distribute tasks across many disparate microcontroller nodes.

View on HN

I've followed this project for a longer time and I see less of the puritanical approach.

The "typical" setup before Klipper was Octoprint on a Raspberry Pi and a 8-bit board connected by USB. This setup ran into a lot of space / runtime / etc. issues for implementing advanced algorithms (or simply delta kinematics). Octoprint mostly just passes GCode to the 8-bit board which has to do all calculations.

With Klipper, the've split the workload so that both systems do what they are better at. The faster non-realtime processor does the heavy lifting regarding motion kinematics and the slower realtime controller does the synchronized moves. This allows for additional flexibility as it's much easier to have a modular linux tool and keep the uC firmware common.

I think the uP/uC split is a good alternative to bigger and more expensive boards like the Duet Series of boards.

If any it is less relevant now because of the 32 bit printer boards...

3D printers are becoming extraordinarily inexpensive. When you can get a decent 3D printer for a couple hundred dollars, it’s more important than ever to have firmware with impressive functionality that can run in the cheapest of microcontrollers.

that's why FluidNC is so great: https://github.com/bdring/FluidNC Designed specifically for teh ESP32, it's a ground-up rewrite of grbl for ESP32. I've replaced all my various firmwares across devices (not my printers- those run prusa firmware) I build or use (microscopes, CNCs, various stages).

I still like the idea of a microcontroller doing the low-level work mostly controlled by a higher level microprocessor/SBC but it seems unnecessary?

Why doesn't Marlin feature such resonance compensation then, except for "it has not been built yet"? I suppose Klipper does offload heavy computation to a multi-core Raspberry Pi as opposed to a single-core STM32F1 running at 32MHz generally.

Reply on news.ycombinator.com