Siemens 802C Serial Handshaking: Configure RTS/CTS vs XON/XOFF

Problem Overview

Field engineers commissioning the Siemens SINUMERIK 802C controller frequently encounter a serial file transfer failure that looks like a configuration paradox: the controller menu is set to XON/XOFF software handshaking, PCIN on the PC side is configured to match, the cable tests good against a SINUMERIK 810D, and yet no data is ever delivered to the controller. RX activity on the PC is silent, the transfer never advances, and the operator sees a hung communication session.

The root cause is a mismatch between the controller's expected flow control mechanism and the transfer protocol used by PCIN. The 802C firmware exposes XON/XOFF in the serial setup menu because it shares a common parameter set with other SINUMERIK controllers, but the reliable transfer path for the 802C base line with PCIN 4.x/6.x and WinPCIN is RTS/CTS hardware handshaking. Selecting XON/XOFF leaves the 802C waiting for in-band flow control characters that PCIN never sends, while the actual data stream is gated by control lines the controller has been told to ignore.

This article documents the underlying protocol behavior, the cable wiring required for hardware handshaking, the PCIN configuration parameters that must agree on both sides, and the verification steps that confirm a healthy link. The same procedure applies whether you are moving part programs, tool lists, or compensation data files.

Handshaking Fundamentals: Hardware vs. Software Flow Control

RS-232 flow control exists because the sender and the receiver operate at independent speeds and have independent buffer depths. If the sender overruns the receiver, characters are dropped. The two dominant flow control mechanisms are fundamentally different in where and how the pause/resume signal travels.

The crucial point for the 802C is the transparency row. PCIN transfers files that contain arbitrary byte values: part program G-code is mostly ASCII but tools, compensation tables, and binary archives contain the full 0x00-0xFF range. If the receiver is gating on XON/XOFF, any payload byte that happens to equal 0x11 or 0x13 will be mis-interpreted as a flow control command, truncating or corrupting the file. The 802C base line firmware does not implement XON/XOFF escaping, so the transfer cannot be made reliable with software handshaking. Hardware handshaking sidesteps this entirely because RTS/CTS signals travel on separate wires and never appear in the data stream.

SINUMERIK 802C Serial Interface Architecture

The 802C base line exposes its serial channel through the X122 interface on the operator panel backplane. The electrical interface conforms to RS-232C (EIA/TIA-232), and the protocol used by PCIN for file transfer is a Siemens-proprietary framed protocol layered on top of the asynchronous UART. The relevant electrical and protocol parameters are:

Verify the exact pinout and supported baud rates against the device-specific SINUMERIK 802C base line operator's manual on the Siemens Industry Online Support portal before commissioning. The reference manuals are organized by controller variant and firmware release.

Why XON/XOFF Fails on the 802C with PCIN

When the operator selects XON/XOFF in the 802C serial setup, the firmware configures its UART to interpret received bytes 0x11 and 0x13 as flow control tokens. PCIN, however, expects to drive the 802C's CTS line to throttle its own transmissions. Two problems compound:

1. No outbound gating. PCIN never sees a software XOFF because it is not running in software-handshaking mode either; the 802C has only listened, never spoken the XOFF token. PCIN therefore dumps the entire file into its transmit buffer, which the 802C either discards or partially accepts, depending on whether any payload byte collides with 0x11/0x13.
2. Payload collision. When a payload byte coincidentally equals XON (0x11) or XOFF (0x13), the 802C's UART either spuriously resumes or pauses, desynchronizing the framed protocol. PCIN's framing layer does not include escaping for these bytes, so a single occurrence in the wrong place breaks the transfer.

Field reports confirm that this manifests as "nothing happens" on the controller side: the 802C serial menu shows the configuration is set, PCIN reports it has begun sending, but the controller's part program directory never updates and no error message is raised. The cable itself is fine; both controllers (802C and 810D) passed a physical test, which proves the wires are continuous. The fault is purely in the flow control negotiation.

Cable Requirements: Full Hardware Handshaking Null Modem

A standard 3-wire null modem (TX, RX, GND only) is insufficient for the 802C because it leaves RTS and CTS unconnected. PCIN requires the 802C to assert RTS when it is ready to receive, and to gate its own transmissions on CTS. Without these signals looped back correctly, the sender has no way to know when the receiver is ready.

The required cable is a null modem with full hardware handshaking. The exact pinout depends on whether the controller uses a DB-25 or DB-9 connector; refer to the operator manual for the specific variant. A representative full-handshaking null modem between a PC DB-9 and the 802C connector is:

The two pairs that matter most for flow control are RTS↔CTS crossed and DTR↔DSR crossed. When you wire these correctly, each side asserts a "ready" line that the other side interprets as "go ahead." A common field error is to loop RTS back to RTS and CTS back to CTS on the same end of the cable; this satisfies the local UART but provides no information to the far end. Always cross them.

To verify the cable before connecting it to the controller, perform a continuity test with a multimeter:

1. Confirm TX on the PC end lands on RX on the controller end.
2. Confirm RX on the PC end lands on TX on the controller end.
3. Confirm RTS on the PC end lands on CTS on the controller end.
4. Confirm CTS on the PC end lands on RTS on the controller end.
5. Confirm signal ground is continuous on the dedicated ground pin.
6. Confirm shield/frame ground is bonded at one end only to avoid ground loops.

PCIN Software Configuration

PCIN is the Siemens toolchain used to move files between a PC and a SINUMERIK controller over a serial link. Two interfaces exist: the legacy PCIN 4.x (DOS-era) and the more recent WinPCIN for Windows. The relevant setup parameters must match the controller exactly, because the 802C will silently ignore a transfer whose framing or handshake disagrees.

The single most consequential parameter is the handshake field. Set it to RTS/CTS before initiating any transfer. Save the configuration so subsequent sessions do not revert to defaults.

802C Controller-Side Configuration

On the 802C base line, the serial interface is configured through the Setup menu on the operator panel. The exact menu path varies slightly by firmware release, but the general sequence is:

1. Press the Setup key to enter the setup menu.
2. Navigate to the serial interface / communication submenu.
3. Set the baud rate to the value matched in PCIN.
4. Set the handshake to RTS/CTS (not XON/XOFF).
5. Save the configuration and exit back to the operating area.

If the menu offers a "protocol" or "transfer mode" parameter, leave it at the PCIN-compatible default. Do not enable any diagnostic or echo mode, as these will interfere with the framed protocol.

Step-by-Step: Resolving the Handshaking Mismatch

Use this procedure to bring a failing 802C serial link into service. Each step has an explicit verification so you can isolate any remaining fault.

1. Power down both devices. Disconnect the serial cable before changing wiring. Hot-swapping DB-25/DB-9 connectors can short signal lines and damage UARTs.
2. Inspect or rebuild the cable. Use the full-handshaking null modem pinout from the table above. A pre-built cable labeled "null modem" is often a 3-wire variant and will not work.
3. Configure PCIN. Launch PCIN or WinPCIN, open the interface setup, set COM port, baud rate, and select RTS/CTS hardware handshaking. Save the profile.
4. Configure the 802C. On the controller, set the serial parameters to match PCIN exactly, with handshake set to RTS/CTS.
5. Connect the cable. Power up both devices. Confirm the PC recognizes the COM port (Device Manager on Windows should show the USB-to-serial adapter or native COM port without errors).
6. Run a receive test. From PCIN, send a small known-good file (for example, a short G-code program such as %_N_TEST_MPF). Watch the controller's directory listing for the new file.
7. Observe the handshake LEDs. If your USB-to-serial adapter exposes RTS/CTS LEDs, you should see them toggle during transfer. Frozen LEDs indicate a wiring fault.
8. Verify the file. Open the received file on the controller (or read it back via PCIN) and confirm byte-for-byte equality with the source.

Verification Procedure and Diagnostics

Beyond a successful transfer, several diagnostic checks confirm the link is healthy and will remain stable under production load.

Loopback Test

With the controller disconnected and the cable looped back on itself (TX to RX, RTS to CTS, DTR to DSR), PCIN should echo any transmitted data back to its receive window. If the echo fails, the fault is in the PC, the adapter, or the cable - not the controller.

Voltage Measurements

With the cable connected to a powered-on 802C and a running PC, measure the RS-232 levels with a multimeter or oscilloscope:

A controller that is in XON/XOFF mode will leave RTS and CTS at indeterminate or static levels because the firmware does not drive those lines as part of the software-handshake state machine. If your measurements show RTS/CTS not toggling at all, the controller is still configured for software handshaking and the menu change did not take effect.

Transfer Log Inspection

PCIN displays a transfer log with byte counts, error counts, and timing. A healthy transfer shows zero errors and a steady data rate equal to the configured baud rate divided by 10 (for 8N1 with overhead). Re-transmitted blocks or rising error counts indicate either buffer overruns (cable too long, baud rate too high) or noise (missing shield ground).

Troubleshooting Matrix

Notes on Edge Cases and Field-Proven Caveats

Several recurring situations are worth calling out explicitly for the field engineer.

• USB-to-serial adapters vary. Some low-cost adapters only expose TX, RX, and GND on the DB-9 and do not break out RTS/CTS to the connector. Verify with the adapter datasheet (FTDI FT232R, Silicon Labs CP2102N, and WCH CH340 all break out the full handshake set when properly implemented).
• Cable length vs. baud rate. RS-232C is rated to 15 m at low baud rates, but in practice the 802C's receiver begins to show errors above 3 m at 115200 baud. For shop floors with motor drives and VFDs nearby, use shielded cable and keep length under 5 m.
• Firmware variants. Earlier 802C base line firmware revisions had different menu structures. When in doubt, upgrade the controller to the latest released firmware (available on the Siemens Industry Online Support portal) and re-verify the serial menu.
• PCIN version compatibility. WinPCIN is the supported Windows replacement for PCIN 4.x. The protocol is forward-compatible, but the saved profile format differs. Do not mix profiles between versions.
• Reverting to XON/XOFF "just to test." Several operators have reported that toggling back to XON/XOFF after a working RTS/CTS session breaks the next transfer because the controller retained stale state. Always cycle power on the controller after a handshake change.