For a project involving Splines I have written a script to transform NURB-Spline-Curves to many small G1 commands based on the cox de boor recursion formula. (similar to how arcs work internaly in klipper already)
This function exists also in LinuxCNC or others like Heidenhain (p.172), so I wanted to ask if there is a big enough benefit to implement this here in Klipper.
Pros and Cons for using Splines instead of segmentation by slicer:
fewer GCode lines → smaller GCode files
Slicers / CAM-Tools don´t have to implement it itself
increased calculation complexety and calculation at run time on host → maby too much when having complex NURBS and using a weak host, but don’t know
complex when writing manually / lots of possible mistakes when writing that gcode
For implementation, I would convert every Spline to NURBS and than segemtate it based on the existing config “gcode_arcs resolution” as the max distance of a straight line.
This should be possible, but similar to G-code arcs, this would introduce another layer of approximations to the motion planning since even if the CAD file used NURBS, as soon as you export it to a slicer, it transforms it to an STL made of triangles, an approximation (this also applies even if you export as STEP and import into slicer). Then, the slicer would have to detect the spline, approximate it again as a G5 command. Finally, Klipper would turn the G5 command into a series of G1’s.
In short, the series of approximations are:
CAD in NURBS
Slicer: CAD to STL triangles
Slicer: Triangles → G5 spline
Klipper: G5 spline → G1 lines
This could be simplified by just having one approximation (CAD to slicer):
tbh, I was not aware that everything still goes through STL / mesh, even through they support importing it. This makes me wonder if they plan to move eventually to STEP and analytical slicing.
However, if a few users want to try this now (e.g., those using CAM software, writing its own GCode generating scripts, etc.) or if slicers do switch to STEP internally in the future, then the NURBS command (G5) would be relevant.
If we assume the above, G5 would be an enabler for others. So the question is: Is this worth it to implement in Klipper?
I would like to see it though it deserves a bit more flexibility than linuxCNC et al. specify, namely curviness on all axes including E.
There are also G5.1 - quadratic spline and G5.2 - G5.3 - NURBS curve