---
title: "Fusion 360 Post Processor G-Code Output Wrong? Fix the Translator"
description: "When Fusion 360 outputs wrong G-code, the toolpath is almost never the problem: the post processor is. The four mismatch types and the fix ladder."
url: https://gcodepractice.com/journal/fusion-360-post-processor-g-code-output-wrong/
canonical: https://gcodepractice.com/journal/fusion-360-post-processor-g-code-output-wrong/
author: "Lawrence Arya"
authorUrl: https://www.linkedin.com/in/vibecoding/
published: 2026-06-07
updated: 2026-06-07
category: "Guides"
tags: ["fusion 360", "post processor", "cam", "troubleshooting"]
lang: en
---

# Fusion 360 Post Processor G-Code Output Wrong? Fix the Translator

> **TL;DR** When Fusion 360 outputs G-code your machine rejects or runs strangely, the toolpath is almost never the problem; the post processor is. The post is a translator script that converts Fusion's internal toolpath into one control's dialect, and a wrong or misconfigured post produces wrong code from a perfect toolpath: rejected words, wrong arc format, missing safety lines, unit surprises. The fix ladder runs: pick the correct post from Autodesk's post library, check the post's own options in the output dialog, edit the .cps for persistent quirks, and verify in a simulator before metal.

When Fusion 360 outputs wrong G-code, the instinct is to blame the toolpath or the software, and both are usually innocent. Between the toolpath you simulated and the file your machine read sits a [post processor](https://en.wikipedia.org/wiki/Post_processor): a translator script that converts Fusion's internal moves into one specific control's dialect. A wrong or misconfigured translator produces wrong code from a perfect toolpath, which is why the same operation posts beautifully for one machine and gibberish for another.

## What the post actually does

A Fusion toolpath is dialect-neutral geometry: positions, feeds, tool changes, in an internal form no machine reads. The post processor, a JavaScript file with a .cps extension, walks that toolpath and writes out one control's version of it: this control's preferred retract style, its arc format, its coolant codes, its header conventions. Two machines running the same toolpath through different posts get meaningfully different files, both correct. One machine running a file posted for a different control gets a file that is wrong in whichever ways the two dialects disagree, and those disagreements sort into four recognizable types.

## The four mismatch types

| Symptom at the machine | Likely cause | Where to fix it |
| --- | --- | --- |
| Control rejects words or alarms on load | Post written for a different control's dialect | Get the control-specific post from the library |
| Arcs cut wrong or alarm mid-arc | Arc format mismatch: R versus I/J, absolute versus incremental centers | Post options first, then the post's arc settings |
| Strange retracts, tool-change moves, or G28 surprises | Sequence conventions differ per machine | Post options for retract style; edit the post if needed |
| Everything runs 25 times too far or too short | Units mismatch between post output and control setting | Output units option, and the control's own units state |

The G28 row deserves a flag: posts that retract through G28 move via an intermediate point, and on a machine where that waypoint logic surprises you, the result is the classic dive described in [why did my Z axis dive into the chuck on G28](/journal/why-did-my-z-axis-dive-into-the-chuck-on-g28/). Many posts offer a G53-style retract option precisely because of it, and the [G28-versus-G53 retract decision](/journal/fusion-360-g28-vs-g53-safe-retract/) has its own page.

## The fix ladder, cheapest rung first

**Rung 1: confirm the post itself.** [Autodesk's post library](https://cam.autodesk.com/hsmposts/) is free and searchable, and the search term that matters is your control, not your machine brand: the control owns the dialect. A Fanuc-control mill from any builder is closer to another Fanuc machine than to its own builder's other models with different controls. Generic posts exist for unsupported setups; they are starting points, not finished translators.

**Rung 2: the options dialog.** A large share of "wrong output" is a correct post with one option set wrong: output units, safe-retract style, work offset numbering, coolant behavior. The NC program dialog exposes the post's properties, and reading through them once teaches you what the post author already anticipated. Change one option, re-post, diff the files.

**Rung 3: edit the .cps.** Posts are JavaScript, openly editable, and small persistent quirks are routine fixes: a coolant code your machine wants after tool changes, a header line your shop requires. Copy the library post, make one change, compare outputs. If the change came from an AI assistant, the failure modes are their own story, covered in [fixing ChatGPT-edited Fusion post code](/journal/how-to-fix-chatgpt-fusion-360-post-processor-code/).

**Rung 4: verify before metal.** A post change is a software release for your machine. Run the posted file through a backplot or [simulator](/journal/how-to-simulate-g-code-without-a-machine/), check the header words against the control's supported list, and give the first run single-block attention.

## Why this is not a Fusion bug

[Fusion 360](https://www.autodesk.com/products/fusion-360/overview) computes toolpaths in a dialect-neutral form, and that design is what makes one CAM system drive hundreds of controls. The cost is that correctness lives in the translation layer, maintained per control, configurable per shop. The same architecture, and the same diagnosis, applies across the CAM world: [Mastercam's version of wrong output](/journal/mastercam-outputting-wrong-g-code/) has different file names and the same root cause, and the [hobby-router version in VCarve](/journal/vectric-vcarve-g-code-troubleshooting/) is this story at GRBL scale.

## The skill that makes posts debuggable

Every rung of the ladder leans on one ability: reading the posted file and recognizing what belongs and what does not. That is vocabulary fluency, and it trains in minutes a day; the free 60-second drills on the [G-code practice page](/g-code-practice/) build exactly the recall that turns a posted header from noise into a checklist. A machinist who reads the output never has to trust the translator blindly, which is the entire difference between using CAM and being used by it.

## Sources

- [Autodesk: Fusion 360 post processor library](https://cam.autodesk.com/hsmposts/)
- [Autodesk: Fusion 360 overview](https://www.autodesk.com/products/fusion-360/overview)
- [Wikipedia: Post processor](https://en.wikipedia.org/wiki/Post_processor)

## Frequently asked questions

### Why is my Fusion 360 post processor outputting wrong G-code?

Almost always because the post does not match your machine: a generic or wrong-control post emits words your control rejects, the wrong arc or units format, or a retract sequence your machine handles differently. Confirm the right post from Autodesk's library, then check the post's options before suspecting the toolpath.

### How do I get the correct post processor for my machine in Fusion 360?

Autodesk maintains a free searchable post library. Search for your control rather than your machine brand alone, since the control dictates the dialect, and prefer a control-specific post over a generic one.

### Can I edit a Fusion 360 post processor myself?

Yes. Posts are JavaScript files with the .cps extension, and small quirks are routine edits. Copy the working library post, change one thing at a time, and compare output files before and after.

### What should I check before running posted G-code on the machine?

Read the header against your control's supported words, confirm units and work offset, then run it through a simulator or backplot before metal. The free G-Code Sprint app drills the code vocabulary that makes that header scannable at a glance.

---

Source: https://gcodepractice.com/journal/fusion-360-post-processor-g-code-output-wrong/
Author: Lawrence Arya — https://www.linkedin.com/in/vibecoding/