S7-1500 Send_P2P Receive_P2P Freeport ASCII Troubleshooting

Problem Overview

Engineers commissioning a SIMATIC S7-1500 CPU 1513-1 PN (6ES7513-1AM02-0AB0) with a CM PtP RS422/485 BA or CM PtP RS422/485 HF (6ES7541-1AB00-0AB0) communication module frequently hit two recurring failure modes when implementing Freeport (ASCII) point-to-point links in TIA Portal V13 SP1 / V14 SP1:

1. Send_P2P returns no DONE, the TX LED never lights, and no bytes appear on the bus. The PC-side serial sniffer (COM port monitor) confirms zero traffic from the CM.
2. Receive_P2P latches on STATUS = 16#7002 ("interim call - data transmission running") indefinitely, even though the slave sensor is known to broadcast RS232/RS422 frames continuously at power-up.

Both faults block the entire application even though the hardware is wired, the protocol is selected, and the program logic looks correct. The cause is rarely the cable or the slave device; it is a combination of buffer addressing, instruction instance-data layout, and EN/REQ timing on the Send_P2P / Receive_P2P function blocks.

Affected Hardware, Firmware, and Software

Freeport (ASCII) Configuration on the CM PtP Module

Freeport on the S7-1500 CM PtP requires the following parameters to be loaded from the project into the module during PLC startup. Verify each setting in the module's device configuration under "Properties → Port configuration → Protocol":

These values must match the sensor byte-for-byte. The CM PtP does not auto-negotiate; a single mismatched bit will cause both Send_P2P and Receive_P2P to appear to "do nothing" because the UART never sees a valid frame and the module never raises the receive-complete status.

Root Cause #1 — Send_P2P Buffer Indexing

The most common reason Send_P2P refuses to transmit is incorrect slice indexing on the input parameter DATA (also labeled SEND in some TIA Portal versions). Engineers often pass a single indexed element of an array instead of the full array.

Failing Pattern

// FB instance: "out" (instance DB of Send_P2P)
// User DB: "DataBuffer" with array [0..31] of BYTE named Static_1

// WRONG — passes only one byte, LEN=0 internally, nothing to send
"out".SEND    := "DataBuffer".Static_1[0];  // single BYTE
"out".LEN     := 10;
"out".REQ     := TRUE;

When SEND is a single BYTE element, the instruction's LEN check evaluates against the source length and concludes the buffer is empty. The CM never receives a transmit request; STATUS returns 16#7001 ("job running") for a few cycles, then 16#7000 ("no job active") without ever leaving the PLC.

Correct Pattern

// RIGHT — pass the whole array slice so LEN references the real buffer size
"out".SEND    := "DataBuffer".Static_1;     // whole array reference
"out".LEN     := 10;                         // bytes to transmit (0 = use full buffer length)
"out".REQ     := TRUE;

Root Cause #2 — Receive_P2P Stuck on 16#7002

Status 16#7002 on Receive_P2P means "interim call - data transmission in progress". It is the same as the in-flight status 16#7001 on Send_P2P and is normal for one cycle. When the value persists continuously, the receive job is never being started by the CM because:

1. EN_R is not latched TRUE — Receive_P2P only checks for incoming bytes while EN_R is high. If EN_R is pulsed by mistake, the job is repeatedly started and aborted without ever capturing a frame.
2. Send_P2P holds the port — The CM PtP is half-duplex. If a Send_P2P job is still in flight (REQ high, DONE not yet seen), Receive_P2P is suspended on the bus. STATUS sits at 16#7002 until the send completes (or times out at 16#80C0).
3. No end delimiter configured — The CM receives bytes but the Freeport driver never marks a frame complete, so NDR is never set and the receive job remains "active".
4. No termination character on the wire — The sensor may broadcast ASCII lines terminated with CR/LF. If the CM end-delimiter is set to a different character (or to "none"), frames never close.

Step-by-Step Diagnostic for 16#7002

1. Disconnect the slave cable. In a watch/force table, force EN_R := TRUE permanently and trigger REQ := TRUE on Send_P2P with a 5-byte buffer (e.g. ASCII "HELLO"). Observe the CM TX LED; it should flash for the duration of transmission, then DONE should set for one cycle.
2. If TX LED still does not light, the fault is in the Send_P2P buffer indexing (see Root Cause #1). Fix it before continuing.
3. Reconnect the slave cable. With a known-good free-port end-delimiter (CR, LF, or CR+LF) configured, force EN_R := TRUE on Receive_P2P. Watch NDR and the data area. The first complete frame should raise NDR for one cycle and load the buffer.
4. Capture the bytes on the wire with an RS422 USB sniffer (FTDI USB-RS422-WE-1800-BT or similar) to confirm framing, baud, and delimiters independently of the PLC.

Root Cause #3 — Overlap Between Send_P2P and Receive_P2P

The CM PtP RS422/485 is a half-duplex UART. While Send_P2P owns the transmit register, Receive_P2P is paused. A frequent programming mistake is to wire DONE of Send_P2P to EN_R of Receive_P2P, then drive REQ of Send_P2P from the same bit memory used for EN_R. This creates a one-cycle overlap where the bus is being driven by both instructions.

Safe Sequencing Pattern

// Single shared request bit "sendReq" (BOOL) - never pulsed during a Receive
IF "startCmd" AND NOT "busBusy" THEN
    "sendReq" := TRUE;
END_IF;

// Send_P2P instance "sendInst"
"sendInst".REQ   := "sendReq";
"sendInst".SEND  := "txBuffer".frame;        // full array, not [0]
"sendInst".LEN   := UINT#10;

IF "sendInst".DONE THEN
    "sendReq"     := FALSE;                   // drop REQ on DONE
    "txComplete"  := TRUE;                    // latched for one cycle
END_IF;

IF "sendInst".ERROR THEN
    "sendReq" := FALSE;
    "txError" := TRUE;
END_IF;

// Receive_P2P instance "recvInst" - EN_R held continuously after first send completes
"recvInst".EN_R := "txComplete" OR "rcvActive";
"recvInst".LEN  := 0;                         // accept variable length

IF "recvInst".NDR THEN
    // copy "recvInst".DATA into a working DB
    BLKMOV ; // user processing
    "rcvActive" := TRUE;                      // keep EN_R latched
END_IF;

Special Character Handling — The $ Sign

In Freeport configuration of the CM PtP, the $ character is reserved as an escape prefix. Common sequences:

If the application must transmit a literal dollar sign as data, the configuration must contain $$. A single $ is consumed by the parser and never reaches the wire. This applies to the Freeport message configuration in the module properties, not to the runtime buffer passed to Send_P2P (which is raw bytes).

Modbus RTU Limitation on CM PtP RS422/485 BA

The BA variant (6ES7540-1AB00-0AB0) supports Freeport (ASCII) only. The HF variant (6ES7541-1AB00-0AB0) supports Modbus RTU master/slave, USS, and Freeport. If a project is migrated from a Modbus RTU slave to a BA module, the port configuration will be rejected at compile time, or — if previously compiled and downloaded — the module returns STATUS = 16#80A1 ("parameter assignment error") and the protocol does not start.

Options When the Wrong Module is Installed

1. Replace the BA module with the HF module (catalog 6ES7541-1AB00-0AB0). Same wiring, same project footprint.
2. Implement Modbus RTU inside the user program on top of Freeport — not recommended, only viable for small PDUs at low baud.
3. Bridge through a third-party Modbus TCP ↔ RTU gateway connected to the CPU 1513-1 PN's PROFINET port. Recommended when the sensor/actuator vendor does not support PROFINET directly.

Diagnostic LED Behavior on the CM PtP

Status Code Reference for Send_P2P and Receive_P2P

Resolution Procedure (Step-by-Step)

1. Confirm module type. In the device configuration of the S7-1500 station, verify the CM PtP catalog number is 6ES7541-1AB00-0AB0 (HF) if Modbus is required, or 6ES7540-1AB00-0AB0 (BA) for Freeport-only.
2. Re-download hardware configuration to the CPU. The CM PtP does not retain its port parameters across power cycles unless configuration is online.
3. Match port parameters with the slave: baud 115200, parity none, 8 data bits, 1 stop bit, end delimiter = CR (0x0D) or CR+LF (0x0D 0x0A).
4. Fix Send_P2P buffer indexing. Replace any reference of the form "out".Static_1[0] with the full array reference "out".Static_1.
5. Test Send_P2P without slave. Force REQ := TRUE from a watch table with a 5-byte buffer. Confirm TX LED flashes; expect DONE := TRUE for one cycle.
6. Wire Receive_P2P after Send completes. Latch EN_R := TRUE from a "first DONE" memory; never pulse it on every scan.
7. Test Receive_P2P with slave connected. Watch NDR; the data area should populate with the first full frame.
8. Decouple SEND and RECEIVE by calling them in separate OB priority classes if high baud is sustained.
9. Capture traffic independently with a USB RS422 sniffer to verify framing, delimiters, and that the slave is in fact transmitting continuously.
10. Document final STATUS code in HMI for first-line diagnostic. Use 16#80D0, 16#80C0, 16#80C1 as alarm categories for operator action.

Verification Checklist

• [ ] CM PtP DIAG LED steady green within 2 seconds of CPU RUN.
• [ ] TX LED flickers on every Send_P2P REQ cycle.
• [ ] RX LED flickers on every slave frame, independent of the program.
• [ ] Send_P2P DONE asserts for exactly one scan per REQ pulse.
• [ ] Receive_P2P NDR asserts for exactly one scan on each complete frame.
• [ ] No concurrent REQ and EN_R active at the same time (verify with cross-reference watch table).
• [ ] STATUS = 16#0000 between jobs.
• [ ] A USB sniffer on the bus shows the exact same bytes seen by Receive_P2P.
• [ ] Buffer overflow does not occur; consider ring buffer if frames arrive faster than processing.

Performance and Timing Considerations

At 115 200 bit/s, 8N1, a 32-byte frame is approximately 3.2 ms on the wire. Receive_P2P must complete its user-side processing (BLKMOV, parsing, write to DB) before the next frame arrives, or the buffer is overwritten. A sensor broadcasting at 10 Hz (every 100 ms) gives 30 ms of headroom. A sensor at 100 Hz leaves only 7 ms — long enough on S7-1500 only if the parsing logic is implemented in a fast OB (OB1) and the data target is an optimized DB.

For sustained high-rate links, distribute load by:

• Moving parsing into a time-driven OB (e.g. OB30 at 1 ms) separate from the cyclic OB.
• Using a ring-buffer DB large enough for several seconds of frames.
• Reducing baud to 19 200 or 38 400 if the slave supports it — halves or quarters the time pressure.

Migration Notes to TIA Portal V15 / V16 / V17 / V18 / V19 / V20

The Freeport configuration on the CM PtP is forward-compatible across TIA Portal versions. Projects created in V13 SP1 / V14 SP1 open in V15+ and continue to work after recompile. Notable changes that affect field troubleshooting:

• V15: added diagnostics blocks for PtP modules under "PtP_PortStatus", reducing the need to evaluate STATUS manually.
• V16: enhanced status code set for Receive_P2P, including 16#80E0 for buffer-overrun on extended frames.
• V17 / V18: Send_P2P / Receive_P2P migrated to the unified "PtP" instruction namespace; the legacy names remain available as aliases.
• V20: the canonical documentation entry for Freeport is the "Data transmission with Freeport (S7-1500)" page in the TIA Portal Help, linked in the References section above.

Troubleshooting Matrix

Frequently Asked Questions