Yes, it is good that there is software that understands G-code for 3D printers, but using it as _the_ data format? Ridiculous. That would be as if one used plotter instructions to print in 2D; instead of "here is a rectangle; fill it with pure red", one would have zillions of "move pen to x,y; draw to x,z; move to x,y+0.01; draw to x,z+0.01; move to x,y+0.02,…" instructions.
Also, I don't even think G-code is that good of an idea for generic CNC files. Suppose your file says "use a 10mm bit", while your CNC machine only supports bits up to 5mm. You can sort-of emulate the larger one, but it will be inefficient and lead to lower quality cuts.
There are complex G-codes, such as threading, which allows you to define the pitch, thread depth, cutting style, the distance to move away from the material between passes the distance to cut the thread, etc. But a lot of G-code files do consist of thousands of discrete lines.
The reduction of a 3d shape to motor signals will eventually come to a stage that deals with lots discrete vectors, regardless of how you represent the data, G-code or not. G-code files consisting of thousands of lines are usually created by a CAM software anyways, not by hand.
Your strawman argument of a 10mm bit when only a 5mm bit is available extends to just about any type of standardized process that consists of instructions being evaluated.
And yes, it applies to any process that consists of instructions. Again, that's why I think that is a bad way to describe a 3D object for a generic printer interface.
That's why you can use G-code both for additive and subtractive processes.
People don't really write G-code anymore, it's generated from a 3D model. G-code is like the compiled version of the model made for execution on the printer.
>Also, I don't even think G-code is that good of an idea for generic CNC files
Why make such a ridiculous assumption when you just said you heard about this only 5 minutes ago? You're making a blanket statement about a technology that's been around for more than 40 years based on 5 minutes of googling.
Having a language which simply describes the movement of your tool through space is nice--there is less chance that a later vendor decides to add overrides to your "red rectangle" to be more of a blue circle.
There is also much less chance for hardware vendors to screw up their implementations and introduce incompatibilities: move this bit here, at this speed. It makes the firmware much simpler, and makes the shelf-life of files much longer.
It seems to be a pretty good solution, though with not as great a shiny factor as others.
