Empowering The Programmer

On the shop floor, the value of automation is clear. By automating predictable, repetitive tasks, a manufacturer gets more benefit out of its investment in skilled labor. Employees are set free to apply their efforts to higher-value work.

This same rationale applies to programming. By automating mental tasks that are predictable and repetitive, programmers can be set free to focus on more sophisticated programming challenges. In other words, cost-saving automation can take the form of software as well as hardware.

Where software for computer-aided manufacturing is concerned, two capabilities hold out the promise of delivering far more programming automation than most shops enjoy today. These capabilities go by the names automatic feature recognition and knowledge-based machining. The two capabilities work together. When CAM software can automatically identify the CAD model's various geometric features, the software can then call upon stored machining knowledge to determine the best way for each of those features to be machined. Thus the software can—in theory—kick out the NC code on its own.

In practice, automated programming systems generally demand more human intervention than that. A programmer of some sort not only has to input the machining "knowledge" on which the programming algorithms are based, but also has to refine that knowledge as part designs, processes and manufacturing methods change. What's more, if the part geometry is at all complex, then a programmer probably has to help the system along with various steps in its analysis.

But the work that a programmer still does have to do is not the important point. Far more important is the fact that automated programming systems are now achieving significant time savings in real-world applications.

One application using automated programming for relatively complex parts involves the U.S. military. It also involves several companies concerned with military aircraft production. A joint project called the High Throughput Manufacturing Program—"HiThru" for short—seeks to speed the production of aircraft structural components by minimizing programming time.

The project was conceived to let aircraft service depots respond quickly in cases where a replacement part is needed and no NC program exists. The project begins at the point where a CAD solid model exists, and aims to develop an automated programming system to let the depot obtain an NC file from this model as quickly as possible. Potentially, the depot might scan the old part, create the model from the resulting data, and use this model to generate the program for a machine tool located on site. In a test of automated programming algorithms developed so far, HiThru team members generated five-axis tool paths from the CAD models for parts originally made on three- or four-axis machines. Five-axis machining saves on setup and cutting time, and through the use of automated programming, it saved on programming time also. Savings fell in the range of 30 to 90 programmer hours. Partly to realize these same savings for themselves, and partly to realize other benefits as well, the manufacturers of original aircraft parts are also interested in this technology.

In fact, even for manufacturers far removed from the aircraft industry, a close look at the HiThru project is valuable. As a real-world example of automatic feature recognition and knowledge-based machining, the project illustrates at least two important points for understanding these technologies. One is the value of constraints. HiThru's automated programming system generates NC code for aircraft structural members machined from rectangular billet, and the range of parts is no broader than that. The system works well because the application is so well defined.

The other point the project illustrates is just how difficult it may be at the outset to equip an automated programming system with the machining knowledge it needs. Part of the difficulty results from the fact that different portions of the knowledge may exist in different people's minds. If so, those people have to work together to pool what they know.

HiThru At A Glance

The National Center for Manufacturing Sciences (Ann Arbor, Michigan) is the partner in the HiThru project that brought all of the other partners together and now coordinates their efforts. Other partners who have been with the project from the beginning include Cincinnati Machine, Sikorsky Aircraft, software company Technology Answers and the Warner Robins Air Logistics Center. Joining the project more recently were Boeing Military Aircraft and Missile Systems and the Cherry Point Naval Air Depot.

Most of these names will be familiar to anyone whose work touches on military aircraft production. The Warner Robins and Cherry Point facilities are military depots charged with repairing aircraft and returning them to service quickly. Sikorsky and Boeing are aircraft manufacturers, and Cincinnati Machine supplies companies such as these with five-axis machine tools designed for aircraft part production. The one name that may not be familiar is Technology Answers of San Diego, California—the only software supplier in the group.

Technology Answers offers a platform for automated programming. The company's "Cimskil" software includes feature recognition technology that analyzes solid models created in Catia or Pro/Engineer (among other CAD systems) to identify their various discrete features. A table-driven interface that is still being developed will allow users to input their own rules for determining what the software does with this information, effectively letting the user "program" the software without using a programming language such as C++. One application of the software is automatic costing, based on user-defined rules for the operations and expenses associated with various machined features. But another application is NC programming. By building in rules that describe the optimal tool paths and parameters for machining various features, a manufacturer not only can achieve automated programming, but also can "perfect" its programming process by capturing all of its preferred machining methods in one place.

While members of the depot community see this system as a means to produce replacement parts quickly, manufacturers of new aircraft see a variety of potential advantages beyond just the chance to produce original parts quickly. One advantage relates to the manufacturer's own interest in service parts. Bob Golembeski, a HiThru participant who is chief of NC programming for Sikorsky, notes that a military aircraft supplier is obliged to be the manufacturer of last resort for any part it sells. A plane might be in service for 30 or 40 years, and toward the end of that time, any machine tool used to make a particular part may no longer be available. However, the solid model should still exist. With automated programming, the model could be used to quickly generate a program for whatever is the preferred machine tool of that future time.

Another advantage—one that may be even more important—is the opportunity to capture preferred machining methods. The reasons why this is important relate to the realities of aircraft part production.

Mr. Golembeski explains that military aircraft parts today are often programmed conservatively. The short production runs don't justify the extra programming time that would be needed to make the NC program as efficient as it could be. And this isn't the only source of inefficiency; differences in technique from programmer to programmer contribute to inefficiency as well. This latter point is particularly problematic in the military aircraft industry, where the programmer is often a contractor who will go to another assignment later, leaving the aircraft manufacturer to deduce the logic of the program that was left behind. With an automated programming system, the aircraft manufacturer could apply the most efficient machining methods to every part, apply consistent methods from part to part, and maintain its machining methods in house.

When the Cimskil software is used for automated programming, it outputs an APT Cutter Location file ready for postprocessing. Because the software's feature recognition capability includes algorithms developed specifically with five-axis machining in mind, the product was a natural choice for the HiThru program. What remained was to equip the system with the rules it needed to write the most effective tool paths possible for aerostructure parts. No one person, and no one company, had enough knowledge to do this alone.

Part Programming Time Machining Time
 Conventional HiThru Conventional HiThru
80-120 hrs 7 hrs no data available 5 axis

set 10    0:31
set 20    0:23
Total     0:54

 
 45-75 hrs 12 hrs 3 axis
set 10    0:46
set 20    1:22
set 30    2:05
Total     4:13
 5 axis
set 10    0:47
set 20    0:22
------    -----
Total     1:09
 
 45-75 hrs 3 hrs
45 min. 4 axis
set 10    0:14
set 20    2:05
set 30    0:03
Total     2:22
 5 axis
set 10    0:05
set 20    0:36
------    -----
Total     0:41
 
 45-75 hrs 6 hrs 4 axis
set 10    0:06
set 20    1:08
set 30    0:54
set 40    0:05
Total     2:13
 5 axis
set 10    0:29
set 20    0:15
------    -----
------    -----
Total     0:44
 
 45-75 hrs 24 hrs 4 axis
set 10    0:12
set 20    1:09
set 30    1:15
set 40    0:02
Total     2:38
 5 axis
set 10    0:37
set 20    0:19
------    -----
------    -----
Total     0:56
 
This table shows programming time savings realized as a result of automated programming. Differences in geometric complexity help account for differences in the amount of time saved. This table also shows savings in machining time. These latter savings result from a variety of factors, including five-axis machining, faster spindle speed, and a higher metal removal rate resulting from low-chatter machining. This last point lies outside the focus of this article, but it's addressed in detail in "Maximum Aluminum," one of the articles listed in the Learn Mores at the top of this article. It is also worth noting that the test parts differ somewhat from actual production parts. Specifically, the HiThru machining omits features such as rivet holes that do account for a small percentage of each part's "conventional" machining time. (Machining time given in hours:minutes.)

Meeting Of Minds

Involving multiple people who have programming expertise is valuable in an application that leaves so much room for differences in technique. In addition, because aircraft part machining often occurs near the speed and power limits of the machine, the involvement of the machine tool builder is also valuable. While the aircraft manufacturer may know what fixturing, tooling and tool path to use, the machine tool builder knows the machine's horsepower and vibration characteristics—or whether the machine can do what the aircraft maker might want it to do. For the companies involved in HiThru, a large part of the investment so far has been the consultation time necessary to bring these various experts together.

To figure out the "rules" for machining aircraft components out of rectangular stock, HiThru team members talked their way through one part after another. They looked at about 20 representative parts, all aluminum. (The group is working on titanium parts now.) For each part, they analyzed the step-by-step sequence of machining passes. When team members differed as to how they would machine a given feature, or at what point in the cycle they would machine it, the team tried to account for the difference and decide which method made more sense. As similarities in the processing strategies for various parts began to emerge, these similarities suggested the algorithms the software should follow to script a machining sequence automatically.

There was plenty of processing similarity because the parts themselves were so similar. All were aircraft structural members. All were machined from plate stock. If the application was any less focused than this, the range of features might be too large to recognize, and the range of machining techniques might be too great to capture. In other words, constraints account for why this application was a good candidate for automated programming.

Constraints Are Liberating

Jim Dallam, a representative from Cincinnati Machine on the HiThru team, illustrates this point in an interesting way. He points to a different process for making physical forms out of 3D CAD models—stereolithography. This process does not require NC programming the way machining does, and he notes that constraints explain why. Stereolithography builds the 3D form out of horizontal layers; it can't work any other way. Though there are still processing choices, complex NC programming is not needed because the range of choices is so narrow.

By contrast, a CNC machining center offers any number of ways to generate the form. The programmer can choose to machine one side first or the other side first; he can cut a wide channel using a wide tool or using several passes with a narrow tool; he can drill a hole or he can mill the hole by feeding in circles. And even before these sorts of choices, the programmer makes choices that are more fundamental. He decides, for example, whether the part has enough rotational symmetry for a lathe, or whether it belongs on a machining center instead. If it goes to a machining center, he may decide whether its features best suit it to a three-, four- or five-axis machine.

The ideal application for automated programming is one in which basic decisions such as machine type have already been dictated, and many of the more specific decisions are bounded by limits as well.

Applications where automated programming has been successfully applied using other CAM systems serve to illustrate this. In a small number of production plants, turned parts with family similarity are machined straight from the CAD file with little programmer involvement. And in a small number of mold and die shops, the hole machining cycles for tooling plates are programmed in much the same way. In each of these applications, the choice of machine tool is clear, and the universe of machined features is small and well defined.

The same is true of the HiThru application. The intended machine tool is a five-axis machining center. And the range of features is limited to what can be found on an aerostructure part—a list that includes pockets, cut-outs, flange tops and the profile around a part's perimeter.

Test Parts

The table (above, right) summarizes the success of the HiThru program so far. The savings in programming time represent the payoff from Phase 1 of a three-phase project. Phase 1's goal was to establish and prove out a set of programming rules based on representative parts. The parts shown in the table were programmed using those rules and run on a Cincinnati V5 five-axis machining center. In Phase 2 (which is likely to be complete by the time this article appears), the goal is to improve the software's user interface so rules are easier to input and modify. Phase 3 extends the automated programming system to other machine models, to titanium, and perhaps also to thin-wall milling and other requirements of newer aircraft parts. (Walls and floors for the test parts were all at least 0.080 inch thick, which is not particularly thin by the standards of aircraft parts today.)

The table shows how much programming time was saved, but it also shows that a significant amount of programming time still remains. At various points throughout the automatic programming process, the software does still need prompting and participation from a human overseer. However, the larger part of this remaining programming time is due not to limitations of the system, but instead to faults in what the system has to work with. Errors in the solid model can produce features that the automated system cannot correctly recognize. These errors can come from the designer, but they can also result when the conversion of data from one format to another introduces microscopic faces, split faces, gaps where edges fail to join and other misinterpretations. In cases where any of these common errors occur, a programmer may have to intervene, using the superior feature recognition ability of his own mind and eye to help move the process along.

Model Processes

That a CAD model might contain significant geometric error will come as no surprise to anyone who routinely works with complex solid models created upstream. In various industries, problems sharing CAD geometry are a source of cost and delay in the supply chain for machined parts. A growing appreciation for the scope of this cost and delay has led to improvements in designers' procedures and improvements in the way model data are transferred and interpreted. So what would happen if, in the future, an automated programming system like HiThru's could rely on solid models so solid that their features could always be recognized?

For large manufacturers, parts would move from design to manufacturing with less delay. But small shops might see a change in the very way they receive NC files. Cincinnati Machine's Mr. Dallam says a supplier to these shops such as Cincinnati might maintain knowledge-based programming systems for various classes of parts as a way to support these shops. Contract shops might come to accept it as standard practice that when they receive a CAD file for a job, they send that file to the machine tool builder for the NC program needed to run that job on the builder's machine.

This is all very speculative. Shops will need NC programmers for quite some time. Not only are automated programming systems still a rarity, but they also need both "run-time" users who oversee the automated programming and "development" users who can define and refine the rules that determine how the tool paths are generated. At these two different levels, human involvement is still required.

In the short term, the problem that automatic feature recognition and knowledge-based machined are ready to address is the short supply of NC programmers. What this article has been referring to as automated NC programming can't replace the human any better than most shop floor automation can. But it can extend the human's reach. The programmer using an automated system such as the one the HiThru project envisions can devote his time solely to the most difficult aspects of programming any part. He can also see his impact multiplied, as one instance of inputting "knowledge" gets applied to the way in which part after part is machined from that moment forward.