Why G codes?

I only recently built a Kossel mini for a friend but am planning a Delta machine for myself.
Perhaps this is a noobish question to which the answer should be obvious but it has me perplexed.
It makes sense that a cartesian printer uses G codes to send the extruder to X,Y and Z positions but not a Delta.
It seems that a lot of calculations are being done at run time by using them. It would make more sense to me to have the delta parameters input to the slicer which then outputs codes for the A,B and C carriage positions to be used at run time. Or have I missed something?

Regardless of whether the machine is Cartesian or delta you still want the extruder to move in straight lines, so the slicer only needs to specify the endpoints. If it did that in delta tower positions it would still need nearly as much maths to make the motors move the head in a straight line between the two end points.

The motors of a delta do not move linearly, so the firmware breaks the move into lots of short lines. If the slicer did that job the amount of data sent to the firmware would be enourmous. I.e. there isn't a concise way to describe the individual motor movements, AFAIK. There was an idea a long time ago to send splines to the firmware for non linear motion.

---

[www.hydraraptor.blogspot.com]

Thanks Chris. What you seem to be saying is that essentially the gcode would have to be a much larger file in order to ensure linear movement if it were done that way. I wish I had the time spare to investigate how big the files would become and explore the viability but sadly don't.

Not, if you would compress it to splines too.

Could the splines be created in some sort of gcode so that the amount of data in the gcode file and the work done by the Arduino are both optimized?
But then 32 bit Arduinos for $20 are not far away so perhaps it isn't worth the effort.

yes

Another issue here is bed leveling / auto calibration.

Even given gcodes in X,Y, and Z, one must apply a rotation transformation to them at runtime to account for an unlevel bed. This turns out to be a trivial matrix multiplication operation when working in xyz-space. But I'm not positive it can be done quite that simply in delta coordinates. It would definitely be a good idea to look into this beforehand, because you're not going to gain anything if it turns out that accounting for the bed plane means converting to cartesian, rotating, and then converting back to delta coordinates. The above is only really relevant if using an auto-leveling system though.

But I think a bigger issue is that it forces the slicer to take on an entirely new role. Anyone developing even a slightly different motion system for 3d printers would need to edit every slicer on the market to add support for their printer, whereas currently, they only really need to add support into one firmware.