The search is reasonable and the tool does not exist: there is no universal G-code syntax checker, for the unfixable reason that G-code has no universal syntax. Every control defines its own dialect, legal words, number formats, cycle structures, so a checker that blessed files in the abstract would still miss exactly what your machine rejects. What exists instead is a stack: four layered checks that together catch what a large language model typically gets wrong at the syntax level, plus the human pass that syntax tools can never replace.
Why the single checker cannot exist
A C compiler can check C because C has one standard. G-code’s standard defines the format of words, not the set of valid ones: G71 is a roughing cycle on one control, an unsupported word on another, and inch-mode selection on a third. Checking syntax therefore means checking against one dialect, and the only complete authority on your dialect is your control and its documentation. Every tool below approximates that authority from a different angle, which is why they stack rather than compete.
The four-layer stack
| Layer | What it catches | What it waves through |
|---|---|---|
| Browser viewer, NCViewer style | Unparseable lines, malformed words, unplottable geometry | Dialect-foreign codes that parse fine |
| Strict interpreter, LinuxCNC sim | Rule violations: bad cycle structure, illegal combinations | Things legal in LinuxCNC but not on your control |
| Editor highlighting | Visual anomalies: odd words, missing decimals, stray text | Anything that looks normal |
| Your control’s dry run | The actual dialect, enforced by the only authority | Semantic errors: legal code doing wrong things |
Layer 1, the viewer. Paste the output into a browser viewer first: ten seconds, no install, and it rejects the crudest failures, lines that do not parse, words without numbers, arcs that cannot resolve. A clean plot here means the file is shaped like G-code, nothing more.
Layer 2, the strict interpreter. LinuxCNC’s simulator runs a real production interpreter with documented rules and loud errors, which makes it the closest free thing to a genuine syntax checker. It enforces structure the viewer ignores: cycle formats, word combinations, modal legality. The asterisk stays honest: it enforces LinuxCNC’s dialect, so its verdicts are evidence about your Fanuc, not proof.
Layer 3, highlighting. An editor with NC syntax highlighting turns anomalies visual: dialect-foreign words color differently, comments that swallowed code stand out, a missing decimal reads wrong at a glance. This layer is only as good as the eye scanning it, which is where vocabulary recognition becomes a tool spec.
Layer 4, the control. Load the file, dry run, watch for alarms. Your control is the one true checker for your dialect, and using it last, after the free layers caught the embarrassing errors, is just sequencing: machine time is the expensive check, so it goes at the end of the funnel.
The gap no checker covers
Syntax-clean is not safe. A file can pass all four layers and still rapid through a clamp, run a feed the cutter cannot survive, or execute a cycle with swapped parameters that happens to be legal. Those are semantic failures, meaning, not grammar, and they are caught by the human passes: geometry read against intent, physics against the formulas, clearance against the actual setup. The full ordered procedure is the six-pass verification method; the syntax stack here is passes one through three of it, industrialized.
Whether AI users can skip building that judgment has a one-word answer, no, and the syntax stack is honest about its role: it filters the cheap failures so your attention is spent where tools cannot go.
The habit that powers layer three
Highlighting only helps an eye that knows what belongs. That recognition is trainable vocabulary: the free 60-second rounds on the G-code practice page drill the core until foreign words snag your attention the way typos do in your native language. With that recall in place, the stack runs in minutes: viewer, interpreter, scan, dry run, and the only thing left for deep attention is the part that was always yours, whether the code should do what it legally says.
Sources
Frequently asked questions
Is there a G-code syntax checker for ChatGPT output?
Not a universal one, because G-code syntax is dialect-specific: each control defines its own legal words and formats. The practical stack layers a browser viewer, a strict interpreter like LinuxCNC’s simulator, editor highlighting, and your own control’s dry run, with a human semantic pass on top.
Will a G-code viewer catch ChatGPT’s syntax errors?
It catches the crude ones: malformed words, unparseable lines, unplottable geometry. It accepts plenty your control will reject, and it cannot see semantic problems at all.
Why is a syntax-clean file still potentially dangerous?
Because syntax is grammar, not meaning. A perfectly legal file can still rapid through a clamp, overfeed a cutter, or run a cycle with swapped parameters. Geometry, physics, and clearance checks stay human work.
What skill makes the syntax stack actually work?
Recognition: knowing your control’s vocabulary well enough that a foreign word stops your eye. The free G-Code Sprint app builds that in 60-second recall rounds, repeating misses until anomalies stand out.