I was looking at G-code for 3D printers and found this page "alternatives to g-code".
https://reprap.org/wiki/Firmware/Alternative#alternatives_to_G-code
In it they describe something I was groping towards here and in subsequent comments.
>>21602
They say that,
"... Much of the ""Firmware - experimental" RepRap discussion forum discusses protocols that are hopefully easier to interpret than G-code.
splines and circles: By describing every move in the form of curved cubic splines, not only do we reduce the volume of data required to describe a curved part, but it may also make the microcontroller firmware simpler and faster. Faster: only integer arithmetic required. Simpler: the firmware only needs a single subroutine to handle cubic splines, rather than several subroutines to handle straight lines, circles, arcs, and the involute curve used for twice for each gear-tooth..."
Curved cubic splines! And about them,
"...Less volume: 8 cubic splines per circle are more than adequate for high precision CAD/CAM machines[5], while apparently (?) the current RepRapGCodes requires hundreds of tiny straight line segments to approximate the same circle.
Elegant multispline motion controller and RepOlaRap and Repic5D mention such splines.
Elegant multispline motion controller "will not use G-code. It will use a custom language based on cubic Bezier curves. This allows for much better description of arcs and will result in much higher quality prints with a much lower data throughput requirements."..."
Some others. Any of you ever heard of Don Lancaster? He did articles on electronics and postscript. I think he came up with the "flutterwumpers",
"... Flutterwumper Library generally focuses on generating shapes in PostScript format, and then converting directly from PostScript to "step, direction" pulses, without ever going through G-code.
".gcode versus .s3g" discusses the ".s3g" format file produced by replicatorG. It also mentions that USB seems to have high latency..."
and etc. This is some good basic, foundational stuff. At some point all of this will have to be used in some form. That the high precision CAD/CAM machine use 8 cubic splines per circle tells you that it's likely it's close to optimal. They have thought deeply about this and all these machines started life severely compute constrained compared to even low power microcontrollers of today. So at the very least it should be close to being adequate for anything we could come up with. The tool heads of these use the same sort of 3D motion that I talked about for programming movement for limbs and body parts.