History, Evolution & Learning Guide
From punched paper tape in an early-1950s helicopter-blade experiment to the CAM-generated, AI-assisted programs running on today's shop floors — how G-code came to exist, why it splintered into dozens of dialects, and everything you need to learn to read and write it yourself, from your very first line of code up to synchronized multi-channel programming.
G-code did not begin as a language at all. It began as a workaround for a manufacturing problem that had nothing to do with programming syntax and everything to do with geometry that was too complicated to cut by hand with any consistency. In the late 1940s, a Michigan-based manufacturer of aircraft propeller components was struggling to produce the smoothly curved profiles needed for helicopter rotor blade templates. Tracing those curves through a series of manually set points on a milling machine was slow and inconsistent from part to part, and the tolerances demanded by aircraft work left very little room for the kind of drift that comes from a human operator interpreting a drawing freehand at the machine.
The company's proposed fix, worked out in partnership with engineers who would go on to collaborate with the Massachusetts Institute of Technology, was to describe a curved profile as a dense series of coordinate points, feed those points into a machine on punched cards, and let the machine's own motors move the cutter from point to point automatically rather than relying on an operator's hand. MIT's Servomechanisms Laboratory, already deep into servo-motor and feedback-control research for military applications, took on the job of actually building a working version of the idea under Air Force sponsorship. The result, demonstrated publicly in 1952, was a modified milling machine that read punched paper tape and moved its cutting head along three axes automatically, guided entirely by the numbers encoded on that tape.
It is worth pausing on how different that early machine was from anything a modern machinist would recognize as running "G-code." There was no letter-address format yet, no shared vocabulary of G and M words, and no expectation that a program written for one machine would mean anything at all to a different one. Each installation effectively spoke its own private numeric dialect, understood only by the specific hardware and the specific engineers who had built it. What the 1952 demonstration proved was not a programming language — it was a concept: that a cutting tool's path through space could be described entirely as numbers, stored on a medium a machine could read on its own, and executed with a repeatability no human hand could match. Everything that followed, including the language this article is ultimately about, exists to make that concept usable outside a single laboratory.
Once numerical control moved beyond a single laboratory demonstration and into real production across multiple companies, the absence of a shared language stopped being a minor inconvenience and became a genuine obstacle to growth. A program written for one manufacturer's control had no chance of running correctly on another's, which meant every machine tool builder was, in effect, forcing its customers to relearn an entirely new coding scheme with every new piece of equipment they bought. Training, tooling documentation, and even simple troubleshooting all had to be duplicated from scratch for every control on the shop floor.
The organization that stepped into that gap in the United States was the Electronic Industries Association, an industry trade group better known for setting standards in the electronics and telecommunications world. Through the 1960s and into the 1970s, the EIA developed and refined a standard for numerical control programming, published under the designation RS-274, that defined a common structural format: a program built from sequential blocks of instruction, each block made up of individual "words," and each word formed from a single letter address followed by a number. That letter-address format is the direct ancestor of the syntax every modern G-code program still uses — a line that opens with an N for its sequence number, followed by G and M words for preparatory and miscellaneous functions, and X, Y, Z, F, S, and T words for position, feed, speed, and tooling.
The "G" itself refers to what the standard calls a preparatory function — an instruction that tells the control how to interpret the motion words that follow it, whether that means moving in a straight line, tracing an arc, or switching between absolute and incremental positioning. A later revision of the American standard, commonly referred to as RS-274-D, refined and formalized that word-address scheme into something close to what is still recognizable today. Internationally, a parallel and closely related standard was published by the International Organization for Standardization as ISO 6983, describing essentially the same letter-address, block-structured approach and giving machine tool builders outside the United States a comparable reference point to build against.
It is important to be precise about what standardization actually achieved and what it did not. RS-274 and ISO 6983 established a shared skeleton — the general shape of a program, the meaning of a line number, the idea that G means "how to move" and M means "do something else entirely" — but neither standard attempted to lock down every single code number to one single universal meaning across every builder and every machine type. That gap, left open by design to give manufacturers room to support their own machine's specific capabilities, is precisely where the fragmentation described later in this article took root.
Standardizing the language a program was written in solved only part of the problem. For roughly the first three decades of numerical control, the far more mundane challenge was simply getting a program from the place it was written into the machine that needed to run it. The earliest and longest-lived answer was a roll of punched paper tape, fed through a mechanical tape reader bolted onto the side of the control cabinet. A single stray hole, a torn perforation, or a piece of tape fed in backward could stop a job cold, and a long, complex program might require a correspondingly long, physically unwieldy roll of tape that had to be stored, labeled, and handled with real care.
Through the 1960s and 1970s, as computers themselves became more capable and more affordable, a natural next step emerged: rather than punching a fresh tape for every machine, connect several machines to a single central computer over a wired connection and let that computer feed each one its program directly. This approach, generally known as Direct Numerical Control, removed the physical tape roll from routine operation entirely for shops that adopted it, though tape and tape-equivalent formats remained common for years afterward, particularly on older or smaller installations that never received the network upgrade.
The 1980s and 1990s brought the shift that most directly shaped the machines still running in shops today: the replacement of dedicated, purpose-built control hardware with something much closer to an ordinary industrial computer. Onboard memory meant a program no longer had to be read continuously from an external medium while it ran; it could simply be loaded once and stored. Floppy disk drives briefly became the standard way to move a program onto a machine, in much the same role tape had once played, before being displaced in turn by direct computer links, and eventually by USB drives and Ethernet connections as those became standard on ordinary office computers first and machine tools shortly after.
The most recent chapter in this particular thread of the story is less about the physical medium and more about connectivity generally. Modern controls are frequently networked not just to receive a program but to report back — cycle times, spindle load, tool wear data, and machine status flowing continuously to a central monitoring system as part of what is now generally described under the banner of Industry 4.0 or the industrial internet of things. The program itself, in most shops, no longer travels on any physical medium at all; it exists as a file on a server and is simply called up by the machine that needs it, a world away from a technician carefully feeding a fragile paper tape through a mechanical reader, even though the underlying G-code language those files contain has changed far less than the medium carrying it.
If RS-274 and ISO 6983 had produced one single, universally interchangeable language, this section would not need to exist. What actually happened is closer to what happens to any widely spoken human language left to develop independently across many separate regions: a shared foundation gradually grew a collection of distinct local accents, each mutually intelligible in its broad strokes but genuinely incompatible in its details.
Every major control manufacturer — Fanuc and Mitsubishi in Japan, Siemens and Heidenhain in Germany, Fagor in Spain, and a long list of others — built its controls around the RS-274 and ISO 6983 skeleton, but each also layered its own extensions on top of that skeleton to support features specific to its own hardware and its own idea of how a programmer should work. A canned drilling cycle on one control might be invoked with a code number that means something entirely different, or does not exist at all, on another. Custom macro variable syntax, the punctuation used for comments, the exact behavior of a canned cycle's optional parameters, and even something as basic as which axis letters are available by default could all differ meaningfully from one control family to the next.
Machine tool builders added a further layer of divergence on top of the controller manufacturers' own variations. Some builders developed proprietary conversational programming systems that sit on top of, or in some cases largely replace, a programmer's direct interaction with raw G-code — Mazak's Mazatrol and Okuma's OSP-native conversational modes are well-known examples, each generating underlying G-code-equivalent motion instructions while presenting the programmer with a very different, more graphical or menu-driven interface. A programmer fluent in one builder's conversational system may find another builder's system, and even a third builder's straight G-code interface, genuinely unfamiliar despite all of them ultimately controlling the same three or five axes of motion.
The practical consequence of this fragmentation is a piece of software that most working CNC programmers now take entirely for granted: the post processor. A post processor's job is to take a generic, machine-independent toolpath — of the kind a CAM system calculates internally, described later in this article — and translate it into the exact dialect a specific machine and control combination expects, correct code numbers, correct syntax, correct canned cycle behavior, and all. Without that translation step, "G-code" as a single portable file would barely exist in practice; what exists instead is a large family of closely related but distinct languages, unified by a common ancestor standard and made interchangeable, in practical terms, only by software built specifically to bridge the gaps between them.
For roughly the first two decades of numerical control's existence, a program was, in a very literal sense, written by a person — a process programmer sat down with a part drawing, worked out the coordinates and motion commands needed to cut it, and typed or punched the result directly. That approach scales acceptably for simple geometry but becomes genuinely impractical for anything with complex curves, blended surfaces, or a large number of individual features, where the sheer volume of coordinate calculation quickly exceeds what is reasonable to do reliably by hand.
The first serious answer to that problem actually predates the fully standardized G-code format described earlier in this article. APT, short for Automatically Programmed Tools, was developed at MIT beginning in the mid-1950s as a higher-level way to describe machining operations using something closer to geometric statements and English-like syntax than raw coordinate lists, with a separate processor translating that higher-level description down into the specific motion instructions a given machine could execute. APT is reasonably considered an early ancestor of modern CAM software's core idea: describe what you want cut in terms of geometry and operations, and let software work out the detailed motion.
That idea matured considerably over the following decades as computing power became cheap enough to put genuinely capable CAD and CAM software on an ordinary desktop computer rather than a mainframe. Commercial CAM packages proliferated from the 1980s onward, letting a programmer define a part's geometry, select a machining strategy, and let the software calculate a toolpath automatically, dramatically compressing the time needed to program complex work compared to calculating every coordinate by hand. Crucially, that CAM-calculated toolpath is not yet G-code in any specific dialect; it is a generic, internal representation that only becomes an executable program once it passes through the post processor described in the previous section, tailored to the exact machine and control the shop intends to run it on.
By the early 2000s, this had quietly become the dominant way most G-code came into existence in any shop doing work with meaningful geometric complexity. Hand-written G-code did not disappear — it remains entirely normal, and often genuinely faster, for simple prismatic parts, quick edits on the shop floor, or straightforward turning work — but for anything approaching real three-dimensional complexity, the overwhelming majority of code running on modern machines is generated by CAM software and a post processor rather than typed by a person line by line. Understanding G-code by hand nonetheless remains essential even in a CAM-dominated world, both because someone still has to be able to read, verify, and correct what the software produces, and because every CAM-generated program still ultimately resolves down into exactly the same letter-address language this article's second half is devoted to teaching.
Given how thoroughly the way programs get written has changed since the 1950s, it is worth asking a genuinely interesting question: why does the underlying language itself remain so remarkably close to a format standardized decades ago, rather than having been replaced outright by something newer? Several real attempts have been made to replace it, and it is worth understanding both why they emerged and why G-code has, so far, outlasted every one of them.
The most ambitious of these attempts is STEP-NC, formally published as ISO 14649 and closely related to the broader STEP standard used for exchanging product-model data across engineering software. Rather than describing a part as a sequence of low-level motion commands the way G-code does, STEP-NC describes it as a set of manufacturing features — a pocket, a hole pattern, a specific chamfer — along with the tolerances and stock information a control would, in principle, need to work out the actual toolpath itself. The appeal is real: a feature-based file is more portable, more independent of any specific machine's kinematics, and arguably closer to how a human engineer actually thinks about a part. Adoption, however, has remained limited relative to that ambition, held back by the sheer scale of retooling required across control manufacturers, CAM vendors, and shop floor training that a genuine replacement of G-code would demand industry-wide.
A less radical but far more commercially successful development has been the growth of conversational and shop-floor programming interfaces, mentioned briefly in the earlier discussion of dialect fragmentation. These systems, offered in various forms by most major machine tool builders and by a number of independent software vendors, let an operator build up a machining sequence through menus, prompts, or a graphical interface rather than typing raw G-code directly. Underneath, in the overwhelming majority of cases, the system is still generating conventional G-code-equivalent motion instructions for the control to execute; the conversational layer changes how a program gets authored, not fundamentally what gets executed at the machine level.
The newest thread in this ongoing story is the arrival of artificial intelligence into both CAM programming and G-code verification. CAM vendors have begun introducing features that suggest toolpath strategies, recognize machining features automatically from a part's geometry, or generate a first-pass program that a human programmer then reviews and refines rather than building entirely from scratch. On the verification side, simulation software has begun explicitly supporting the validation of AI-generated toolpaths alongside conventionally programmed ones, treating the source of a program as increasingly irrelevant to the separate question of whether it is actually safe and correct to run. What has not changed, even as the authoring process becomes steadily more automated, is the execution format sitting at the very bottom of the stack: a file built from sequential blocks of G and M words, tracing directly back to a standard first drafted in the 1960s and 70s, still doing the same essential job it always has.
The seven levels below are organized to build on each other in order, and each one is now covered in considerably more depth than a first pass through the topic usually needs — treat it less like a single sitting and more like a reference to return to as each stage of real practice raises its own questions. Every level is written to be genuinely usable across the major control families rather than tied to one specific builder's exact syntax — though, as covered in Part One, always expect small differences once you sit down at a real machine, and treat every example here as illustrative of a widely shared convention rather than a guaranteed match for your own control's manual.
Every G-code program, regardless of control or dialect, is built from the same basic unit: a block, which is simply one line of instruction. A block is made up of individual words, and a word is nothing more than a single letter address immediately followed by a number. Learning to read G-code starts with learning to mentally chop a line into its individual words rather than trying to absorb the whole line as one dense chunk, the same way a new reader of any language starts by sounding out individual syllables before reading whole sentences fluently.
N010 G01 X25.0 Z-10.0 F0.2 (finish pass)
Reading that line word by word: N010 is a sequence number, mainly there to help a human locate a specific line and, in some cases, to jump to during a program restart — it has no effect on the machine's motion itself. G01 is a preparatory function telling the control to move in a straight line at a controlled feed rate rather than rapid traverse. X25.0 and Z-10.0 are position words specifying where that straight-line move should end. F0.2 sets the feed rate the move should happen at. The text in parentheses is a comment, ignored entirely by the control and included purely for a human reading the program later.
Before diving further into individual words, it helps to see where a single block sits inside a complete program, because a beginner who has only ever seen isolated example lines can struggle to picture how those lines actually fit together into something a machine runs from start to finish. A minimal but complete program generally follows a recognizable shape: an opening marker and program number, a block or two that establishes safe starting conditions, the body of the program doing the actual work, and a formal ending.
% (start-of-program marker, used by some controls) O1001 (program number, used to store and recall this file) G21 (work in millimeters rather than inches) G90 G54 (absolute positioning, using work offset 1) M03 S1200 (spindle on clockwise, 1200 rpm) G00 X0 Z5.0 (rapid to a safe starting position) G01 Z0 F0.15 (feed down to the part face) G01 X20.0 (cut a diameter) G00 X50.0 Z50.0 (rapid clear of the part) M05 (spindle off) M30 (end of program, reset to the start) % (end-of-program marker)
That short example, deliberately simple, already demonstrates a habit worth building early: every program should establish its own conditions explicitly near the top rather than assuming the control is already sitting in the state the programmer wants. Units, positioning mode, and the active work offset are all things a previous program, or a previous operator action, might have left in a different state — a well-written program does not gamble on that and states its assumptions in its own opening blocks.
The table below extends the basic set of letters from a first glance at a program to the fuller list a working programmer runs into almost immediately once real cycles and arcs enter the picture. Not every letter appears on every control or every axis configuration, but recognizing what a letter generally does, even before knowing every one of its specific uses, makes an unfamiliar block far less intimidating to read.
| Letter | Common meaning |
|---|---|
| N | Block (line) sequence number, for reference and program navigation only. |
| G | Preparatory function — sets the mode the following motion or behavior should follow. |
| M | Miscellaneous function — controls something other than direct axis motion, such as the spindle or coolant. |
| X / Y / Z | Linear axis positions. A lathe typically uses only X and Z; a three-axis mill uses all three. |
| A / B / C | Rotary axis positions, typically rotation around the X, Y, and Z axes respectively, used on multi-axis mills and lathes with a live B-axis or C-axis. |
| F | Feed rate — how fast the tool moves while cutting. |
| S | Spindle speed. |
| T | Tool selection, usually paired with an offset number. |
| I / J / K | Arc center offsets from the arc's starting point, used with circular interpolation, corresponding to the X, Y, and Z axes respectively. |
| R | Radius value, used both as an alternate way to define an arc and as a retract-plane value in many canned cycles. |
| P / Q | General-purpose parameter words, whose exact meaning depends entirely on the specific G-code they appear alongside — commonly a dwell time, a cycle sub-block reference, or a depth-of-cut value. |
| D / H | Offset numbers, commonly referencing a cutter compensation value (D) or a tool length offset value (H) stored in the control's offset table. |
| L | Repeat count, most often seen alongside a subprogram call. |
| %, O | Program start marker and program number, used to identify and store the file on the control. |
Two small formatting habits are worth internalizing early, because both are common sources of confusion for a beginner copying examples from different sources. First, decimal points matter enormously in G-code — a value like X1 and a value like X1.0 can, on some older or more literally interpreted controls, be treated very differently, since a number without an explicit decimal point may default to being read in the smallest programmable increment rather than as a whole unit. Modern controls are generally forgiving here, but writing every dimensional value with an explicit decimal point, even when it is a whole number, is a habit that costs nothing and removes an entire category of ambiguity.
Second, comment syntax is one of the more visibly inconsistent details between control families, even though the underlying purpose — leaving a note for a human that the control itself ignores — is identical everywhere. Parentheses, as used throughout this guide, are extremely common and widely understood. Some dialects instead, or additionally, treat everything following a semicolon on a line as a comment. A programmer moving between machines should expect to see both conventions and should check which one, or both, a specific control actually supports before relying on it.
One distinction that trips up almost every beginner at some point is the difference between a modal and a non-modal command. A modal G-code, once specified, stays in effect for every following block until a different code in the same modal group replaces it — meaning a program does not have to repeat G01 on every single line as long as the mode has not changed. A non-modal code applies only to the single block it appears on and needs to be restated every time it is actually needed. Recognizing which codes are modal is the single most useful habit for actually reading a real program rather than just a textbook example, since a real program leans heavily on that behavior to stay compact, and a block several lines below the last visible G01 may still be operating in linear interpolation mode without saying so explicitly on that line.
A practical consequence of modality worth internalizing early: reading a single isolated block out of context can be genuinely misleading. A line that reads simply "X30.0 Z-5.0 F0.2" with no G-code word at all is not incomplete — it is relying entirely on whatever motion mode was last set several lines earlier, and correctly reading it requires scanning backward through the program to find that mode. Beginners who try to interpret every line in total isolation, rather than tracking modal state as they read down through a program, tend to badly misjudge what a real program is actually doing.
Before any motion command makes sense, a program needs a shared understanding of where "zero" actually is. Several related ideas govern that: whether a position is stated in absolute or incremental terms, which physical point on the machine or part that position is measured from, which plane a given motion or arc is meant to happen in, and — on a lathe specifically — whether a position along a given axis is being described as a radius or a full diameter.
Absolute versus incremental positioning is controlled by a modal pair of G-codes, conventionally G90 for absolute and G91 for incremental. In absolute mode, every coordinate in a motion block describes a position relative to the active zero point, regardless of where the tool currently sits. In incremental mode, every coordinate instead describes a distance and direction to travel from the tool's current position. The two modes describe exactly the same physical moves in different terms, and mixing them up is one of the most common sources of a program that runs but ends up somewhere entirely unintended.
(absolute — move to X10.0, regardless of current position) G90 G01 X10.0 F0.15 (incremental — move 10.0 further in X from wherever the tool is now) G91 G01 X10.0 F0.15
It is worth being honest about why incremental mode still earns a place in modern programming even though absolute mode is generally easier to read and safer to troubleshoot. Incremental positioning is genuinely convenient for repeating a fixed pattern of moves at several different starting locations — a bolt-hole spacing, a series of identically stepped grooves — since the same sequence of incremental moves produces the same relative pattern no matter where it starts from. That said, most working programmers default to absolute positioning for the majority of a program precisely because a mistake in one incremental block tends to carry forward and compound into every block that follows it, whereas a mistake in one absolute block is generally contained to that single move.
Work coordinate systems solve a related but separate problem: a machine's own internal reference point, set once at the factory or re-established during a machine home cycle, is rarely a convenient zero to program against for an actual part. Work offsets, commonly selected with codes such as G54 through G59 and their extended variants (frequently written as G54.1 followed by a further index number when a control supports more than the original six), let a program reference a zero point that has been set specifically for the current job — typically a corner or center of the actual workpiece — without the programmer needing to know or care where that point sits relative to the machine's own internal origin.
A shop can store several different work offsets simultaneously, letting a single program reference several fixtures or several identical parts staged in different locations on the same setup — a technique commonly used to run several vises or several bar-fed parts across one table without rewriting the program for each one, simply by calling a different offset before each part's section of the program runs.
G90 G54 (work on the part in fixture position 1) ... machining moves for part 1 ... G55 (switch zero to fixture position 2) ... identical moves now apply to part 2 ...
Separately from work offsets, most controls also support a dedicated machine home or reference position, commonly reached through a code such as G28, used to send the machine to a fixed, repeatable physical location — often needed before a tool change or at the very start and end of a program, independent of whatever work offset happens to be active at the time. This position is tied to the machine's own physical limit switches or encoders rather than to any particular part or fixture, which is precisely why it is trusted as a genuinely safe, repeatable place to send the machine when nothing else about the current setup can be assumed.
A detail that rarely comes up until a program includes its first arc or a canned cycle is plane selection — telling the control which two axes a circular move or cycle should be interpreted within. G17 selects the XY plane, the default assumption on most three-axis mills; G18 selects the ZX plane, the natural default for turning; and G19 selects the YZ plane, used less often but genuinely necessary on certain multi-axis and side-milling operations. An arc command written correctly in every other respect will still behave unexpectedly if the active plane does not match the axes the programmer actually intended the arc to move within, which makes plane selection worth checking deliberately rather than assuming it is already correct.
One further wrinkle specific to turning is worth flagging clearly for anyone coming to lathe programming from milling, or vice versa: many lathe controls program the X axis in terms of full diameter rather than radius, meaning a call for X30.0 positions the tool at a 30-millimeter diameter rather than 30 millimeters out from centerline. This is a control-level setting rather than a fixed rule, and some lathes and some specific operations do use radius programming instead, but assuming the wrong convention is a genuinely common source of a part machined at exactly half, or exactly double, its intended size — worth confirming explicitly on any turning control before trusting a first program to a real part.
With position and coordinate systems established, the next layer is the small set of codes that actually move the tool. Nearly every program, however complex, is built almost entirely from just a handful of these, and a genuinely comfortable command of this level is what separates someone who can recognize G-code from someone who can actually predict what a given block will do physically before running it.
| Code | Motion |
|---|---|
| G00 | Rapid traverse — the fastest move the machine can make, used for non-cutting repositioning. Never used while the tool is engaged in material. |
| G01 | Linear interpolation — a straight-line move at a controlled, programmed feed rate, used for the large majority of actual cutting. |
| G02 | Circular interpolation, clockwise — traces an arc, defined either by an arc-center offset (commonly I, J, and K words) or a radius value (commonly R). |
| G03 | Circular interpolation, counterclockwise — the mirror of G02, using the same center-offset or radius syntax. |
| G04 | Dwell — pauses motion for a specified time, commonly used to let a tool clear a bore or a thread relieve properly before the next move. |
The distinction between G00 and G01 deserves special attention early on, because it is also a common source of real damage rather than just a wrong dimension. Rapid traverse moves at the fastest speed a machine's servos can manage and, on many controls, follows whatever path the control finds most direct — not necessarily a straight line between two points, and in some implementations each axis simply moves at its own maximum rate independently, arriving at slightly different times and tracing a path that only looks straight in the simplest cases. That makes G00 entirely inappropriate for any move where the tool is still in or near material, and it is why a confidently written program keeps a very clear mental boundary between rapid repositioning moves, always planned well clear of the workpiece and any fixturing, and controlled cutting moves. A beginner reading an unfamiliar program should always check which mode a block is in before assuming what it will actually do physically, and should be especially cautious of any block that appears to combine a large positional change with what looks like it might still be inside stock.
Arcs are where a beginner's mental model of motion commands genuinely has to expand beyond simple point-to-point thinking, because an arc block needs to communicate not just an endpoint but a center and a direction of travel as well. The two common ways of supplying that information are worth understanding side by side rather than treating one as simply a shortcut for the other.
(defined by a radius value) G02 X40.0 Z-5.0 R5.0 (defined by an incremental center offset from the arc's starting point) G02 X40.0 Z-5.0 I5.0 K0
The R-value method is generally easier to read and to write by hand, since it directly matches the number most people would use if describing the same arc out loud — "a five-millimeter-radius corner." Its one real limitation is ambiguity on an arc of exactly 180 degrees, where a single radius value cannot, by itself, distinguish between the two possible arcs that share that radius and those endpoints, which is why the I, J, K method remains the more precise and more universally supported option, and is generally what CAM-generated programs rely on even though it is less immediately intuitive to a person reading it directly. I, J, and K values are incremental distances from the arc's starting point to its center, corresponding respectively to the X, Y, and Z axes, and are supplied only for the axes actually relevant to the plane the arc is being cut in.
A detail that becomes relevant as soon as an F word starts appearing on a program is which of two feed-rate modes is currently active. Feed per minute, commonly selected with a code such as G94, expresses the F value as a distance the tool travels in one minute, and is the more familiar convention for most milling work. Feed per revolution, commonly selected with a code such as G95, instead expresses the F value as a distance the tool advances for each single revolution of the spindle — the standard convention for the large majority of turning work, since a turned surface finish depends directly on how far the tool advances per spindle revolution rather than on any fixed unit of time. Reading an F word without first confirming which of these two modes is active can lead to a feed rate that is wildly different from what the programmer actually intended, even though the number on the page looks perfectly reasonable in isolation.
G04 is simple in concept but genuinely useful in specific situations: it pauses all axis motion, and typically the spindle continues turning, for a specified length of time, commonly supplied through a P word in milliseconds or seconds depending on the control. A brief dwell at the bottom of a bored hole lets the tool spring back slightly and cut a cleaner, rounder bottom before retracting; a dwell after a threading pass lets a thread properly relieve before the next motion begins. Once G02 and G03 are genuinely comfortable, many controls also support helical interpolation — an arc in one plane combined with simultaneous, continuous motion along the remaining axis, tracing a spiral rather than a flat circle, most commonly used for milling a thread or a helical pocket wall in a single continuous motion rather than a series of flat, stepped passes. Helical motion is mentioned here deliberately early, as a preview, precisely because it is nothing more than circular interpolation with one additional axis moving at the same time — a natural next step once flat arcs are second nature, well before the genuinely advanced multi-axis material covered later in this guide.
Writing every single pass of a repetitive operation — a deep drilled hole, a series of roughing passes down to a finished turned diameter, a threading operation — as individual G01 and G02 blocks would make even a moderately complex program enormous and genuinely error-prone. Canned cycles solve that by packaging a whole repetitive sequence of moves behind a single code and a handful of parameters, letting the control work out the individual passes internally, and this section covers both the milling and turning sides of that idea in more depth than a single summary table can convey on its own.
Drilling cycles are a particularly good place to learn the general logic of canned cycles, because the family of related codes differs from each other in one clearly explainable way at a time rather than being a collection of unrelated behaviors.
| Code | Typical use |
|---|---|
| G81 | Simple drilling cycle — rapid to the hole, feed to depth, rapid retract. The baseline every other drilling cycle builds on. |
| G82 | Drilling with a dwell at the bottom of the hole before retracting, commonly used for spot-facing or counterboring where a cleaner flat bottom matters. |
| G83 | Peck drilling cycle — repeatedly feeds and retracts in steps, used for deep holes where chip clearing and heat buildup matter. |
| G84 | Tapping cycle — synchronizes spindle rotation and axis feed so the tool advances at exactly the thread's pitch, then reverses on the way out. |
| G73 | A higher-speed peck drilling variant, retracting only a small amount between pecks rather than fully out of the hole, used where full retraction on every peck would waste time without adding real benefit. |
G83 X20.0 Y15.0 Z-25.0 R2.0 Q5.0 F0.1
Reading that block: X and Y position the hole. Z gives the final drilled depth. R sets the retract plane the tool returns to between pecks, or rapids down to before the cycle starts feeding. Q sets the depth of each individual peck. F sets the feed rate for the actual drilling motion. Once one member of this cycle family is genuinely understood parameter by parameter, the rest of the family reads far more easily, because each one is really just G81's core logic with one specific behavior added or changed.
Turning cycles follow a comparable logic but are organized around a different problem: removing a large amount of material down to a finished profile without the programmer having to calculate every individual roughing pass by hand.
| Code | Typical use |
|---|---|
| G71 | Roughing cycle along the Z axis, repeatedly cutting toward a described finish profile in a series of automatically calculated depth-of-cut passes. |
| G72 | A face-roughing variant of the same idea, cutting passes primarily along the X axis rather than Z, suited to parts with more material to remove facing off than turning down. |
| G70 | A finishing pass, tracing the final profile described for a roughing cycle at finishing feed, once the roughing cycle has already cleared the bulk material. |
| G73 | A pattern-repeat roughing cycle, well suited to castings or forgings that already roughly resemble the finished shape, since it follows the general contour rather than cutting straight passes. |
| G76 | A threading cycle, automatically calculating a series of passes at increasing depth to cut a thread to a specified pitch and depth, rather than requiring each threading pass to be programmed individually. |
A detail worth calling out explicitly: G71 and G70 are almost always used as a genuine pair rather than in isolation. The roughing cycle reads a range of block numbers elsewhere in the program that describe the finished profile geometry, cuts that profile in rough passes leaving a small finishing allowance, and the finishing cycle then reads that exact same block range afterward to trace the final pass. This is one of the clearest examples in ordinary G-code of one part of a program directly referencing another part of the same program, and it is worth deliberately tracing through a real example of the two cycles together, rather than reading about either one alone, to see how that reference actually works.
Alongside G-codes, most programs lean just as heavily on M-codes, which govern machine behavior outside of direct axis motion — turning the spindle on and off, controlling coolant, changing tools, and marking the beginning and end of a program. The table below extends the basic set from a first look at M-codes to a fuller working list.
| Code | Function |
|---|---|
| M00 | Program stop — halts execution entirely, requiring an operator to press cycle start again to continue, often used to allow an in-process inspection or a manual repositioning. |
| M01 | Optional stop — behaves like M00, but only if the operator has separately enabled an "optional stop" switch on the control, letting a program include checkpoints that can be skipped during unattended running. |
| M03 / M04 | Start the spindle clockwise or counterclockwise. |
| M05 | Stop the spindle. |
| M06 | Execute a tool change, typically paired with a T word specifying which tool. |
| M08 / M09 | Turn coolant on or off. |
| M19 | Orient the spindle to a fixed angular position, commonly used before certain tool changes or before a boring bar retracts clear of a finished bore. |
| M30 | End of program, and reset the control back to the beginning. |
| M02 | End of program, without the automatic reset behavior of M30. |
| M98 / M99 | Call a subprogram and return from one, covered in full in Level 6 of this guide. |
Canned cycles are also where dialect differences described in Part One become most noticeable in day-to-day work. The general concept — package a repetitive operation behind one code — is close to universal, but the exact parameters a given cycle expects, and even which specific code numbers are used for which cycle, vary enough between control families that this is usually the first place a programmer moving to an unfamiliar machine needs to stop and check the manual rather than assume a code behaves identically to how it behaved on the last control they used.
Because canned cycles are modal, a drilling or turning cycle called once stays active for every following block that includes the position words it expects, executing the entire cycle again at each new location, until it is explicitly cancelled with a code such as G80. This behavior is what makes hitting a whole pattern of holes genuinely compact to program — a series of blocks containing only new X and Y values, with no G-code repeated on any of them, will each trigger the full drilling cycle again at that new position — but it is also a real trap for a program that forgets to cancel the cycle before a following rapid repositioning move, since that next move may be unexpectedly interpreted as another call to the still-active cycle rather than as simple, cycle-free rapid traverse.
G81 X10.0 Y10.0 Z-8.0 R2.0 F0.1 (drill the first hole, cycle becomes active) X30.0 Y10.0 (cycle repeats automatically at the new position) X30.0 Y30.0 (and again) G80 (cancel the cycle before continuing) G00 Z50.0 (now a genuinely plain rapid move)
Every tool in a machine's turret or spindle has a slightly different physical length and, in milling, a specific cutter diameter — and neither of those values is something a programmer should have to bake individually into every single coordinate in a program. Compensation exists to separate a program's geometry, which describes the part, from a specific tool's physical dimensions, which are instead stored separately in the control's own offset table and applied automatically.
Tool length compensation, commonly invoked with a code such as G43 paired with an offset number, tells the control to add a stored length value to the programmed Z position, so that a program written around the part's geometry works correctly regardless of exactly how long the specific tool loaded in the spindle happens to be. In practice, this is what makes it possible to write an entire milling program's Z depths as if every tool shared a single common reference length, and then let each tool's individually measured length — set at the machine, measured on a presetter, or entered from a tool's known specification — silently correct for the real difference once that specific tool is actually loaded.
T05 M06 (change to tool 5) G43 H05 Z10.0 (apply tool 5's stored length offset, move to a safe Z)
Cutter compensation, commonly G41 for left-hand and G42 for right-hand offset, does the equivalent job for a milling cutter's radius, letting a program be written directly along a part's actual finished profile while the control automatically offsets the toolpath outward or inward by the cutter's radius. The distinction between G41 and G42 refers to which side of the programmed path the cutter sits on, viewed in the direction of travel — left-hand compensation keeps the cutter to the left of the programmed line, right-hand keeps it to the right, and choosing correctly depends on which side of the finished profile is meant to be removed as waste.
G41 D01 X10.0 Y10.0 F0.1 (engage left compensation using offset 01, lead in) G01 X40.0 (cut along the profile — cutter stays offset by its radius) G01 Y40.0 G40 X0 Y0 (cancel compensation, lead away cleanly)
A detail genuinely worth learning early rather than the hard way: cutter compensation should always be engaged and cancelled during a dedicated lead-in and lead-out move, off the actual finished surface of the part, rather than starting or stopping exactly on the profile itself. Engaging or cancelling compensation directly against the finished surface can produce a small but very real gouge or step at that exact point, because the control needs at least one full move to establish the offset relationship correctly before it can be trusted to follow the programmed path precisely.
Turning work has its own closely related concept: tool nose radius compensation, commonly enabled with a code such as G41 or G42 in a turning context as well, which accounts for the fact that a turning insert's cutting edge is not a perfect mathematical point but a small radius, which would otherwise introduce a small but real geometric error on tapers, arcs, and chamfers if left uncorrected. On a straight cut parallel to an axis, an uncorrected nose radius makes very little practical difference, which is exactly why the error can go unnoticed on simple parts and then show up as a surprising few thousandths of inaccuracy the first time the same uncompensated program is used to cut an angled or curved feature.
Most controls that support compensation also separate a tool's offset value into at least two distinct numbers: a geometry offset, representing the tool's fundamental measured dimension, and a wear offset, a much smaller adjustment layered on top of it to compensate for gradual insert wear or a slightly out-of-tolerance finished dimension without touching the underlying geometry value. In practice, an operator fine-tuning a part's size after a first-article inspection will almost always adjust the wear offset rather than the geometry offset, since the wear value is explicitly meant to absorb exactly that kind of small, ongoing correction, while the geometry offset is meant to stay stable as the tool's actual measured baseline. As with canned cycles, the underlying concept behind every form of compensation is shared broadly across controls, while the exact code numbers, offset-table structure, and geometry-versus-wear conventions used to apply it vary meaningfully enough between builders to be a genuine, worthwhile item to confirm on any new machine.
Once a program includes a sequence that needs to repeat — the same drilled hole pattern at several locations, the same roughing pass run at several different depths — retyping that sequence every time it is needed quickly becomes both tedious and a real source of copy-paste errors. This level covers two closely related but distinct tools for solving that problem: subprograms, which repeat a fixed block of code, and macro variables, which let a program's behavior actually change based on values that can be set, calculated, or even measured at run time.
Subprograms solve the simplest version of the repetition problem: a block of code is written once, stored under its own program number, and called from a main program with a code such as M98, with control returning to the calling program once an M99 inside the subprogram is reached. A subprogram can typically also be told to repeat a specified number of times in a single call, letting a repeated pattern collapse down to one or two lines in the calling program.
(main program) G00 X10.0 Y10.0 M98 P1010 L3 (call subprogram O1010, run it three times) M30 (subprogram O1010, stored separately) O1010 G01 Z-5.0 F0.1 G00 Z5.0 G91 X20.0 (step over incrementally, so each repeat lands somewhere new) G90 M99 (return to the calling program)
That example is worth studying closely, because it demonstrates a genuinely useful pattern: switching briefly into incremental mode inside the subprogram to step the starting position over by a fixed amount on each repeat, then switching back to absolute mode before the subprogram ends, so the calling program does not have to guess what positioning mode it will be left in. Subprograms can also call other subprograms, nested several levels deep on most controls, which becomes a genuinely powerful way to build up complex, repeated geometry from small, individually tested pieces rather than one enormous, hard-to-debug block of code.
Parametric or macro programming takes the same underlying idea further, by letting a program use variables rather than fixed numbers wherever a value might need to change from one run to the next. Most Fanuc-derived controls implement this as what is generally called custom macro B, using a hash symbol followed by a number, such as #1 or #101, to represent a variable that can be assigned a value, tested with conditional logic, and carried through arithmetic. Siemens controls offer a broadly comparable capability built around R-parameters, and most other major control families provide some functionally similar mechanism, even where the exact syntax differs.
It is worth knowing, even at an introductory level, that macro variable numbers are not all equivalent to each other. A meaningful range, often something like #1 through #33 on many Fanuc-style implementations, is local to the currently running program and is cleared once that program ends — perfectly suited to temporary values used only within a single cycle. A separate range, often in the low hundreds, is reserved for values passed as arguments into a macro call. And a further range, often in the high hundreds, is commonly persistent, retaining its value even after the program that set it has finished running and the machine has been powered off and back on — genuinely useful for a value, such as a cumulative part counter or an accumulated tool-wear adjustment, that needs to survive across separate program runs rather than resetting every time.
(#1 holds a hole depth that can be changed in one place) #1 = -12.5 (#2 is calculated from #1 rather than typed separately) #2 = #1 - 2.0 (a simple conditional — skip ahead if #1 is already at final depth) IF [#1 GE -12.5] GOTO 50 G01 Z#1 F0.15 N50 (execution continues here either way)
That short example touches on the three building blocks that make macro programming genuinely powerful rather than just a shorthand for typing numbers: assignment, where a variable is given a value directly or as the result of a calculation; arithmetic, letting one variable be derived from another rather than entered independently and therefore at risk of falling out of sync; and conditional logic, using an IF statement paired with a comparison and a GOTO to change which blocks of the program actually execute depending on a variable's current value. WHILE loops, supported on many of the same controls, extend that same conditional idea into repeating a block of code automatically until a condition is no longer true, rather than requiring a fixed, pre-known repeat count the way a simple M98 subprogram call does.
The real value of macro variables shows up most clearly in what is often called family-of-parts programming: a single program written to produce a whole range of similar parts that differ only in a handful of dimensions, with those dimensions exposed as variables set once near the top of the program, or even prompted from the operator at run time through a dedicated input command many controls support for exactly this purpose.
(#10 = number of holes, #11 = circle radius, #12 = starting angle) #10 = 6 #11 = 25.0 #12 = 0 #13 = 1 (loop counter) WHILE [#13 LE #10] DO1 #14 = #12 + [360 / #10 * (#13 - 1)] (angle for this hole) #15 = #11 * COS[#14] (X position from angle and radius) #16 = #11 * SIN[#14] (Y position from angle and radius) G00 X#15 Y#16 M98 P2000 (call a drilling subprogram at this position) #13 = #13 + 1 END1
Nothing about that example is control-specific syntax a beginner needs to memorize immediately — the point of walking through it is to see, concretely, how a loop counter, a small trigonometric calculation, and a subprogram call combine into a program that can drill a bolt circle with any number of holes, any radius, and any starting angle, simply by changing three numbers near the top rather than rewriting the geometry by hand for every new part. Rather than maintaining a separate, nearly identical program for every size or hole-count variant, a shop maintains one program and simply changes the values feeding into it — a meaningful jump in both flexibility and maintainability once a programmer is genuinely comfortable with the fundamentals covered in the levels before this one.
Beyond the simple M98 subprogram call, many controls also support a dedicated macro call, commonly G65, which behaves similarly but explicitly allows arguments to be passed into the called program using letter addresses that map to specific macro variable numbers — letting a single reusable macro accept, for example, a hole diameter and depth as direct arguments on the calling line itself, rather than requiring those values to be set as separate variable-assignment blocks beforehand. This is a genuinely more advanced and more self-contained way of packaging reusable logic, and it is generally worth learning only once plain subprograms and basic macro variables are already comfortable, since it layers additional syntax on top of both.
Everything up through macro programming applies, in some form, to essentially any CNC machine. The territory beyond that point tends to be specific to more capable machine architectures and to production environments where the added complexity genuinely pays for itself, and each topic below is expanded here with enough detail to understand what it actually involves, even though genuine fluency in any one of them is realistically built through real production work rather than reading alone.
On a genuine four- or five-axis machine, programming stops being purely about linear and rotary positions treated separately and starts requiring an understanding of how the control coordinates them together. The central concept here is tool center point management — often invoked through a code such as G43.4 or a comparable rotary tool center point mode — which keeps the actual cutting point steady in space even as rotary axes tilt the tool around it. Without that mode active, tilting a rotary axis moves the tool's physical tip through space as a direct side effect of the rotation itself, forcing a programmer to calculate compensating linear moves by hand for every single rotary adjustment; with it active, the control handles that compensation automatically, letting a programmer describe a tilted surface in terms of the part's actual geometry rather than in terms of the specific kinematic chain of the particular machine cutting it.
Swiss-type lathes and turn-mill centers with more than one independently movable turret or spindle require explicit synchronization commands to coordinate motion across channels — managing which operation happens on which spindle, when a part transfers from a main spindle to a sub-spindle, and how two tools cutting simultaneously on the same part are kept from colliding with each other. A typical synchronized program is written as two or more parallel channel listings rather than one single linear sequence, with specific synchronization codes acting as checkpoints that force one channel to wait for another to reach a corresponding checkpoint before either is allowed to continue — a concept genuinely closer to coordinating two separate but cooperating programs than to writing one longer version of a single-spindle program.
Touch-probe cycles let a program measure a feature, a fixture offset, or a tool's actual dimensions directly at the machine, feeding the result back into the running program's own variables — effectively combining macro programming with real, physical measurement taken mid-cycle. A probing move is typically invoked with a dedicated code, commonly built around G31 on many controls, which behaves like an ordinary linear move except that it stops the instant the probe's stylus contacts a surface, rather than continuing to its programmed endpoint, and stores the exact position at which contact occurred into a system variable the rest of the program can then read. A program can use that captured position to automatically set a work offset from a rough casting's actual location, confirm a critical dimension is within tolerance before proceeding to a following operation, or detect a broken tool by checking whether it is still the expected length.
Some modern controls and add-on systems can adjust a programmed feed rate in real time based on actual cutting load, rather than running a single conservative feed rate calculated in advance for the worst-case section of a cut. In practice this generally works by monitoring spindle load, cutting force, or a comparable proxy for how hard a tool is actually working at any given moment, and automatically increasing feed where the cut is lighter than the worst case while backing it off where the cut briefly becomes heavier — extracting real cycle-time improvement without requiring a programmer to hand-calculate a separate feed rate for every individual section of a complex toolpath.
Larger production programs frequently track cumulative tool usage, automatically substituting a backup tool from an equivalent offset group once a primary tool reaches a defined wear or usage limit, without requiring the program itself to be rewritten. This is generally configured through a separate tool-life management table rather than through inline G-code logic, letting the same underlying program run unattended across an entire shift while the control quietly rotates through several physically identical backup tools as each one in turn reaches its programmed limit.
Two further capabilities worth knowing by name, even if not covered in exhaustive depth here, are rigid tapping and back working. Rigid tapping synchronizes spindle rotation and axis feed with enough precision to cut a thread without a floating tap holder — a meaningful step up in both speed and thread quality compared to older tapping methods, and one that depends on the servo-level synchronization discussed briefly under multi-channel programming above. Back working, common on Swiss-type and sub-spindle-equipped lathes, refers to machining the reverse face of a part after it has been transferred to a secondary spindle, letting a single setup complete features on both ends of a part that would otherwise require a completely separate second operation.
At an advanced level, being able to read, verify, and hand-edit code that a CAM system and post processor produced automatically — rather than only ever writing a program from a blank page — is arguably the single most commonly used real-world skill in this entire list, since, as covered in Part One, the large majority of genuinely complex geometry running in modern shops is programmed this way rather than typed by hand from scratch. That skill includes recognizing the somewhat denser, more literal style CAM-generated code tends to have compared to hand-written code — often restating a motion mode on every single block rather than relying on modal behavior, and expressing curves as large numbers of very short linear segments rather than as true arcs — without mistaking that stylistic density for an error simply because it looks less economical than a hand-written equivalent would.
Two further pieces of advanced territory are worth knowing about, even briefly. Most macro-capable controls let a program raise its own custom alarm, commonly through a dedicated code such as #3000, paired with a programmer-written message — letting a well-built macro stop itself deliberately and clearly, with an explanation an operator can actually read, rather than running an operation with an out-of-range or nonsensical parameter and failing in some less predictable, less informative way further down the program. Building that kind of deliberate error-checking into a reusable macro is a genuine mark of a mature, production-ready program rather than a first-draft one.
Separately, very large programs — a genuinely enormous 3D surface toolpath, for instance — can sometimes exceed a control's available internal memory. Rather than the historical direct numerical control link described in Part One being purely a relic of the tape era, a comparable technique, often called drip-feeding, is still in active use today: the control executes a program block by block while continuously receiving the next portion over a live network connection from an external computer, rather than holding the entire file in its own memory at once. This is less a distinct programming skill than a workflow detail, but it is a direct, living descendant of exactly the networked-execution idea introduced decades earlier, and worth recognizing as such.
None of the topics in this level are meaningfully approachable without genuine, comfortable command of everything in Levels 1 through 6 first. They are laid out here less as a curriculum to work through line by line and more as an honest map of where the language keeps going once the fundamentals are solid — useful mainly so that a learner knows roughly what still lies ahead and does not mistake fluency with the basics for the ceiling of what G-code programming actually involves.
Knowing the individual pieces of a language and being able to actually use it under real conditions are two different skills, and the gap between them is where most self-taught programmers either build genuine confidence or quietly stall out. The path below is one reasonable order in which to close that gap, moving deliberately from low-risk practice toward real production work, with each step expanded here into a fuller description of what actually doing it looks like in practice rather than a one-line summary.
G-code has survived more than seventy years of change in almost everything around it — the physical medium a program travels on, the software that writes it, the interfaces programmers use to interact with it, and now the AI systems beginning to assist with authoring it — while remaining, at its core, remarkably close to the letter-address format standardized in the 1960s and 70s. That durability is itself the most useful thing a learner can take away from its history: the fundamentals covered in Part Two of this guide are not a snapshot of one moment in CNC technology, but a language that has already proven itself worth learning properly, one line at a time, from a beginner's first G01 straight through to synchronized, multi-channel, five-axis production work.