Troubleshooting CPM2A RXD(47) No-Protocol Serial Receive Failures

Overview

The Omron CPM2A CPU integrates an RS-232C port (port 1) on the faceplate that supports both Host Link (SYSWAY) and no-protocol communication. In no-protocol mode, the ladder RXD(47) instruction reads bytes from the port into DM/HR/AR memory while TXD(48) writes DM/HR/AR data out to the port. The most common commissioning failure for a custom PC <-> CPM2A link is that RXD(47) executes but never reports a complete receive: the receive-complete flag AR08.06 stays OFF, the receive-in-progress flag AR08.05 never asserts, and the PC transmits into silence. The CPM2A does not log a fault code for this; the bytes are silently discarded at the UART. This article documents the failure mode, walks through the underlying port architecture, identifies the parity mismatch as the most common root cause, and provides a verification procedure that resolves it on a production bench. Cable, ladder, and PC-side .NET serial issues are also covered. Cross-references to the official CPM1/CPM1A/CPM2A/CPM2C/SRM1 Programming Manual (W353) and the CPM2A Operation Manual (W352-E1-07) are used throughout.

Problem Symptoms

Typical bench symptoms when RXD(47) is misconfigured, when the physical layer is wrong, or when there is a UART-format mismatch between the host PC and the CPM2A:

• PC transmits from its COM port (verified by loopback to a second PC or by a Saleae/USBee logic analyzer) but the CPM2A never sets AR08.06 (Port 1 Receive Complete Flag).
• Ladder executes RXD(47) with the correct control word (N+1 = number of bytes, D = destination word), but the destination word remains at 0 and AR08.05 (Port 1 Receive-In-Progress Flag) never pulses.
• No error code is generated in AR08. The CPM2A simply discards the incoming byte stream at the UART and continues scanning.
• Transmission from the PLC to the PC using TXD(48) works correctly; only the receive direction is dead. This asymmetric behavior is a fingerprint of a one-sided parity or frame-format mismatch because the PC's UART ignores parity bits, while the CPM2A's RXD(47) hard-checks them.
• Power-cycling the PLC does not help. Changing the baud rate does not help. Re-flashing the project does not help. The receive remains dead until the format code in DM6645 is corrected.

CPM2A Serial Port Architecture

The CPM2A has one built-in RS-232C port (port 1) on the CPU faceplate, plus a peripheral port on the CPU module. The peripheral port is dedicated to programming via CX-Programmer and is not usable for general-purpose serial. The RS-232C port can run in one of three modes selected by DM6645 bits 4-7:

• Host Link (SYSWAY) - 7 data bits, even or no parity, 2 stop bits. Used for SYSWAY command/response traffic (for example, @00RD..., @00WR..., @00RR...).
• No-protocol - selectable 7/8/9 data bit frames with N/E/O parity and 1 or 2 stop bits. Used for custom ASCII or binary protocols where the application owns the byte stream.
• 1:1 NT Link / 1:N NT Link - reserved for Omron NS-series PT connection. Incompatible with custom PC traffic.

For custom PC software written in C++ Win32, VB, Delphi, C#, or .NET SerialPort, you almost always want no-protocol mode with full control over the byte format. Host Link is used only if the PC is acting as a SYSWAY master and sending @-prefixed commands with checksum and CR terminator. The original failure case in the source is a textbook no-protocol RXD(47) issue with the PC set to 8-N-1 and the PLC set to 8-1-O.

RXD(47) and TXD(48) Instruction Specification

Per section 45 (High-speed Counters / Serial Communications) of the CPM1/CPM1A/CPM2A/CPM2C/SRM1 Programming Manual (W353) and the CPM2A Operation Manual (W352-E1-07), the ladder instructions involved in serial I/O are:

The C (control) word layout is identical for RXD and TXD:

For RXD(47), N+1 bytes are stored at the destination starting at D, low byte first. Each byte uses one word. If D = DM0200 and N = 5, the 5 received bytes are stored at DM0200 (low byte, byte 0), DM0201 (low byte, byte 1), DM0202 (low byte, byte 2), DM0203 (low byte, byte 3), and DM0204 (low byte, byte 4). The high bytes of those words are not used and remain at their previous value. The maximum N is 256 (write 0 to the low byte of the C word); at 256 bytes, the destination occupies 256 contiguous words.

Flags affected by RXD(47) on port 1:

• AR08.05 - Port 1 Receive Flag (in progress). Asserts when the first byte arrives; remains set until N bytes have been received cleanly or a parity/framing error occurs.
• AR08.06 - Port 1 Receive Complete Flag. Asserts for one scan after N bytes have been received cleanly.
• AR08.07 - Port 1 Transmit Complete Flag. Used by TXD only; pulses for one scan after the last byte has been clocked out.

Port 1 Configuration: DM6645-DM6648

Serial port 1 is configured through four data memory words. These must be set by ladder or transferred from the programming console at startup. They are read by the port hardware at the next port reset (typically a power cycle or a STOP -> RUN transition with a port-reset bit). The mapping is documented in section 3 of the W352 CPM2A Operation Manual:

DM6645 encoding for port 1:

The frame format code is shifted left by 4 bits and OR'd with the baud rate. So 9600 baud with 8-N-1 no-protocol is DM6645 = 0x0030 + 0x0003 = 0x0033. The original failure case was 9600 with 8-1-O, which is DM6645 = 0x0050 + 0x0003 = 0x0053. The PC was sending 8-N-1, so the PLC's UART was rejecting every byte on parity grounds.

The 9-bit no-protocol frame formats (DM6645 = 0x06, 0x07, 0x08) are used for legacy devices that employ the 9th bit as an address marker (DM in many 8051-based industrial protocols). For most PC <-> PLC traffic you want 8-N-1 (DM6645 = 0x33), 8-E-1 (DM6645 = 0x43), or 7-E-2 (DM6645 = 0x00, 0x01) for Host Link.

One-to-One Cable Wiring (PC <-> CPM2A)

For no-protocol or Host Link traffic between a PC COM port and the CPM2A RS-232C port, the cable is a 9-pin D-sub null-modem. Per the CPM2A/CMM2C Communications Functions manual and confirmed by the working TXD direction in the source case, the standard one-to-one PC <-> CPM2A cable is wired as follows:

Pin 5 of the PC DB-9 must connect to pin 9 of the CPM2A; this is the signal ground path and is mandatory for any reliable communication, especially over cable lengths greater than 1.5 m. The PC-side short between pins 4&6 (DTR/DSR) and 7&8 (RTS/CTS) handshakes the PC's UART so the DTE output drivers are enabled. The PLC-side short between pins 4&5 ties the CPM2A's internal RTS to its own CTS so it always considers the channel "clear to send." If you leave the PLC pins 4&5 open, transmissions may still work because the CPM2A does not assert RTS by default in no-protocol mode, but some PCs will refuse to transmit without seeing DSR or CTS high - which is why the .NET SerialPort has the RtsEnable property discussed below.

Root Cause Analysis: Parity Mismatch

The actual root cause in the source case was a frame-format mismatch between the PC and the CPM2A. The PC was configured for 8, N, 1 (8 data, no parity, 1 stop), but DM6645 was set to 8, 1, O (8 data, 1 stop, odd parity). The Omron W353 manual documents that the CPM2A's UART will reject any received byte whose parity bit does not match the configured parity, and the rejection is silent: the byte is simply not loaded into the receive buffer and AR08.05/AR08.06 are never set. The host PC ignored this because its UART ignores incoming parity bits, so the PC's transmit path was active and its transmit line was driving the correct 8-N-1 waveform into the cable. The CPM2A, expecting an odd parity bit, saw the stop bit (a logic 1) in the parity-bit slot, computed parity as "even" for most printable ASCII characters (whose low 7 bits have an even number of 1s), and discarded every byte.

This is a one-sided failure: the PLC can still transmit to the PC because the PC's UART is more permissive and ignores the parity bit on receive, treating all incoming bytes as valid 8-bit data. Hence the symptom observed by the original poster: TXD(48) works perfectly; RXD(47) never completes.

Confirming the Parity Mismatch on a Logic Analyzer

Connect a Saleae Logic 2, USBee DX, or PicoScope 2204A to the RXD line of the CPM2A (pin 3 on the PLC side of the cable, signal ground on pin 9). Set the analyzer to 9600 8-N-1, decode, and you should see all bytes correctly. Switch the analyzer to 9600 8-O-1 and the same byte stream will show framing or parity errors on every byte. If the analyzer rejects the byte stream under 8-O-1, the CPM2A will also reject it. This is the fastest empirical way to confirm a parity mismatch before changing the PLC program.

Why Odd vs Even Parity Produces Different ASCII Results

For printable ASCII (0x20-0x7E), the parity bit is calculated as the XOR of the seven data bits. ASCII 'A' (0x41) has data bits 1000001, which is 2 ones, so the odd parity bit is 0 and the even parity bit is 1. ASCII 'T' (0x54) has data bits 1010100, which is 3 ones, so the odd parity bit is 1 and the even parity bit is 0. If the PC sends no parity bit and the CPM2A reads the stop bit (logic 1) in the parity-bit slot, the apparent parity of the byte is "odd" for ASCII characters with an even number of 1s and "even" for ASCII characters with an odd number of 1s. So an 8-N-1 PC + 8-1-O PLC will only accept half the printable ASCII character set, and an 8-N-1 PC + 8-1-E PLC will only accept the other half. The character set that fails the parity check is silently dropped.

Correcting the Parity Setting

Change DM6645 in the CPM2A to match the PC. If the PC is 8, N, 1, set DM6645 = 0x0033 (9600 baud, 8-N-1, no-protocol). For other baud rates use the same frame format code (3) with the appropriate low-nibble value: 0x0013 for 2400, 0x0023 for 4800, 0x0043 for 19200. If the PC is 7, E, 1, set DM6645 = 0x0040 (9600, 7-E-2 Host Link) or 0x0044 (9600, 8-E-1 no-protocol) depending on whether the data is binary or text-only.

For a one-shot ladder configuration at first scan, use a single MOV instruction at the top of the program:

          P_First_Cycle
             |
        [MOV  #0033  DM6645]    ; 9600 baud, 8-N-1 no-protocol
             |
        [MOV  #0000  DM6646]    ; no transmission delay
             |
        [MOV  #0000  DM6647]    ; no CTS control, no PLC Link
             |
        [MOV  #0000  DM6648]    ; node number irrelevant in no-protocol
             |
        [END]

Reload the project to the PLC, place the PLC in RUN mode, and re-execute the C++ test program. RXD(47) should now complete and AR08.06 should pulse for one scan per received block. If your PC software is itself half-duplex or echoes back what it receives, set a small DM6646 transmission delay (10-100 ms) to prevent the PLC's TXD from colliding with the PC's incoming message stream.

Ladder Logic Pattern for RXD(47)

A robust receive pattern uses a "trigger" bit to start a new RXD execution only after the previous receive has been processed. This prevents the receive buffer from being overwritten if a second block arrives before the first has been consumed by the application logic:

             |          P_On
             |          |
             |     [MOV  &0020  D0100]    ; C-word: receive 32 bytes
             |          |
             |     [RXD  DM0300  D0100]    ; D0100=C-word, DM0300=destination
             |
; On the next rung, copy the received data only after the receive completes:
             |          AR08.06
             |          |
             |     [MOV  DM0300  HR0100]    ; process the first 16-byte block
             |     [MOV  DM0310  HR0200]    ; process the second 16-byte block
             |          |
             |     [BCLR  AR08.06  AR08.06]  ; acknowledge completion (some firmware requires this)
             |

PC-Side Considerations

Win32 CreateFile / DCB

When using C++ Win32 directly via CreateFile() on COM1, set the DCB structure as follows for 9600 8-N-1 no-protocol:

DCB dcb = {0};
dcb.DCBlength = sizeof(DCB);
dcb.BaudRate  = CBR_9600;
dcb.ByteSize  = 8;
dcb.Parity    = NOPARITY;
dcb.StopBits  = ONESTOPBIT;
dcb.fRtsControl = RTS_CONTROL_ENABLE;  // required on some USB-serial adapters
dcb.fDtrControl = DTR_CONTROL_ENABLE;  // not strictly required but recommended
SetCommState(hCom, &dcb);

For a 32-bit block sent as one write:

BYTE buffer[32] = { 'T','E','S','T', /* ... 28 more bytes ... */ };
DWORD written = 0;
WriteFile(hCom, buffer, sizeof(buffer), &written, NULL);
// AR08.06 should pulse for one scan in the PLC after the 32nd byte arrives.

.NET SerialPort

The .NET 2.0+ System.IO.Ports.SerialPort class defaults fRtsControl to RTS_CONTROL_DISABLE, which leaves the PC's RTS pin low. If the cable shorts 7+8 on the PC side, this does not matter because the loopback forces the UART into "always clear to send." If the cable does not short 7+8 (e.g., a fully wired null-modem that relies on hardware handshaking) or if the USB-serial adapter enforces hardware flow control, transmissions will be blocked. The fix:

SerialPort sp = new SerialPort("COM1", 9600, Parity.None, 8, StopBits.One);
sp.RtsEnable = true;          // <-- required when .NET 2.0+ controls the port and 7+8 not shorted
sp.DtrEnable = true;          // recommended for the same reason
sp.Handshake = Handshake.None; // we are managing the protocol at the application layer
sp.ReadTimeout = 500;
sp.WriteTimeout = 500;
sp.Open();
sp.Write(Encoding.ASCII.GetBytes("TEST"));

Without RtsEnable = true, the .NET SerialPort object will assert RTS low, which the USB-serial UART (FTDI FT232, Silicon Labs CP2102, CH340) may interpret as "not clear to send" and refuse to transmit, producing the same symptom as a dead cable. This issue was reported in .NET 2.0 (.NET FX 2.0.50727) and is documented in the MSDN library for System.IO.Ports.SerialPort.RtsEnable.

USB-Serial Adapter Caveats

Modern PCs rarely have native DB-9 COM ports; most benches use a USB-to-RS232 adapter (FTDI, Prolific PL2303, or CH340). These adapters typically enumerate as COM3, COM4, or higher. The 5 V supply on the adapter is for the line driver, not for the PLC; the CPM2A port 1 is a true RS-232C port with +/- 12 V levels and will not be damaged by a 5 V TTL adapter if the adapter is a true RS-232 level converter (not a 5 V TTL serial). Do not use a 5 V TTL serial (e.g., an FTDI basic breakout configured for 3.3 V or 5 V TTL) directly on the CPM2A; the logic levels are incompatible and the port may be damaged. Use only adapters marked "RS-232" or "EIA-232" on the housing.

Verification Procedure

1. Open CX-Programmer and connect online to the CPM2A via the peripheral port or USB.
2. Place the PLC in PROGRAM mode and clear DM6645 to a known value (for example, 0x0000).
3. Set DM6645 = 0x0033 (9600, 8-N-1, no-protocol) and re-enter RUN mode. If your application needs a non-default baud rate, set the corresponding low-nibble value (0x01, 0x02, 0x04).
4. Power-cycle the PLC to make sure the new DM6645 takes effect. Some CPM2A firmware revisions only reload port settings at boot, not at STOP -> RUN transitions.
5. Open a serial terminal (PuTTY, Tera Term, or your C++ test program) configured for 9600 8-N-1 with local echo off.
6. From the PC, send a 4-byte ASCII block (for example, "TEST").
7. Watch AR08.05 in the watch window. It should pulse high the moment the first byte arrives and stay high until all N bytes have been received.
8. Watch AR08.06. It should pulse high for one scan after the 4th byte has been received.
9. Open the destination data area (e.g., DM0300) and verify the bytes appear in the low bytes of DM0300-DM0301 in order: 0x54 (T), 0x45 (E), 0x53 (S), 0x54 (T).
10. Repeat with a 256-byte block to confirm the maximum N value works and that no buffer overrun occurs.
11. Run the test for at least 10 minutes to confirm no intermittent drops on a long cable run (pin 5 to pin 9 ground integrity is the usual failure point on long runs).

Common Pitfalls Matrix

Inline Wiring Diagram (SVG)

Comparison: No-Protocol vs Host Link vs Modbus

Frequently Asked Questions