Causes by source
| Source | Typical cause | Symptom |
|---|---|---|
| Post selection | Wrong machine or controller post chosen | Wrong codes, alarms, unexpected motion |
| Controller mismatch | Post written for another series or option set | Unsupported codes, cycle alarms |
| Kinematics | Wrong rotary direction, pivot or limits | Wrong positions after rotation, over-travel |
| Units and format | Inch/mm mix, missing decimal points | Moves 25.4× or 1000× wrong |
| Modal state bugs | Post assumes a modal code is still active | Wrong plane, feed mode or offset after a tool change |
| CAM setup | Wrong WCS, offset number, tool number or length | Correct code, wrong place |
| Machine data | Wrong M-codes, tool change position, limits | Functions not activating, alarms |
A classic modal bug
G18 (previous op used XZ plane for arcs)
T5 M06
G00 X20. Y10.
G02 X30. Y20. I10. J0. (arc intended in XY - but G18 still active!)
(Fix: post always re-outputs G17/G18/G19 at each operation start)Diagnosing: post or CAM?
- Check the CAM toolpath in stock simulation. If it's wrong there, it's a CAM issue.
- If CAM is right, simulate the posted G-code. If that's wrong, it's a post issue.
- If both simulations are right but the machine differs, check machine data and offsets.
Prevention
- One approved post per machine, clearly named, under version control.
- Safe start blocks that restate modal codes at every operation.
- Built-in post checks for limits, speeds and tool ranges.
- CAM templates with correct WCS and tool data.
- G-code simulation for new posts and complex work.
Most incorrect G-code is predictable, and preventable with the right post design.
Fix incorrect G-code at the source
See our CNC post processor development service and post processor debugging.