Reading a program to understand it and reading it to find its errors are different activities, and conflating them is why errors survive careful review. Understanding follows the program’s flow; error-hunting interrogates it against four specific ways programs go wrong. Hunt all four at once and attention diffuses into nothing; hunt them one species at a time, in four fast passes, and each pass is almost mechanical.
Why careful reading misses errors
The proofreading literature has known this for a century: people miss typos in text they understand, because comprehension fills gaps. The same mechanism operates on programs. A reader following the program’s story reads G02 where G03 is written, supplies the missing decimal mentally, and glides over the foreign word, because the story makes sense and sense-making papers over defects. Error-hunting works by breaking comprehension on purpose: you stop reading the program as a story and start interrogating it as evidence, one category of wrongness at a time. The categories are the whole method.
The four species
| Species | What it is | The telltale | The scan |
|---|---|---|---|
| Syntax | Words your control rejects or misparses | Foreign codes, malformed numbers, missing decimals | Every word against the dialect |
| State | Wrong or missing modes, units, offsets | Thin headers, leftover G91, no G40/G49 cancels | Header plus every mode-changing word |
| Geometry | Legal code, wrong shape | Arcs bowing wrong, depths stacking oddly | Plot it and compare against intent |
| Physics | Right shape, impossible numbers | F and S words that ignore the cutter | Every F, S, and depth against the formulas |
The species matter because they hide from each other’s scans: a state error is invisible to a geometry plot until it isn’t, and a physics error plots beautifully. The machine’s own reading process explains why: the control executes words under standing rules, so wrongness can live in the word, the rule, the resulting path, or the resulting forces, four different places.
Pass 1: syntax, the dialect scan
Read every G and M word asking one question: does my control document this? Anything foreign is an error now, before the control says so with an alarm. Number formats ride along in this pass, the missing decimal point being the classic catch. A strict reference like the LinuxCNC overview defines what well-formed even means, and a viewer like NCViewer pre-filters the crudest failures in seconds.
Pass 2: state, the bookkeeping scan
Ignore the geometry completely. Read the header, then jump from mode word to mode word, units, distance mode, plane, offset, comp, asking at each: what is the full machine state right now, and did anything get turned on that never gets turned off? This is the pass that catches the leftover G91 above an innocent-looking move and the comp that picks up and never cancels. It is also the pass software cannot run for you, because correct state is defined by your intent, not by the file.
Pass 3: geometry, the plot scan
Plot the program and compare shapes against intent: profile right, arcs bowing the right way, depth steps stacking as planned, rapids crossing where nothing stands. Eyes are superb at wrong-shape detection once the code becomes a picture, which is the entire case for backplots. What the picture cannot show, rapid-versus-feed and the state behind the path, passes 1 and 2 already covered, which is why plot-only review, the coordinate-graph trap, misses whole species.
Pass 4: physics, the numbers scan
Collect every F, S, and depth-of-cut and sanity-check them against the tool and material: spindle speed from the surface-speed formula, feed from chip load, depths against what the cutter survives. The arithmetic is the two-formula card, thirty seconds per tool, and it catches the error class that runs clean in every simulator and snaps cutters in the real world.
Running the passes in practice
Order them cheap-to-expensive and the workflow stays fast: syntax and state are pure reading, geometry needs a plotter, physics needs the tool data. On familiar programs the four passes take minutes; on a stranger’s file, or an AI’s, they expand naturally into the fuller verification those files deserve, and in shops with verification software the same species taxonomy is how you triage an error log instead of drowning in it. Two reading skills support every pass: not skipping lines under time pressure, trained directly with line-discipline exercises, and vocabulary at recall speed, because a reader still decoding words has no attention left for hunting. That second half is what the free 60-second rounds on the G-code practice page train: codes answering instantly, so your eye is free to notice what should not be there. Error-hunting, at bottom, is fluency plus a checklist, and the checklist fits on an index card.
Sources
Frequently asked questions
How do you read G-code to find errors?
By species, not by line. Errors sort into four kinds, syntax, state, geometry, and physics, and each has its own telltales and its own scan. Four fast passes, one species each, find what a single careful read-through misses.
What errors are hardest to find when reading G-code?
State errors. A missing units word or a leftover G91 is invisible at the line where damage happens, because the error lives in what was declared hundreds of lines earlier. The state scan reads only the header and every mode-changing word.
Can software find G-code errors for me?
Some species, partly: a strict interpreter catches syntax, a backplot exposes geometry. Nothing automatic catches state errors against your intent or physics errors against your tooling. Tools narrow the hunt; two passes stay human.
What is the best way to get faster at finding errors in G-code?
Make the vocabulary automatic so your attention is free for the hunt. The free G-Code Sprint app builds that recall in 60-second daily rounds, repeating missed codes until they stick.