Resolving Receive_P2P Status 7002 on S7-1200 RS-485

Problem Description: Receive_P2P Stuck on STATUS 7002

A common point-to-point (PtP) fault pattern on the SIMATIC S7-1200 platform is an RCV_PTP / Receive_P2P block that never advances beyond STATUS word W#16#7002 (decimal 28674) even though the RX LED on the RS-485 communication module is flashing. The physical layer is clearly detecting character activity, yet the instruction never reports a successful reception: NDR stays FALSE, ERROR stays FALSE, and the captured LENGTH remains at the start value.

This symptom occurs in production configurations using the 6ES7 214-1HG40-0XB0 (CPU 1214C DC/DC/DC) and 6ES7 241-1CH32-0XB0 (CB 1241 RS-485 signal board) programmed in TIA Portal V14 SP1, with firmware 4.1 on the S7-1200. The same fault has been reproduced in TIA Portal V15 through V20 with the modern Receive_P2P instruction when the receive call is not configured correctly.

The block enters a "waiting" state because one of the configured frame-end criteria is never satisfied. The CM keeps streaming incoming characters into its ring buffer (hence the RX LED), but the instruction keeps discarding the partial frame because the configured end delimiter, idle-line timeout, or fixed message length never lines up with what the remote device is sending.

Affected Hardware and Firmware

The Receive_P2P instruction reference (TIA Portal V20) describes the modern function block used for S7-1200 and S7-1500 point-to-point communication. The legacy RCV_PTP instruction appears in the same instruction tree for backward-compatible projects.

Root Cause Analysis

Five independent root causes can each produce the "stuck on 7002 with blinking RX" pattern. Address them in this order.

Cause 1 — Conditional Call of the Receive Block

Wrapping RCV_PTP in an IF statement or driving its EN with a one-shot means the block is executed once, the partial frame is loaded into the input LENGTH, and the block is never re-entered to commit or flush it. The CM continues to accept bytes; the block never returns a new STATUS because it is not being called.

Symptom signature: LENGTH changes from 0 to a non-zero value after the first character burst, then the program never re-enters the block. RX LED keeps blinking because the CM is still receiving — the instruction simply is not allowed to do anything.

Cause 2 — Swapped A/B Polarity on RS-485

RS-485 is polarity-sensitive at the data-link layer. If R(A) and R(B) are reversed relative to the remote transmitter's T(A) / T(B), the CM will see noise-driven character transitions on the line and the RX LED will flicker. No valid stop-bit is detected, so the UART layer keeps "receiving" garbage but the framing logic never closes a frame.

Siemens convention: A = non-inverting (Data+), B = inverting (Data−). Swap A and B on the PLC side as a first test; do not swap at both ends simultaneously.

Cause 3 — Frame End-Detection Mismatch

The CB 1241 RS-485 is configured to terminate a receive frame on one of these triggers: a fixed message length, an end delimiter, an idle-line gap, or a character/timeout condition. If the remote device is sending framed telegrams (e.g. Modbus RTU, ASCII with CR/LF) but the CM is configured for a 50 ms idle line, the block will time out the partial frame, return 7002 ("waiting" or "no complete frame"), and discard the buffer.

Inspect the CM's Port Configuration → End of message detection in the device properties. Typical settings on a Modbus RTU slave are:

• End delimiter: none
• Idle line / inter-character timeout: 3.5 character times at the configured baud rate
• Fixed length: disabled (unless the protocol is fixed-frame)

Cause 4 — Block Version Mismatch (Library FBs vs. Auto-Instantiated FBs)

The TIA Portal library contains multiple generations of the PtP receive FB. Versions 2.0, 2.1, 2.2, and 3.x differ in their instance DB structure, STATUS decoding, and whether they require explicit EN handling. If the project is online with one version and the offline project references a different version, the FB may appear to "do nothing" because the instance data layout is stale.

For firmware 4.1 S7-1200 + CM 1241 modules, the historically stable FB is the version distributed with TIA V14 SP1. For TIA V15 and later, regenerate the FB from the current instruction palette so the version stamp matches the engineering tool.

Cause 5 — LENGTH Not Reset After Each Receive

Once Receive_P2P returns with NDR = TRUE and a LENGTH value, that LENGTH is the output for that cycle. If the same variable is wired back into the LENGTH input, the next call will ask the block to receive that many bytes — but the next telegram may be a different length. The block can then return 7002 forever waiting for the exact byte count that no longer matches the line traffic.

Best practice: keep the input LENGTH at the maximum telegram size (e.g. 255 for Modbus, 1024 for large ASCII frames) and ignore the input LENGTH after NDR is set; read the output LENGTH to know how many bytes were actually received.

STATUS Code Reference for Receive_P2P / RCV_PTP

The exact decode depends on the FB version. Capture the STATUS word on every cycle into a marker for trend analysis; do not rely on visual inspection of the watch table.

Correct Block Call Pattern

The receive instruction must be called every cycle in OB1 (or the cyclic OB) without conditions. The Receive_P2P "Enable receive messages" reference explicitly states that the instruction checks messages received in the CM or CB and transfers them to the CPU when a complete message is available — this is event-driven inside the FB and requires the FB to be cyclically scheduled.

Minimal correct pattern in Structured Text (OB1):

// Cyclic, unconditional call - no IF, no one-shot
RCV_PTP_Instance(BUFFER := #recvBuffer,
                 LENGTH := 255,                  // max telegram size, fixed
                 PTR := 0,                       // always start at buffer offset 0
                 EN_R := TRUE,                   // permanent enable
                 NDR => #ndrFlag,
                 ERROR => #errFlag,
                 STATUS => #statusWord);

// Edge detection on NDR
IF #ndrFlag THEN
    #rcvLength := #statusWord AND 16#7FFF;     // lower 15 bits = byte count
    // process telegram
END_IF;

// Edge detection on ERROR
IF #errFlag THEN
    #lastError := #statusWord;                  // capture for HMI/diagnostics
END_IF;

Notes on the pattern:

• EN_R stays TRUE continuously; the block is not gated by application logic.
• LENGTH is the maximum size of a single telegram, not the bytes received.
• PTR resets to 0 if you want a fresh buffer per frame. Setting PTR to a non-zero offset pre-pends history; for normal streaming, leave it at 0.
• The byte count in NDR is in the low 15 bits of STATUS (per FB v2.2 and later). Older versions exposed it via the LENGTH output only — check the FB documentation for your version.

Hardware Verification Procedure

1. Power down both the S7-1200 and the remote RS-485 device.
2. Identify R(A) / R(B) on the CB 1241 and the remote device. Confirm Siemens convention: A = Data+, B = Data−.
3. Use a multimeter to measure the DC bias between A and B with the remote device powered: a healthy idle RS-485 line sits at roughly 200 mV (A higher than B) when the master has fail-safe biasing, or near 0 V on an unbiased bus.
4. Connect a USB-to-RS-485 converter on a PC to the same wire pair and run a terminal program at the configured baud rate. If you can read intelligible ASCII from the remote device, the wiring and polarity are correct.
5. Disconnect the PC, power the S7-1200, and observe the RX LED. If the LED blinks on remote traffic, the CM is seeing the line. If the LED never blinks, swap A and B on the PLC side as a test.

Software Configuration Verification

1. In the project tree, open Devices & Networks → CB 1241 RS-485 → Properties → Port Configuration.
2. Set Transmission speed to match the remote device (9600 / 19200 / 38400 / 115200 bit/s typical).
3. Set Parity, Data bits, Stop bits to match exactly. Any mismatch produces 80B1 framing errors, not 7002.
4. Set End of message detection to the protocol in use. For Modbus RTU use idle-line 3.5 char times. For ASCII with CR use "End character = 0x0D". For fixed-length telegrams use the exact byte count.
5. Set Flow control to None for RS-485 (RS-485 is half-duplex; RTS is not used for direction control on the CB 1241).
6. Compile the project, download hardware configuration, then download the program. Do not perform a single "download all" if you want to verify the configuration separately.

Diagnostic Step — STATUS Latching Block

Insert a dedicated FB that latches the first non-zero STATUS value into a marker for HMI display. Because NDR, ERROR, and STATUS are valid for one cycle only, naive HMI polling of these tags will return 0 / 7000 most of the time. The proper engineering pattern is:

// In OB1, every cycle, AFTER the RCV_PTP call:
IF #errFlag AND #lastError = 16#0000 THEN
    #lastError := #statusWord;
    #errorTimestamp := #systemClock;     // DATE_AND_TIME
END_IF;

IF #ndrFlag THEN
    #lastNDR := TRUE;
    #lastNDR_Time := #systemClock;
END_IF;

Expose lastError, lastNDR, and errorTimestamp to the HMI so the operator can see when the last successful receive happened and what the last error code was.

Troubleshooting Matrix

Verification Checklist After the Fix

• Open the watch table in TIA Portal online mode. RCV_PTP.NDR toggles TRUE on each new telegram.
• RCV_PTP.ERROR stays FALSE during normal operation.
• RCV_PTP.STATUS cycles through 7000 → 7001 → 7002 → 0001 (NDR) under steady traffic.
• From the remote device, send a known telegram and confirm the bytes land in recvBuffer at offsets 0..LENGTH-1.
• Stress-test with a continuous stream at the expected polling rate for at least 10 minutes; watch for 80A2 overflow.
• Power-cycle the S7-1200 and verify reception starts within one polling cycle without any operator intervention (no warm-up IF needed).

Edge Cases and Field-Proven Caveats

• Multiple CM 1241 modules on one CPU: each CM has its own instance DB; do not share FBs across modules. The STATUS 7002 is per-CB, not per-CPU.
• RS-485 biasing on the CB 1241: the signal board provides internal fail-safe bias through the configuration. If the remote device also biases the bus, double-biasing can hold the line in mark state and produce 7002 with no RX activity. Disable biasing on one end.
• Program changes during commissioning: any edit to the receive block invalidates the instance DB. Always download the program after edits, not just the watch table.
• Watchdog on long telegrams: if the telegram is longer than the configured maximum, the block returns 80A1 (timeout) and discards the buffer. Increase the buffer in the instance DB or split the protocol.
• Migration to Receive_P2P from RCV_PTP: the modern instruction returns byte count in STATUS, the legacy one in LENGTH. Migrating a project without re-mapping both tags produces a "block appears dead" symptom identical to STATUS 7002.