---
title: "How to Read G-Code to Find Errors: The Four Error Species"
description: "Error-hunting in G-code is a different read than understanding it: four error species, each with telltales, found by scanning in passes instead of lines."
url: https://gcodepractice.com/journal/how-to-read-g-code-to-find-errors/
canonical: https://gcodepractice.com/journal/how-to-read-g-code-to-find-errors/
author: "Lawrence Arya"
authorUrl: https://www.linkedin.com/in/vibecoding/
published: 2026-06-07
updated: 2026-06-07
category: "Guides"
tags: ["error hunting", "reading code", "debugging"]
lang: en
---

# How to Read G-Code to Find Errors: The Four Error Species

> **TL;DR** Reading G-code to find errors is a different activity from reading it to understand: errors come in four species, syntax errors (words your control rejects), state errors (wrong or missing modes, units, and offsets), geometry errors (legal code cutting the wrong shape), and physics errors (right shape at impossible feeds, speeds, or depths), and each species has its own telltales and its own scan. Hunting all four in one careful read-through is how errors get missed; four fast passes, one species each, is how they get found.

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](/journal/how-does-a-cnc-machine-read-code-step-by-step/) 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](/journal/missing-decimal-point-in-g-code-crash/) being the classic catch. A strict reference like the [LinuxCNC overview](https://linuxcnc.org/docs/html/gcode/overview.html) defines what well-formed even means, and a viewer like [NCViewer](https://ncviewer.com/) 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](/journal/is-g-code-just-an-x-y-coordinate-graph/), 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](/journal/cnc-programming-without-the-confusing-math/), 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](/journal/how-to-manually-verify-ai-generated-g-code/), 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](/journal/how-to-read-a-vericut-error-log-g-code/) instead of drowning in it. Two reading skills support every pass: not skipping lines under time pressure, trained directly with [line-discipline exercises](/journal/how-to-stop-skipping-lines-when-reading-g-code/), 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](/g-code-practice/) 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

- [LinuxCNC: G-code overview](https://linuxcnc.org/docs/html/gcode/overview.html)
- [Wikipedia: G-code](https://en.wikipedia.org/wiki/G-code)
- [NCViewer: online G-code viewer](https://ncviewer.com/)

## 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.

---

Source: https://gcodepractice.com/journal/how-to-read-g-code-to-find-errors/
Author: Lawrence Arya — https://www.linkedin.com/in/vibecoding/