---
title: "Mach4 G-Code Syntax vs Mach3: What the Rewrite Changed"
description: "Mach4 is a ground-up rewrite of Mach3, but the G-code syntax stayed standard-shaped. What changed is the architecture, scripting, and plugins, not the language."
url: https://gcodepractice.com/journal/mach4-g-code-syntax-vs-mach3/
canonical: https://gcodepractice.com/journal/mach4-g-code-syntax-vs-mach3/
author: "Lawrence Arya"
authorUrl: https://www.linkedin.com/in/vibecoding/
published: 2026-06-07
updated: 2026-06-07
category: "Code reference"
tags: ["mach4", "mach3", "syntax", "migration"]
lang: en
---

# Mach4 G-Code Syntax vs Mach3: What the Rewrite Changed

> **TL;DR** Mach4 is a ground-up rewrite of Mach3, and the G-code syntax is the part that barely changed: both run the standard PC-controller subset, so the motion, offsets, cycles, and M-spine read the same and most core programs move between them with normal care. What the rewrite changed is everything around the code, a new software architecture, Lua scripting replacing Mach3's VBScript-style macros, a different plugin model, and reworked screens, so the migration pain is in macros, screen sets, and plugins rather than in the part programs, and a machinist's G-code skills carry straight across.

Mach4 being a ground-up rewrite of Mach3 sets an expectation the G-code quietly disappoints: the part-program syntax is the part the rewrite mostly left alone. [Mach](https://www.machsupport.com/) rebuilt the architecture, the scripting, and the plugin model, and kept the standard PC-controller dialect, so the migration pain lives in macros and screens while the language a machinist types carries straight across. Separating those two is the whole practical story.

## What stayed: the part-program language

Both Mach3 and Mach4 run the standard-shaped subset the PC-controller family shares, motion, planes, units, distance modes, the offset family, common cycles, the M-spine, behaving as the [reference dialects](https://linuxcnc.org/docs/html/gcode/g-code.html) describe. Core part programs move between the versions with the normal porting care, and a machinist's reading and writing skills need no relearning, the same continuity the [Mach3-versus-Fanuc comparison](/journal/mach3-g-code-list-vs-fanuc/) and the [UCCNC compatibility map](/journal/does-uccnc-use-standard-g-code/) trace across the whole family. The G-code, in short, was never the thing that needed rewriting.

The one place a careful machinist double-checks is the M-code periphery, because the M-spine's standard members behave the same while builder and plugin-mapped M-codes depend on the new plugin model: an M-code that triggered an accessory through a Mach3 plugin reaches that accessory through a Mach4 plugin instead, and the mapping is part of the customization migration rather than the part program. So a program full of M03, M08, M30 ports cleanly, and a program leaning on a shop-specific M-code inherits whatever the new plugin layer was configured to provide, which is one more reason to keep the part-program and customization layers mentally separate.

## What changed: everything around the code

| Layer | Mach3 | Mach4 |
| --- | --- | --- |
| Part-program G-code | Standard subset | The same subset |
| Architecture | Older codebase | Ground-up rewrite for stability and capability |
| Scripting / macros | VBScript-style macro language | Lua |
| Plugins | Mach3 plugin model | A different plugin model |
| Screens | Mach3 screen sets | Reworked screen sets |

The scripting row is the migration's center of gravity: Mach4 adopted [Lua](https://en.wikipedia.org/wiki/Lua_(programming_language)) where Mach3 used an older macro language, so anyone who wrote macros is rewriting them, not copying them. The plugin and screen rows compound it for heavily customized setups. None of these touch the part programs, which is exactly why the migration effort is so unevenly distributed: trivial for the G-code library, real for the customization layer, and the honest plan budgets accordingly.

## Why a rewrite spares the language

The pattern is familiar from every control generation in this cluster: the part-program language is the foundation a user base's programs are built on, and rewriting it would orphan that base, so builders rebuild everything else and hold the language steady, the same logic that kept [Haas Classic programs running on NGC](/journal/haas-classic-controller-vs-ngc-g-code-differences/) and Fanuc programs running under [the iHMI tiles](/journal/fanuc-ihmi-interface-where-is-the-g-code/). Mach4's rewrite improved the software's bones, architecture, scripting power, plugin flexibility, precisely because those could change without breaking the one thing that must not: the programs people already run.

## The migration plan that fits

Separate the two layers and the plan writes itself. Part programs: expect standard porting care, header read, dialect check on anything unusual, single-block first run, and most of the library moves. Customization: budget genuine time for rewriting macros into Lua, rebuilding screen sets, and re-establishing plugins, this is where a Mach3-to-Mach4 project actually spends its hours. Skills: nothing to relearn on the G-code side, which means the portable investment, the standard core at recall speed from the free 60-second rounds on the [G-code practice page](/g-code-practice/), pays across both versions and every other standard-shaped controller a shop might run. The rewrite was real; it just happened almost everywhere except the part you type.

## Sources

- [Mach: official site](https://www.machsupport.com/)
- [LinuxCNC: G-code reference](https://linuxcnc.org/docs/html/gcode/g-code.html)
- [Wikipedia: Lua](https://en.wikipedia.org/wiki/Lua_(programming_language))

## Frequently asked questions

### How does Mach4 G-code syntax differ from Mach3?

Barely: both run the standard PC-controller subset, so motion, offsets, cycles, and the M-spine read the same and core programs move with normal care. The rewrite targeted architecture, scripting, and plugins, not the part-program language.

### What actually changed in the Mach3 to Mach4 rewrite?

The software underneath: a new architecture, Lua scripting replacing the older macro language, a different plugin model, and reworked screens. These matter for macros and customization, almost not at all for writing and running part programs.

### Will my Mach3 macros work in Mach4?

Generally not directly: Mach4 uses Lua, so macros and screen customizations are rewritten rather than copied. Part programs are separate and mostly carry over, so budget the migration time for the scripting and screens.

### Do my G-code skills transfer from Mach3 to Mach4?

Completely: the part-program language is the standard subset on both, and the same skills reach any standard-shaped control. The free G-Code Sprint app drills that portable core the rewrite left alone.

---

Source: https://gcodepractice.com/journal/mach4-g-code-syntax-vs-mach3/
Author: Lawrence Arya — https://www.linkedin.com/in/vibecoding/