---
title: "Vectric VCarve G-Code Troubleshooting for Router Owners"
description: "Most VCarve G-code problems are post processor mismatches: the wrong .pp file for your controller. The symptom table and the air-cut habit that ends them."
url: https://gcodepractice.com/journal/vectric-vcarve-g-code-troubleshooting/
canonical: https://gcodepractice.com/journal/vectric-vcarve-g-code-troubleshooting/
author: "Lawrence Arya"
authorUrl: https://www.linkedin.com/in/vibecoding/
published: 2026-06-07
updated: 2026-06-07
category: "Guides"
tags: ["vcarve", "vectric", "cnc router", "troubleshooting"]
lang: en
---

# Vectric VCarve G-Code Troubleshooting for Router Owners

> **TL;DR** Most VCarve G-code trouble is not a VCarve bug; it is a post processor mismatch. Vectric ships dozens of .pp post files because hobby and pro router controllers, GRBL, Mach3, Mach4, DSP pendants, and the rest, speak different dialects, and a file saved with the wrong post produces a router that ignores the file, cuts arcs strangely, plunges wrong, or moves at comic-book scale. Pick the post that names your controller, check the file's first lines against what your controller supports, and air-cut every new combination above the work.

VCarve trouble has a comforting statistic behind it: the toolpath engine inside [Vectric's](https://www.vectric.com/) software is mature and rarely the problem, while the step everyone clicks past, choosing the post processor when saving toolpaths, causes the large majority of what gets reported as G-code bugs. VCarve ships dozens of .pp files because router controllers genuinely speak different dialects, and every mismatch symptom below traces back to a file written in the wrong one.

## What a .pp file decides

The post processor is the last step of every toolpath save, and it decides everything dialect-shaped about the output: the file extension, the header lines, how arcs are written, how units are declared, which M codes appear for spindle and accessories, and how the file ends. The geometry you drew and the cut depths you set pass through untouched; the language they are expressed in is entirely the post's choice. That split explains the otherwise confusing experience of a toolpath that previews perfectly and runs wrong: the preview showed the geometry, and the geometry was never the problem.

## The symptom table

| What the router does | What it usually means | The fix |
| --- | --- | --- |
| Ignores the file or errors on load | File extension or header from a different controller family | Re-save with the post naming your controller |
| Arcs cut as straight chords or alarm | Arc format mismatch: I/J versus R versus no-arc support | Use the matching post; polyline variant for weak controllers |
| Plunges through the work or hovers above it | Z zero convention or plunge handling differs | Confirm Z zero (surface versus bed) and the post's plunge moves |
| Cuts at 1/25th scale or 25x too far | Inch post on a metric controller or the reverse | Pick the unit-matched post variant |
| Spindle never starts or dust collector fires instead | M-code wiring differs per controller | Check which M codes your controller maps to which relays |

The last row is router-specific comedy with real consequences: hobby controllers map M codes to whatever relays the builder wired, the territory covered in [wood router M-codes](/journal/cnc-wood-router-m-codes-list/), so a post emitting M8 for coolant may switch nothing, or something surprising.

## Why routers are the post-mismatch capital

Industrial machines ship with one control and often one vendor-blessed post. Routers live in a wilder ecosystem: the same VCarve file might feed a GRBL board, a Mach3 PC, a Mach4 setup, or a standalone DSP pendant, and those four disagree about arcs, file headers, units handling, and M codes. A [post processor](https://en.wikipedia.org/wiki/Post_processor) exists precisely to absorb those disagreements, which is why the post choice carries more correctness per click than any other setting in the save dialog, the same translator economics as the [Fusion 360 version of this problem](/journal/fusion-360-post-processor-g-code-output-wrong/) at industrial scale.

The selection rule: pick by controller, not by machine brand. A GRBL-based machine wants a GRBL post whoever built the gantry, and the [Grbl wiki](https://github.com/gnea/grbl/wiki) publishes exactly which codes the firmware supports, which turns post verification into a reading exercise: open the saved file, read the first twenty lines, and confirm every word appears in [the supported list](/journal/grbl-supported-g-codes-list/).

## The two habits that end the trouble

**Read the file's opening.** Twenty lines tell you the dialect: units word, the arc format on the first curve, which M codes appear. Reading a GRBL-bound file is its [own small skill](/journal/how-to-read-a-grbl-g-code-file/), and it converts every future mismatch from a mid-cut surprise into a pre-run catch.

**Air-cut every new combination.** New post, new controller, new VCarve version: run the file with the Z zero raised above the work and watch the whole program in air. Thirty seconds of theater, and it catches scale errors, plunge surprises, and arc weirdness with nothing at stake. Production shops dry-run for the same reason; the habit scales down to a garage perfectly.

## When it really is not the post

The honest remainder: Z-zero convention mistakes (file made for surface zero, machine zeroed on the bed), toolpaths calculated for a different material thickness, and controller settings like GRBL's own configuration flags. These present like post problems and survive a post swap; the file-reading habit sorts them quickly, because the file is correct and says so. The vocabulary that makes those twenty lines readable at a glance is drillable in minutes a day on the [G-code practice page](/g-code-practice/), and a router owner who reads headers fluently debugs the whole stack, post, controller, zeroing, with the file as witness.

## Sources

- [Vectric: VCarve official site](https://www.vectric.com/)
- [Grbl wiki](https://github.com/gnea/grbl/wiki)
- [Wikipedia: Post processor](https://en.wikipedia.org/wiki/Post_processor)

## Frequently asked questions

### Why is my VCarve G-code not working on my CNC router?

The most common cause by far is saving the toolpath with the wrong post processor for your controller. A mismatched post produces files your controller ignores, misreads, or runs at the wrong scale. Re-save with the post that names your controller and compare the first lines against its supported codes.

### Which post processor should I pick in VCarve?

The one that names your controller, not your machine brand: a GRBL-based machine wants a GRBL post regardless of who built the frame. Inch versus metric variants matter as much as the name.

### Why do arcs from VCarve cut wrong on my router?

Arc handling is the most dialect-sensitive part of router G-code: some controllers want I and J, others accept R, and some handle arcs poorly enough that a polyline post is the dependable choice. Arc weirdness is a strong wrong-post signal.

### What should I learn to troubleshoot router G-code myself?

The small code core your controller runs, well enough to read a file's first twenty lines and spot what does not belong. The free G-Code Sprint app drills that core in 60-second recall rounds.

---

Source: https://gcodepractice.com/journal/vectric-vcarve-g-code-troubleshooting/
Author: Lawrence Arya — https://www.linkedin.com/in/vibecoding/