---
title: "How to Read a VERICUT Error Log Against Your G-Code"
description: "A VERICUT error log triages into four families: program errors, collisions, overtravel, and setup mismatches. Reading it by family beats reading it by line."
url: https://gcodepractice.com/journal/how-to-read-a-vericut-error-log-g-code/
canonical: https://gcodepractice.com/journal/how-to-read-a-vericut-error-log-g-code/
author: "Lawrence Arya"
authorUrl: https://www.linkedin.com/in/vibecoding/
published: 2026-06-07
updated: 2026-06-07
category: "Guides"
tags: ["vericut", "verification", "error log", "simulation"]
lang: en
---

# How to Read a VERICUT Error Log Against Your G-Code

> **TL;DR** Read a VERICUT error log by family rather than line by line: program errors (the NC code itself is illegal or questionable), collision reports (modeled geometry contacted modeled geometry), travel and limit violations (an axis exceeded the modeled envelope), and setup mismatches (the simulation's stock, fixture, or tool table disagrees with the program's assumptions). Each family points at a different culprit, and the fourth family is the humbling one: a large share of red in any verification log is the simulation setup being wrong about the job, not the G-code being wrong about the part.

A [VERICUT](https://www.cgtech.com/) error log reads like an indictment of your program, and treating it that way wastes afternoons. The log is better read as a conversation between two descriptions of reality, your NC program and the software's model of your machine, stock, fixtures, and tools, and an error means the two descriptions disagree. Either side can be the wrong one, which is why the productive read triages by family before touching any line of code.

## Two descriptions, one log

Verification software holds two complete descriptions of the same job. The program describes intent: positions, feeds, tool calls, in your control's dialect. The project setup describes the world: machine kinematics and travel, stock dimensions, fixture geometry, the tool table. The simulation walks the first description through the second and writes a log entry wherever they conflict. Nothing in that process knows which description is correct, a fact the log's confident formatting hides, and rediscovering it per error is what makes log-reading slow. Sorting errors into families restores it up front, because each family carries its own odds about which side is lying.

## The four families

| Family | What the log is saying | The usual culprit |
| --- | --- | --- |
| Program errors | This NC code is illegal or suspect as written | The G-code: syntax, bad cycle structure, undefined tools |
| Collisions | Modeled geometry contacted modeled geometry | Either the code's path or the model's geometry |
| Travel and limit violations | An axis exceeded the modeled envelope | Waypoints, retracts, and offsets, or a mis-modeled envelope |
| Setup mismatches | The job's data disagrees with itself | The simulation setup: stock, fixture position, tool table |

The families matter because each points somewhere different. Program errors send you to the code with confidence; the other three send you to a comparison, and comparisons have two sides.

## Family 1: program errors, the trustworthy red

When verification software flags illegal words, malformed cycles, or undefined tool calls, believe it: this is the same [syntax-and-structure species](/journal/how-to-read-g-code-to-find-errors/) a strict interpreter catches, reported with block numbers. The reading skill is opening the flagged block in its modal context, what motion mode, offset, and comp state were active, because the flagged line is sometimes the victim of a state set far above it, the standard [block-plus-state grammar](https://linuxcnc.org/docs/html/gcode/overview.html) of all NC reading.

## Family 2: collisions, the two-sided red

A collision report says two modeled objects met. Whether the program or the model is at fault is genuinely open: a rapid through a modeled clamp may be a real path error, or a clamp modeled where no clamp sits. Two habits make this family fast. Fix the earliest collision first, downstream contacts are often consequences of the first bad position and evaporate with it. And for each contact, ask the model question explicitly: is this geometry where the simulation thinks it is? Holder profiles, fixture heights, and stock overhang are the repeat offenders.

## Family 3: travel violations, the waypoint family

Overtravel in simulation has the same anatomy as overtravel at the machine: a commanded position, often an [intermediate waypoint on a G28-style retract](/journal/z-axis-overtravel-on-g28/), resolved outside the envelope. The simulation version arrives cheaper, no alarm, no operator, and earlier, which is its entire value. The check order matches the machine version: which position was commanded, in which distance mode, under which offset, against which modeled travel.

## Family 4: setup mismatches, the humbling red

A large share of red in any verification log traces to the simulation being wrong about the job: stock defined larger than what is clamped, a fixture translated a few millimeters from its real position, tool lengths stale since the last regrind. This family masquerades as the other three, phantom collisions, impossible gouges, and the tell is volume: when one operation lights up with errors that make no physical sense together, audit the setup data before the code. The verification-layer version of an old rule: when the [simulator and reality disagree](/journal/how-to-simulate-g-code-without-a-machine/), the disagreement is the finding, and reality outranks.

No public reference replaces the software's own documentation for log specifics, formats and report options are licensed-product territory, but the triage logic above is portable across every verification tool in [numerically controlled](https://en.wikipedia.org/wiki/Numerical_control) machining, because all of them compare a program against a model and report disagreements.

## The fluency the log assumes

Every family eventually lands you on a block number, and the log's usefulness is bounded by how fast you can read what you find there: the flagged line, its modal context, the offsets in force. That is recall territory, the difference between a log being a to-do list and being homework, and it is the same fluency that [verification work of every kind](/journal/how-to-manually-verify-ai-generated-g-code/) runs on. The free 60-second drills on the [G-code practice page](/g-code-practice/) keep that vocabulary at speed, so the afternoon goes to resolving disagreements instead of decoding them.

## Sources

- [CGTech: VERICUT official site](https://www.cgtech.com/)
- [LinuxCNC: G-code overview](https://linuxcnc.org/docs/html/gcode/overview.html)
- [Wikipedia: Numerical control](https://en.wikipedia.org/wiki/Numerical_control)

## Frequently asked questions

### How do you read a VERICUT error log against your G-code?

Triage by family first: program errors point at the NC code, collisions at modeled geometry, travel violations at the envelope, and setup mismatches at the simulation itself. Each family has a different culprit, and sorting first prevents editing good code to satisfy a bad setup.

### Why does VERICUT report errors on code that runs fine on the machine?

Because the simulation runs against models, and models drift from reality: fixtures modeled tall, stale tool lengths, oversized stock. When the log and the machine disagree, the disagreement itself is the finding.

### Which VERICUT errors should be fixed first?

Collisions and travel violations first, then program errors, then warnings. Inside the collision family, fix the earliest one: downstream contacts are often consequences of the first bad position.

### What G-code knowledge does reading verification logs require?

Enough fluency to open the flagged block and understand its modal context without a reference. The free G-Code Sprint app builds that recall in 60-second daily rounds.

---

Source: https://gcodepractice.com/journal/how-to-read-a-vericut-error-log-g-code/
Author: Lawrence Arya — https://www.linkedin.com/in/vibecoding/