Obviously, given the computer processor limitations of the time, it was something of a miracle that arcs were supported.
Given the movement to 32-bit (and larger?) processors for 3D printing and so forth, has there been any research into a G-code successor or alternative which supports tool movement described using some sort of more generalized curve?
If not, why not?
LinuxCNC has G5 cubic splines, G5.1 quadratic splines, and G5.2 NURBS blocks. The LinuxCNC G5 documentation covers those.
However, it’s not clear that G5 means the same everywhere. Looks like FANUC uses G5 but it doesn’t look the same to me.
For “why not?” my guess is that CAM just resolves to arc segments?
Obviously I missed that.
I stand corrected.
Thanks!
More “informed” than “corrected” 
DangerKlippers exposes the entire math module to templates. I vaguely wonder whether it would be possible to implement some of that in DangerKlippers that way? 
(Probably that would be silly though…)
A while back there was a request to add ellipses and bezier curve gcodes to linuxCNC, that doesn’t seem to have gone anywhere.
I’m sure that WIll knows that NIST’s PC based Enhanced Machine Controller (Mach3 and LinuxCNC, originally EMC2, were based on EMC) greatly predates 8 bit Gcode interpreters like grbl, and there were a number of earlier commercial non-microcontroller controllers out there, but others may not. I was running LinuxCNC (in it’s EMC2 incarnation) (no cubic splines, ellipses, or bezier curves) on a 64b AMD processor in 2008, although tbh I have no idea if any of the machine controller used 64b instructions anywhere.
I was recently poking around in the Gcode history bin looking for a little history of Gerber’s original version, which was from the late 1950s/early 1960s. This stuff has been around almost as long as I have and coincidentally is about the same age as Jack Kirby’s a long way from microprocessors first integrated circuits. The gcode replacement movement probably started around the same time, and hasn’t been any more successful than the one true gcode standard movement. I suspect that we’ll be using g-code long after xml, json, and the other attempts hit the discount table
In the early 70s I worked in a mainframe systems programming group where they had a couple guys running their lucrative APT postprocessor business. There was no way they were going to let the punk college student summer employee anywhere near it other than drooling on the windows to the CNC Bridgeport room, alas. APT (Automatically Programmed Tool) was, iirc, an alternative to gcode from slightly earlier than gerbers
Will could argue otherwise, Vectric does bezier curves natively and while I haven’t used Carbide Create since the V7 paywall it does also, and they are not alone.
I meant that I expected that CAM was resolving complex curves to arc segments (or straight segments…) in post, and once you have written such a post once, the cost to reuse it is small…
Yes, Vectric (and Carbide Create) import Bézier curves and Vectric writes out G-code using G2/G3 arcs to approximate the curves needed for a toolpath (Carbide Create converts to polylines and approximates using lines).
The LinuxCNC support is interesting…
The Shopbot folks also had a G-code replacement.
At some point I’ll hopefully be able to circle back to this and work up something interesting.