Brief History of G-Code, Numerical Control, and G-Code Complilers

G-Code (more precisely G and M Code, more formally, RS-274D or other names) is a programming code that dates back circa 1950, and was originally developed to control mechanical machining operations using paper tape.

It shows.

The last ratified standard was in 1980, and the last open source variant in 2000 (RS274NGC_3.pdf – 2000). Most manufacturers extend it in their own directions, making incompatible changes to others doing the same thing. The standardized code has no ability to do any of the commonly done flow control (loops)or logic operations (if, then, else, and, nor). Outrageous, says someone coming from a computing background.

When one examines in detail the actual history, intended operations and uses of these machines, a different picture emerges.

Simple Machines have existed for thousands of years, with compound or complex machines for hundreds, and each generally performed simple, repeated tasks. For example: windmills were used to grind grains to flour continuously, the Archimedes screw was used to lift water. More complex machines, such as the lathe, exist to rotate items, removing material from their diameters. In most cases, the machining progression is a straightforward, beginning-to-end process. 

To illustrate, here is a sample process to produce a wooden candlestick from a raw work-piece on a lathe. It can be broken down into single, discrete steps:

  • load the work-piece into the lathe
  • start the lathe (bow, pedal, water, steam, electricity or other motive power)
  • turn the work-piece cylindrical with a tool
  • carve away material to form the general intended shape
  • carve decorative features if desired
  • drill a hole for the candle
  • stop the lathe
  • unload the machined work-piece

In the above example, there is very little need for any advanced flow control or logic. The workflow is a straightforward progression of isolated steps performed in a procedural manner.

Historically, someone would perform all those steps by hand, and doing so quickly with minimal mistakes became a production bottleneck when industries switched from cottage level craftsmanship to mass production. After all, a Master woodworker can only turn out so many finished pieces in a day. Adding more people and more lathes would speed up production, but costs also rise, since more Master level woodworkers are needed, as is more machines. It is an oversimplification, but it can be said the focus changed to more production at less cost. 

As technology progressed, what used to take a Master level worker with a handheld gouge and pedal powered rotary motion to produce could now be manufactured in a single cycle by an unskilled person placing a work-piece blank into a lathe equipped with multiple cutting knives on a bar and triggering the entire series of operations with a single motion, drastically decreasing machining time. Factories in the 20th century had rows of such machines, each doing a single set of operations on the work-piece, and once completing its process, transferred the work-piece to the next machine to do the following operations. In the generally more complex metalworking world, ways were found of reproducing the actions of the master worker via mechanical means (cams, levers and gears shaped to replicate the same actions). Now that same Master level worker could oversee gangs of lesser skilled personnel overseeing the mechanically automated machines.

Manufacturing continued to move from skilled worker to assembly line worker to automation.

This was acceptable for industry for a time, but setting up each machine mechanically to do only one job and then changing the job performed required expensive and time consuming changes to the mechanisms. A logical extension of the technique was to make a single machine capable of performing the actions of several other machines. Enter the world of Numerical Control (NC); the precursor to Computer Numerical Control.

Machines were constructed that could have their work patterns altered by a punched paper tape, which was fed into a reader, which in turn controlled the machine operation. As technology progressed, the paper tape was replaced with magnetic media, but the basic operations required to produced the same candlestick really did not change; the same operations had to occur, in the same order; only the timeframe for the production of the product had shifted from hours to seconds. The production of G-Code reflected that process; the produced code had little need of more than the ability to loop operations and utilize subroutines. Typical operations were:

  • re-iterate a cutting/drilling/boring/milling procedure until final depth was reached
  • utilize a preexisting movements (subroutine) when a particular point in the main program was reached (move the machine to a specific spot, trigger the drilling subroutine, move to another spot, trigger the drilling routine again)

Very procedural programming.

Enter the 21st century, with vertical machining centers capable of self-feeding in work stock, performing lathe and mill operations simultaneously while interfacing to external automation systems, and now operational complexity has outstripped the original purposes.

Machine control manufactures extended the standard G-Code to include storage variables, more so-called canned cycles, goto, if-then-else flow control, AND,OR,NOR logic, and even so-called conversational programming (select operation, select size, select depth, select direction, speeds and feeds, push go; the machine generates the G-Code), all to the goal of increasing production, decreasing cycle time, improving cost-effectiveness.

But what if you have none of those features built in to the controller? Enter G-Code Compilers.

General purpose computer programming languages have long since needed flow control and conditional operations, and it is entirely possible to interface the two. An example from my own research is using C language to handle the flow and conditionals, and have it produce executable G-Code for each case. Here is an example from the web; someone made a compiler that converts logical arguments in C to LinuxCNC compatible G-Code:

CGCC Gcode CompilerFeatures and Examples

// Constants
const float X_Holes = 10;
const float Y_Holes = 10;
// Loop
for (float y = 0; y < Y_Holes; y++) {
for (float x = 0; x < X_Holes; x++) {
if (x != y) {
G00 Z1
G00 X[x] Y[y]
G01 Z0 F1
G00 Z1
The above code is as follows:
– Want to drill a grid of 100 holes in a 10 x 10 inch grid
– the code is repeated 100 times with different X and Y coordinates.
– The code has to skip a line of holes down the diagonal where X equals Y

The person states that LinuxCNC CAN produce this workflow through the added-on O-codes (extension of the original RS-274D standard) but it is hard to produce good programs quickly. The result is a program that takes C language syntax incorporating G-Code and produces LinuxCNC compatible Gcode.

Others have similar needs:

GCME – G-Code Meta Compiler