// September 8, 2026 · Crux Resolve LLC

CNC RS232 over WiFi: DNC and program-transfer considerations

Many older CNC controls still exchange programs through RS232. A WiFi serial bridge can remove the long host-to-machine serial cable in some DNC and file-transfer workflows, but only when the machine, cabling, flow-control method, serial settings, and PC software are all compatible.

Do not buy by machine brand alone. Different controls—even within the same manufacturer—can use different connectors, pinouts, flow-control methods, and serial settings. Check the exact control documentation before connecting a bridge.

Why CNC equipment still uses RS232

Legacy and long-lived CNC controls often use serial communication for part-program transfer, setup, diagnostics, or DNC workflows. The machine may remain mechanically useful for decades even when the surrounding computers and networks change.

That makes the communication layer a natural modernization target: keep the control, but replace an inconvenient physical cable path with a local network connection where the serial requirements allow it.

The basic WiFi DNC path

Typical path: DNC / transfer software ⇄ TCP or virtual COM ⇄ WiFi serial bridge ⇄ RS232 cable ⇄ CNC control.

The bridge does not convert G-code or understand the CNC program format. It transports the same serial byte stream the control already expects.

If the host software can open a TCP connection directly, it may talk to the bridge without a local COM port. Older DNC software that only opens COM ports may need a compatible TCP-to-virtual-COM utility.

Step 1: identify the exact CNC serial interface

Start with the machine or control manual. Record:

whether the interface is explicitly RS232,
connector type and gender,
TX, RX, and signal-ground pins,
baud rate, data bits, parity, and stop bits,
software or hardware flow-control requirements,
and any special DNC/drip-feed timing behavior.

A DB9 or DB25 connector is not enough by itself. See DB9 Does Not Mean RS232 for the interface-identification process.

Step 2: distinguish software flow control from hardware flow control

This is especially important for CNC transfers.

XON/XOFF software flow control

XON/XOFF uses control characters inside the serial data stream to pause and resume transmission. Because those characters travel as bytes, a transparent serial bridge can carry them when the UART and application timing are otherwise compatible.

RTS/CTS hardware flow control

RTS and CTS use separate physical signal lines outside the TX/RX byte stream. A three-wire bridge cannot reproduce those signals if its hardware does not route them.

Current GhostBridge GB-01 limitation: GB-01 does not route RTS/CTS or other modem-control lines. A CNC workflow that requires hardware RTS/CTS is therefore not a direct fit for the current production hardware.

Step 3: verify cable orientation

The CNC control and bridge must be wired so each transmitter reaches the opposite receiver. Depending on DTE/DCE orientation, the connection may require a straight-through cable, a null-modem arrangement, or a DB25-to-DB9 adapter with the correct signal mapping.

Do not infer the wiring only from connector gender. Use the documented pinout. See RS232 DTE vs DCE and Null-Modem Cables Explained.

Step 4: match the serial settings exactly

The bridge-side UART and CNC control must use the same communication parameters. A typical notation such as 9600 7E1 or 9600 8N1 describes baud rate, data bits, parity, and stop bits.

CNC controls may use settings that differ from modern defaults, so do not assume 8N1. Read the actual machine configuration and match it deliberately.

Step 5: understand what the PC software expects

DNC and transfer programs vary. Some are designed around physical COM ports; others support network endpoints or external serial device servers.

If your software only supports a COM port, test the complete virtual-COM path before depending on it for production transfers. The virtual-COM utility, operating system, WiFi link, bridge firmware, and CNC control all become part of the communication chain.

Program upload/download vs drip feeding

Sending or receiving a complete program is generally a simpler communication case than real-time drip feeding. Drip feeding can place tighter demands on flow control, buffering, timing, and reconnect behavior.

A bridge that works for a short file transfer should not automatically be assumed to work for long unattended drip-feed operation. Test the exact workload you intend to use.

When WiFi is useful in a CNC workflow

The PC or operator does not need to remain physically tethered to the control.
Running or maintaining a long serial cable through the shop is inconvenient.
The machine control is still useful but lacks modern Ethernet or WiFi connectivity.
The host workflow already supports TCP or a tested virtual-COM layer.
The control uses compatible RS232 and does not require unsupported hardware handshaking.

When a hardened industrial device server is the better choice

A shop-floor installation may need features beyond a compact local bridge, including DIN-rail mounting, wide-temperature ratings, isolated serial ports, 12–48 V industrial power, managed WLAN modes, RS422/RS485, or full hardware handshaking.

If those are requirements, choose hardware designed for that environment rather than treating a compact three-wire bridge as a universal industrial replacement.

Where GhostBridge GB-01 fits

GhostBridge GB-01 is a local WiFi-to-standard-3-wire-RS232 TCP bridge. Its current DB9 male interface uses pin 2 RX into GhostBridge, pin 3 TX out, and pin 5 signal ground.

It can be a candidate for a CNC transfer workflow only when the exact control uses compatible true RS232, the required serial settings can be matched, the cable orientation is correct, and the workflow does not require RTS/CTS or other physical modem-control lines.

If you know the control model but are unsure about those requirements, use the compatibility request rather than ordering by brand or connector shape.