---
title: "PrintNC DIY Machine G-Code Troubleshooting: Three Layers"
description: "On a PrintNC you are operator and machine builder at once, so G-code trouble has three suspect layers: the program, the post, and the configuration you wrote."
url: https://gcodepractice.com/journal/printnc-diy-machine-g-code-troubleshooting/
canonical: https://gcodepractice.com/journal/printnc-diy-machine-g-code-troubleshooting/
author: "Lawrence Arya"
authorUrl: https://www.linkedin.com/in/vibecoding/
published: 2026-06-07
updated: 2026-06-07
category: "Guides"
tags: ["printnc", "diy cnc", "troubleshooting", "linuxcnc"]
lang: en
---

# PrintNC DIY Machine G-Code Troubleshooting: Three Layers

> **TL;DR** G-code troubleshooting on a PrintNC, or any DIY machine, differs from factory-machine troubleshooting in one structural way: the machine's configuration is yours too, so every symptom has three suspect layers instead of two: the program (the usual code suspects), the post processor (the translator you chose), and the machine configuration (the controller setup you wrote, axis scaling, limits, spindle control, homing). The layer test is portability: if the same file misbehaves identically in a simulator, it is the program; if it runs clean in simulation and wrong on the machine, suspect the post or the config you built.

A PrintNC owner troubleshooting G-code holds a job nobody at a factory machine has: you are the operator, the programmer, and the machine builder, simultaneously, because the [PrintNC](https://wiki.printnc.info/) is a community-designed machine you assembled and configured yourself. That third hat changes troubleshooting structurally. On factory iron, the machine's own correctness is somebody's warranty; on your build, the configuration is one more file you wrote, and it joins the suspect list with everything else.

## What the PrintNC situation actually is

The PrintNC design gives you a steel-framed machine capable of real metal cutting at a community-documented build cost, and it deliberately leaves the control stack open: builders choose their controller, wire their own electronics, and write the configuration that tells the software what the hardware is. That openness is the design's strength and the troubleshooting context in one: there is no single canonical PrintNC dialect or config, only your machine's, which means symptom diagnosis has to begin by sorting which of three authorship layers produced the misbehavior, because all three authors were you.

## The three layers

| Layer | What lives there | The symptom signature |
| --- | --- | --- |
| Program | The G-code itself: the usual error species | Fails the same way anywhere, including simulators |
| Post processor | The translator between CAM and your controller | Clean toolpath, wrong words or formats for your dialect |
| Machine configuration | Axis scaling, limits, homing, spindle control: the setup you built | Correct code, physically wrong behavior |

The layer test is portability. Run the suspect file through a simulator or a [strict reference interpreter](/journal/g-code-simulator-for-ubuntu-linux/): misbehavior that reproduces identically is the program's, and the standard [error-species scan](/journal/how-to-read-g-code-to-find-errors/) finds it. Behavior that is clean in simulation and wrong on the machine belongs to the bottom two layers, which factory operators never have to think about and you always do.

## The post layer on a DIY machine

DIY builds feel the post-processor problem more acutely than factory shops because nothing was ever vendor-blessed: you chose a controller, your CAM needed a post for it, and the [pick-the-post-by-controller rule](/journal/vectric-vcarve-g-code-troubleshooting/) is the entire game. The dialect your machine actually speaks is defined by what you installed, LinuxCNC's documented [G-code set](https://linuxcnc.org/docs/html/gcode/g-code.html), [GRBL's published list](https://github.com/gnea/grbl/wiki), or another controller's, and the twenty-line file-header read against that list catches most post mismatches before they reach steel. Arc formats and units declarations are the repeat offenders, same as on every router.

## The configuration layer, where DIY earns its reputation

The genuinely DIY failures live in the config, and they have recognizable signatures. Proportional dimension errors, every feature on one axis wrong by the same percentage, are scaling: steps-per-unit set wrong for the pulleys and screws you actually installed. Position drift that accumulates over a job points at lost steps: acceleration or velocity configured past what your steppers deliver, a mechanical bind, or both. Homing and limit surprises, including [overtravel-flavored alarms](/journal/z-axis-overtravel-on-g28/), trace to switch placement and soft-limit values you typed. Spindle behavior that ignores S words is the spindle-control section of your config, and M-codes that do nothing are unmapped outputs, the DIY version of the [builder-owned M-code layer](/journal/cnc-wood-router-m-codes-list/), except the builder is you, which at least means the documentation is whoever you can find in the mirror.

The community's accumulated answers live in the [PrintNC wiki](https://wiki.printnc.info/) and its build threads, and the configuration discipline that prevents most of this is the same one any [custom machine behavior](/journal/custom-m-codes-in-linuxcnc-setup/) deserves: every config change logged, one change at a time, with a test file run after each.

## The diagnostic sequence, assembled

In practice: simulate the file first, ten minutes, splits the problem in half. If the program is innocent, read the file header against your controller's documented dialect, that is the post check. If the words are legal, measure the symptom's shape, proportional points at scaling, accumulating points at lost steps, local-to-one-move points back at the program after all. Air-cut above the work for anything that survived the desk checks. The sequence runs on the same fluency every machine demands, the core vocabulary at recall speed, drilled free in the 60-second rounds on the [G-code practice page](/g-code-practice/), plus the one skill DIY adds: remembering that the machine's own description of reality is a file you can open.

## Sources

- [PrintNC wiki: community documentation](https://wiki.printnc.info/)
- [LinuxCNC: G-code reference](https://linuxcnc.org/docs/html/gcode/g-code.html)
- [Grbl wiki: configuration and supported codes](https://github.com/gnea/grbl/wiki)

## Frequently asked questions

### How do I troubleshoot G-code problems on a PrintNC?

Sort the symptom into three layers: the program (fails the same way anywhere), the post processor (dialect mismatches), and the machine configuration you built (scaling, limits, homing, spindle). The portability test splits them: identical misbehavior in a simulator means program; clean simulation plus wrong machine behavior means post or config.

### Why does my PrintNC cut the wrong size when the G-code looks right?

Wrong-size with correct code points at configuration: steps-per-unit scaling or a units mismatch. Scaling errors are proportional across every feature on the axis, which distinguishes them from local program errors.

### Which controller setup does PrintNC use for G-code?

The community runs several, with LinuxCNC prominent. Your build runs what you chose, and that choice decides your dialect, configuration format, and reference documentation.

### What is the best way to build G-code skill alongside a DIY machine build?

Drill the standard core in parallel with the build: the free G-Code Sprint app handles it in 60-second recall rounds, and LinuxCNC's simulator runs real programs before your hardware can.

---

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