What is Post-Processing?

In the early days of post-processing, a post-processor was considered an interface tool between computer-aided manufacturing (CAM) systems and numerically controlled (NC) machines – a mere translator, reading the manufacturing instructions issued from a CAM system and writing an appropriate rendition for a target NC machine. Today however, post-processing has evolved to include a dynamic range of code optimization tools which are responsible for outputting the most efficient and productive machine tool code possible.

NC post-processing

NC post-processing is responsible for joining two very different technologies, and it often serves to compensate for weaknesses on either end. Therein lies the crux of the issue: a post-processor can enhance technology, or it can inhibit it, depending upon its application.

To understand how a post-processor can enhance technology, it helps to understand how and why post-processing evolved, how it has been traditionally applied, and how the emergence of advanced post-processing systems has changed the way it is used today. This article will show how post-processors can be used as key components in factory automation.


What is a Post-Processor?

Most CAM systems generate one or more types of neutral language files containing instructions for a CNC machine. These are either in a binary format called CLDATA or some ASCII readable format tailored after the APT language. APT is an acronym for “Automatically Programmed Tools,” software that accepts symbolic geometry and manufacturing instructions, and generates CLDATA describing the manufacturing operation in absolute terms. Some CAM systems provide a large degree of flexibility, allowing just about anything to be included in the neutral file, others are quite strict about what can and cannot be included.

At the other end of the equation sits the NC machine. It requires input customized for the controller being used and arguably to a lesser extent, the operator running the machine. Most important, the NC machine must be driven in a manner that satisfies shop floor criteria, which are primarily based on safety, efficiency and tradition.

Between these two lies the post-processor. The post-processor is software responsible for translating neutral instructions from the CAM system into the specific instructions required by the NC machine (Figure 1). This software responds to the unique requirements and limitations of the CAM system, NC machine and manufacturing environment. Therefore, post-processing is an important part of factory automation, as is anything that lies on the critical path between the design engineer and the shipping department.

Enter Post-Processing

Post-processors can do many other things besides translating CLDATA to NC machine codes. For example a post-processor may summarize axes travels, feed and speed limits, job run-time and tool usage information, which enables better selection and scheduling of resources.

More sophisticated post-processors may validate the program before it is run by the machine tool. There are many simple rules that a post-processor can follow, with warning messages displayed when these rules are violated. Some examples: Noting if a tool is not selected near the start of the program, warning when motions at feed rate are done with a stopped spindle, flagging long series of positioning moves, or conversely, flagging feed moves at or above the program clearance plane, or noting if diameter or length compensation switches are not changed when a tool is.

Beyond simple validation comes correction. There are many situations where a post-processor can detect an error and correct it. Examples include: cycles left active during a tool change (they should be temporarily cancelled), selecting an incorrect or nonexistent spindle gear range (the post-processor should select a range that supports the speed), or specifying an unavailable coolant type (the post-processor should select the next best type).

The best post-processors maintain a global picture of the entire job at all times, using upcoming events to help make decisions about current ones. The NC programmer uses this information to optimize the job without intervention. For example: pre-selecting the next tool as soon as physically possible, segmenting a tape at a tool change if the entire upcoming tool path will not fit on the current reel, selecting a spindle gear that best fits the current and subsequent speed requirements, or switching intelligently between parallel axes (Z and W) based on the types of upcoming operations and available travel limits.

Post-processors can also work around limitations and bugs in the CAM system or in the machine tool. It is generally far easier to change the post-processor than it is to get a new revision of the CAM system, or a new executive revision for the NC controller.

The important point to be made here is that the NC programmer should not be concerned about machine tool or machine operator idiosyncrasies that do not directly affect the production of a job. Wherever possible, good post-processors should hide these details within.

Standard CAM systems, standard NC machines, standard CLDATA and standard post-processor vocabulary can not all be mixed together to instantly produce a working system. There are too many variables in the real world, and standards are too restricted in scope, to achieve integration with off-the-shelf components.

Is this all starting to sound familiar?

It really makes no difference if the interface between CAM and NC is unified or not. Market pressures will ultimately create incompatibilities, and software will be necessary to bridge the gap. The only question left to answer is, what software?

What Might Have Been

But let us suppose for a moment that a single unifying solution had been created in a reasonable time frame, and that a significant number of CAM companies and NC controller manufacturers agreed to do things differently for the common good. What then?

Time passes and CAM and NC vendors soon realize that a single unifying solution does not account for competitiveness. There are at least three ways a new feature (such as probing) can be brought to market in this environment. One is to revise the standard first, then provide this feature to customers at a suitable point after the standard is next published. The second is to provide the feature to customers first, then press for standardization later. The third is to ignore any effort to standardize company proprietary information and get the feature to market as quickly as possible.

No contest. The feature goes to market as quickly as possible.

Now things get a little more complicated. If the feature is an NC one, how will the customer’s CAM system access it, and vice versa? The standard has to be extended on both sides of the interface to make the feature work. The CAM and NC vendors must both agree to incorporate nonstandard functionality to allow access to this new feature. Who will profit? Will both profit equally?

It would be more likely that some sort of pre-processor would be required to change the output of the CAM system to satisfy the input requirements of the NC machine. Besides, a pre-processor is probably already needed to handle binary format conversions between the CAM system computer and the NC controller. Initially the conversion will be simple, but as time goes on and deviations from the standard continue, the conversion will become more complex, perhaps to the point where different pre-processors might be required for different NC machines.

Who will provide the pre-processor, especially if both the CAM system output and the NC machine input contain extensions to the standard? What happens when a revised standard appears, or a CAM vendor leaves the market, or the computer manufacturer tells you that the computer you are using is obsolete and not object-compatible with the newest model?

A Historical Perspective

People often ask if post-processors are really needed, wondering if perhaps the whole issue has been perpetrated on the unsuspecting by unscrupulous software houses! In fact, there really isn’t a conspiracy, just a lot of practicality. International standards (ISO) as well as national standards (ANSI, EIA) define both an output format for CAM systems and an input format for NC machines. These two formats, output and input, differ significantly.

Why not one standard, one format? Standards are more often than not based on existing practice. They serve to define a single method from a host of possible choices, all of which are generally rooted in actual practice. Standards that go against common practice do appear from time to time, but they are hard to justify, difficult to create and slow to be accepted. They also require a lot more dedication and effort than most people are willing to volunteer.

So when the proliferation of competing APT systems warranted a standard to help define and control the format of its inputs and outputs, standards were created defining the core elements required for manufacturing. Similarly, the proliferation of controllers also demanded some uniformity, and NC control language standards were created defining the core practices of industry.