Empowering the programmer: A project aimed at making military aircraft parts faster shows just how much productivity gain can come from automating the programmer's repetitive tasks

Modern Machine Shop, April, 2002 by Peter C. Zelinski

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 on page 72 summarizes the success of the HiThru program so far. The savings in programming time represent the payofffrom 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.0 80 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?