A CNC machine reads code the way a musician sight-reads: one bar at a time, with a few bars of lookahead, under rules set earlier in the piece. It never sees the finished part. What it sees is the next block, the modal rules currently in force, and a short queue of moves it has already planned. Walking through that pipeline once, stage by stage, removes most of the mystery from why controls behave the way they do.
Stage 1: the block becomes words
The interpreter takes one line, a block, and splits it into letter-and-number words: G01, X50.0, F200. Each letter routes its number into a different slot, position, feed, speed, tool, exactly as the word-address format has worked since the punched-tape era. The parsing rules are strict and documented, the LinuxCNC overview is a readable version, and strictness is the point: there is no tone of voice in a program, so the grammar carries everything.
Stage 2: the words update the standing rules
Most G words do not cause motion; they change the modal state, the set of rules in force until further notice. Motion mode, units, absolute versus incremental, active offset, feed mode: each lives in a group where the last word spoken wins and stays. This is the single most important fact about reading code, because it means a block cannot be understood alone. X50 is a rapid in one state, a cutting move in another, and an inch or a millimeter depending on words that may sit two hundred lines earlier.
| Stage | What happens | What can go wrong |
|---|---|---|
| Parse | The block splits into letter-number words | Typos and missing decimals parse as legal, wrong commands |
| Modal update | Words replace the active rule in their group | A leftover mode from earlier code changes the block’s meaning |
| Motion planning | Moves are queued and blended with lookahead | Sharp geometry forces slowdowns the program never mentions |
| Execution | Servos drive axes, feedback confirms position | Following errors and alarms when the machine cannot comply |
| Switch sync | M words fire relays in sequence with motion | A switch fires earlier or later than the programmer assumed |
Stage 3: the planner looks ahead
A single block tells the control where to end up; it says nothing about how to join that move smoothly to the next one. So real controls plan ahead: they hold a buffer of upcoming moves and compute speeds across the queue, slowing into corners and carrying speed through gentle curves. Hobby firmware documents this visibly, the Grbl interface notes describe its streaming buffer and planner outright, and industrial controls do the same job at larger scale. Lookahead is why a machine sometimes moves slower than the programmed feed: the geometry ahead, not the F word, set the limit.
Stage 4: motion becomes electricity
The planned move goes to the servo loop: each axis drive receives a stream of commanded positions, motors turn, and encoders report back where the axis actually is. The control compares commanded against actual continuously, and a gap beyond tolerance raises a following-error alarm rather than a scrapped part. This closed loop is the entire trick that numerical control added to machining in the 1950s: not strength, but the discipline of checking position thousands of times a second.
Stage 5: switches fire in sequence
M words ride the same pipeline with one difference: instead of motion they throw machine functions, spindle, coolant, tool change, program stop. The control sequences them with the motion around them, and the fine print of that sequencing is dialect territory: whether a switch completes before the next move starts varies by control and by code, which is one of several reasons the same program can behave differently on two machines.
What this explains at the keyboard
Three everyday mysteries fall out of the pipeline directly. A program that runs slower than its F words: lookahead and corner physics. A block that did something different than written: modal state set far above it. A crash from an innocent-looking line: the machine executed exactly what the words plus the standing rules commanded, with no picture of the part to warn it. The machine reads state plus block; programmers who read the same way stop being surprised.
That reading skill has two halves: tracking state, which grows from narrating short programs aloud, and instant vocabulary, which grows from recall practice, the free 60-second rounds on the G-code practice page drill exactly that half. Both together are what machinists mean when they say someone can read code.
Sources
Frequently asked questions
How does a CNC machine read code step by step?
Block by block, through a pipeline: parse the line into letter-number words, update the modal state those words change, convert the move into planned axis motion, blend it with the moves queued ahead, then execute it through the servo loop while feedback confirms the result. M words fire their switches in sequence with the motion around them.
Does a CNC machine read the whole program before starting?
No. The control works through the program block by block, with a lookahead buffer of upcoming moves for speed planning. It has no picture of the finished part.
What is modal state in a CNC control?
The set of rules currently in force: active motion mode, units, absolute or incremental positioning, active work offset, feed mode, and more. A word stays in effect until another word in its group replaces it.
What is the best way to learn to read G-code the way the machine does?
Practice reading blocks while tracking state, and drill the vocabulary until it is automatic. The free G-Code Sprint app covers the vocabulary half in 60-second recall rounds; narrating short programs aloud builds the state-tracking half.