Ryan pointed this to me deep in another topic, but I don’t want to keep taking Andy’s post up with firmware stuff.
This thing is really unique. Instead of doing the motion and geometry computations on the microcontroller, they are all done on a faster processor, like a raspberry pi. It computes very raw commands, like “pulse this output 120 times at time 1:34:55”. I haven’t looked at the exact messages, but the microcontroller troller is free from computation, logic and physics. It’s just a slave to the klipper code. This is a great segmentation of responsibility because microcontrollers are great at output at a specific time, but lousy at physics. Python on the pi is great because the code can be developed and understood quickly, and it can integrate with more advanced components, like web GUIs or plot tools.
The Python code still accepts gcode as input, so slicers and cam software will still work.
The microcontroller’s responsibilities can even be split between multiple micros, so the micro responsible for the hotend could be different than the one responsible for motion. I’m not 100% sure they have the timing error low enough to split up x/y on different micros, but it’s possible.
Since all the complicated stuff is on the pi, you can switch firmwares by just starting a different version, or a different configuration. No need to flash, and no need to destroy the stable to try an experiment.
It’s a very interesting idea. I’d want to know more about error handling before I switch over, and I’m sure there will be growing pains w.r.t. catching up to features of other firmwares but it’s very promising. A lot of people know Python, and faster testing means faster development, so if this gets picked up, I’m sure it could run wild.