The Process Before The Program

A process can be computerized and still not be automated. In the same way that a manual machinist may drive the machine through the same moves for part after part, a CNC programmer working in CAM might input similar information to create program after program. In either case, "automation" would refer to freeing the human being from having to initiate the repetitive steps.

CAM developers have steadily been bringing greater automation to programming. Any number of capabilities might qualify here; software that is better able to interpret model data, or better able to optimize a pattern of tool paths, can lead to a more automated process. While there may be no strict definition of programming automation, there is a threshold that is worth noting. When a shop's software reaches a certain level of effectiveness at recognizing the features the shop machines and assigning operations to those features, the role of the programmer begins to change. No longer does the programmer devote so much attention to recognizing and interpreting features with his own eye and hand. Instead, the programmer's most valuable attention is focused on defining the logic by which these machining operations are applied. Taking a step back from creating programs directly, the programmer instead writes the processes by which these programs are created automatically.

One software company that is attempting to move CNC programming in this direction is Pathtrace, developer of EdgeCAM software. A utility from the company called "Strategy Manager" allows a programmer to graphically construct algorithms for automated programming by manipulating flow chart symbols on the screen. For example, the user might construct an algorithm that says any hole size X or smaller should be drilled to size, any hole larger than X should receive a starter hole first, and any hole whose diameter is specified to a certain number of decimal places should be reamed for accuracy. Such an algorithm would allow the software to execute a decision-making process that a human programmer might otherwise have to think through again and again, for every hole he confronts.

The Holy Grail for software automation like this would be the ability to craft algorithms so thorough, they let the model go in and let a complete and efficient NC program come out without any human contact required. Such seamless automation rarely occurs today. Certain features are easier to recognize than others, and certain situations are easier to automate. In fact, given the way that designers design and manufacturers produce, it may be that this ideal will never be attained for all machined parts. But at the same time, there is a growing range of applications for which writing processes is indeed an attractive and practical approach—one that can yield significant returns over creating every program from scratch.

Three employees of Pathtrace—technical director Raf Lobato, engineer Andy Schaffner and CEO Steve Sivitter—recently offered thoughts on the potential benefits of this sort of CAM automation. They also described the challenges that are inherent to automating the programming function in this way.

The Benefits

Automated programming can do more than save on programming time. For some shops, in fact, this savings will be the least of the benefits. Potentially more significant is the chance to realize greater consistency from job to job. For example, one very realistic achievement could be a process in which every hole in the shop is machined by means of an identical set of best practices.

Such an achievement would represent a departure from the way many shops do their programming. In shops with multiple programmers, each individual may follow his or her own personal decision-making rules—some of which are valid and some of which are based on nothing but personal habit. The results of this variation from programmer to programmer can include inconsistent cycle times and inconsistent quality. By forcing the process to standardize on the most effective techniques, automated programming can make machining cycles faster, more capable and more predictable.

The same standardization can save cost before the cut begins. One of the more expensive decisions that a programmer makes is the choice of cutting tools. If different programmers routinely specify different tools, then that raises the number of tools that the shop has to order, store and track. By defining in advance what tools will always be assigned to particular features, the shop can reduce this inventory demand. (Pathtrace, for example, has a utility called "Tool Selector" that allows the user to limit what tools will be used in pocketing. For any particular pocket or collection of pockets, the software calculates the most efficient tool paths it can using only the shop's preferred set of tools.)

One other benefit of automated programming has to do with the significance of a shop's personnel. A shop is vulnerable if it relies too heavily on a small number of programmers. What if one of those programmers leaves? Not only would the shop need to find a replacement, there is also the question of the experience that might be lost. If a shop makes no attempt to capture its machining and programming knowledge within some kind of automated or standardized system, then a programmer who leaves the company may be taking valuable knowledge away.

The Challenges

Automated programming, or letting software assign machining operations in place of humans assigning them, combines two basic CAM concepts. These are feature recognition and knowledge-based machining. The CAM system first recognizes a model feature, then applies machining knowledge to make the right programming choices. Mr. Lobato describes three fundamental requirements for this approach to programming to work:

1. The feature must be defined in the model.
2. The software must be able to recognize that feature.
3. The software must be able to do something meaningful with the recognition it has made.

An attempt at CAM automation may fail on any of these points. If the model from the customer is inaccurate or incomplete, then this may cause a failure of point 1. Human intervention would be needed. In the case of a solid model that simply carries a designer's error, the human programmer may be able to spot the problem immediately. But it is difficult (at best) to design software able to make the same intuitive leap.

At the other extreme would be a feature the software can recognize without fail, but still can't do anything about—a failure of point 3. An example would be a pocket with a sharp internal corner. An automated programming system that is limited to a machining center's capabilities would be helpless to create such a feature.

Then there is the middle ground, point 2. A feature might be both reasonable and clearly defined, but nevertheless difficult to identify because the same geometry might suggest different features. Consider a T-slot, for example. At a small size, this slot is a single milled feature created using a T-slot tool. But at a larger size, this slot becomes a combination of milled features that are machined using a sequence of tools.

Because of all of these potential sources for ambiguity, seamless automation is difficult to achieve. Just as with automation on the shop floor, automation in CAM is less likely to result in an unattended process and more likely to result in a "lightly attended" process. A human programmer probably will still be needed to coax the programming along by making key interpretations and refinements along the way. Even so, programming this way can represent a significant improvement over a process in which the programmer confronts every feature of every part as if it was something new.

More Effective Features

Two types of machined features that lend themselves very readily to automated programming are pockets and holes. These features are easy for software to recognize. What's more, the associated machining decisions, though they may be complex, can be precisely defined. When should a hole be drilled in steps instead of all at once? When should a hole be reamed? When should a hole be circular milled instead of drilled? When should a pocket be machined through trochoidal milling instead of parallel passes? Decisions such as these are all based on criteria the shop can articulate. And this articulation becomes the basis for automating the decisions with CAM.

Other features may also lend themselves to automated programming, depending on their context within the shop's own family of parts. Open areas of the part are subject to interpretation, for example. Is an open area a surface that must be milled, or is it simply a feature of the original workpiece whose dimensions are to be left intact? A company machining a narrow range of parts may be able to make a particular assumption that covers all of its parts, while a shop machining a broader mix may have to treat this question as yet another area of ambiguity that calls for case-by-case involvement.

Even where the most recognizable features are concerned, however, there remains one fundamental limit to how well any automated programming system can work. Such a system can only use the information that the model is able to convey. Most models leave out useful or even necessary manufacturing data.

For example, what about surface finish? The finish of a hole may dictate how best to machine it. Today, some shops color-code features according to their finish requirement, so the CAM software can use this color as a decision-making parameter. But short of a work-around solution such as this, there is no formal way to include surface finish data in designs made with the most popular solid modelers.

How to let a model define not just geometry but also manufacturing requirements is a problem that the developers of these systems are working on. To more fully automate programming, CAM technology can only go so far. CAD software companies can also contribute—and most likely will contribute—by enabling models to carry information that lets stand-alone CAM systems put them to use more effectively.