Post-Processors & CAM Integration

Your CAM system does not speak your machine's language. It computes toolpath in a neutral, machine-agnostic form—CL data (cutter location data): tool positions, orientations, feeds, and events with no dialect attached. The post-processor is the translator that turns that neutral path into one specific machine's G-code—its cycles, its offsets, its format rules, its quirks. Everything this wiki documents per control—work offsets, canned cycles, modal styles, decimal-point rules—a post encodes as executable configuration. Which is exactly why a wrong post is so expensive: it does not break one program, it taxes every program, forever, until someone fixes it.

If someone in your shop edits posted code by hand at the control every morning, this page is about that. The edits are not the problem—they are the symptom.

What a Post Actually Decides

A post is not a find-and-replace on G-codes. It is a long list of decisions about how this shop's programs should look on this machine—and every one of those decisions has a failure mode you have probably seen on the floor:

Decision	How it goes wrong
Program header / footer—safe start line, program number style, end-of-program housekeeping	Post omits `G49`/`G80` from the start line; a leftover length offset from the last job drives the first rapid into the vise
Canned cycles vs longhand—emit `G83`, or expand every peck as G00/G01 moves	Longhand output triples the file size, defeats drip-feed, and hides the operation's intent from the operator
Work-offset strategy—`G54`–`G59`, extended offsets (`G54.1 P` / `G154 P`), or one offset plus `G52` shifts	Post hard-codes `G54`; the second fixture on the table cuts the first fixture's part
Tool-change sequence & safe retracts—how Z gets clear, whether the next tool pre-stages	Retract goes to `G53 Z0` on a machine where the post assumed `G91 G28`; the first tool change on a taller part hits the ceiling of the envelope—or the part
Arc output—`I J K` vs `R`, and whether arcs split at quadrant or plane boundaries	`R`-format arc at almost exactly 180° flips to the wrong side; full-circle arcs alarm on controls that require IJK for 360°
Drilling cycle mapping—which CAM cycle becomes which control cycle, and how parameters map	CAM's "chip break" posts as full-retract `G83` instead of `G73`; a 500-hole plate takes four times as long
Number format—decimal points, trailing zeros, coordinate rounding	Post drops the decimal point; on a Fanuc, `X25` without a point means 0.0025″ (or 0.025 mm)—the classic missing-decimal crash
Rotary axis handling—sign conventions, shortest-path vs signed direction, unwind moves	B posts positive where the machine counts negative; the 4th-axis part comes out mirrored—or the table winds up 720° and drags the coolant lines with it
Coolant & M-code timing—where `M08` lands relative to approach, which codes share a block	Coolant turns on after the tool is already in the cut; or an M-code the builder assigned differently on this machine fires the wrong relay

Every row in that table is a rule the control itself documents somewhere—and that this wiki covers per control. The post is where those rules stop being documentation and start being enforced automatically.

The Same Part, Five Dialects

To make it concrete: here is one identical operation—spot-drill two holes 14 mm deep—as five different posts would output it. Same CL data in every case. Only the post changes.

Fanuc (the ISO baseline—see G-Code Fundamentals and Canned Cycles). The cycle is modal: define it once, then just list positions, then cancel with G80:

G90 G54 G00 X25. Y25. S2400 M03
G43 H04 Z25. M08
G81 G99 Z-14. R2. F150.
X50. Y25.
G80

Haas speaks near-identical Fanuc dialect—the visible post difference here is the work-offset strategy. Beyond G54–G59, Haas uses G154 P1–P99 where Fanuc uses G54.1 P (see Haas Programming & Macros):

G90 G154 P10 G00 X25. Y25. S2400 M03
G43 H04 Z25. M08
G81 G99 Z-14. R2. F150.
X50. Y25.
G80

Siemens SINUMERIK in native mode has no G81 at all—drilling is a function call, CYCLE81(...), made modal with MCALL and canceled by a bare MCALL. A post targeting an 840D must choose between this native output and the control's Fanuc-compatible ISO mode (see Sinumerik Programming Basics):

T="SPOT_DRILL_6" M6
G54 G90 G0 X25 Y25 S2400 M3 M8
MCALL CYCLE81(25, 0, 2, -14)
X25 Y25
X50 Y25
MCALL

Heidenhain in Klartext looks nothing like any of the above: the cycle is defined with named Q-parameters, then triggered at each position by M99 on the move (see the Heidenhain Series Guide):

TOOL CALL 4 Z S2400
CYCL DEF 200 DRILLING ~
Q200=+2  ;SET-UP CLEARANCE ~
Q201=-14 ;DEPTH ~
Q206=+150 ;FEED RATE FOR PLNGNG
L X+25 Y+25 R0 FMAX M3 M99
L X+50 Y+25 R0 FMAX M99

Mazak EIA/ISO is again Fanuc-family G-code—G81/G80 work as expected—but a Mazak post still has real decisions to make: Mazatrol-vs-EIA program handling, builder-specific M-codes, and Smooth/Matrix-generation differences (see Mazak EIA/ISO Programming):

G90 G54 G00 X25. Y25. S2400 M03
G43 H04 Z25. M08
G81 Z-14. R2. F150.
X50. Y25.
G80

Five outputs, one operation. This is the entire reason the wiki is organized per control: the concepts are universal, but the spelling is not—and the post is the piece of software that owns the spelling. When the post gets a dialect rule wrong, the error shows up in every program that touches that machine.

Hand Edits Are a Smell

Here is the operational test of a healthy post: posted code runs as posted. If an operator opens every program at the control and makes the same edits before pressing Cycle Start—fix the header, swap the offset, move the coolant line—the post is wrong, and the shop is paying for it in a currency worse than time: every edit is untracked, unrepeatable, and one fat-fingered keystroke away from a crash. The edited program on the control no longer matches the file in CAM, so the next revision of the part silently reintroduces every "fixed" mistake.

Sort the edits your shop actually makes into two piles:

Recurring edits → they belong in the post. Header or safe-start-line changes, work-offset swaps, tool-change retract style, coolant timing, adding a G04 dwell before every rigid tap retract. If the same edit happens on the third program in a row, it is a configuration rule wearing an operator costume.
Legitimate one-offs → fine at the control. Proving out a new setup single-block, dropping a feed by feel in a nasty material, bumping an offset for this batch of castings. These are judgment applied to one part on one day—exactly what an operator is for.

And treat the post itself like the production asset it is: version the post, not the edits. Keep post files under version control (or at minimum dated copies with a change log), note why each rule changed, and make sure every seat of CAM posts with the same revision. A shop with five programmers and five slightly different copies of "the Haas post" has five dialects of its own machine.

5-Axis and the Post

On a 3-axis mill, a bad post wastes time. On a 5-axis machine, the post is doing genuine kinematics, and the failure modes get physical:

TCP on or off. With tool center point control active (Fanuc G43.4, Siemens TRAORI, Heidenhain M128/FUNCTION TCPM), the control compensates rotary motion at the tool tip and the post can output tip coordinates. Without it, the post must bake the machine's pivot lengths into every point—and a program posted for one machine is wrong on every other machine, and wrong on the same machine after a tool length change.
TWP vs raw rotary angles. For 3+2 work, a good post outputs a tilted work plane command (G68.2, CYCLE800, PLANE SPATIAL) and lets the control derive the rotary positions; a lazy post positions the rotaries raw and shifts offsets by hand-computed values that break the moment the fixture moves.
Kinematic model correctness. The post carries a model of the machine—which axis carries which, pivot distances, rotary zero orientations. If that model does not match the iron (or the control's own kinematic table), every tilted move is subtly wrong in a way a backplot will not show.
Singularity handling. Near the pole (e.g. A0 on a table/table machine), a tiny tool-vector change demands a huge C move. The post decides whether to reorder, dwell, linearize through, or alarm—the wrong choice leaves a dwell mark or whips the table mid-cut.
Linearization tolerance. Between output points, the machine's rotary+linear interpolation does not follow the CAM path exactly. The post's linearization tolerance decides how densely to fill points—too loose gouges walls, too tight floods the control with microscopic blocks.

The mechanisms behind all of these—TCP, tilted work planes, and how each control family implements them—are covered in 5-Axis: TWP & TCPM.

Verifying a Post

A new or modified post is guilty until proven innocent. This is a practical acceptance pass—cheap to run, and it catches the large majority of post defects before they reach the spindle:

Backplot the posted file against CAM. Load the output G-code into a backplotter (or the control's graphics) and overlay it on the CAM toolpath. They should be indistinguishable; investigate any divergence, however small.
Single-block a proven part. Post a part the shop has already made successfully with the old workflow and run it single-block, comparing behavior move by move—not just the finished dimensions.
Exercise every cycle the post can emit. Drill, peck, chip-break, tap, bore—confirm each maps to the intended control cycle with the intended retract behavior (G98/G99, return-plane parameters), not just "a hole appeared."
Cut arcs in all active planes and directions. CW and CCW, crossing quadrants, full circles, and G18/G19 arcs if the machine uses them—arc formatting bugs hide in the cases nobody posts on day one.
Verify rotary sign conventions physically. Command a small positive move on each rotary axis and watch which way the table (or head) actually turns before trusting any indexed work.
Test inch and metric both if the shop runs both—number formatting, feeds, and cycle parameters can be correct in one unit system and wrong in the other.
Dry-run any macros or probing blocks the post emits. If the post injects probe calls, tool-breakage checks, or shop macros, run them empty first—a wrong argument in a probing call moves real hardware. (See Intro to CNC Macros.)

Write the checklist results down. The point of an acceptance pass is that the next post revision only has to re-verify what changed.

Machine Simulation and Digital Twins

A CAM backplot verifies the toolpath CAM intended; it never sees the posted code. Post-aware machine simulation—Vericut-class G-code simulators, and increasingly the control-embedded digital twins shipped by the control makers themselves—runs the actual output file through a software copy of the control logic and a solid model of the machine, fixtures, and stock. That is the only pre-run tool that catches the specifically post-shaped failures: a cycle that retracts to the wrong plane, a rotary unwind that sweeps the head through the tailstock, a tool-change retract that clears the part in CAM's world but not on this machine's travels. For 5-axis work or expensive one-off parts, simulating the posted code is not gold-plating—it is the last inspection step before the machine becomes the test fixture.

References

CAM vendor post-processor documentation (e.g. Autodesk Post Processor Reference, Mastercam Post Development Guide, Siemens NX Post Builder / Post Configurator documentation)—each documents the same decision surface described on this page for its own post format.
Control programming manuals per family (Fanuc, Haas, Siemens SINUMERIK, Heidenhain, Mazak)—the authoritative source for the dialect rules a post must encode; see the per-control articles across this wiki.