Postprocessor

Postprocessor is the software that turns a CAM toolpath into the G-code that one particular machine will run, and it is the translator that lets the same CAM program serve the whole shop. CAM thinks in toolpaths — the cutter following a surface, the pocket clearing its island, the holes drilling their pattern — and it describes those paths in a way that is independent of any machine. But a machining centre does not run a toolpath; it runs a program in its own dialect of G-code, with its own formats, its own M-code numbers, its own habits of subprograms and cycles, and its own way of writing a header and an end. The postprocessor is the bridge: it takes the generic toolpath and writes it out as the specific, complete program the machine expects, applying every one of those local rules. This entry sets out what a postprocessor is, what it controls and why it matters.

The translator between CAM and machine

The postprocessor works at the end of the CAM session, and its job is translation. During programming, the software computes the toolpath without yet caring which machine will cut it — the same path could rough a pocket on a vertical machining centre or drive a different control that reads the same work. When the program is to be made, the programmer chooses the machine it is for, and the postprocessor that belongs to that machine takes over: it writes the program’s structure — its number, its opening blocks, its tool changes and its end — and it writes out the moves of the toolpath in the addresses, formats and codes that the machine’s control reads. The toolpath is the message and the postprocessor is the language it is translated into; the message is the same for every machine, and the translation differs for each one.

Why each machine needs its own

The need for a postprocessor is the need for translation: machines do not all speak the same G-code. The motion words of the common codes are widely shared, but beyond them the controls differ in ways that matter: the M-codes for coolant, spindle and tool change are numbered differently from one maker to another; controls differ in the format they accept for feedrates and positions, in the decimals and leading zeros they expect, and in whether they want arc data in one form or another; and machines differ in their axes, their toolchangers and their optional features, so a program for a simple three-axis mill is not a program for a five-axis machine or a mill-turn. A generic toolpath written as one machine’s code would fail on another — it would stop on an unrecognised code, run the wrong coolant, or misread a feedrate. The postprocessor exists to make each machine’s program in that machine’s own dialect, so that the shop can program once and run the path on whichever machine the job needs.

What a postprocessor controls

A postprocessor controls the whole surface of the program it writes, and its settings are a portrait of the machine. It writes the program’s opening and ending — the safety blocks that set the machine’s state, the program number and the final end code — in the form the shop wants. It decides how tool changes are written, how tool length and cutter compensation are called, and whether a canned cycle is written as the cycle or expanded into its individual moves. It formats the numbers: how many decimal places a feedrate carries, whether a position is written with or without trailing zeros, and what the control will read without complaint. And it carries the machine’s special rules — its axis configuration, its limits, the codes for its particular coolant or its fourth axis — so that the program matches the iron. Changing the machine, the control’s options or the shop’s conventions means changing the postprocessor, and the settings that were right for one machine are not right for another.

Postprocessors in the shop

In the running of the shop the postprocessor is set up once per machine and then trusted, but it is kept under watch. Each machine has its postprocessor configured for it, usually from the CAM maker’s library and adjusted to the machine — the programmer posts a test program, loads it on the machine and corrects what the control rejects, until the post writes code the machine accepts first time. From then on the post is part of the machine’s identity: a program is posted for the machine that will run it, and the machinist who reads the code can still recognise the post’s handwriting, and can spot when a program was posted for the wrong machine — the M-code that means something else, the format the control is stumbling over. The postprocessor is not a mysterious black box but a translator with known rules, and the machinist who reads G-code is the proof-reader who catches the translation’s errors before the machine does.

The bridge that makes CAM practical

The postprocessor is what makes CAM practical across a real shop, and it completes the chain that this programming group has described. The part’s model is programmed in CAM into toolpaths; the postprocessor translates the toolpaths into the program of the machine that will cut it; and that program is sent to the control, where it is loaded and proved, as the group’s later concepts describe. Without the postprocessor, every machine would need its programs written in its own code from the start, and the economy of CAM — program once, run anywhere the toolpath fits — would be lost. With it, the same toolpath becomes a clean program for every machine in the shop, written in each one’s dialect, in the format its control reads, with the codes its maker defined — the fundamentals of the language applied by a translator that the machinist understands and checks, standing between the CAM’s plan and the machine’s run.