Postprocessors: An Integral Part Of Machine Tools

Production CNC manufacturing relies heavily on CAM software. Without CAM support it is next to impossible for a CNC machine to do what a CNC machine is supposed to do—make good parts 24 hours a day, 7 days a week.

The most expensive “time” in production CNC machining is machine time. Machine time should be reduced and protected at all costs. Any machine time spent not cutting good parts is a waste.

CAM software is a three-legged stool because it provides three major functions. A deficiency in any one of the “legs” will produce an unstable machining platform or, worse, a dangerous one.

CAM’s three major functions include the following:

CAD for manufacturing: A shop must be able to work from any CAD file provided from any customer, or from drawings and sketches. It also needs to be able to correct designs, modify them for manufacturability, design tooling from the original part design, as well as support future revisions and updates from the customer.

CAM for toolpath creation: A shop must be able to develop and apply its own machining strategies, tools and fixtures, create an efficient tool path and verify a tool path. A shop needs to support the machines on which it intends to cut, including vertical mills, horizontal mills, vertical lathes, horizontal lathes, mill-turns, Swiss-type machines, multitask machines, EDM machines, and so on.

Postprocessing: A shop must be able to create perfect G code for a specific machine, exactly programming and cutting the part created with the CAM system.

Most shops are familiar with these three functions, though most focus on the first two. They are the most graphic, and the easiest to evaluate. However, the third leg is no less important.

CAM software creates a part program in its own general terms. It defines all details, including tool cutting motion, feed rates, spindle speeds, coolants, machining cycles, tool change positions, tool changes, tool offsets, cutter compensation, clearance moves, subspindles, parts catchers, indexers, bar feeds, robot loaders, work fixture offsets, and so on. These details are different for different types and configurations of CNC machines. Quality CAM software will offer detailed machine type selections for program creation, so that a shop does not have to dig through tons of inappropriate choices for the task at hand.

Almost all CNC machines are programmed with a text file called “G code.” There is an EIA specification defining the basics. Even the most successful non-G-code programming machine brand, Mazak, offers G code in its “EIA option” and relies on G code for its most complex machine—the Integrex. G code is a text file language that CNC programmers can read, as it is similar for all CNC machines. It is called G-code because the primary action commands start with the letter “G.” Some examples include the following:

G0: a rapid move
G1: a feed linear move
G2/G3: clockwise and counterclockwise arcs
G41/G42: cutter compensation on left/right
G54: work fixture offset #1
G81: simple drill cycle
G90: absolute positions
G91: incremental positions

The list goes on, and even a simple machine will have a large number of G commands. G commands are frequently followed by a variable string of letters and values for them to act upon. For example, “G1 X5. Y5.” is a line to move to X5 Y5.
There are also M commands, which are not involved with tool motion. Some examples include the following:

M0: program stop
M1: optional program stop
M2 or M30: end of program
M3/M4: spindle on CW/CCW
M5: spindle off
M99: end of sub-program

This list goes on, and even a simple machine will have a lot of M commands. M codes usually don’t have a list of values after them.

There are other letters, such as the following:
X, Y, Z, I, J, K: positions used with G0, G1, G2, G3
S: rpm
F: feed rate
T: tool number

This list of commands is a fraction of the full set a CNC machine would use, but it gives you an idea. Even this short list isn’t consistent across CNC machines. For example, while Fanuc uses G54, Fadal uses E1, Heidenhain uses CYC DEF 7.0 DATUM SHIFT, Okuma uses G15 H1, and so on.

Unfortunately, because CNC controls have been around for about 50 years, each control manufacturer has been “improving its product” since then. This means that instead of making controls more compatible with other CNCs, the manufacturers do exactly the opposite. They want to make their products “different” and “better” so that they can sell more than their competition.

Therefore, they add commands and change the G-code formats, sometimes to make manual programming easier or to add new cutting methods or provide better cutting control. No two machines program exactly the same way.

In the beginning, NCs programmed more similarly to each other, but in odd text formats required by their primitive electronics. “X010000” might be X 10.0 in an old, fixed format machine with 3.3 decimal place fixed format or X 1.0 in a 2.4 format. Early posts handled different numeric formats, and there were dozens of them. As computers improved, “X10.” became common for 10.0. Arcs are common moves: G2 X1 Y0 I0 J0 uses IJ for the center point and XY for the end point. Some machines use IJ incrementally from the start point; some use absolute. A defined cycle like G81 has a number of parameters, usually varying from control brand to control brand. These are only some of the G-code variations found in early NC machines.

As controls added more sophisticated functions, they typically did so in different ways. Fanuc cycles are different from Siemens cycles, which are different from others. Even in a single brand, G codes changed. Every time Fanuc had a better idea, it became a different G code from their earlier models. To “help” with these legacy issues, a modern Fanuc lathe control offers three different command sets, so that new G-code programs can be “more” or “less” similar to old G-code programs for older machines. A shop can pick the command set of its choice with a “parameter” (a flag set on/off, or to a value, inside the control).

Parameters are another source of G-code differences to be accounted for by a postprocessor. A Fanuc, Siemens or Mitsubishi CNC control is sold to a machine tool builder who configures that control to his machine. One way he does this is by setting the thousands of parameters to settings of his choice. Hundreds of these parameters will have some effect on the G-code format. When this machine is delivered to a dealer, the dealer’s application engineers will frequently change some of these programming style parameters to match the style they teach.

When the machine is delivered to a customer, the customer may change the programming style parameters to match his company’s preferences. When control manufacturers fix a bug or add a new feature, they put out a new version of their control software, and sometimes this makes a difference in the G code. Two machines of the same brand, model and control model can have a lot of G-code differences by the time they get to the shop floor, and the postprocessor is responsible for all of them.

Postprocessors have had to deal with an ever-growing complexity and variation of CNC machines. The early CNC machines were three-axis mills and two-axis lathes. Today, these are simple compared to a five-axis pallet-changing mill or a multitasking machine.

Multitasking machines are where post complexity really skyrockets. Not only can a multitasking machine have about any number of axes and spindles imaginable, but they literally run multiple programs/flows at the same time. The need for the CAM software to synchronize and make programming simple is huge.

The posting problem is worse. These machines commonly include a variety of non-cutting functions that have to be integrated and synchronized with the cutting actions. How does this machine “load” the spindle? Is it operator-loaded with a chuck or with a bar feed, auto bar feed, subspindle bar pull or a robot? How is a spindle unloaded? Is this done by the use of a chuck, part catcher or part gripper? Is it sucked out, blown out, pushed out or done by a robot? How is a part shifted? Is this done by use of a subspindle pull, bar feed, auto bar feed or a robot? How is the subspindle moved in? Is it done by spinning? Does the spindle stop? Is the C axis aligned? Is the C axis offset? Is the torque sensed? Where is the subspindle returned to? With the part? Without the part? How is the parts catcher moved in and out? How is the turret parked? How are tailstocks moved in/out? How are steady-rests moved? The list goes on.

Postprocessor systems have been developed to deal with all these variations, in a number of ways, resulting in different types of postprocessor systems.

One way is with a list of options and a table of data values. These were the easiest to define and the best do-it-yourself types of postprocessors in the early days. They could handle hundreds of simple, predefined variations. However, they couldn’t move an M3 to a different line of output. They couldn’t deal with a new type of variation, and they couldn’t deal with issues requiring different logic or math calculations.

A postprocessor system following this approach of continually adding options and table data for every variation they encountered would have hundreds of pages of table data and hundreds of pages of posting options. That early advantage of simplicity would be lost along the way.

Another way to develop posts is to use more sophisticated computer languages to develop software to do posting. The developer actually wrote a post in Basic, Fortran, Pascal, C, C++, and so on. This required the developer to be a competent computer programmer. It also required the programmer to start each new post almost from scratch. While this offers flexibility and power to the developer, it made postprocessors expensive to create and to debug.

A third approach starts with a special computer language developed only for postprocessing, with special functions and commands to simplify handling of the specific needs of postprocessing. This approach can be combined with a basic data table to simplify handling of the most common output format variations. These hybrid development tools can be optimized for simplicity, usually sacrificing flexibility and power, or they can be optimized for flexibility and power, usually sacrificing simplicity.

Throughout the past 20 years, CAM software companies have developed a variety of different tools and pushed them in a variety of different directions, depending on what their post goals are. Shops should ask themselves: Who is the user expected to be? Who is going to create the postprocessor—an expert post developer or the CNC programmer? There are advantages to both. If it’s the CNC programmer, he can work on the post until it meets his desires or until it is close enough. However, this is not a job he is trained for or may not be a job he’s good at, and it takes away from his CNC programming time. An expert post developer costs money, but if he delivers a good product, the company will save money in the long run.

Is the stated goal of the postprocessor system to eliminate G-code editing? Not an easy goal, but a valuable one. Editing G-code output from a CAM system is a waste of time and is dangerous. Simple mistakes—such as one omitted decimal point—can be damaging to a CNC machine. What is your cost for a week of downtime and repairs? Beyond the suitability of the postprocessor system for the intended postprocessor developer, there is the issue of research. Is your CNC programmer already expert on the most intimate details of your new CNC machine? He will have to be before he can start on a postprocessor.

Unfortunately, not all CAM software products provide perfect postprocessors. Many CAM companies disassociate themselves from postprocessor creation because it’s complicated. Instead, they offer do-it-yourself kits, leaving the difficulties of good post creation as an after-CAM software purchase reality check. Some provide a collection of standard posts, which might be close in output to your machines. However, “close” is not so good when it comes to G code.

Some leave “custom post creation” to their resellers and dealers. We believe that a full service CAM provider should include all three legs of the software stool, including factory-developed custom postprocessors, reseller-developed custom postprocessors, customer-developed custom postprocessors or an easy-to-use, do-it-yourself kit for basic machines. We have a library of more than 7,000 postprocessors to draw upon for new customers. We have a staff of 12 engineers dedicated to post research, creation and support. I think most machine shops would prefer a turnkey solution, letting the experts take responsibility for the details and the problems.

A good CAM solution needs to cover manufacturing CAD, CAM toolpath creation and postprocessing. All aspects of a CAM solution need to be considered. CNC machines vary widely in the exact details of the G code they require. A good postprocessor solution will create a G-code program for a specific machine that cuts exactly the part programmed, without requiring G-code editing. A poor postprocessing solution creates extra work and risks that aren’t necessary or desirable.

— 3D Systems