Configuring Siemens CP 341 RS232C with MOXA NPort 5210

System Overview and Application Context

The integration of a legacy RS-232 field device with a modern Ethernet-based SCADA layer is one of the most common migration problems in brownfield automation. This article documents a concrete field configuration: a SIMATIC S7-300 CPU 313C (6ES7 313-5BF03-0AB0 or compatible variant) with a CP 341 RS232C communication module exchanging ASCII frames with client-side RISC PLCs through a MOXA NPort 5210 general-purpose device server. The NPort 5210 acts as a transparent serial-to-Ethernet gateway, exposing its two RS-232 RJ45 ports as TCP server, TCP client, or UDP endpoints on a 10/100BaseT(X) LAN. All CP 341 parameters, including protocol, baud rate, parity, character frame, and XON/XOFF flow control, must match the NPort 5210 port profile on a bit-for-bit basis; otherwise the CP will report SF (group fault) and the SEND/RECEIVE function blocks will set the ERROR output with a status word in the upper byte that encodes the exact reject reason.

The CP 341 (order number 6ES7 341-1AH01-0AE0 for the RS-232 variant, or 6ES7 341-1BH01-0AE0 for RS-422/485) is a point-to-point serial module for the S7-300 rack that supports ASCII and 3964(R) protocols. When using ASCII framing with the loadable drivers, the user calls FB 7 "P_SND_RK" (send with handshake from RK directory) and FB 8 "P_RCV_RK" (receive with handshake) from the standard CP 341 / CP 441 point-to-point block library. Both blocks operate on a configured DB that contains a structured data area for the parameter header plus an Array of Bytes payload. The MOXA NPort 5210 is part of the NPort 5200 series. Its two serial ports are physically presented as RJ45 connectors, which is unusual for RS-232 and frequently misread by integrators familiar with DB-9 pinouts. The on-board DB-9 connector is absent on the NPort 5210; instead, MOXA ships the unit with an RJ45-to-DB9 adapter cable or a dedicated RJ45-to-DB25 cable for DCE/DTE conversion as documented in the NPort 5200 Series Quick Installation Guide.

Hardware Components and Order Numbers

CP 341 Hardware Configuration in STEP 7

Open the SIMATIC 300 station in HW Config and slot the CP 341 next to the CPU. Double-click the module and select the CP 341 Properties dialog. In the "Protocol" tab the operator chooses either "ASCII" or "3964R". For transparent raw ASCII traffic to the NPort 5210, select "ASCII driver"; the 3964R option is unsuitable because it adds STX/ETX framing and DLE stuffing that the remote RISC PLC will not accept unless it is also a Siemens device.

Inside the ASCII driver parameters, configure:

• Baud rate: 9600 (default for legacy RISC PLCs; verify against the RISC manual).
• Data bits: 8
• Parity: Even (most common on European PLCs; use None for Modbus-style transparent streams)
• Stop bits: 1
• Flow control: None (XON/XOFF optional if the NPort 5210 side is set to "XON/XOFF software")
• End-of-receive criteria: Fixed receive timeout (recommended 200 ms for polling masters) or character count (matches the LEN output of P_RCV_RK)

The CP 341 stores its configuration in a CP-specific parameter DB; download the HW Config to the CPU and the parameters will be pushed into the CP on the next STOP-to-RUN transition. A subsequent download of just the user program is not sufficient for changes to the protocol, baud, or flow-control settings.

MOXA NPort 5210 Configuration

Install the NPort Administration Suite on an engineering workstation, attach the NPort to the LAN, and let the utility broadcast-discover the unit. The factory default IP is 192.168.127.254 with no login. Open the NPort web console at http://192.168.127.254 or use the Administration Suite "Configure" tab.

The critical settings for a CP 341 master polling a downstream RISC device through the NPort are:

1. Operating mode: Real COM (also called "RFC 2217" or "Driver Mode") is not required for CP 341 because the S7-300 cannot install MOXA's virtual COM port. Use TCP Server mode instead; the CP 341 acts as the TCP client and connects to the NPort's listening port.
2. TCP Server port: 4001 (default; avoid overlapping with other services).
3. Max connection: 1 (point-to-point architecture).
4. Serial parameters: 9600/8/E/1, no flow control. These values must match the CP 341 parameter assignment exactly. A parity mismatch is the single most common reason the CP 341 reports SF and the SEND block returns STATUS = 0x1A (character framing error) or 0x07 (BREAK received).
5. Packet delimiter / inter-character timeout: 50 ms. This forces the NPort to forward buffered data even if fewer than 4 characters have accumulated.
6. Force transmit (timeout): 50 ms. Sends accumulated bytes to the TCP socket even if no delimiter has been received.
7. IP address: assign a static address (e.g., 192.168.0.50) outside the DHCP pool.

After saving, cycle the NPort power to ensure all parameters are committed to flash. The TX/RX LEDs above each RJ45 socket reflect the RS-232 line activity after TCP connection establishment; they will remain dark if no TCP session is open, which is normal for a server in idle state.

Cable Wiring Between CP 341 and NPort 5210

The CP 341 front-panel RJ45 socket pins follow the Siemens standard for RS-232 DCE-like devices (the CP behaves as DCE). The MOXA NPort 5210 ports are DTE. The MOXA-supplied CBL-RJ45M9-150 cable implements a 1:1 crossover equivalent that swaps TD/RD, RTS/CTS, and DTR/DSR in the same way a USB-to-serial null-modem cable would. The relevant pin map for the NPort 5210 RJ45 port (per the NPort 5200 Quick Installation Guide) is:

If a third-party RJ45-to-DB9 cable is used instead of the MOXA-supplied unit, ensure pin 2 (RXD) and pin 3 (TXD) are crossed between the two devices. A straight-through cable will appear to work for short bench tests because of TTL-like voltage tolerance but will fail intermittently on the plant floor once cable capacitance rises above ~25 pF/ft. The SF LED on the CP 341 turning RED the instant the cable is unplugged, as reported in the field case, is a strong indicator that the line is electrically intact but no incoming data is being decoded as valid characters - often a framing or polarity issue introduced by an incorrect cable.

STEP 7 Program Structure and P_SND_RK / P_RCV_RK

The CP 341 point-to-point blocks require three blocks: the parameter DB created by HW Config, a send/receive data DB, and the OB1 or cyclic OB that calls the FB. The send/receive data DB must be declared with a precise structure:

DATA_BLOCK DB221
TITLE = CP341_SendRecv_Buffer
VERSION : 0.1
  STRUCT
    Header   : ARRAY[1..6] OF BYTE;   // CP 341 parameter header
    TxBuffer : ARRAY[1..30] OF BYTE;   // Transmit payload, maximum 30 bytes
    RxBuffer : ARRAY[1..30] OF BYTE;   // Receive payload, maximum 30 bytes
  END_STRUCT;
END_DATA_BLOCK

The send call in OB1 looks like this:

CALL FB 7, DB100  // DB100 is the instance DB of P_SND_RK
   REQ   := M10.0;         // edge-triggered send request
   LADDR := W#16#100;      // logical address of CP 341 (HW Config, default 256 decimal = 0x100)
   DB_NO := 221;           // data DB number
   DBB_NO := 8;            // offset of TxBuffer in DB221 (1 + 6 header + 1 = byte 8)
   LEN   := 12;            // MUST be <= ARRAY upper bound (30)
   DONE  := M20.0;         // TRUE for one cycle on success
   ERROR := M20.1;         // TRUE for one cycle on failure
   STATUS:= MW22;          // STATUS word, low byte = error, high byte = info
END_CALL;

The corresponding receive call uses FB 8 "P_RCV_RK" with the same logical address and a separate offset pointing into RxBuffer. The LEN input on P_RCV_RK is the maximum length the user is willing to receive; it must also not exceed the DB array upper bound.

Root Cause: Buffer Length Mismatch

The most common reason that the CP 341 LEDs stay dark and the send block never completes is a data length violation. If the send DB declares TxBuffer : ARRAY[1..30] OF BYTE but the application logic passes LEN := 50, the CP 341 firmware rejects the request with STATUS = 0x09 ("DB length error") before any data is queued. Because no character has been written to the UART, neither TX nor any error LED on the front panel appears to flash - the failure is internal to the parameter validation phase. This is exactly the symptom reported in the field case where the user had a 30-byte DB but was passing 50 bytes to P_SND_RK.

The fix is to ensure the LEN input never exceeds the upper bound declared in the DB, OR to enlarge the array. For CP 341 with ASCII driver, the absolute maximum per send call is 1024 bytes per the Siemens documentation; the practical limit is the user's DB declaration. If a larger frame is required, either:

1. Enlarge the array (e.g., ARRAY[1..1024] OF BYTE) and pass the actual length up to 1024.
2. Segment the transmission across multiple P_SND_RK calls using a state machine, each call carrying a sub-frame that fits the buffer.

Additionally, the LEN input is edge-sensitive only when paired with a rising-edge REQ; passing the same REQ bit high continuously does NOT trigger multiple transmissions. A common field pattern is:

      A     M10.0
      FP    M10.1            // detect rising edge
      =     DB100.DBX0.0     // feed REQ of P_SND_RK
      AN    M20.1            // ignore request while error pending
      =     M10.0            // reset request after successful cycle

LED Diagnostics on the CP 341 Front Panel

The field-observed behavior - "SF LED goes RED the moment I unplug the cable, but never during the test" - is consistent with the CP 341 detecting loss of carrier (CTS low or DSR low on NPort side). When the cable is connected, the NPort 5210 holds its DTR/CTS outputs active, and the CP 341 treats the line as healthy. Unplugging drops the carrier sense and the CP 341 transitions to fault state, illuminating SF. This is normal for hardware-handshake-aware firmware. If hardware handshake is disabled on both sides (CP 341 set to "None" and NPort 5210 set to "None"), the SF LED behavior on unplug should disappear because the CP no longer monitors the handshake lines.

End-to-End Verification Procedure

1. Bench-loopback the CP 341 alone: connect TX (pin 3) to RX (pin 2) at the CP 341 RJ45 socket via a short jumper with GND common. Load the ASCII driver, configure 9600/8/N/1, and call P_SND_RK with a known 5-byte string ("HELLO"). P_RCV_RK should return the same 5 bytes. If this fails, the problem is inside the CP configuration and not the NPort link.
2. Verify the NPort 5210 link: from a laptop, use NPort Administration Suite to map COM1 to the NPort 5210 port 1 in "Real COM" mode. Open PuTTY on COM1, connect to 9600/8/N/1, type characters and confirm the laptop transmits successfully (the NPort 5210 should show the connected TCP socket in the Administration Suite "Monitor" tab).
3. Establish CP 341 to NPort 5210 socket: configure the NPort in TCP Server mode on port 4001, point the SCADA or a Wireshark capture to the NPort's IP, and send a short ASCII frame from the CP 341. Confirm the TCP payload contains the expected bytes via Wireshark on port 4001.
4. End-to-end traffic: connect the SCADA / RISC PLC to the NPort, send a poll from the CP 341, and confirm the response echoes back through the NPort to the CP 341's RxBuffer with the correct byte count in LEN output of P_RCV_RK.
5. Soak test: run continuous polling at 100 ms for 30 minutes. Monitor for SF LED activation and STATUS errors. If intermittent failures appear after 10-20 minutes, suspect TCP keep-alive timeouts on the NPort (default 7 minutes); reduce to 60 seconds for industrial applications.

Troubleshooting Matrix

Performance and Limits

The CP 341 RS232C module is rated for a maximum of 19.2 kbps with the default hardware revision; later modules (6ES7 341-1AH02-0AE0) support up to 115.2 kbps with firmware V2.x. The MOXA NPort 5210 supports up to 230.4 kbps per port. For sustained polling of a RISC PLC at 9600 baud, the effective throughput is ~960 bytes/sec, well within both devices. If the application requires higher throughput, consider migrating to CP 341 with RS-422/485 (6ES7 341-1BH02-0AE0) for half-duplex multi-drop or to the CP 343-1 Lean for direct TCP communication without a terminal server.

Latency through the NPort 5210 is dominated by the inter-character timeout. With the recommended 50 ms timeout and a 5-byte request frame, total round-trip latency is approximately 50 ms (request) + 50 ms (response) + 5 ms per-character wire time = 110 ms. For deterministic control loops below 50 ms, the NPort terminal server is the wrong architecture; use a direct RS-232 cable between the CP 341 and the RISC PLC, or upgrade to Ethernet-native field devices.

Field-Proven Cautions