Macro programming gives G-code a memory, and the memory comes in neighborhoods with different evictions policies. The numbers look arbitrary, #1, #101, #501, until the organizing idea lands: the range is the lifespan. Choose by how long the value must live, and most variable mysteries never happen.
The three neighborhoods
| Range | Name | Lifespan | Typical use |
|---|---|---|---|
#1-#33 | Locals | One macro call | Arguments, scratch math |
#100-series | Common (volatile) | Until power-off | Within-job shared values |
#500-series | Common (permanent) | Survives power-off | Counters, calibration |
Two footnotes belong on the table. #0 is the null variable, always empty, and assigning to it is how values get cleared. And exact range sizes and retention behavior vary by control model and installed options, so the table is the standard shape, while your machine’s manual is the standard’s local enforcement.
What makes locals special?
Scope, and the argument mapping. When a program calls G65 P9010 A5. B2., the letters land in locals by fixed assignment, A into #1, B into #2, and so on, which is how a macro receives its inputs. Each call level gets fresh locals, nested calls do not trample each other, and everything evaporates when the call returns. That makes locals perfect for what they are for, internal math, and wrong for everything else: a value stored in #5 with hopes for tomorrow was gone before the spindle stopped. The same scoping logic, in different syntax, runs LinuxCNC’s named parameters in O-code subroutines, and the call-and-return structure underneath is the M98 and M99 subprogram pattern wearing macro clothes.
When do the #100s earn their keep?
Whenever two programs or macros must share a value within a running session. A probing routine measures a boss and parks the result in #110; the finishing program reads #110 and compensates; both forget gracefully at shutdown because the value was only ever today’s news. That volatility is a feature in shops that treat it as one, and a trap in shops that do not, which brings up the classic failure.
Why do counters belong in the #500s?
Because Friday exists. The canonical mistake stores a parts counter in #101, watches it work flawlessly all week, and discovers Monday that the weekend power-down cleared it to zero, along with the probe calibration value that lived in #115. Permanents survive power cycles by design, which makes the #500-series the home of anything with a future: production counters of the kind built in the turning macro examples, tool-change tallies, probe offsets, and per-fixture constants. The discipline that keeps permanents useful is a shop allocation map, a posted list of which #500s mean what, because every program on the machine sees the same neighborhood, and two macros squatting on #510 debug each other forever.
How do you keep the system honest?
Three habits, all cheap. Comment every non-local variable at first assignment, #510 = 0 (insert change counter, see board). Initialize deliberately rather than trusting leftovers, since commons remember whatever the last job left unless cleared. And when a stored value misbehaves, check lifespan before suspecting corruption: vanished means volatile range plus a power cycle, persisted-when-it-should-not-have means a permanent nobody reset. The system variables above the user ranges, machine positions, offsets, and modal state, follow the same read-the-manual rule with higher stakes, and the parameter documentation in LinuxCNC’s O-code reference shows the same architecture from the open-source side, with the quick lookups living in the usual code references.
Bottom line
The range is the lifespan: locals #1-#33 live one call and carry arguments, #100-series commons share within a session and clear at power-off, #500-series permanents survive for counters and calibration. Map your #500s on the wall, comment first assignments, and diagnose vanishing values as lifespan mismatches first. The plain-code foundation under all of it drills free on the G-code practice hub.
Sources
- LinuxCNC O-code and parameter documentation
- LinuxCNC G-code reference
- CNCCookbook: G-code and M-code reference
Frequently asked questions
What is the difference between #100 and #500 variables?
Lifespan: #100-series commons clear at power-off on most controls; #500-series permanents survive power cycles, so counters and calibration values belong there.
What are the #1 to #33 local variables for?
Scratch space inside one macro call and the landing spots for G65 arguments (A to #1, B to #2). They reset between calls.
Why did my macro counter reset to zero?
It lived in a volatile #100-series variable through a power cycle. Move it to a #500-series permanent and it survives shutdowns.
What is the best way to learn macro variables and the codes around them?
Make the plain-code layer reflex first. A free app like G-Code Sprint drills the everyday codes and repeats whichever ones you miss; the variable ranges are then three facts on top.
G-Code Sprint is a study and practice tool only. Always follow your instructor, employer, machine manual, and shop safety procedures.