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 are required to produce programs to run a variety of different types of NC machines including 2-axis lathes, 3, 4 and 5-axis mills, wire EDM machines, punch presses and mill-turn 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, a file not intended for any specific machine but that 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 data of the cutter path and in the case of 4 and 5-axis applications, tool angle vectors. This neutral file has been traditionally referred to as the CL file (Center Line 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?

Problem 1: The Codes Are Not In Order
Here we will examine just a few of the postprocessing problems CAM users typically face. The first problem is simply getting the correct codes output in the desired order at critical places in the NC program. The critical areas are normally the start of the program, a tool change, and the end of the program. Getting the correct cutter (diameter and length) compensation codes 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 postprocessor for a particular machine/control combination it is unlikely that such a postprocessor would produce an NC program with the exact codes and 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 problem encountered 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 a multi-axis machine tool. Limitations include the inability to control multiple rotary axes such as two or more rotary tables or rotary heads. Even in cases where the rotary axes can be controlled, the CAM softwares’ postprocessor may not be able to accurately calculate the feedrates necessary to keep the tool tip moving at the programmed feedrate 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 options and features contained in their machine control unit. Examples include advanced probing cycles, the support for variables within the NC program, and the calling of 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 features. An example of this occurred at a shop I 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 older postprocessors is a problem faced mostly by the larger companies. These postprocessors are typically mainframe based and 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 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.

What Are The Solutions?
Among the most frustrating problems facing todays’ CAM user include the inability to output the appropriate codes in the desired order, difficulty in creating programs for sophisticated machine tools, the inability to take advantage of advanced machine control features, and replacing older postprocessors. What are some potential solutions to these problems?

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.

A New Machine Tool Programming Standard
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 (3, 4 or 5-axis mills, mill-turns, lathes, etc.) to run on any machine/control combination, regardless of manufacturer, within the same class of machine. 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 1970’s. This standard is known as BCL or 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 machine tool builders to add value to their products and differentiate themselves from the competition. As a result, only a few machine tool manufacturers even offer BCL as an option. In addition, the majority of CAM systems are unable to produce a BCL file.

Universal Postprocessors Can Offer Solutions
A more immediate solution would be 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 made and sold 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 on the market is PostWorks by NCCS. An evaluation of this product reveals that it is flexible enough to output very precise machine code, supports a wide variety of complex machine tools, and has the capability to support special machine control features. PostWorks also runs on modern computing platforms and has methods to support existing data.

PostWorks allows the user to associate a ‘user defined block’ with a specific action, such as loading a tool. The user defined block can be formatted to the exact specifications of the user.

PostWorks supports up to ten axes; six linear axes, and four rotary axes enabling it to run virtually any multi-axis machine including mills, lathes, mill-turns, EDMs, flame cutters, water jets, and ultra-sonic cutting machines. Through the use of simple menu selections the user defines the physical characteristics of the machine such as how many axes does it support, the type of rotary axes, and machine travel limits . Once the data has been entered PostWorks 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 postprocessor.

PostWorks also supports modern machine control features. An example of this would be spline interpolation. Most of us are aware of circular interpolation which allows circular moves to be programmed in a single block or line 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 it allows tool paths generated by driving across a non-analytical curve or surface to be output as a NURBS curve. Thus, a tool path that would normally require 250 points to produce a curved path can be output in as little as 60 points. In addition, because the machine control would interpolate the NURBS curve, the movement on the machine would be much smoother than the traditional linear movement.

To maintain existing data, PostWorks 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.

In summary, while Computer-Aided Manufacturing has indeed become a mature technology, 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.