If your shop routinely edits G-code by hand before running it, that is not normal friction to be tolerated — it is a post-processor that does not match your machine. And every manual edit is a chance to crash something expensive.
What a post-processor actually does
Inside CAM, a toolpath is machine-agnostic: a sequence of positions, feeds, and operations expressed abstractly. The post-processor translates that into the specific dialect your controller speaks.
| CAM's internal intent | What the post must decide |
|---|---|
| "Move to this point at this feed" | Format, decimal places, modal or explicit G-code |
| "Change to tool 4" | The exact tool-change sequence this machine requires |
| "Use this work coordinate system" | G54–G59, extended offsets, or machine-specific scheme |
| "Drill a hole, peck cycle" | Which canned cycle, and whether it is supported at all |
| "Rotate the A axis" | Sign convention, shortest path, unwind behaviour |
| "Start the spindle" | Order relative to coolant, dwell for spin-up |
Why generic posts break
Controller dialects genuinely differ
Fanuc, Siemens, Heidenhain, Haas, Mazak and Okuma each have their own conventions for cycles, offsets, subprograms and macro programming. A program that runs cleanly on one may be rejected, or worse silently misinterpreted, on another.
Machine configuration is not just the controller
Two machines with identical controllers still differ: table-table versus head-head rotary configuration, axis travel limits, tool-change position, whether the fourth axis unwinds, spindle orientation for tool changes. The post must encode the machine, not just the control brand.
Undocumented behaviour
Every machine has quirks nobody wrote down — a cycle that behaves differently near a limit, an offset that must be commanded before a particular move, a dwell required after a specific operation. These are learned on the floor, and they are exactly what a generic post cannot know.
The dangerous failure is the silent one. A rejected program is inconvenient. A program the control accepts and interprets differently than intended — wrong offset, wrong plane, wrong rotary direction — moves the machine somewhere unexpected at rapid feed. That is the case a proper post-processor exists to prevent.
The parts that most often need customising
- Tool change sequence — the exact order of retract, orient, change, restart, and coolant.
- Work and tool offsets — which scheme, and when it is applied.
- Canned cycles — which are supported, and what to emit when one is not.
- Rotary handling — sign conventions, shortest-path decisions, and unwind logic.
- Program header and footer — safe start block, units, plane selection, safe end state.
- High-speed / look-ahead modes — the smoothing commands your control supports.
- Comments and operator messages — formatted so the control accepts them.
- Number formatting — decimals, leading zeros, and modal suppression.
How a post gets built properly
- Collect known-good programs that already run correctly on the machine. These are the specification.
- Document the machine configuration — kinematics, travel, tool change position, supported cycles.
- Interview the operators. They know the quirks, and that knowledge exists nowhere else.
- Write the post and compare its output line by line against the known-good programs.
- Dry-run on the machine — no material, generous clearance, single block, hand on the feed hold.
- Cut air, then cut material, then verify dimensions on the finished part.
- Lock it down with version control and a documented change process.
Step 5 is not optional and cannot be shortened. A post-processor is not finished when the G-code looks right in a text editor. It is finished when it has been proven on the actual machine. Budget commissioning time explicitly — it is where the real quirks surface.
What it is worth
If a programmer spends fifteen minutes editing every program, and you run ten programs a week, that is over 100 hours a year spent on manual correction — plus the risk that one edit is wrong.
Beyond the time, a correct post removes a category of risk: hand-edited G-code is unreviewed G-code, and the failure mode is a machine crash rather than a compile error.
When you need a custom post rather than a tweak
- Your machine has non-standard kinematics the generic post cannot express.
- You use cycles or macro programming the stock post does not emit.
- You are a machine builder shipping machines and need a post your customers can rely on.
- You are embedding CAM in your own product and must generate correct output automatically.
- Manual editing has become a routine step rather than an exception.
Editing G-code by hand more often than you would like? Tell us the machines and controls involved — we write and floor-verify post-processors. See our CAM software service.