Plain G-code runs the same moves every time. Macro variables give a program memory: it can count parts, compare a measured size against a limit, or pick a different path — and leave the result somewhere other software can read.
The variable ranges
On many controls the numbers are grouped like this. Exact ranges vary between control makers, so treat this as a typical layout, not a rule.
#1–#33
- Type
- Local — arguments passed into one macro call
- Kept after power-off?
- No
#100–#199
- Type
- Common — shared by all programs
- Kept after power-off?
- No
#500–#999
- Type
- Common, retained — battery-backed
- Kept after power-off?
- Yes
#1000 and up
- Type
- System — set by the control (offsets, tool, alarms)
- Kept after power-off?
- Control-managed
| Range | Type | Kept after power-off? |
|---|---|---|
| #1–#33 | Local — arguments passed into one macro call | No |
| #100–#199 | Common — shared by all programs | No |
| #500–#999 | Common, retained — battery-backed | Yes |
| #1000 and up | System — set by the control (offsets, tool, alarms) | Control-managed |
What shops use them for
- Part counting —
#777=#777+1before the program end - Tool life — a target and an actual count per tool, updated each part
- Probing and gauging — writing a measured value straight into an offset
- Family-of-parts programs — one program, with sizes held in variables
Reading macro variables from outside
Many controls let networked software read macro variables while a program runs. ThingConnect reads the variables you choose for each machine about once a second. If a machine counts parts in a macro variable instead of its standard counter, that variable can be set as the machine’s part count, so cycle time and output reports work the same as on every other machine. Per-tool counters in macro variables feed tool life monitoring.