Machine Context
Maybe you are aware that 3d printers nowaways use firmware called klipper https://www.klipper3d.org/
It basicaly works on a principle where MCU does not interpret g-code directly, but g-code is interpreted by PC software and converted to much simpler commands. Basicaly MCU board acts as IO expander with interpolation capabilities. This makes everything much easier and allows for faster feeds while keeping the serial protocol simple. As a bonus the PC software can support custom or advanced g-codes that are too complex for MCU firmware.
For a long time i was contributing to the bCNC project and i’ve come to realize that the original GRBL g-code based protocol is a huge pain once we start implementing advanced features. It is unnecessarily stateful. (eg. moving axes while job is paused, handling of the work offsets, coordinate systems, etc, etc…).
Feature Description
Klipper is mainly meant for 3d printers and as far as i know it’s not commonly used by DIY CNC milling machines as the ecosystem does not seem to be ready. But i was thinking that maybe FluidNC can include some kind of klipper-like mode, that would allow to accept klipper protocol. So we can start experimenting with shifting in this direction, which to me seems to be the right one…
Other Approaches
I beleive this should be discussed more in GRBL-like community, so we better understand the limitations of both klipper and grbl when compared to each other.
There are some projects exploring use of klipper in milling machines:
* https://klipper.discourse.group/t/klipper-for-cnc-initiatives-and-projects-list/5698
* https://github.com/naikymen/klipper-for-cnc
How I Can Help
I can help with bCNC integration if we decide this is the right thing to do.
#1 – MitchBradley 于 2025-07-14
I agree that many aspects of the Grbl protocol are quite troublesome, but adhering to it does enable one to use many pieces of a large ecosystem. Klipper, of course, has its own ecosystem, but it is very different from the Grbl ecosystem so trying to straddle the two would be an immense effort.
FluidNC is optimized to fit within the constraints of an ESP32. Adding a “Klipper mode” would likely interfere with the existing functionality, and also likely cause it to not fit within the memory constraints. Doing what you suggest would be better done as a separate project, not subject to all of the constraints that shape FluidNC.