DNC & File Handling

DNC — direct numerical control — and its file handling are how a program travels from the computer where it was made to the machine that will run it. The work of this group has described the program’s making: the CAM session that planned the toolpaths, the postprocessor that wrote them as a program, and the simulation that proved it before metal was cut. But a program on an office computer cuts nothing; the control runs only what it holds. Getting the right file, in the right revision, onto the right machine is the business of DNC and file handling — the plumbing of the shop’s programs — and this entry sets out how programs reach the machine and how the files are kept straight once they do.

The journey of a program

A program’s journey has changed with the shop. In the earliest days of CNC, and still for the simplest work, a program could be written at the machine itself, block by block on the control’s panel, and run from its memory. As programs came to be written away from the machine — first on paper tape, then in CAM on a computer — the problem became getting them to the machine intact. Tape gave way to the electronic link, and the acronym DNC was coined for direct numerical control: a system in which one computer served a number of machines, sending each its programs. The modern meaning is wider — DNC is the general name for linking a computer to a machine’s control so that programs can be sent as files — but the older idea survives: the program is made off the machine and moved to it electronically.

Transfer methods

The program travels by whatever link the machine offers, and the methods span the machine’s age. Older controls, and many still at work, take programs over a serial cable, a point-to-point link in which the two ends must agree on the details of the conversation — the baud rate that sets the speed, the parity and stop bits that frame each character, and the handshaking that keeps a fast computer from overwhelming a slower control. A mismatch of settings sends nothing or sends garble, so a good link, once established, is left alone. Newer machines link over the network, pulling files from a shared folder or receiving them through the machine maker’s software, which makes sending a program as ordinary as saving a file. Almost every machine also offers a USB port or memory card to carry the file to the control by hand. However it arrives, the program must arrive whole, and the shop’s habit is to check it — the size the control reports should match the file the computer sent.

Memory and the size of programs

Once on the machine the program must be stored, and the control’s memory shapes the whole question of file size. A control keeps programs in its own memory — finite, and on older machines small by the standards of any computer — and a program must fit there to run from it. Much of this group’s work is short: a simple program’s structure of a few hundred blocks fits any control easily. But the long work of machining — the surface-finishing toolpaths that step across a whole mould, the simultaneous moves of a five-axis job — produces files many times the length of a hand-written program, and they can exceed what the control holds. The machine’s memory is a working store for the programs running now, and it fills faster than the shop expects.

Drip feeding the large program

When a program is larger than the control’s memory, the machine can still run it, and that is DNC at its most literal. Instead of the whole program being stored on the control first, the control runs it directly from the computer, taking each block as it needs it and executing it on arrival, so the program never sits in the machine’s memory at all. This is drip feeding, and it lets the machine cut a program of any size, limited only by the computer that feeds it. Drip feeding asks more of the link than ordinary transfer: computer and control must keep pace through the whole run, and a break in the link — a cable fault, a computer that sleeps, a network that drops — stops the machine where it is, in the middle of a cut, with the tool in the work. The shop that drip feeds a long program treats the link as part of the setup, tested before the run and watched during it. The program’s size stops being the barrier; the reliability of the link becomes the new constraint.

File handling: naming, storage and versions

Programs that live as files bring the discipline of files with them, and file handling is the half of the subject that keeps the shop out of trouble. A program’s code names itself with its program number, and the shop’s rule is that the file name and the program number agree — the file the computer holds is the program the control will load, and a name that lies about its contents is a trap. Files need a home: the control keeps what is running now, in its limited memory, while the computer holds the library of every program the shop owns, backed up so a lost file is recovered, not re-written. And files have versions, where the care matters most. A program is made in CAM, posted to a file, edited perhaps at the control by the machinist who reads the code and finds an error, then proved on the machine; every change after the first posting makes a new revision, and unless the master file and the machine’s file are kept the same, two versions of the truth exist and the wrong one will be run one day. The loaded program must be exactly the one simulated and proved, or the proof means nothing.

Keeping the pipe clean

DNC and file handling succeed when they become invisible — when the right program is on the right machine and no one has to wonder whether it is the current one. The habits are simple: a reliable link, set up once and tested; file names and program numbers that agree and carry the part’s revision; a control that holds only what it runs; a computer that holds and backs up the library; and the rule that an edit made anywhere is written back to the master. With those habits, the program that CAM made, the postprocessor translated and simulation proved reaches the machine as itself, and the final dry run and prove-out proves the code the shop means to cut, not a copy that drifted. The plumbing carries the program; the discipline keeps it clean.