Siemens CP341 RS485 2-Wire ASCII: Resolving Receive Failure

Overview

The Siemens CP341 communication processor (order numbers 6ES7341-1BH01-0AE0 for RS422/485 and 6ES7341-1CH01-0AE0 for RS485) is one of the most widely deployed point-to-point modules for S7-300 stations. When configured for half-duplex 2-wire RS485 ASCII, the module can transmit commands reliably yet fail to receive any reply, even though the same cable, baud rate, and protocol work when terminated by a PC running a terminal emulator. This article documents the exact failure mode where FB7 P_RCV reports NDR = 0 and ERROR = 0, no RXD LED activity is observed, and standard diagnostic counters stay empty. The root cause is almost always a combination of wiring topology and protocol parameters that does not match the half-duplex direction control expected by the module.

CP341 Hardware Variants and Pin Assignment

The CP341 is shipped in three hardware variants. Each variant uses a 15-pin D-sub female connector (X27) and a separate 9-pin D-sub for the parameter assignment interface.

For the 2-wire ASCII scenario, the relevant connector pinout is:

In 2-wire mode, pins 2 and 15 carry the bidirectional differential pair. Pins 5 and 6 are not used and must not be wired. Using a 4-wire cable with all four signal lines connected to a half-duplex slave has no electrical effect on the CP341 itself, but the cable conversion (or the converter electronics) determines whether the receiver path is actually connected.

Configuration Parameters That Matter

The CP341 ASCII driver is configured in the STEP 7 hardware configuration under Properties > Communication > Protocol. Each parameter below has been shown to break 2-wire reception when set incorrectly. The values used in the field incident were:

Root Cause: The 2-Wire Direction Control Loop

Half-duplex RS485 on the CP341 works because the module controls a direction line (internally derived from RTS of the on-board UART) that tri-states the line driver when it is not actively transmitting. The cycle is:

1. FB8 P_SEND is called. The driver turns the line driver ON (transmit) and the differential pair is driven by the master.
2. FB8 P_SEND completes. The line driver is turned OFF; the differential pair is released.
3. FB7 P_RCV is called with EN_R = TRUE. The driver turns the receiver ON and monitors the pair for the first character of a response.
4. The slave's response toggles the differential pair. The CP341 receiver samples it and the ASCII driver reconstructs the frame using the configured character delay as the frame end.

If the CP341 never enters step 3, no RXD LED activity is ever generated. Three conditions prevent this transition:

• FB7 is never called, or EN_R is held FALSE.
• FB7 is called, but the ASCII driver is busy with a previous receive that never completed (DONE never returned).
• The receiver input is physically disconnected or shorted to a constant level, so even with the receiver enabled, no edge activity reaches the UART.

In the field incident, the two CP341s talking to each other proved that both modules could execute the cycle correctly. The LCD slave was also proven correct by the Hyperterminal test. The only remaining variable was the physical medium between the CP341 and the slave.

Why the Original 2-Wire Cable Failed

The original symptom was: TXD LED flashes on send, no RXD activity on receive, NDR = 0, ERROR = 0. When the cable was replaced with a 4-wire cable (using two of the four wires for the A/B pair and leaving the others unconnected), reception started working. This is the diagnostic fingerprint of one of three physical-layer problems:

1. Polarity reversal on a single conductor: the 2-wire cable had the A and B signals crossed at one end. RS485 is polarity-sensitive; a crossed pair presents an idle-high-to-slave but idle-low-to-master, leaving the differential receiver of the CP341 unable to recognize the start bit. A spare conductor in the 4-wire cable made it possible to fix the wiring without re-terminating both ends.
2. Open circuit on the slave's transmitter: the 2-wire cable lacked the ground reference connection (pin 4 / shield). Without a defined common-mode reference, the slave's RS485 driver could not produce a valid differential swing relative to the CP341's ground. A 4-wire cable was more likely to have the shield or a spare wire used as a ground reference.
3. Missing or misplaced termination: a single 120 Ω termination at the wrong end of the trunk can be tolerated; a missing termination combined with stubs in the cable causes severe ringing. A 4-wire cable run with the unused pair shorted at one end (or unterminated) often accidentally provides a better impedance profile than a 2-wire cable with the same stubs.

Per the National Instruments knowledge base article "Set Up 2-Wire (Half-Duplex) Communication with RS-485 Port", the canonical rule for 2-wire RS485 is: short the transmit and receive signals together on the RS-485 port. On a CP341, this short is performed inside the module when the half-duplex 2-wire protocol is selected. If the cable or the slave device breaks that rule by keeping transmit and receive as separate pairs, the CP341 will only ever see its own transmitted signal echoed back on the receiver pair, never the slave's reply.

Recommended Wiring for CP341 RS485 2-Wire ASCII

Use one twisted pair, terminated at each end with 120 Ω, and connect the shield to functional earth at one end only:

CP341 (X27)         Cable Pair          LCD Slave
Pin 2  T/R (A)  -- Pair 1 (twist)  --  A
Pin 15 T/R (B)  -- Pair 1 (twist)  --  B
Pin 4  Shield   -- Shield         --  Shield (or GND)

[120 ohm]               [120 ohm]
A ----====---- A
B ----====---- B

Important constraints:

• Do not connect pins 5 and 6 (R(A) and R(B)) of the CP341 to anything in 2-wire mode.
• If the CP341 module variant is 6ES7341-1BH01-0AE0 (RS422/485), it must be configured in the hardware configuration as RS485 (2-wire), not RS422 (4-wire), otherwise the internal direction control is not enabled and the driver will not tri-state the transmitter between messages.
• Maximum cable length for 19200 bit/s is 1200 m per the EIA-485 standard, but in industrial cabinets keep it under 30 m to avoid ground loops.

FB7 P_RCV Programming Reference

The FB7 P_RCV block (library SIMATIC communications blocks for CP341) requires specific call patterns. A common cause of NDR never being set is calling FB7 only once per PLC cycle and expecting it to stay armed. The following OB1 pattern is the recommended way to keep the receiver armed continuously:

CALL FB7, DB7
   EN_R   := TRUE         // keep receiver armed every call
   R      := FALSE         // do not abort an in-progress receive
   LADDR  := W#16#100      // base address from hardware config (example: 256)
   DB_NO  := 12            // any data block >= 12 used to buffer the message
   DBB_NO := 0             // start of data in DB_NO
   LEN    := 250           // maximum receive length (matches buffer size)
   RCV_ST := MW200         // additional status word (optional)
   NDR    := M10.0
   ERROR  := M10.1
   STATUS := MW202

For cyclic polling, call FB7 in OB1 (or a cyclic OB such as OB35) with EN_R = TRUE. The block then arms the receiver and sets NDR = 1 the first time a complete frame is received. After the user program copies the buffer, it must call FB7 with R = TRUE for one scan to release the buffer and re-arm the next receive. The recommended pattern uses a rising-edge on NDR to trigger a one-shot reset:

// Re-arm FB7 on NDR or ERROR
A M10.0     // NDR
O M10.1     // ERROR
= #rearm_request

// one-shot pulse to R input
FP #rearm_edge
S #rearm_pulse

CALL FB7, DB7
   EN_R := TRUE
   R    := #rearm_pulse
   ...

FB8 P_SEND Programming Reference

FB8 P_SEND is called whenever a new message must be transmitted. The block is non-blocking; the user program can resume work while the driver is shifting out the bytes:

CALL FB8, DB8
   REQ    := #send_trigger    // rising edge starts the send
   LADDR  := W#16#100
   SEND   := P#DB20.DBX0.0 BYTE 32   // any pointer to a send buffer
   DONE   := M12.0
   ERROR  := M12.1
   STATUS := MW204

Important sequencing rules in half-duplex:

• Do not call FB7 with EN_R = TRUE while a previous FB8 call has not yet returned DONE = 1. The CP341 ASCII driver queues requests, but simultaneous TX and RX requests on a 2-wire bus are not arbitrated by the module and will collide on the bus.
• Insert a guard time after DONE = 1 before calling EN_R = TRUE on FB7. The slave's response turnaround time is at least the configured character delay (here 4 ms, increased to 50 ms during testing). One OB1 cycle at 100 ms is a safe value.

Diagnostic Procedure When NDR Never Sets

Follow this checklist in order before assuming a software defect:

1. Verify the LED state on the CP341. A constantly lit or blinking RXD LED with no NDR = 1 indicates the receiver is seeing characters but the frame end is not detected — usually a character delay misconfiguration. A completely dark RXD LED during a known transmit-to-receive sequence points to a physical-layer issue.
2. Loop the cable back. Connect pins 2 and 15 at the slave end with a 120 Ω resistor. The CP341 should now echo every transmitted frame. If NDR = 1 fires on the echo, the CP341 is correct; the problem is the slave or the slave-side wiring.
3. Measure the differential voltage on pins 2 and 15 with an oscilloscope during a send from the CP341. A valid RS485 signal shows ±1.5 V differential with the idle state near 0 V. A flat-line differential of 0 V with one conductor held at +5 V indicates a broken wire or a shorted pair.
4. Check the slave's transmit enable timing. Many RS485 slaves tri-state their transmitter until they detect a valid message. If the slave does not release the bus within the character delay window, the CP341 sees the bus as idle and never starts a receive.
5. Swap the A and B wires at one end. RS485 is polarity-sensitive and a single crossed pair presents as a permanently idle or permanently asserted line to the receiver.
6. Try a different character delay. The field incident started at 4 ms and was raised to 50 ms without success; this rules out character delay as the root cause and is useful diagnostic evidence.
7. Compare the ASCII frame on Portmon. The user has already confirmed the frame ends with 0x0D as expected, so the frame end character is not the issue. Confirm that the slave is actually transmitting — a silent slave (e.g., waiting for a different command) will look identical to a broken cable.

Why the 4-Wire Cable Worked

Once the 2-wire cable was replaced with a 4-wire cable and the LCD began responding, the most likely explanation is one of the following:

• The 4-wire cable had a continuous, unbroken shield connection that the 2-wire cable lacked. RS485 receivers require a stable common-mode reference; without the shield, large ground potential differences between the CP341 chassis and the LCD chassis push the differential signal out of the receiver's common-mode range.
• The 2-wire cable had one of the two signal conductors damaged (e.g., a broken crimp). The 4-wire cable's two spare conductors allowed the operator to rewire to a good conductor pair.
• The 4-wire cable's twist ratio was tighter (most multi-pair cables used in cabinets are 1 pair per twist), producing a more stable characteristic impedance and reducing reflections on the bus.

From a logical perspective, the CP341 does not "know" that it is wired 2-wire or 4-wire — it only knows whether the protocol is configured as half-duplex 2-wire (which enables internal direction control) or full-duplex 4-wire (which disables it). As long as the 4-wire cable uses only one twisted pair on pins 2 and 15, the protocol and the cable are consistent. The two extra conductors must remain unconnected at both ends to avoid unintended stubs.

Termination and Biasing

For a point-to-point CP341-to-LCD link under 30 m, a single 120 Ω termination at one end is usually sufficient. For longer runs or for multi-drop buses:

The fail-safe bias resistors are required by the EIA-485 standard to keep the bus in a defined idle state when no driver is active. Without them, the CP341 receiver can oscillate on noise and produce spurious characters that never match the configured character delay.

Verification Procedure

After applying the fix, verify the link with the following sequence:

1. Power-cycle the CP341 and confirm the SF LED is off. A solid SF LED indicates a parameter or driver block mismatch.
2. Trigger a single FB8 P_SEND and observe both TXD and RXD LEDs. RXD should flash at least once after the slave's response turnaround.
3. Confirm NDR = 1 for one PLC cycle and that the received data in the configured DB matches the expected response (verify against the Portmon capture from the Hyperterminal test).
4. Run a 24-hour soak test with FB7 called every 100 ms to confirm no missed frames and no ERROR = 1 events.

Troubleshooting Matrix

Documentation References

For further details, consult the official Siemens documentation:

• SIMATIC S7-300 CP341 Point-to-Point Communication, Installation and Parameter Assignment
• SIMATIC S7-300 CP341 Point-to-Point Communication, Function Blocks — covers FB7 P_RCV and FB8 P_SEND parameter list
• National Instruments KB: Set Up 2-Wire (Half-Duplex) Communication with RS-485 Port