SINUMERIK 810D WINPCIN RS232 Transmission Error Field

1. Problem Description

The SINUMERIK 810D controller equipped with a PCU20 and a freshly installed replacement CCU module (no hard disk present in the CCU) reports the alarm "RS232C transmission error has occurred" during WINPCIN archive loading. Both NCK and PLC backup files trigger the alarm, and the failure pattern scales inversely with the configured baudrate:

• 9600 baud: transfer aborts within the first several percentage points of the progress bar.
• 1200 baud: transfer advances further before the alarm, but still fails mid-stream.
• 300 baud: transfer reaches approximately 90% before the alarm is raised.
• One PLC archive: cannot complete at any baudrate, even 300.
• Small NC programs (a few hundred bytes): transfer without any error.

The S4 selector is set to position 2, the reset sequence S4 = 2-3-2-3-2 is performed correctly, and S3 = 1 is engaged with the reset button. Two different RS232 cables have been swapped and both produce the same fault, and the PC end is connected to COM2 on the HMI side. The deterministic relationship between baudrate and the position at which the alarm fires points to a flow-control, buffer-handling, or NV-RAM retention fault rather than a hard cable failure. The sections below walk through the controller architecture, the WINPCIN parameters, the S3/S4 modes, and a step-by-step isolation procedure that resolves the fault in the field without specialised tooling.

2. SINUMERIK 810D PCU20 + CCU Architecture Relevant to PCIN Transfer

The SINUMERIK 810D pairs an NCU (numerical control unit) with an MMC (man-machine communication) subsystem. In the PCU20 configuration the MMC runs on a passive backplane that accepts a removable CCU (Compact Control Unit) card carrying the CPU, RAM, and the SRAM-backed NV-RAM. Without the rotating hard disk, all boot data, NCK machine data, and PLC user program must come in via the RS232 (X2 / COM2) channel using the Tape-mode protocol implemented by WINPCIN on the PC side.

When a CCU card is brand-new and the internal lithium backup battery is at low cell voltage, the SRAM may not retain the partial archive once the controller flushes its internal buffer. The PCIN write succeeds on the wire but is rejected on the next controller cycle, producing the classic late-stage transmission error. Recharging the backup battery by leaving the unit powered for several hours, or applying the archive in smaller chunks, is the standard Siemens-documented mitigation.

3. WINPCIN Configuration Parameters

WINPCIN is the Siemens-supplied Tape-mode file server that ships on the SINUMERIK toolbox disk and is documented in the SINUMERIK 810D/840D programming manuals. Mismatched serial parameters are the single most common cause of a partial-transfer abort, because the Tape-mode protocol has no native CRC - every byte the PC sends must be acknowledged by the controller's protocol stack before the next block is requested.

4. S3 and S4 DIP Switch Positions for Data Transfer

The PCU20 carries two rotary/hex switches labelled S3 and S4 that gate the NCK and PLC reset and the PCIN download modes. Selecting the wrong combination leaves the controller in normal-cycle mode where it will reject any incoming PCIN stream and surface an RS232C alarm on the next polling cycle.

For the reported fault the operator selected S4=2 and performed the reset sequence S4 = 2 -> 3 -> 2 -> 3 -> 2 with S3=1. This is correct for an NCK startup download: each toggle of S3=1 with the controller in S4=2 issues a fresh NCK reset and re-arms the PCIN receiver. After the NCK download completes the operator must switch to S4=4 and S3=2 for the PLC startup archive. Performing NCK and PLC in a single combined reset (S3=3, S4=6) is permitted but doubles the buffer pressure and is the most common trigger of mid-stream transmission aborts.

5. RS232 Interface Specification and Cabling

The PCU20 COM2 (X2) is a D-sub 9-pin male with the Siemens RS232C variant pinout. A standard 1:1 DB9 male-to-female RS232 extension cable is the correct choice; null-modem crossover is not required because the controller already presents DTE behaviour on COM2.

1:1 wiring is correct because both ends are DTE; only the ground, TX, RX, and the four handshake lines are required for PCIN. Pins 1 (CD) and 9 (RI) are not used.

Cable length should not exceed 15 m at 9600 baud, 30 m at 4800 baud, and 60 m at 2400 baud or below. Shielded cable (e.g. Lapp ETHERLINE or Belden 8102) is required in any plant environment with VFD cables, welding supplies, or relay panels within 1 m of the run. Unshielded cable in such environments is the single most common root cause of an "aborts at 90% at 300 baud but works for tiny files" symptom - the larger the transfer the longer the cumulative noise exposure.

6. Baudrate Behaviour Analysis

The observed inverse relationship between baudrate and progress (9600 fails fastest, 1200 progresses further, 300 reaches 90%) is the textbook signature of one of three root causes:

1. Flow-control mismatch. When WINPCIN is set to "none" but the controller expects XON/XOFF (or vice versa), the controller's UART overruns at high line speeds because it has no time to send an XOFF before the next block arrives. Lowering baudrate slows the data rate enough that the controller's poll loop keeps up.
2. Buffer flush in the PCU20 PCIN task. The PCU20 dedicates a single HMI task slot to the PCIN handler. If the HMI is also servicing display updates or if a background PLC scan is running, the PCIN task is preempted. At 9600 baud the input buffer overflows within a few seconds; at 300 baud it survives several minutes.
3. USB-to-serial converter overrun. Consumer-grade USB-to-serial adapters without a 128-byte FIFO (CH340, CP2102 in default mode, Prolific PL2303 HXA) drop characters above 9600 baud on Windows. The drops arrive in clusters, the controller's checksum rejects the block, and the alarm fires. Reducing the baudrate reduces the drop rate below the controller's retransmit threshold.

The fact that one PLC archive still fails at 300 baud is the discriminator: case 1 and case 3 would both succeed at very low baudrate eventually, so case 2 (PCU20 PCIN task contention) or, more commonly, a corrupted PLC archive is the dominant cause for that specific file.

7. NCK and PLC Backup File Transfer Sequence

The correct field procedure for restoring startup data to a fresh CCU on an 810D PCU20 is the following. Always transfer NCK first, verify, then PLC.

1. Power on the controller with no CCU card inserted until the PCU20 chassis is energised; insert the CCU. Wait 30 seconds for NV-RAM stabilise.
2. Connect the PC running WINPCIN to COM2 on the HMI with the 1:1 DB9 cable. Power-on sequence: controller first, then PC, then WINPCIN.
3. Set S3 = 1, S4 = 2. Press and hold the reset button until the HMI displays "NCK general reset".
4. On WINPCIN select Data In, choose the NCK archive file, set baudrate = 9600 (start), 7E2, XON/XOFF. Click Start.
5. Monitor both the WINPCIN progress bar and the HMI percentage indicator. If both reach 100% with no alarm, NCK is loaded.
6. Power-cycle the controller. Verify the NCK comes up with the expected machine data. Confirm no alarm remains in the NCK alarm history.
7. Set S3 = 2, S4 = 4. Press and hold reset until the HMI displays "PLC general reset".
8. Repeat the WINPCIN Data In for the PLC archive. Do not interrupt; this archive is typically 5-30x larger than the NCK archive.
9. Power-cycle again. Confirm PLC is in RUN.
10. Perform an NCK/PLC combined reset (S3 = 3) and verify final state.

8. Diagnostic Procedure

Run this procedure in order. Stop at the first step that changes the symptom and apply the corresponding solution from Section 9 before continuing.

1. Confirm cable integrity. Use a multimeter to verify continuity on pins 2, 3, 4, 5, 6, 7, 8. Measure shield-to-ground resistance; should be less than 1 ohm. Replace the cable if any pin fails continuity.
2. Loop-back test the PC. Short pins 2 and 3 on the PC end DB9 connector, start WINPCIN Data Out on any small file, and confirm the file returns byte-for-byte identical. This proves the PC UART and WINPCIN are not corrupting data.
3. Loop-back test the controller COM2. With the controller powered and the PC disconnected, use the HMI service menu to enter "RS232 test" if available, or temporarily short pins 2-3 at the HMI end and have the controller echo a known character. Reconnect and re-test.
4. Transfer a small known-good NC program. Create a 1-line program (for example N10 G01 G90 X-100 Y-120 F120), transfer out from the controller with S4=3 to the PC, then transfer back in with S4=2. This proves the round-trip path is intact and isolates the fault to large-archive handling.
5. Inflate the test file. Copy-paste the test line to over 500 lines, then transfer in. If the inflate still succeeds, the channel is good and the original archive is suspect. If the inflate fails at the same percentage, the channel is the fault.
6. Sweep baudrates. Re-run the inflated test at 9600, 4800, 2400, 1200, 600, 300. Plot percentage-at-failure versus baudrate. A linear correlation confirms a flow-control / overrun issue. A flat failure at the same block number regardless of baudrate points to a file-format or checksum fault.
7. Inspect WINPCIN log. Enable WINPCIN's verbose log (option File > Log) and capture the failing block number, hex content, and the alarm string. Compare against a known-good archive to detect truncation, embedded null bytes, or missing LF terminators.
8. Check NV-RAM battery. Measure the lithium cell voltage on the CCU card with the unit powered off for at least 5 minutes. A voltage below 2.7 V on a CR2032 (or 3.0 V nominal) means the cell must be replaced before any reliable archive write can occur.
9. Verify S3/S4 transition timing. Use a stopwatch: each S3 toggle with the reset button held for 1-2 seconds must produce a fresh "general reset" message on the HMI. If the message does not appear, the switch contact is oxidised; cycle S3 ten times rapidly, then retry.
10. Test with a different PC. If possible, repeat the entire procedure from a known-good laptop with a native DB9 port or an industrial-grade USB-serial adapter (FTDI FT232R or Moxa UPort 1130).

9. Solutions by Root Cause

10. Verification Checklist

After applying any solution, perform the following checks before declaring the fault closed:

• NCK startup archive transfers at 9600 baud to 100% with no RS232C alarm, both on WINPCIN and on the HMI progress indicator.
• PLC startup archive transfers at 9600 baud to 100% with no RS232C alarm.
• A round-trip test (PC <- controller with S4=3, then PC -> controller with S4=2) of a 500-line NC program completes byte-for-byte identical using a checksum tool such as fciv.exe or certutil -hashfile.
• Controller power-cycle (S3=3) brings NCK and PLC up without re-issuing the RS232C alarm.
• No new alarms appear in the NCK alarm history (Menu > Diagnostics > Alarm Log) for 24 hours of operation.
• Battery voltage measured > 2.9 V after 5 minutes power-off.
• WINPCIN verbose log retained for the engineering record and attached to the commissioning report.

11. Related Siemens Service Alarms

The PCIN transfer path can raise several Siemens alarms that the field engineer should be able to distinguish:

12. Field Notes and Caveats

The combination of a brand-new CCU card, a discharged NV-RAM lithium cell, and the desire to load a complete startup archive in a single operation is the dominant root cause pattern in the field. Siemens service documentation explicitly recommends a four-hour soak before the first NV-RAM write to allow the lithium cell to reach its operational voltage under load. Skipping this soak produces the "aborts at 90% at 300 baud" symptom that is otherwise very confusing because the channel itself is functioning correctly.

USB-to-serial adapters remain a hidden risk. Industrial installations should specify a known-good industrial adapter (FTDI, Moxa, Advantech) and lock the COM port assignment in Windows Device Manager so that field engineers do not pick the wrong virtual port after a Windows update reassigns bus enumeration.

Finally, an archive that fails at a fixed block number regardless of baudrate is not a transmission fault - it is a corrupted archive. Re-source the archive from the OEM or rebuild from the STEP 7 project. Do not attempt to patch the failing block in a hex editor; the block's checksum is computed over the entire preceding stream and any manual edit will simply shift the failure to the next block.

FAQ