CNC Macro Programs: How Formulas Become Cutting Motion

• 1
  What a CNC macro program actually is
• 2
  Variables, arithmetic, and branching inside the control
• 3
  When a macro beats CAM, and when it does not
• 4
  Chord error, step size, and surface finish
• 5
  Where macro programs go wrong on the shop floor
• 6
  Macro program vs CAM toolpath

A standard G-code program is a list. Line 1 sends the tool somewhere, line 2 sends it somewhere else, and the control never computes anything on its own. A macro program is different. It contains arithmetic, conditional branches, and variables, so the control calculates positions while the cycle runs.

The classic example is an ellipse. There is no G-code for an ellipse. Without a macro you would sit with a calculator and build the curve point by point, then approximate it with short straight moves. With a macro you write the parametric equation once, and the control generates every point on the fly at whatever step size you choose.

That is the whole idea. The programmer supplies the rule, the machine supplies the coordinates. Fanuc calls this Macro B. Haas, Mitsubishi, and Siemens controllers have equivalent systems with different syntax.

It matters because a macro is reusable. Change one variable, and the same program cuts a different size part. A CAM toolpath is fixed geometry. That difference decides which one you should use.

Macro systems use numbered variables. Local variables (#1–#33) live only inside a single call and are wiped when the subroutine ends. Common variables (#100–#199 and #500–#999) persist across calls, and on most controls they survive a power cycle if you keep them in the #500 range. A value written to #500 is still there tomorrow morning.

Arithmetic is straightforward: #101 = #102 * 2, or #103 = SQRT[#104]. Trigonometry functions such as SIN and ATAN let you solve for a point on a circle or a lead-in angle. Comparison and branching (IF, GOTO, WHILE) let the program repeat a pass until a counter reaches zero.

The control executes this at block-processing speed, which is fast but not free. A WHILE loop that generates thousands of tiny linear moves will be limited by the machine's block processing rate, not by the servo. That ceiling is the single most common reason a macro cycle runs slower than the programmer expected.

System variables are where macros touch the machine itself. Reading a system variable gives you the current tool offset, the active work coordinate, or the remaining travel. Writing one changes it. That power is also the risk, since a wrong write can shift an offset without any alarm.

• 1
  Local variables#1–#33, cleared when the subprogram returns
• 2
  Common variables#100–#199 volatile, #500–#999 retained
• 3
  System variablesRead or write offsets, coordinates, and machine state

Macros win on families of parts. If you machine the same bracket in twelve lengths, one macro with a length variable replaces twelve CAM files and twelve setups of proofing. The same applies to bolt circles, pocket arrays, and chamfer routines that repeat across a shop.

They also win on geometry that is easy to describe mathematically and painful to model. Ellipses, parabolas, spiral grooves, and non-circular bores fall into this group. So do probing routines that must decide something at runtime, such as finding a rough casting's actual position and shifting the work coordinate accordingly.

CAM wins on free-form surfaces. A five-axis impeller or an organic medical housing has no compact equation. Sending a hundred thousand points through a macro loop is slower and harder to verify than posting a toolpath.

The deciding question is simple. Can you write the shape as a formula with a handful of inputs? If yes, a macro is usually shorter and easier to revise. If no, use CAM.

A macro approximates a curve with straight segments. The gap between the true curve and the straight line is chord error, and it is set by your step size. Halve the angular step and you roughly quarter the chord error, but you double the number of blocks.

On a part that needs Ra 0.8–1.6 μm, the step size has to be small enough that the scallop height stays under the finish requirement. For a Ø100 mm arc, a 1° step already produces visible faceting on a polished surface. A 0.1° step does not, but it multiplies the block count tenfold.

This is the trade you are making. Tighter geometry costs cycle time. On a control with a modest block processing rate, a very fine step can starve the servos and leave witness marks even though the math is correct.

For our own work at ±0.005 mm, we usually generate the coarse curve with a macro and let a finishing pass clean up the scallops. That keeps the cycle short without gambling on the surface.

The first failure mode is an uninitialized variable. If a common variable from a previous job still holds a value, the macro happily uses it. A pocket that should be 40 mm deep comes out 40 mm plus whatever was left in #501. Always clear or explicitly set variables at the top of the program.

The second is a loop that never exits. A WHILE condition that depends on a value the loop itself changes can run forever, or until the control faults. Add a hard counter and a maximum iteration limit.

The third is offset corruption. Writing to a system variable that controls tool length or work shift can move the part without an alarm. Restrict writes to a known set of variables and log them.

None of these are exotic. They are ordinary programming discipline. A macro is only as safe as the person who wrote the variable table.

• 1
  Clear common variablesSet #500–#520 to zero at program start
• 2
  Cap every loopAdd an iteration counter with a hard ceiling
• 3
  Limit system writesOnly touch offsets you have documented