Wireless DNC Setup: Troubleshooting Drip-Feed Dropouts

Overview: What Wireless DNC Actually Solves

Replacing hard-wired RS-232 runs to each CNC with a shop-floor laptop, a USB-to-RS232 adapter, and a wireless link removes the two chronic problems of cabled DNC: serial cable bundles trailing across walkways or overhead trays, and the walk back to the office for every program revision. The working topology proven in the field is:

1. Office PC holds the master NC program library on a shared folder.
2. Shop laptop joins the plant WLAN and maps that share as a network drive.
3. Laptop connects to the CNC control via USB-to-RS232 adapter and a machine-specific serial cable.
4. DNC/communications software on the laptop performs send-to-machine and receive-from-machine, then writes the received file back to the laptop or the office share.

That configuration works reliably for whole-file transfers — programs that fit entirely in the control's program memory. It becomes a hazard the moment you drip-feed (DNC mode / tape mode / continuous execution from the serial port). The distinction between those two modes is the single most important design decision in this article.

Full-File Upload vs. Drip-Feed: Failure Modes

Root Causes of Wireless DNC Failures

1. Non-buffering DNC software

Many DNC packages open the source file and stream it block-by-block straight to the COM port. If the source path is a UNC/mapped network drive, every block read is a network I/O. One lost association, roaming event, or VPN renegotiation and the read blocks — the serial stream pauses. If the control is executing from that stream, motion behavior at that moment is controller-dependent and not something you want to characterize experimentally with a tool engaged.

Rule: the file being transmitted must reside on the local disk of the transmitting machine before the first block leaves the port.

2. Electromagnetic interference from the machine itself

CNC machines are strong EMI sources — spindle and axis drives switch at high frequency, and the resulting broadband noise plus contactor transients can degrade 2.4 GHz WLAN link quality near the machine and inject noise onto unshielded RS-232 runs. Symptoms include intermittent framing/parity errors, transfers that fail at a different byte count each attempt, and WLAN throughput that collapses only while the spindle runs.

3. VPN and roaming layers stacked on top of the transfer

Shop networks that route file access through a VPN tunnel add another failure domain. A tunnel rekey or reconnect looks identical to a dropped network drive to the DNC software. Controls with strict serial timeouts (this class of failure is commonly seen loading long programs into Heidenhain TNC controls) will error out on the resulting gap.

Recommended Architecture

Option A — Wireless laptop, local staging folder (simplest)

1. Create a dedicated staging folder on the laptop's local drive, e.g. C:\DNC_OUT. Put a shortcut on the desktop.
2. Drag the programs you intend to run from the office share into C:\DNC_OUT. This is a copy operation over the WLAN; if it fails, it fails harmlessly and you retry.
3. Point the DNC software at C:\DNC_OUT only. Never browse to a network path from inside the DNC send dialog.
4. After the machining job is complete and any edited program has been received back and archived to the office share, empty C:\DNC_OUT.

Clearing the folder between jobs is not housekeeping pedantry — it prevents sending a stale revision that was left behind from a previous setup, which is the most common non-electrical cause of scrapped first articles in this workflow.

Option B — Wired DNC PC at the machine, wireless only for authoring

Keep an older PC hard-wired to the plant Ethernet at the machine, cabled to the control's serial port. Author and edit on the wireless laptop, then drag files into a shared folder on that PC. The wireless link now carries only file copies; the drip-feed stream originates from a wired machine with local disk access. This is the configuration to use if you drip-feed regularly.

USB-to-RS232 Adapter Selection and Setup

The adapter is the most common source of "it worked yesterday" complaints. Consumer-grade adapters from office-supply retailers (a Belkin unit purchased for about $29 has been used successfully for straight file transfer) are adequate for whole-file upload/download, but evaluate them against these points:

Serial parameter matching

Both ends must agree exactly. Read the values out of the control's I/O parameter screen and mirror them in the DNC software:

Baud rate      : must match control setting (e.g. 4800 / 9600 / 19200 / 38400)
Data bits      : 7 or 8
Parity         : Even / Odd / None
Stop bits      : 1 or 2
Flow control   : XON/XOFF (software) or RTS/CTS (hardware) - must match
End-of-block   : CR, LF, or CR+LF as the control expects
Control codes  : DC1..DC4 handling, % start/end markers

Mismatched flow control is the classic long-program failure: short programs transfer fine because they fit the control's buffer, long ones truncate at a consistent byte count once the buffer fills and the control's stop request is ignored.

Cabling and grounding

• Use shielded serial cable with the shield bonded at one end only to avoid a ground loop between the control cabinet and the laptop.
• Route the serial cable away from spindle/servo power conductors and drive cabinets. Cross power runs at 90 degrees where crossing is unavoidable.
• Keep the run as short as practical. RS-232 is a low-noise-margin, single-ended signal; long runs in a machine environment are exactly where EMI shows up as parity errors.
• Verify the pinout the control expects (2/3 swap, DTR/DSR or RTS/CTS jumpering at the control end). Do not assume a straight-through cable works.

Verification Procedure

1. Baseline the link. Send a short known-good program with the spindle off. Confirm clean receipt at the control.
2. Test under machine load. Repeat the transfer with the spindle and axes running. If the transfer now fails or the WLAN link degrades, you have an EMI problem, not a software problem.
3. Round-trip verify. Send a program to the control, then receive it back to a new file on the laptop and byte-compare against the original (file compare utility or checksum). Any difference indicates parity, flow-control, or control-code mismatch.
4. Check block counts on long programs. Compare the block/line count at the control against the source file. A consistent truncation point identifies a flow-control failure.
5. Dry-run before cutting. Run the transferred program in single block with rapid override at zero and Z offset raised, especially the first time after any change to adapter, cable, or DNC settings.
6. Confirm the staging folder is current. Before the run, verify the file timestamp in the local staging folder matches the office master.

Operating Rules

• Transmit only from a local drive. No network paths inside the DNC send dialog.
• Drip-feed only from a wired machine, or from DNC software that has demonstrably loaded the entire file into memory first.
• Empty the staging folder after every job.
• Keep the office share as the single source of truth. Edits made at the control get received back and pushed to the share before the setup is torn down.
• Do not let the laptop sleep during a transfer — the USB adapter will re-enumerate and the port handle dies.
• Keep one known-good serial cable and one spare adapter in the toolbox. Swapping hardware is the fastest way to isolate an intermittent.

FAQ