What's Wrong with Postprocessors?

 Without a doubt, the most important file produced by any CAM system is the NC program that will run the machine tool. Yet, surprisingly, surveys taken of CAM users indicate that producing an appropriately formatted NC program remains one of their most perplexing problems. After over 30 years of computer assisted NC programming, why does there still seem to be a missing link between CAM systems and the machine tools they are suppose to run? How can this missing link be found?

How NC Programs Are Created

To answer these questions, let's first take a look at how NC program files are created. General purpose CAM systems produce programs to run a variety of different types of NC machines including two-axis lathes; three-, four- and five-axis mills; wire EDM machines; punch presses; and turn/mill machines. In addition, there is virtually an unlimited number of machine and control combinations. 

To accommodate this large variety of output requirements, most CAM systems produce a neutral tool path file. That is, the file is not intended for any specific machine but simply contains generic commands to do such things as change a tool or turn on the coolant. The neutral file also contains the X-Y-Z coordinate data of the cutter path and, in the case of four- and five-axis applications, it includes tool angle vectors as well. This neutral file traditionally has been referred to as the CL (cutter location) file. 

A separate program, generally referred to as the postprocessor (because processing takes place after the tool path has been generated), is used to format the neutral CL file into an NC program that is suitable for a specific machine/control combination. This can be thought of as being similar to a printer driver, where a single word processing application is required to print to a variety of different printers. 

So why isn't producing a good NC program as easy as printing a file?

Machine control units are encouraged to follow certain standards (EIA/ISO) for machine control program-ming. As a result, certain codes mean the same thing regardless of the machine being programmed. For example, an M08 code means to turn on the coolant. Most machine tool builders do a reasonable job of following the standards for basic functions such as turning on the coolant, loading the tool or producing circular movements. However, when it comes to more specialized functions such as drilling and probing cycles, adherence to a specific standard is nearly non-existent. The program codes required to perform these functions can vary drastically from machine to machine. 

This variability makes it virtually impossible for a single NC program to run more than one machine/control combination. In addition, in order to differentiate themselves in a highly competitive market, machine tool builders add a wide variety of special functions that add appeal to their particular product. For instance, a machine tool builder might provide helical interpolation which, of course, will require special codes. In all likelihood these codes would not be understood by an older control unit. This complicates the situation in which an NC program needs to be moved from a machine that supports the function to some other machine that does not. 

To further complicate things there is tremendous flexibility in how any one machine/control combination is programmed. This means that two different companies with exactly the same machine/control combination may choose to program in a completely different way, using different combinations of available codes and functions. 

When we take all these factors into account we begin to see why producing a good NC program is not as simple as clicking the print button. And, consequently, there are a number of very common post processing problems that CAM users typically face.

Problem 1: The Codes Are Not In Order

The first problem is simply getting the correct codes output in the desired order at critical places in the NC program. The critical areas normally come at the start of the program, at a tool change, and at the end of the program. Getting the correct cutter compensation codes (diameter and length) output at the appropriate place is also a difficult task. As previously stated, individual companies and even departments within the same company have different requirements and frequently adopt different methods for employing such things as tool changes and cutter diameter compensation. 

Thus, a postprocessor configured for one company may not be suitable for another. Even if your CAM system comes equipped with a pre-configured post-processor for a particular machine/control combination, it is unlikely that such a postprocessor would produce an NC program with the exact codes in the exact order desired by your organization. 

The CAM user is then faced with three undesirable choices: accept the output as generated (can confuse machine operators); have the NC programmer edit and modify each individual NC program before it is sent to the machine tool (results in mistakes and inconsistencies); or modify the postprocessor configuration (requires personnel with the appropriate expertise or aid from the CAM vendor).

Problem 2: Sophisticated Machines Not Supported

Another common problem is that an organization will purchase a machine tool which their current CAM system cannot support. Many of the low to moderately priced CAM systems do not fully address the requirements of multi-axis machine tools, for instance. Limitations include the inability to control multiple rotary axes such as two or more rotary tables or heads. 

Even in cases where the rotary axes can be controlled, the CAM software's postprocessor may not be able to accurately calculate the feed rates necessary to keep the tool tip moving at the programmed feed rate as the rotary axes are moving simultaneously. Problems such as these are frequently overlooked until after the machine tool is purchased and is on the floor waiting for a program. Changing or upgrading the CAM system is sometimes the only way to overcome such problems.

Problem 3: Special Features Not Supported

A third problem frustrating CAM users is that postprocessors frequently do not support special features contained in their machine control unit. Examples include advanced probing cycles, the support for variables within the NC program, and the calling of some sub programs. In most cases the staff will be trained on the advanced features of their control only to find out later that their CAM system cannot take advantage of these capabilities. 

An example of this occurred at a shop we recently visited where the NC programmers were manually programming touch probe cycles. The intent of the probing cycle was to determine how much excess material existed on a forging they were about to machine. The result would determine how many machining passes would be required to remove the material, which varied from forging to forging. They manually programmed the cycles because their CAM system was unable to output the necessary codes. In fact, it is not uncommon for programmers to manually edit CAM generated programs in order to add codes and cycles supported by the control unit but not their postprocessor.

Problem 4: Replacing Existing Postprocessors

The need to replace some older postprocessors is a problem faced mostly by larger companies. These postpro-cessors are typically mainframe based and were written many years ago. In this age of corporate downsizing, shrinking MIS departments and distributed networks, companies find themselves with no one to maintain the old postprocessors and/or they want them to run on local computing platforms.Porting the old postprocessors to run them on modern computing platforms is a dreadful task. Thus, usually new postprocessors are written and/or purchased. The difficulty in this is producing the same output as the older posts and being compatible with existing CAM data.

Recognizing Problems And Improving Products

CAM vendors must fully recognize these problems and continue to improve their postprocessing products to address them. When compared to the CAM systems of ten years ago, the vendors have indeed made significant progress in these areas but more work is needed. This of course will be done over the long term, as it will take time for CAM vendors to address each problem.

Another long term solution, although unlikely, would be the adoption by the machine tool industry of a modern and more rigid standard for machine tool programming. Such a standard would allow a single program generated for a certain class of machine to run on any machine/control combination, regardless of manufacturer. This would virtually eliminate the need for postprocessors on new machines that conform to the standard. 

Ironically, such a standard already exists and has since the mid 1970s. This standard is known as BCL, for binary CL file. It was inspired by the US military to overcome the problem of machine incompatibilities on sensitive projects where there may be a need to transfer the manufacturing of critical components from one manufacturing plant to another. So what's happened to the BCL standard and why is it not widely used? Because of the competitive nature of the machine tool industry such conformity to a standard would make it difficult for builders to add value to their controls and differentiate themselves from the competition. Today, only a few machine tool manufacturers offer BCL as an option and the majority of CAM systems are unable to produce a BCL file.

A more immediate solution is the use of one of the several universal postprocessors on the market. These products are designed to be compatible with the most popular CAM systems and are developed by companies who specialize in providing postprocessing solutions. Because of their specialization, the products and services provided by these companies are able to address the problems discussed earlier.

One of the universal postprocessors—or "generic" as they are sometimes called—on the market is PostWorks by NCCS. An evaluation of this product helps reveal how today's postprocessing technology is flexible enough to output very precise machine code, support a wide variety of complex machine tools, and has the capability to support special machine control features.

The postprocessor allows the user to associate a "user defined block" with a specific action, such as loading a tool. Then this block can be formatted to whatever specifications are desired (see Figure 1). It supports up to ten axes—six linear and four rotary—enabling it to run virtually any multi-axis machine including mills, lathes, turn/mill machines, EDMs, flame cutters, waterjets, and ultrasonic cutting machines. Through the use of simple menu selections, the user defines the physical characteristics of the machine, such as how many axes it supports, the type of rotary axes, and the machine travel limits (see Figure 2). Once the data has been entered the postprocessor will create a solid model of the machine tool, allowing the movement of the machine to be simulated on the computer screen. This aides in verifying the accuracy of the program.

The postprocessor also supports many modern machine control features. A good example is spline interpola-tion. Most of us are aware of circular interpolation which allows circular moves to be programmed in a single block of NC code as opposed to requiring linear (point to point) data to produce a circle. This results in shorter NC programs and smoother movement on the machine, and hence a more accurate part. Spline interpolation is essentially the same concept except that it allows tool paths generated by driving across a non-analytical curve or surface. Thus, a curved tool path that would normally require a great deal of point-to-point data can be output in far fewer program blocks. In addition, because the machine control would interpolate the curve, the movement on the machine would be much smoother than the traditional linear movement (see Figure 3).

To maintain existing data, the post processor supports a number of CAM system output formats including CATIA, UGII, APT, NCL and VARIMETRIX. The system also allows a macro to be associated with any postprocessor input command. The macro can then be made to emulate the output of an existing postprocessor command or to create a customized function (see Figure 4).

In summary, while computer-aided manufacturing technology has indeed become mature, creating output for the wide variety of machine/control combinations remains a difficult problem. The solution to these problems will require more work from CAM vendors and more cooperation among machine tool manufacturers. In the short term, universal postprocessors and services provided by the makers of these products can provide the missing link between your CAM system and your machine tool.