DNC, Drip-Feed & File Transfer

Two different problems share the same cables and the same vocabulary. The first is transfer: getting a program file from the computer where CAM wrote it into the control that will run it. The second is drip-feed (often just called "DNC"): running a program that is too big to fit in control memory at all, by streaming it to the control block by block while it cuts. Both got serious the day shops started cutting 3D surfaces—a CAM system approximating a mold cavity with thousands of tiny line segments can produce a program of tens or hundreds of megabytes, while plenty of controls on the floor still measure their program memory in kilobytes or a few megabytes. This page covers how files move, how streaming works, what breaks, and what each control family in this wiki actually offers.

Transfer: How Programs Reach the Control

Every mechanism ever used to load a program is still in service somewhere. Roughly in historical order:

Serial deserves one more minute, because so many good machines still depend on it and because its failures are so recognizable. RS-232 has no error correction of its own—when the two ends disagree, the data doesn't refuse to arrive, it arrives wrong, and the symptom tells you which setting to suspect:

The settings themselves live in each control's I/O or communications setup pages and differ by builder and generation—get them from your machine's manual and record what works (see the advice section below).

What each control family in this wiki gives you:

• Fanuc — RS-232 on essentially everything; PCMCIA/CF memory card slot on the 16i/18i/21i era onward (which also enables memory-card DNC, below); embedded Ethernet with FTP transfer on later 30i-family controls. Which I/O channel is active is a control setting—confirm it in your machine's manual.
• Haas NGC — USB ports on the pendant, plus Net Share: the control connects to a shared network folder and it shows up as a device in the file manager alongside USB and user memory.
• Siemens SINUMERIK — SINUMERIK Operate browses USB sticks and configured network drives directly; programs can be copied into NC memory or executed from external storage (see EXTCALL below).
• Heidenhain — TNCremo (free from Heidenhain) transfers files over serial or Ethernet and doubles as a remote file manager; networked TNCs can also mount network shares so the file manager sees server folders directly.
• Okuma OSP — the OSP control is Windows-based, so file handling is ordinary: USB, network folders, copy and paste. Large-program capacity is generous compared to classic NC memory.
• Brother — modern CNC-D00/C00 controls take USB and Ethernet transfer; the machines are popular for high-volume drilling/tapping work where programs are small anyway.
• Mazak — Smooth-generation controls have USB ports and Ethernet networking; older Mazatrol controls used serial and various card formats by generation.

Drip-Feed / DNC: Running Without Loading

Strictly, "DNC" originally meant Direct (or Distributed) Numerical Control—a central computer serving programs to multiple machines. On the shop floor the word almost always means one thing now: the program never loads into control memory. It lives on the PC, the memory card, or the network share, and the control executes blocks as they stream in, holding only a small buffer of upcoming blocks ahead of the cutter. When the buffer's front block is executed it is discarded and another is pulled in behind.

That architecture buys you unlimited program size and costs you three things:

• No jumping backward. Blocks behind the buffer are gone. A GOTO or loop that targets an earlier line, or a subprogram call back into the streamed file, cannot work—the control would have to rewind a stream it no longer has. Drip-fed programs must be straight-line code. (Calling a separate subprogram that lives in control memory is fine.)
• Restarting mid-program is painful. With a program in memory you can search to a block, restart, and go. In a stream, "block 480,000" means fast-forwarding the sender to the right spot and re-establishing modal state (offsets, feed, spindle, comp) manually. Good practice: break monster programs at tool changes so any restart begins at a clean tool-start header.
• Feed starvation. If blocks arrive slower than the machine consumes them, the buffer empties and the machine hitches—a momentary dwell at full engagement that leaves witness marks on a finished surface and hammers the tool.

Starvation is just arithmetic—compare what the link can supply against what the toolpath demands. Supply side: a serial link at 19,200 baud moves roughly 1,920 characters per second (about 10 bits on the wire per character, counting start and stop bits). Demand side: feedrate divided by segment length is the block-consumption rate. Worked once:

SUPPLY  (what the link delivers)
19,200 baud / 10 bits per char        = 1,920 chars/sec
1,920 chars/sec / ~20 chars per block =    96 blocks/sec

DEMAND  (what the toolpath consumes)
200 in/min feed / 60                  =  3.33 in/sec
3.33 in/sec / 0.010 in per segment    =   333 blocks/sec

333 needed  vs  96 delivered  ->  the machine starves

The link supplies less than a third of what the toolpath demands—the machine will hitch no matter how big the buffer is, because a buffer only smooths variation in supply, it cannot raise the average. Your options: raise the link speed (Ethernet or memory-card DNC makes this a non-issue), lengthen the segments (a looser CAM chord tolerance means fewer, longer blocks), or slow the feed. This is also why the control's own block-processing rate matters—a slow interpreter starves itself even from a fast source, and it is why high-speed-machining lookahead options exist on modern controls.

So when do you stream instead of load? The decision is usually simple:

• Fits in memory → load it. In-memory programs restart cleanly, allow subprogram logic and loops, and don't depend on a link staying up mid-cut.
• Too big, control has a fast local source (memory card, USB, network share) → stream from that source via the mechanisms in the next section. Fast local streaming keeps the buffer full and starvation off the table.
• Too big, serial is all you have → classic PC-to-control drip-feed—and now the arithmetic above governs whether the surface finish survives it.

Calling External Programs: M198 and EXTCALL

Modern controls wrap drip-feed in a cleaner idea: keep a small main program in control memory and call the giant file from external storage as a subprogram. The control streams the external file for the duration of the call, then returns.

Fanuc: M198

M198 calls a subprogram from an external device—classically the memory card, which is fast enough that starvation stops being a concern. The external-device channel must be configured on the control, and the called file must be straight-line code (no backward jumps, per the buffering rule above).

O0100 (MAIN - LIVES IN CONTROL MEMORY)
T5 M06                 (FINISH BALL MILL)
G54 G90 S12000 M03
G43 H05 Z1.0 M08
M198 P8001             (RUN O8001 FROM THE MEMORY CARD)
G91 G28 Z0 M09
M30

Siemens: EXTCALL

SINUMERIK's EXTCALL executes a program from external storage (USB, network drive) by path, reloading it through a buffer—same streaming model, same no-backward-jump constraint inside the called file.

; MAIN PROGRAM IN NC MEMORY
T="BALL_6MM" M6
G54 S12000 M3
EXTCALL "CAVITY_FINISH"   ; streams the external file
M30

Haas: run it from where it sits

On the Haas NGC you often don't need a call at all—the control can select and run a program directly from USB or from a Net Share folder in Memory mode, streaming it without copying it into user memory first. For a multi-tool job, keep the main program local and put only the huge surfacing file on the share.

Heidenhain: PGM CALL by path

Heidenhain's CALL PGM takes a file path, and on a networked TNC that path can point at a mounted network drive—so the mechanism is the ordinary program call, aimed at external storage. TNCs also historically supported running programs over the data interface for the true bigger-than-memory case on older hardware.

; KLARTEXT MAIN PROGRAM
TOOL CALL 5 Z S12000
CALL PGM TNC:\CAM\CAVITY_FINISH.H   ; or a mounted network path
M30

Which Machines in This Wiki Do What

One row per control family: where programs natively live, and the sane way to run one that's too big.

Practical Setup Advice

The technology above is the easy half. The habits below are what separate a shop where transfer "just works" from one that loses an hour a week to it.

• One canonical source of truth. The posted file on the server is the program; the copy in the control is a cache. The failure mode is famous: an operator edits at the control to save a part, the edit never comes back to the server, and the next run posts the old code. Either pull control-side edits back and re-post through CAM, or run from the share so there is no second copy to drift.
• Version the post output. Posted G-code is generated text—it belongs in the same revision discipline as any other released document (dated folders at minimum, real version control ideally). "Which program cut these parts?" should have an answer.
• Verify after transfer on legacy serial. RS-232 with marginal settings can drop or corrupt characters silently. Send the file back from the control and compare against the original (or use your DNC software's compare function) before trusting a first run. A missing decimal point is a crash, not a typo.
• Match settings once, write them down. Tape a card with the working serial parameters (baud, parity, data/stop bits, handshake) inside the cabinet door of every serial machine. Twenty minutes of guessing per incident, forever, or one index card.
• ITAR / controlled data. A networked control is a data-transfer endpoint like any workstation: the programs on it (and the geometry they encode) can be technical data subject to the same handling rules as the drawings. That doesn't mean air-gapping every machine—it means the program folders a control can reach should have the same access controls, user accounts, and audit trail as the drawing vault, USB ports should be part of your media policy rather than an exception to it, and machine LANs should be segmented from guest and office traffic. Treat it as ordinary scope definition, done once, rather than a crisis.

See also: External Output / DPRNT for data flowing the other direction—out of the control over these same links; Post Processors for where the transferred file comes from; and G-Code & M-Code Fundamentals for reading what's inside it.

References

• Fanuc, Operator’s Manual (data input/output and subprogram call chapters), FANUC Corporation.
• Haas Automation, Next Generation Control Operator’s Manual (devices and Net Share sections), Haas Automation Inc.
• Siemens, SINUMERIK Operate / Programming Manual (EXTCALL and program management sections), Siemens AG.
• Heidenhain, TNC User’s Manual and TNCremo documentation, DR. JOHANNES HEIDENHAIN GmbH.
• Peter Smid, CNC Programming Handbook (program loading and communications coverage), Industrial Press.