Basics of CNC Postprocessor: Turning Toolpaths into Machine Code
This page explains what a postprocessor actually does between CAM software and a machine controller, and where it goes wrong. It is written for process engineers and programmers who review G-code before a part is cut. After reading, you should be able to tell whether a post is correctly matched to a machine, and when to stop and fix it.
What the rest of this page covers
A postprocessor is a translator with a strict contract: it must output code the controller accepts and the machine can physically follow.
What a CNC postprocessor is, and is not
CAM software plans toolpaths in a neutral space. It knows the shape of the cut, the cutter, and the order of operations, but it does not know which machine will run the job. A postprocessor is the layer that maps that neutral path onto one specific machine and controller. Get the mapping wrong and the machine will either refuse the code or, worse, follow it.
Think of it as a translator with a strict contract. On one side sits CL data or an internal toolpath format. On the other sits the exact syntax a Fanuc, Siemens, Heidenhain, or Mitsubishi control expects. Nothing in between is optional: feed rates, tool change macros, coolant commands, work offsets, and safe retract positions all have to be written the way that control reads them.
It is not a simulator and it is not a verification tool. A postprocessor assumes the toolpath is already correct. It does not check for gouges, collisions, or thin walls. Those checks belong upstream in CAM or downstream in verification software. Confusing the two is how good programmers ship bad code.
It is also not portable. A post tuned for one machine rarely transfers cleanly to another, even of the same model. Spindle warm-up routines, tool setter positions, and rotary axis directions differ. Treat every post as machine-specific, and version it like any other controlled document.
- 1InputCL data or CAM internal toolpath, machine-independent
- 2OutputG-code in the dialect of one specific controller
- 3ScopeOne post per machine and controller combination
- 4Not its jobCollision checks, gouge detection, toolpath strategy
What the postprocessor actually writes
Every post handles the same core set of tasks, even if the syntax differs. It writes the header block with program number, units, and work offset. It emits the tool change sequence, including spindle orientation and length offset call. It converts feed rates into the units and modal form the control expects. It inserts coolant on and off, rapid moves to safe Z, and the end-of-program block that parks the machine.
The harder work is in the details. Rotary axis output needs to match the machine's physical configuration, not just its nominal type. A trunnion table and a swivel head both call themselves 5-axis, but they resolve tool vectors differently. If the post assumes the wrong configuration, the part will be cut at the wrong angle even though the code runs without an alarm.
Feed rate handling is another quiet failure point. Some controls interpret F in inverse time, some in units per minute, some in units per revolution. A post that writes the wrong mode will produce a machine that either crawls or slams. Neither shows up in a dry run without material.
Tool change logic is where posts earn their keep on production machines. A safe tool change needs the spindle stopped, oriented, retracted clear of fixtures, and the correct offset active before the next move. On a 4,000 mm machine with a Ø400 mm rotary table, that retract distance is not trivial. The post has to know the real travel limits, not the catalog numbers.
- 1Header and footerProgram number, units, work offset, safe park
- 2Tool changeSpindle orient, retract, offset call, coolant
- 3Feed modesInverse time vs units per minute vs per revolution
- 4Rotary outputMust match trunnion or swivel-head kinematics
Why 5-axis posts are harder than 3-axis posts
A 3-axis post is mostly a formatting job. The tool axis never changes, so the only geometry question is whether the machine can reach the point. A 5-axis post has to solve the inverse kinematics problem: given a tool tip position and a tool vector, what rotary angles put the tool there? That solution depends on the machine's physical layout, the pivot distance from the rotary center to the spindle face, and the direction of each axis.
Two machines can share the same controller and still need different posts. One might have the C-axis on the table and the A-axis on the head, the other the reverse. The same CAM file will produce different rotary values on each. Programmers who assume otherwise usually find out when the first article comes off the machine with a chamfer on the wrong edge.
Singularities are the other 5-axis problem. When the tool vector lines up with a rotary axis, the required rotary speed approaches infinity. A good post detects this condition and either repositions the tool or splits the move. A post that ignores it will output a rotary move the machine cannot physically follow, and the control will either alarm or stutter through the cut.
On our 16 simultaneous 5-axis machining centers, posts are tuned per machine and re-verified after any mechanical change. A rotary table that has been re-clamped or a spindle that has been replaced changes the pivot distance. The post has to be updated to match, or the first article will drift.
Choosing and validating a post
Start with the controller, not the CAM brand. Most CAM vendors ship a library of generic posts, and generic means someone else's machine. A generic Fanuc post will run on a Fanuc-controlled mill, but it will not know your tool setter position, your fixture height, or your safe retract plane. Those gaps get filled by the programmer at the machine, which is where errors enter.
The better route is a machine-specific post built from the actual parameter set. That means documenting the rotary axis directions, the pivot distances, the travel limits, and the tool change macro. It also means testing on a proven part before it touches a customer job. A post is not validated until it has cut metal and the part has been inspected.
For new parts, we run a first-article check before releasing the program to production. The post output is reviewed against the CAM simulation, then the part is cut and measured. If the rotary values or the tool change sequence are off, it shows up here, not on a finished batch.
When a post cannot be validated, the right answer is usually to fix the post, not to hand-edit the G-code. Manual edits are not repeatable and they hide the root cause. We treat post changes as controlled revisions, so the next job benefits from the fix.
- 1Build from parametersRotary directions, pivot distances, travel limits
- 2Test on proven partCut metal and inspect before customer work
- 3Avoid manual editsNot repeatable, hides the real problem
- 4Version controlTreat post as a controlled document
Post complexity by machine type
This table shows where post work concentrates as machine capability increases.
| Machine type | Post complexity | Main risk | Validation effort |
|---|---|---|---|
| 3-axis mill | Low, mostly formatting | Wrong work offset or retract | One proven part |
| 4-axis mill | Moderate, one rotary axis | Rotary direction and wrap | Two parts, two orientations |
| 5-axis trunnion | High, inverse kinematics | Pivot distance error | First article plus tilt test |
| 5-axis swivel head | High, different kinematics | Tool vector sign error | First article plus tilt test |
| Mill-turn | High, two process modes | Mode switch and offset carry | Sequenced test parts |
Common questions
Can I use one postprocessor for all my machines?
Not reliably. A post is tied to a specific machine and controller combination. Even two machines of the same model can have different tool setter positions, rotary directions, or travel limits.
You can maintain a family of posts that share a common base, but each machine needs its own validated version before it runs production work.
Why does my 5-axis post produce the wrong angle?
The most common cause is a mismatch between the post's assumed kinematics and the machine's real configuration. A trunnion table and a swivel head resolve tool vectors differently, and a post built for one will not work on the other.
The second most common cause is an incorrect pivot distance. That value is measured from the rotary center to the spindle face, and it changes when the machine is rebuilt or a spindle is replaced.
Is a postprocessor the same as a simulator?
No. A postprocessor writes code. A simulator checks code and geometry for collisions, gouges, and overtravel.
They work together. Run the post, then verify the output in a simulator before the job goes to the machine. Skipping either step shifts the risk to the spindle.
How often should a post be re-validated?
After any mechanical change to the machine: spindle replacement, rotary table re-clamping, or a control software update. Also re-validate when the post itself is edited.
For machines in continuous production, a periodic check on a known part is cheap insurance. It catches drift before it reaches a customer order.
Can you build a post for a machine we already own?
In most cases, yes. We need the machine model, the controller, and the parameter set that defines the rotary axes and travel limits.
The post is then tested on a proven part before it is used on customer work. If you have an existing post that is misbehaving, we can review the output and identify where it diverges from the machine.
What tolerance can a well-tuned post hold?
The post itself does not set tolerance. It translates the toolpath the CAM system produced. On our machines, we hold ±0.005 mm on features that the process supports, and finishes from Ra 0.2–0.8 μm when the geometry allows.
If the post is wrong, you will not hit those numbers. That is why we validate the post before the first article, not after.
Send us your part and machine details
We review your geometry, material, and machine configuration, then quote with a free DFM analysis within 12 hours.
12-hour quote100% inspectionNDA on request
