Sinumerik 802D RS-232 PC-to-CNC File Transfer Troubleshooting
Asymmetric RS-232 file transfer on a Sinumerik 802D controller - where the CNC-to-PC direction works but the PC-to-CNC direction fails silently without raising any alarm - is one of the most common commissioning and shop-floor issues on Minimill-class CNC machines. The asymmetry is itself the diagnostic key: the receive path on the CNC side, the receive framing logic, or the receive handshake path has degraded, while the transmit path remains healthy. This reference covers the complete diagnostic tree from physical cable wiring through protocol configuration to part-program header requirements, and is written for engineers who need to restore bidirectional DNC/loading capability without returning the controller to the OEM.
1. Problem Definition and Failure Mode
The reported fault pattern is specific and reproducible:
- CNC to PC (receive on PC): Works correctly. The 802D transmits files, the PC receives them, and the file contents are correct.
- PC to CNC (receive on CNC): Fails silently. No alarm is raised on the HMI, no error code is logged, and the transfer appears to start and never complete.
- Cable: Verified visually, and was functional 48 hours prior.
-
Part program sample shown by operator: Begins with
%_N_16KK_MPFfollowed by;$PATH=/_N_MPF_DIR, then standard preparatory commandsG291 G64 G91 G28 Z0 G0 G17 G40 G49 G80 G90.
A silent PC-to-CNC failure (no alarm, no message) is most often caused by one of five root causes, ranked by field frequency:
- Null-modem cable RX/TX crossover degraded or intermittent on one conductor pair only.
- Receive protocol mismatch (XON/XOFF vs. RTS/CTS) between 802D and PC software.
- Baud rate, data bits, parity, or stop bit mismatch on the receive side.
- MPF file header malformed or path declaration missing the leading
$in column 1. - PC-side COM port or USB-to-serial adapter driver fault.
2. Sinumerik 802D V.24 (RS-232) Interface Specifications
The Sinumerik 802D exposes a single V.24 (RS-232-C compatible) channel on the rear panel, typically labelled X6 on the PCU / CCU housing. The interface conforms to the EIA/TIA-232-E and ITU-T V.24 electrical and mechanical specification and is intended for short-cable (<=15 m), point-to-point DNC file transfer to a host PC.
Key electrical characteristics inherited from the RS-232 standard:
| Parameter | Value | Notes |
|---|---|---|
| Standard | EIA/TIA-232-E (V.24) | Asynchronous serial, point-to-point |
| Logic levels (mark/space) | -3 V to -25 V = 1 (mark); +3 V to +25 V = 0 (space) | Inverted from TTL |
| Maximum cable length | 15 m at full speed | Shorter is more reliable in shop floor environments |
| Maximum signalling rate | Up to 115.2 kbps (802D default 19.2 kbps) | Reference: DigiKey - Understanding the RS-232 Standard |
| Connector (802D X6) | 9-pin D-sub male (DB9) | Some early 802D variants use DB25 |
| Common reference | Texas Instruments SLLA607 - RS-232 Glossary and Selection Guide | Authoritative reference for framing and signal levels |
The 802D V.24 channel is a true DTE (Data Terminal Equipment) port. To communicate with a PC, which is also a DTE, you require a null-modem (crossover) cable. A straight-through cable will yield exactly the symptoms described: TX from CNC reaches the PC, but RX from the PC is looped back to the CNC TX pin, not its RX pin.
3. RS-232 Protocol Fundamentals
RS-232 is asynchronous serial communication. Each transmitted character is framed between a start bit (space) and one or more stop bits (mark), with an optional parity bit. No shared clock exists; both ends must be configured identically for bits per character, parity, and stop bits or framing errors will silently corrupt every character.
Reference framing for a single byte (e.g. 0x41, the ASCII letter 'A', with 8N1, no parity):
| Start | D0 | D1 | D2 | D3 | D4 | D5 | D6 | D7 | Stop |
|---|---|---|---|---|---|---|---|---|---|
| 0 | 1 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 1 |
Bits are transmitted LSB first. Bit time at 19200 baud is 52.08 microseconds; at 9600 baud it is 104.17 microseconds. Mismatch between sender and receiver of even a few percent in bit time will eventually produce framing errors, manifesting as silent receive failure on the 802D because the protocol layer discards the broken frame.
4. Cable Wiring: Null-Modem Requirements
Because both the 802D and the PC are DTEs, the cable must implement a null-modem crossover. The minimum required signal set is:
| DB9 Pin | Signal | Direction at 802D (DTE) | Direction at PC (DTE) |
|---|---|---|---|
| 2 | RXD (Receive Data) | Input | Input |
| 3 | TXD (Transmit Data) | Output | Output |
| 4 | DTR (Data Terminal Ready) | Output | Output |
| 5 | SG (Signal Ground) | - | - |
| 6 | DSR (Data Set Ready) | Input | Input |
| 7 | RTS (Request To Send) | Output | Output |
| 8 | CTS (Clear To Send) | Input | Input |
4.1 Minimum null-modem (3-wire, no handshake)
Used when both sides are configured for XON/XOFF (software handshake):
- DB9-2 (RXD) - 802D - to - DB9-3 (TXD) - PC
- DB9-3 (TXD) - 802D - to - DB9-2 (RXD) - PC
- DB9-5 (SG) - 802D - to - DB9-5 (SG) - PC
4.2 Full null-modem (7-wire, hardware handshake RTS/CTS)
- DB9-2 <-> DB9-3 (RXD/TXD crossover)
- DB9-3 <-> DB9-2 (TXD/RXD crossover)
- DB9-4 (DTR 802D) <-> DB9-6 (DSR PC) AND DB9-1 (CD PC) - loopback to assert DTE-ready to PC
- DB9-6 (DSR 802D) <-> DB9-4 (DTR PC) AND DB9-1 (CD PC) - assert DTE-ready to 802D
- DB9-7 (RTS 802D) <-> DB9-8 (CTS PC)
- DB9-8 (CTS 802D) <-> DB9-7 (RTS PC)
- DB9-5 (SG) <-> DB9-5 (SG)
4.3 Recommended cable
Use a shielded, twisted-pair null-modem cable with metalised backshells. The Siemens catalog reference for a ready-made V.24 cable for Sinumerik controllers is the 6FX2 series; consult the Siemens Industry Online Support portal for the current part number for your specific 802D variant. For a field-fabricated replacement, use at minimum three twisted pairs (TX/RX, RTS/CTS, DTR/DSR) with overall foil + braid shield bonded to the connector shell at both ends.
5. 802D RS-232 Parameter Configuration
Access the interface parameters through the operator panel:
- Press Setup on the HMI.
- Navigate to RS-232 (or V.24 on localised builds).
- Open the Interface configuration page.
The relevant parameters for receive-side debugging are:
| Parameter | Typical Options | 802D Default | Failure Symptom if Wrong |
|---|---|---|---|
| Baud rate | 9600, 19200 | 19200 | Silent framing errors / garbage characters / silent timeout |
| Data bits | 7, 8 | 8 | Silent corruption of all characters |
| Parity | None, Even, Odd | None | Silent corruption when parity mismatch |
| Stop bits | 1, 2 | 1 | Silent framing error if mismatch |
| Protocol | XON/XOFF, RTS/CTS | XON/XOFF | Transfer hangs at start if mismatch with cable wiring |
| XON character | 0x11 (DC1) | 0x11 | Transfer stalls if PC sends different value |
| XOFF character | 0x13 (DC3) | 0x13 | Transfer stalls if PC sends different value |
| End-of-transmission (EOT) | 0x04 | 0x04 | 802D never recognises end of file |
| Stop bit on receive | 1, 2 | 1 | Silent framing error |
6. PC Software: PCIN and WinPCIN Setup
Siemens historically ships two transfer utilities for the Sinumerik family:
- PCIN - DOS-lineage utility. Configurable protocol and baud. Useful for legacy controllers.
- WinPCIN - Windows-native port of PCIN with the same configuration fields plus GUI feedback.
Whichever tool you use, the PC-side configuration must match the 802D byte-for-byte:
| PCIN/WinPCIN Field | Must Match 802D |
|---|---|
| Baud rate | Baud rate |
| Data bits | Data bits |
| Parity | Parity |
| Stop bits | Stop bits |
| Protocol (XON/XOFF or RTS/CTS) | Protocol |
| COM port number | Physical port in use |
If you are using a USB-to-RS-232 adapter (very common today because no modern PC has a native DB9), verify the following before blaming the 802D:
- The adapter uses a proven chipset (FTDI FT232, Silicon Labs CP2102, or WCH CH340 are widely compatible).
- The driver is signed and current. Open Device Manager and confirm no yellow exclamation on the COM port.
- The COM port number assigned by Windows is the one configured in WinPCIN. WinPCIN does not auto-detect.
- The adapter supports the chosen baud rate. Some low-cost adapters cap at 115200 or have poor timing accuracy at 19200 in heavy electrical noise environments. Test at 9600 as a fallback.
7. MPF File Format Requirements
The Sinumerik 802D expects every part program file to begin with a specific two-line header before any G-code or comment lines. The file shown in the source ticket has the correct first header line and an incorrect second header line position. The format is rigid:
%_N_<filename>_MPF
;$PATH=/_N_MPF_DIR
; (program body starts here - comments, G-code, etc.)
Key requirements:
-
%must be in column 1 of the first line. No leading whitespace, no BOM. - The filename inside
_N_..._MPFmust be <= 24 characters, alphanumeric and underscore only. - The
_MPFextension identifies the file as a Main Program File. Use_SPFfor subprograms and_INIfor initialisation files. The 802D will silently reject a file whose extension does not match its target directory. - The path declaration
;$PATH=/_N_MPF_DIRmust be on line 2 and must start with;$. A space between;and$causes the path to be ignored and the file lands in the wrong directory - a common cause of "transferred but not visible" symptoms. - The line terminator must be CR+LF or LF. Some editors (notably Notepad in Windows) save with CR-only which older 802D firmware handles correctly but a few tools mangle. WinPCIN transmits raw bytes; the file's terminator is preserved.
G291 in the sample program: in the Sinumerik 802D context, G291 switches the interpreter to ISO dialect mode for the duration of the program. This is legal and does not affect RS-232 reception, but it does affect how subsequent preparatory commands are parsed. If the program was written under the Siemens dialect and G291 is removed on receive (e.g. by a buggy editor), the program will alarm on first execution. Always transfer the file as-is and edit only after verifying the transfer is complete.8. Step-by-Step Diagnostic Procedure
Follow this sequence. Each step is non-destructive and produces a yes/no answer that localises the fault.
Step 1 - Inspect the cable physically
- Unplug both ends.
- Inspect each pin in the DB9 hood. Bent or recessed pins are the most common cause of "it worked yesterday" failures.
- Check the backshell screws - loose shields invite noise pickup on RX.
Step 2 - Loopback test the cable
- At one end only, jumper pins 2 and 3 (RXD to TXD). Leave the other end connected to the PC.
- Run WinPCIN in Send mode with a short text file.
- If the sent text comes back in the Receive window, the PC TX/RX/Ground path through the cable is healthy.
- Remove the jumper.
Step 3 - Verify parameter parity
- Open the 802D Setup > RS-232 page and write down every parameter.
- Open WinPCIN's Configuration dialog and write down every parameter.
- Compare them line by line. Any difference is a candidate root cause.
Step 4 - Test with a known-good minimal MPF
- Create a file with the minimum legal content:
%_N_TEST_MPF
;$PATH=/_N_MPF_DIR
G91 G28 Z0
M30
- Send it through WinPCIN to the 802D.
- Watch the 802D HMI. If the file appears under Programs, the receive path is functional and your original file has a header problem.
- If the file does not appear, proceed to Step 5.
Step 5 - Use a V.24 breakout box (line monitor)
A V.24 line monitor with per-signal LEDs (commonly available from electronics distributors) is the single most effective diagnostic tool for this fault. See the related Tripp Lite (Eaton) RS-232 cable reference for guidance on connector types and signal identification.
- Insert the breakout box between the 802D X6 and the PC end of the cable.
- Initiate a PC-to-CNC transfer of the TEST file.
- Observe TXD LED on the PC side - it must flash on each character.
- Observe RXD LED on the 802D side - it must mirror TXD on the PC side. If it does not, the cable crossover is faulty or the wrong pins are crossed.
- Observe RTS (PC) and CTS (802D). If RTS is asserted by the PC but CTS is not asserted by the 802D within ~1 second, the 802D is in a non-ready state (alarm, wrong mode, full buffer).
- For XON/XOFF mode, observe the XON (0x11) and XOFF (0x13) flow-control bytes appearing on the data line.
Step 6 - Capture and decode the byte stream
- If a line monitor with a tap or a serial port sniffer is available, capture the bytes the PC transmits.
- Verify the first two bytes transmitted are
0x25 0x5F(ASCII%_) and that the file begins exactly as the 802D expects. - Compare against what the 802D receives. If the bytes differ, the PC COM port or driver is altering the stream.
Step 7 - Re-seat or replace the cable
If Steps 1-6 point to the cable, swap it for a known-good null-modem cable. The original may have a partially fractured conductor (intermittent) that allows low-current TX from the 802D to register on the PC but fails on the higher-impedance RX path back into the 802D.
9. Cable Continuity Verification with a Multimeter
If a breakout box is not available, a digital multimeter with continuity mode is sufficient for verifying the null-modem wiring. With the cable unplugged at both ends:
| Probe at PC End (DB9) | Probe at 802D End (DB9) | Expected Continuity |
|---|---|---|
| Pin 2 (RXD) | Pin 3 (TXD) | Yes |
| Pin 3 (TXD) | Pin 2 (RXD) | Yes |
| Pin 5 (SG) | Pin 5 (SG) | Yes |
| Pin 7 (RTS) - if used | Pin 8 (CTS) | Yes (full null-modem) |
| Pin 8 (CTS) - if used | Pin 7 (RTS) | Yes (full null-modem) |
| Pin 4 (DTR) | Pin 6 (DSR) + Pin 1 (CD) loopback at 802D end | Yes via loopback |
| Pin 2 to Pin 2 (same end) | - | No (would indicate miswire) |
For a 3-wire XON/XOFF cable, the RTS/CTS and DTR/DSR rows are simply not wired. For a hardware-handshake cable, every row must show continuity in the indicated pair.
10. Fault Symptom to Root Cause Matrix
| Observed Symptom | Likely Root Cause | Confirm With |
|---|---|---|
| PC-to-CNC silent, no HMI activity | Cable RX crossover open or 802D RX pin damaged | Loopback test + continuity check |
| PC-to-CNC hangs immediately | CTS not asserted by 802D (wrong protocol, wrong mode, alarm active) | Breakout box observation |
| PC-to-CNC starts, then stalls after N bytes | XON/XOFF mismatch, PC sends 0x13 but 802D expects different XOFF | Byte capture |
| File arrives on 802D but not visible in Programs | MPF header path wrong - landed in a different directory | Browse /_N_MPF_DIR and /_N_CUS_DIR on HMI |
| File arrives but alarms on execution | Line endings corrupted, BOM present, or G291 removed by editor | Inspect received file byte-by-byte on HMI |
| Transfer OK at 9600 but fails at 19200 | Cable too long, USB-serial adapter timing marginal | Shorten cable or swap adapter |
| Works once after power-up, then fails | 802D UART receiver buffer overrun or handshake latch-up | Cycle power, re-test |
| Both directions fail | Wrong cable type entirely (straight-through instead of null-modem) or 802D RS-232 disabled | Verify cable type, check Setup > RS-232 enable |
11. Verification and Acceptance
After repair, perform the following three-step acceptance test before returning the machine to production:
- Bidirectional transfer of a known-good program. Transfer a small test MPF from PC to CNC, then back from CNC to PC. Diff the two files. They must be byte-identical.
-
Program execution test. Load the transferred program on the 802D, single-block through the first five blocks, then run in AUTO. Confirm no alarm (in particular no
12080syntax error, no14011path not found, and no14012file not found). - Long-file stress test. Transfer the largest program you intend to DNC (typically a 2-axis contour around 200 kB). Confirm completion without retry. If errors occur at high baud rates, fall back to 9600 baud and document the configuration.
12. Quick Reference - Minimum Required MPF Header
For operators who only need to fix the immediate problem without reading the full diagnostic, the two-line mandatory header is:
%_N_PROGRAMNAME_MPF
;$PATH=/_N_MPF_DIR
Rules of thumb:
- Filename <= 24 chars, uppercase letters, digits, underscore only.
- Use
_MPFfor main programs,_SPFfor subprograms,_INIfor initialisation files. -
;$at the start of the path line is mandatory - do not insert a space. - Save as plain ASCII or UTF-8 without BOM. CR+LF or LF line endings both work.
13. Standards and Reference Documentation
- DigiKey - Understanding the RS-232 Standard for electrical and signalling fundamentals.
- Texas Instruments SLLA607 - RS-232 Glossary and Selection Guide for transceiver selection and timing.
- Tripp Lite (Eaton) RS-232 Cable and Connector Reference for cable assembly and connector pin identification.
- Wikipedia - RS-232 historical standard reference for protocol history and revision timeline.
- Siemens Industry Online Support for the official Sinumerik 802D operating manual, programming manual, and parameter manual (search "802D" or "SINUMERIK 802D base line").
Why does the CNC-to-PC direction work but PC-to-CNC does not on my Sinumerik 802D?
The most common cause is a degraded null-modem cable: the RXD/TXD crossover pair has higher resistance on the receive conductor, so the lower-voltage PC output fails to register on the 802D while the higher-current CNC output still reaches the PC. Verify the cable with a loopback test and continuity check on DB9 pins 2-3 crossover before changing any settings.
Which baud rate, data bits, parity, and stop bits should I use on the 802D RS-232 interface?
The Sinumerik 802D default is 19200 baud, 8 data bits, no parity, 1 stop bit (19200-8N1). Both the 802D RS-232 setup page and the PC transfer software (PCIN or WinPCIN) must be set to identical values, otherwise the receiver discards every frame silently. Use 9600-8N1 if you are using a low-cost USB-to-serial adapter or a long cable in a noisy environment.
Does the 802D require XON/XOFF or RTS/CTS handshake?
Either is supported. The 802D default is XON/XOFF (software handshake), which requires only the 3-wire null-modem (RX, TX, Ground). If you change to RTS/CTS (hardware handshake) you must also re-wire or replace the cable so that pins 7 and 8 are crossed, otherwise PC-to-CNC will hang silently because the 802D never asserts CTS.
Why is my transferred file not visible in the 802D program list?
Almost always because the second line of the file - ;$PATH=/_N_MPF_DIR - is missing, has a space between ; and $, or has the wrong directory. The 802D accepts the file but stores it in an unexpected directory. Verify the header is exactly %_N_NAME_MPF on line 1 and ;$PATH=/_N_MPF_DIR on line 2 with no leading whitespace.
Why does my program transfer OK but then alarm on execution with a syntax error?
The most likely cause is a corrupted line ending, an inserted BOM, or an editor that stripped the G291 (or other first block). Open the received file on the 802D HMI editor (or transfer it back to the PC and diff against the source) to identify the corruption. Always save MPF files in plain ASCII or UTF-8 without BOM before sending.
Can I use a USB-to-RS-232 adapter with the Sinumerik 802D?
Yes, provided the adapter uses a reliable chipset (FTDI FT232, Silicon Labs CP2102, or WCH CH340), the Windows driver is signed and current, and the COM port number assigned by Windows is the one selected in WinPCIN. Avoid no-name adapters with counterfeit FTDI chips - they often have poor baud-rate accuracy at 19200 and cause intermittent framing errors that look like the 802D is hung.