A solid G-code verification process has six stages: check the file, simulate the toolpath, verify the setup against the program, dry-run the machine, inspect the first part, and record what you proved. Each stage catches a different class of error, and skipping one leaves a gap the others cannot cover. This guide walks through all six in the order a shop actually does them.
TL;DR
- Verify in layers: file review, simulation, setup check, dry run, first-part inspection. No single layer catches everything.
- Read the header and search for negative Z moves before the program ever reaches the machine.
- A control runs legal code exactly as written, so "no alarm" does not mean "correct."
- Dry-run with the Z offset raised and feed override low, with a hand on feed hold.
- Write down what was verified, by whom, and against which revision, so the next run starts from proof instead of memory.
Table of Contents
- What G-code verification actually means
- Why "no alarm" proves nothing
- Stage 1: Review the file before it goes near the machine
- Stage 2: Simulate and backplot the toolpath
- Stage 3: Verify the setup against the program
- Stage 4: Prove out with a dry run
- Stage 5: Inspect the first part
- Stage 6: Keep a record of what you proved
- A verification flow you can print
- Our perspective
- Where Availzye Machinist Pro fits
- FAQ
- Sources
What G-code verification actually means
G-code is the language that tells a mill, lathe or other CNC machine what to do, how, and where. Verification is the work of proving that those instructions, combined with your real setup, will make the right part without hitting anything.
That last phrase matters. A program can be syntactically perfect and still crash, because the code is only half the system. The other half is the vise, the tool in the spindle, and the numbers sitting in the offset table. NIST points out that when a process plan is converted to ISO 6983 G-code, almost all product and process data is stripped out, leaving a primitive sequence of toolpath motions. The program does not know your material or your tolerances. You have to supply that judgment during verification.
Why "no alarm" proves nothing
Mike Lynch of Modern Machine Shop makes a point every operator should have on the wall: a control generally executes legal instructions exactly as written. Motion and setup mistakes may run without any alarm and then drive the tool into the workpiece, the workholding or the machine.
The errors that article lists are worth memorizing, because they are the ones verification exists to catch:
- Syntax mistakes and wrong coordinates or axis addresses
- Forgotten or canceled tool offsets
- Clockwise and counterclockwise commands reversed
- Incremental mode selected instead of absolute
- Wrong program zero or wrong tool measurements
- Omissions such as decimal points, feeds or coolant
Notice that most of these are legal code. Your control will accept every one of them. Only a person or a simulator who knows the intent will flag them.
Stage 1: Review the file before it goes near the machine
Start at the top of the program, not the cut. After post-processing, do a line-by-line read of the first 30 to 50 lines of the header. You are confirming:
- Safety blocks are present and correct
- Units are right (G20 for inch, G21 for metric)
- Work offsets are the ones the setup sheet calls for
- The first tool call is the tool you expect
Then check the file itself. A FANUC training manual from an academic program recommends confirming file names, post-processor identification and negative Z moves, for example by searching the file for "Z-" to be sure no move breaks through where it should not.
Check modal state and compensation
Hidden modal state is where good programmers get burned. A G90/G91 mix, a leftover cutter compensation, or a canned cycle still active from the previous block will not announce itself. Our guide to modal G codes for CNC operators covers how to catch these before cycle start, and the piece on controller CRC versus CAM offsets explains how compensation choices lead to gouging if they are mismatched.
A startup block that resets modal state every time is cheap insurance. See our safe startup G-code templates for control-specific examples.
A quick example
Say a program calls T3 with G43 H3, but your setup sheet lists the 3/8" end mill as T5. Nothing in the file is illegal. The control will happily apply whatever length sits in H3. A header review against the setup sheet catches this in thirty seconds. A crash catches it much more expensively.
Stage 2: Simulate and backplot the toolpath
Simulation comes in two flavors, and they answer different questions.
| Check | What it finds | Where it runs |
|---|---|---|
| CAM backplot and material removal | Gouges and path errors in the toolpath itself | In the CAM system, before the program is generated |
| Control-level simulation | Machine-specific syntax compatibility | On or for the target control |
Backplotting the final G-code, not only the CAM toolpath, is the habit worth building. The CAM preview shows what the software intended. The backplot of the posted file shows what the machine will be told.
Simulation has blind spots, though. It does not know the fixture you clamped on unless someone modeled it, and it cannot see an offset you typed wrong. That is why it is a stage and not the whole process.
Analyzing code you did not write
Sometimes the program comes from a customer, a previous shift or a generator. Run it through a G-code analysis step first to see the rapid moves, depth ranges and feed values in one pass. If an AI tool wrote any part of it, read our guide on how to verify AI-generated G-code before it touches the spindle. The same layers apply, and the review should be stricter, not looser.
Stage 3: Verify the setup against the program
The program and the machine have to describe the same reality. Modern Machine Shop's guidance says to check workholding placement, tool assembly and loading, tool measurements, and entered offsets. It also warns that offline verification may not reveal wrong tool-length compensation or wrong offset use. Those live in the machine, not the file.
A good setup instruction answers the questions an operator would otherwise guess at. Per another Modern Machine Shop piece on the CAM-to-shop handoff, it should document the fixture and mounting method, tool type, stickout and holder, work-offset locations and count, probing assignments, and acceptable tool-length differences between CAM and the actual setup.
Setup verification checklist
- Confirm the program number and revision match the job paperwork.
- Check the fixture or vise position against the setup sheet, including jaw or stop locations.
- Compare each loaded tool and holder with the tool list. Check stickout.
- Confirm each tool length and diameter in the offset table matches the measured value.
- Verify work offsets by touching off or probing a known feature, not by trusting the number on the screen.
- Confirm the count of work offsets the program uses matches the count set.
Tool measurement deserves its own discipline. Our tool presetting workflow goes from assembly to verified offsets, and tool runout is worth checking because it changes the effective cutting diameter you are trusting.
A clear CNC setup sheet is the document that ties this stage together. If the sheet is vague, the verification is vague.
Stage 4: Prove out with a dry run
A dry run checks what no software saw: real offsets, unmodeled fixtures and machine axis limits. The UTEC guidance describes dry runs as complementing software simulation for exactly those real-world issues.
The method is consistent across the sources:
- Raise the Z offset so the toolpath runs safely above the part.
- Cut the feed override to 10 to 25 percent so you can watch clearance between tool, holder and fixtures.
- Keep a hand ready on feed hold or reset. For every new file, watch the entire program run rather than walking away after the first few moves.
- Use single block through the first tool change and the first approach to each new feature.
- Lower the Z offset back to its true value only after the air run is clean, then run the first part.
Watch the distance-to-go display against what you expect, not only the visual. A rapid that looks fine can be a few thousandths from a clamp.
Safety when the machine has to be powered
Testing and positioning often require the machine to be energized. OSHA's lockout/tagout standard, 29 CFR 1910.147(f)(1), sets out sequential steps for testing or positioning: clear the machine of tools and materials, remove employees from hazardous areas, remove lockout devices, and provide effective protection during the test. If your prove-out involves a guard open or a tool being repositioned by hand, review that standard with your safety lead before relying on a habit.
Stage 5: Inspect the first part
After a clean dry run, run the first part and measure it comprehensively against the drawing. "Comprehensively" means every dimension and feature the print calls out, not the two you are worried about. A first part is where a wrong tool-diameter compensation, a thermal shift or a bad zero finally shows up as a number.
If the part is out, resist the urge to patch the offset and continue. Work out which stage should have caught the error. The answer tells you whether the fix belongs in the program, the setup sheet or the tool data.
The skill is recognized formally, too. Ohio's credential alignment guide lists machine verification and dry run, and physical test cutting among the duties for the NIMS CNC lathe and mill credentials.
When an alarm does appear during prove-out, stop and read it. Our checklist of five checks before clearing a G-code alarm keeps you from resetting past the clue.
Stage 6: Keep a record of what you proved
Verification you cannot show is verification the next shift will repeat or skip. A useful release record is short. It should capture:
- Program name, revision and date
- Who wrote or posted it, and who verified it
- Which controls and machines it was proven on
- Setup details: fixture, tool list, stickout, work offsets
- What was run: simulation, dry run, first-part measurement
- Any edit made at the control, and whether it was posted back to the master
That last item is the one shops lose. A proven program gets tweaked on the machine, the change never reaches the master file, and the next run starts from the stale version. Whatever system you use, make "edit at the control" mean "revert or upload and re-version before the job closes." Requirements for formal records vary by customer and industry, so check your quality system or customer contract for anything beyond this baseline.
A verification flow you can print
| Stage | Question it answers | Typical evidence |
|---|---|---|
| 1. File review | Is the code what we think it is? | Header check, search for negative Z, units and offsets confirmed |
| 2. Simulation | Does the path make sense and clear the model? | Backplot of the posted file |
| 3. Setup check | Does the machine match the program? | Signed setup sheet, measured tool data |
| 4. Dry run | Does it clear in real space? | Air run with raised Z and low override |
| 5. First part | Is the part right? | Inspection against the drawing |
| 6. Release | Can anyone repeat this? | Revision, verifier, notes |
Our perspective
We build for machinists, and the pattern we see is that verification fails at the handoffs, not inside any one tool. The program lives in one place, the tool data in a spreadsheet, the offsets on a sticky note and the first-part results in someone's head.
That is why we put the calculators and the shop records in the same app. When you check a feed or a deflection number, the tool and the job it belongs to are one tap away, and the answer does not depend on which tab someone opened. Verification is physics plus paperwork, and both have to be easy or they get skipped on a busy Friday.
Our advice: pick the layers that fit your risk, make them the same every time, and write down the result. A one-off job in soft aluminum and a repeat order in titanium deserve different depth, but both deserve a defined process.
— Availzye
Where Availzye Machinist Pro fits
Availzye Machinist Pro is a cloud-based platform that combines CNC calculators, including G-code analysis, tool deflection and feeds and speeds, with shop tools such as a job tracker, tool crib and shift notes. Use the calculators to sanity-check the numbers behind a program, and the shop tools to keep setup and release records in one place. Plans are Individual at CA$9.99 per month, Small Shop at CA$24.99 per month and Team at CA$49.99 per month, each with a 7-day free trial. You can see the plans and start a trial, or try the G-code generator first.
FAQ
What is the first thing to check in a G-code program?
Start with the header. Confirm the file name, post-processor, units (G20 or G21), work offsets and first tool call, then search for negative Z moves that might cut deeper than intended. These checks take a few minutes and catch the errors most likely to cause a crash.
Is simulation enough to trust a program?
No. Simulation finds path errors, gouges and syntax problems, but it cannot see a mistyped offset, a wrong tool length or a fixture that was never modeled. Follow it with a setup check and a dry run on the actual machine.
How do you dry-run a CNC program safely?
Raise the Z offset so the path runs above the part, reduce feed override to roughly 10 to 25 percent, and watch the full program with a hand near feed hold. If the test needs the machine powered with guards open or tools being moved, follow your lockout/tagout procedure and OSHA's testing and positioning requirements.
Can AI-generated G-code be verified the same way?
Yes, and it should be held to at least the same standard. Run the same file review, simulation, setup check and dry run, and treat the output as an untrusted draft until each stage passes.
Sources
- What is G-code? (TechTarget)
- FANUC CNC Manual
- Toolpath Simulation and Verification: Catching Errors
- Tying Together Design, Process Planning and Machining (NIST)
- Verifying CNC Program Correctness: Step 2 (Modern Machine Shop)
- Refining the Handoff Between the CAM Program and the Real-World Process
- Key CNC Concept #10: Verifying CNC Programs Safely
- OSHA lockout/tagout interpretation, 2024
- Ohio NIMS CNC credential transfer guide