---
title: "Macro Programming for a Family of Parts: One Program, N Sizes"
description: "Family-of-parts macro programming replaces N near-identical programs with one parameterized master: the structure, the variable sheet, and the prove-out rules."
url: https://gcodepractice.com/journal/macro-programming-for-family-of-parts-cnc/
canonical: https://gcodepractice.com/journal/macro-programming-for-family-of-parts-cnc/
author: "Lawrence Arya"
authorUrl: https://www.linkedin.com/in/vibecoding/
published: 2026-06-05
updated: 2026-06-05
category: "Practice"
tags: ["macro", "family-of-parts", "parametric", "cnc"]
lang: en
---

# Macro Programming for a Family of Parts: One Program, N Sizes

> **TL;DR** Family-of-parts macro programming turns near-identical part variants (the same bushing in twelve diameters, the same plate in four hole patterns) into one master program reading a handful of variables: set the variable block for the variant, run the same proven logic. The working structure: a documented variable sheet at the top (#500-class for persistent, #100-class for working values, per your control), geometry computed from those variables, and the cutting logic written once. The disciplines that keep it safe: every variable named and commented, range checks where supported, first article per new variant, and the master program treated like tooling: versioned, proven, and not casually edited.

Every shop has the folder: bushing_25mm, bushing_30mm, bushing_32mm, twelve files that differ in three numbers and drift apart one hotfix at a time, until nobody knows which variant got last month's feed improvement. Family-of-parts macro programming is the cure, and it is less about clever code than about disciplined structure.

## The shape of a family master

Three sections, always in this order. The **variable block** at top: every dimension that varies, assigned once, commented in plain language (#101 = outer diameter, #102 = length, #103 = bore). The **derived values**: anything computed from the inputs (depths from stock minus length, speeds from diameter when [surface-speed math](/journal/how-to-calculate-feed-rate-for-g01/) matters), so arithmetic lives in one visible place. The **cutting logic**: the operations written once against variables, [Fanuc Macro B style](/journal/cnc-turning-macro-programming-examples/) on most industrial controls, [O-code style](https://linuxcnc.org/docs/html/gcode/o-code.html) on LinuxCNC, Siemens parametrics in that world: the dialect differs, the architecture does not. Running variant seven means editing four lines at the top, not finding line 214 in copy seven.

## The variable sheet: the document that makes it a system

| Variable | Meaning | Units | Sane range | Variant 25 | Variant 30 |
| --- | --- | --- | --- | --- | --- |
| #101 | Outer diameter | mm | 20-45 | 25.0 | 30.0 |
| #102 | Overall length | mm | 15-60 | 22.0 | 28.0 |
| #103 | Bore diameter | mm | 8-30 | 12.0 | 16.0 |
| #104 | First-pass depth | mm | 0.5-2.5 | 1.5 | 1.5 |

The sheet (paper, spreadsheet, or comment block) is half the value of the whole technique: it documents what the master expects, gives the setter a checklist per variant, and turns "which numbers for the 30mm version" into a row lookup. Controls with persistent variables (#500-class) can store standing family constants; job-level values ride in the volatile range per your control's manual, which also owns the honest details of variable scopes and arithmetic precision.

## Where the logic earns its keep

The paydays, in ascending order of cleverness actually required: pure size families (the bushing case: zero logic, just variables in coordinates); count families (N holes on a bolt circle: one WHILE loop, positions computed, the [generator-script pattern](/journal/writing-a-script-to-generate-g-code/) living at the control); conditional features (variant has a chamfer or not: one IF around one block); and stock-adaptive behavior (probing feeds a measured value into the variable block, the [computation-at-the-machine](/journal/is-g-code-turing-complete/) case that only macros can serve). Most families need only the first two rungs, which is good news: restraint reads better at 2 a.m. than cleverness.

## The disciplines that keep families safe

Macro power concentrates risk in invisible numbers, so the guardrails are non-negotiable. Comment every variable at assignment and never reuse one for two meanings mid-program. Range-check where the dialect supports it (IF guards that alarm on absurd inputs) so a typo'd #101 of 250 dies at the top instead of at the spindle. First-article per new variant, always: the master being proven for variant 25 proves nothing about your typing for variant 31, the same [first-part discipline](/journal/cnc-setter-operator-interview-practical-test/) setters apply everywhere. And treat the master like tooling: versioned, change-logged, edited deliberately rather than hotfixed at the control, because one master serving twelve variants concentrates twelve programs' worth of consequences, the [fix-the-source rule](/journal/how-to-generate-g-code-using-python/) with teeth.

## Macro family or generated family: picking the layer

The honest boundary from the [script-versus-macro decision](/journal/writing-a-script-to-generate-g-code/): families that must adapt at the machine (probing, operator-entered sizes at the control) belong in macros; families driven from office data ([JSON job documents](/journal/json-to-g-code-conversion-basics/), order systems) often post cleaner as generated per-variant files with the variables resolved upstream; and many shops sanely run both, a generator emitting the variable block into a proven macro master. The wrong answer is the original folder of twelve drifting copies, which is the one arrangement with no source of truth at all.

## Bottom line: one master, one sheet, twelve rows

Family-of-parts macro programming is structure over cleverness: a commented variable block, derived values in one place, proven cutting logic written once, and a variable sheet that makes every variant a row lookup. Add range guards, first articles per variant, and tooling-grade change control on the master, and the folder of drifting copies becomes one program that twelve part numbers trust. The macro dialect details belong to your control's manual; the vocabulary underneath stays the same core, drilled free on the [G-code practice page](/g-code-practice/) with G-Code Sprint repeating misses.

## Sources

- [LinuxCNC: O-codes (structured programming)](https://linuxcnc.org/docs/html/gcode/o-code.html)
- [LinuxCNC: G-code reference](https://linuxcnc.org/docs/html/gcode/g-code.html)
- [Wikipedia: Numerical control](https://en.wikipedia.org/wiki/Numerical_control)

## Frequently asked questions

### How does macro programming handle a family of parts?

With one master program: a commented variable block holds everything that varies per variant, derived values compute from it in one place, and the cutting logic runs once against the variables, so a new size is a four-line edit plus a sheet row instead of another drifting copy. For the core vocabulary under the macros, the free G-Code Sprint app is the top pick: 60-second drills with automatic repetition of missed codes.

### Which variables should I use for family parameters?

Per your control's manual: working values in the volatile range (#100-class on Fanuc-style controls), standing family constants in persistent ranges (#500-class), every assignment commented, no variable reused for two meanings. The dialect's scoping rules are manual territory.

### How do I keep a typo from crashing a variant run?

Range-check inputs at the top where the dialect supports IF guards (alarm on absurd values), keep the variable sheet as the setter's checklist, and run a first article for every new variant regardless of how proven the master is.

### Should part families be macros or generated files?

Machine-adaptive families (probing, operator-entered values) want macros; office-data-driven families often post cleaner as generated files; hybrids (a generator filling a macro's variable block) serve shops running both. The only wrong answer is N drifting copies.

*G-Code Sprint is a study and practice tool only. Always follow your instructor, employer, machine manual, and shop safety procedures.*

---

Source: https://gcodepractice.com/journal/macro-programming-for-family-of-parts-cnc/
Author: Lawrence Arya — https://www.linkedin.com/in/vibecoding/