The most obvious failure of NC file management is when the machine tool crashes because the wrong part program was run. This is an attention-getting event that can bring the shop to a halt. However, it's also a relatively rare event. Much more common—and potentially just as expensive over time—are the minor file management shortcomings that steal productivity and profits from the shop bit by bit.

This article presents some solutions for a range of cases in which poor NC file management can impede the process and cost real money.

To capture the complete impact on the process, it's useful to look at every shop function that file management affects. These functions include programming, shop supervision, manufacturing and non-recurring activities.

Programming

The NC file is created. However, the programmer's job isn't finished once the file has been posted out. This file needs to be identified with the correct part, operation and machine; it has to be associated with the right tooling and fixturing, as well as any special instructions; and it has to be identified and placed in the right location, whether this location is electronic—that is, on the network—or on some physical media.

Using electronic storage in place of physical media such as floppy disks or magnetic tape is one basic way to improve the process. This step saves on the cost of the media itself. It can also save on the time required to identify, transfer and store each file.

But even if the file is stored electronically, there may still be significant room to streamline the process. The job of properly identifying the file, associating it with the right information about tooling and fixturing, and putting all of this information in the right place so the program can be quickly located and accessed may still present a challenge.

The NC file may denote internally what the program is for, what tooling it uses and so on, but none of this information is apparent in a listing of file names in a directory. Descriptive directory and file names do help—particularly if these descriptions can extend beyond the DOS eight-character format. Also, a consistent file naming convention can reduce the chance of a new file inadvertently being given the name of an existing one. However, naming conventions are still limited. Does program 300120, for example, denote part 3001 operation 20, or part 300 operation 120? Naming conventions are generally prone to this sort of misinterpretation.

A better approach may be a system that provides for storing relevant information about a file somewhere other than in the file name. The information can be stored in a database, thus making the information both easier to maintain and potentially available to many other systems.

By storing this "metadata"—data about the file's data—separate from the file itself, it also becomes possible to identify multiple contexts for the same file. For example, if the same part program is used for a given operation on several parts, then the NC file only needs to be stored once, with the metadata identifying each part for which the file is used.

Shop Supervision

The next thing that happens to an NC program is that it's identified as being necessary for a particular job that has to run. How well or poorly the shop gets the right NC file to the right operator at the right time is probably symptomatic of the shop's overall efficiency at communicating with production personnel.

Automating work instruction is one way to improve this communication. Automated instruction forces users to put details in writing, and just this change alone may reduce the error rate compared to verbal instruction. In addition, a message in an automated system can't be misplaced or destroyed the way a note written on a stray piece of paper can be.

The system should also make it clear what information required to run a job (such as the part program) is currently available, potentially saving the operator from a wild goose chase.

Manufacturing Operations

Once the operator knows he has a specific job to run, the steps he takes with respect to the NC part program begin with retrieving it from where it's stored and loading it into the control. The operator will almost certainly check the program in some way—perhaps by inspecting the code or dry-running the machine. He may edit the program because of a change in tooling or fixturing or a last-minute revision to the part. While checking or editing the program, he may consult other documentation such as a blueprint, tool sheet, and/or special fixturing instructions. Then he'll run the job. If all goes well, he'll save the program (if there were any changes) along with any revisions to other documents. He will also have to bring the changes to the attention of all of the people able to make sure the revised data is available the next time the part is made.

The file management system touching on all of these steps can be streamlined in many ways. Possible improvements include:

Local access to programs
The most visible time savings come from eliminating "sneakernet" time—the time spent physically handling storage media. This includes not only the time spent walking to and from the storage location, but also time spent looking up storage media and waiting for them to become available. Even with a DNC system, if the means to initiate download isn't available at the control, there is still sneakernet time in going to and from the terminal controlling file communications.

Also, there is usually information in addition to the part program that has to be retrieved as well. If retrieving these documents can be combined with access to the program, even more time can be saved.

Electronic program download
Physical media and the devices used to read them are subject to wear and tear. The process of reading in files from physical media can be subject to maintenance delays. Thus cutting down on the use of mechanical devices for reading data not only saves a little time each time a new program is read into the control, it occasionally also saves quite a bit of time by overcoming the instances when the mechanical interface breaks down.

Verification with solid modeling
Verifying the program electronically can be faster than dry-running the machine or visually inspecting the code. To maximize effectiveness, more than the tool center line path should be shown—the actual tool and stock geometry should also be included in the model.

Local program modification
If the program needs editing and this can't be done at the control, the operator has to communicate the change to the programming department or else find an open terminal where he can make the change himself. Having a complete part program editor available at the CNC could save a great deal of time.

Management of tool-break restarts
Tools break. When this occurs, the operator has to back up to some point in the NC program and restart from there. While straightforward if the entire part program resides in the control's memory, recovering from a tool break can be a time consuming chore when drip-feeding the program from an external source. That's why a system that can electronically provide just the portion of the program yet to be run, along with the requisite header, tool change and so on, can save a lot of redundant work.

Electronic saving of changed programs
If a program has been changed and if it needs to be stored on physical media, time could be saved both in the actual program transfer, and in storing, labeling and logging the revised version and notifying the right people about its existence.

The same is true of other documentation related to the job—any changes need to be directed to the right people so the originals can be updated. The ability to perform any of these functions electronically—particularly notification and approval—will save time and probably reduce errors.

Non-Recurring Activities

Other possible improvements to the file management system touch on activities that occur less frequently:

Electronic logging of program use
Finding out what program was used to run a particular lot or batch may not even be possible unless a log of files is maintained. If a paper log is used, locating a particular entry may be time-consuming. In addition, recording this entry for each job will take a little time. An electronic logging mechanism can overcome all of these inefficiencies.

Up-to-date equipment
Repairing or replacing the equipment used to transfer programs will be more difficult, time-consuming and expensive for older and more specialized equipment. Paper tape readers and punchers, custom disk or tape drives and even proprietary DNC hardware units are expensive pieces of equipment because they were never produced in large volumes. Even software can become obsolete, it may no longer be compatible with current replacement hardware. For example, many DOS-based communications programs can't be run on Windows NT or Windows 2000.

Expansion with generic hardware
If an existing machine needs to be upgraded to run longer programs, this can be accomplished either by adding memory or by allowing the machine to be drip fed from an external DNC system. For a single machine with a finite memory requirement, the former approach may be cheaper . . . but the latter approach can be applied to other machines later for little or no incremental cost and with no practical limit on program size.

Similarly, expanding a file management system based on proprietary hardware may be less costly in the short term than replacing it altogether with one that uses ordinary PCs, but the incremental cost of further expansion will be less with the generic system.

Disaster recovery
Catastrophic failures can come from human error or from natural causes. The impact can range from an inconvenience—as in a single machine going down, requiring production to be rerouted—to a more wide-spread loss.

To minimize the effect of any such failure, backup and recovery planning has to be a part of any shop's file management strategy and a part of the file management system as well.

The DNC System

Because they can help realize all of the improvements discussed above, DNC systems are the rule rather than the exception in machine shops today. What characteristics should the DNC system possess to help optimize the flow of part programs and their related information? Here is a checklist based on the requirements discussed above:

1. Support for long file and directory names.
2. Capability to group related information with the part program.
3. A system for identifying files according to their part, operation, machine and other relevant information—preferably using a database.
4. Capability for the supervisor to organize the operators' work and communicate what jobs they should work on.
5. Capacity to transfer part programs without the operator having to leave the machine.
6. Electronic verification of the part program.
7. A G code editor for controls not capable of editing.
8. A way to view, edit and/or mark up related documentation.
9. A way to download a properly formatted partial program to restart from a tool break.
10. A way to segregate uploaded files from others and properly identify them.
11. A way for operators to notify others of changes or problems.
12. A log of part program transfers—uploads and downloads.
13. Ability to run on standard, up-to-date PC hardware and system software.
14. Support for multiple simultaneous drip-feed downloads.
15. Easy backup and recovery.

A few other points to consider are these:

1. Is the DNC system upgradeable enough to allow it to be tied into the rest of the company's information systems eventually? Can it be integrated with data collection, monitoring, document management and scheduling?
2. Does the DNC system support special communications protocols that weren't supported by the shop's previous system? It may be possible to bring machines into the system that previously operated as independent islands.
3. How secure is the system? Even if the shop doesn't deal with sensitive information, good security measures can prevent both mistakes and sabotage. The DNC system should make it easy for the shop to define and enforce exactly who has access to each of the files the system is used to manage.

About the author: Keith Frantz is VP of Development