Configuring TSEND_C and TRCV_C on S7-1200 for TCP Communication

Overview

The TSEND_C and TRCV_C instructions implement TCP/IP Open User Communication (OUC) on the integrated PROFINET interface of a SIMATIC S7-1200 CPU. The pair handles both the transport connection (via an embedded TCON/TDISCON) and the data transfer, replacing the legacy combination of TCON + TSEND + TRCV + TDISCON. Per the official Siemens S7-1200 manual collection, the minimum payload is 1 byte and the maximum payload is 8192 bytes per call. The instructions are firmware-agnostic for OUC but require the latest instruction library version installed in TIA Portal for the connected CPU firmware.

Common use cases include:

• Communicating with a third-party device such as a Balluff BIS M RFID processor, vision sensor, scanner, or printer over TCP.
• Building a request/response protocol with an external server (HTTP, ASCII, binary, Modbus TCP, etc.).
• Exchanging data with a non-Siemens controller when PUT/GET is not available.

Prerequisites

Architecture: One Connection, Two Blocks

A persistent TCP connection is described by a single Connection ID, an IP address, a remote port, and a local port. The TSEND_C and TRCV_C instructions on the same S7-1200 do not each open their own socket. They share a single TCON-managed connection if the CONNECT parameter is identical and the same ID is used at both blocks.

Field-proven practice: assign the same Connection ID to the send and receive blocks when the partner is the same device, the same IP, the same port, and the same protocol (TCP). The ID range 1 – 4095 is shared; using one ID for both directions is permitted and avoids exhausting the connection table on a CPU with limited OUC resources (small S7-1200 CPUs allow only 8 active OUC connections on the PROFINET interface).

The recommended control sequence is:

1. Insert TRCV_C first and let it free-run. With EN_R = TRUE, TRCV_C is permanently listening and pulls any data that arrives into the receive DB.
2. Insert TSEND_C with the same ID and matching CONNECT parameter block.
3. Gate the REQ input of TSEND_C with the DONE/ERROR status of TRCV_C and the connection status bit of TSEND_C (STATUS = 7000 means idle/connected, 7002 means the previous job is complete). The REQ input must not be pulsed before the connection is fully established (STATUS = 7000 after the first successful connect).
4. If the remote device drops, both blocks report STATUS = 80C5 (connection terminated) or 80C4 depending on the cause. Clear the REQ line and call a new REQ edge once the partner is reachable again; the embedded TCON will re-establish the socket.

Block Parameters Reference

Step-by-Step Configuration in TIA Portal

1. Insert the blocks. In the project tree open Program blocks > Main (OB1). Drag TSEND_C from Instructions > Communication > Open user communication into a network. Repeat for TRCV_C. TIA Portal auto-generates the instance DBs (InstDB_TSEND_C, InstDB_TRCV_C) and a TCON parameter DB on first use.
2. Configure the connection description. Open the TCON DB and set:

3. Wire the receive path. Set EN_R of TRCV_C to TRUE constantly. Create a receive DB (e.g. DB_RCV) with at least 8192 bytes. Point DATA of TRCV_C to DB_RCV. Decide between:

• Fixed length (ADHOC = FALSE): LEN defines the expected packet size. Use this when the partner sends constant-size frames.
• AdHoc mode (ADHOC = TRUE): The first two bytes of the received frame are interpreted as the length (big-endian UINT). Use this when the partner sends variable-length frames, e.g. a Balluff RFID with responses that vary in size. Allocate the receive area for the largest expected frame; the block reads the actual length and updates RCVD_LEN.

4. Wire the send path. Set CONT = TRUE to keep the socket open between calls. Set LEN either explicitly to the byte count or to 0 if the length is stored in the DATA pointer (with SENDLEN defined). Latch a rising edge on REQ only after the connection has been established.
5. Apply connection gating. A minimal ST snippet to gate REQ on connection status:

// TRCV_C permanently listening
InstDB_TRCV_C(EN_R := TRUE, ID := 1, ADHOC := TRUE, LEN := 0, DATA := P#DB_RCV.DBX0.0 BYTE 8192);

// Gate TSEND_C REQ on the receive instance being idle and previous send DONE/ERROR
"tag_Send_OK" := InstDB_TRCV_C.NDR OR InstDB_TRCV_C.ERROR;
IF (InstDB_TSEND_C.STATUS = 16#7000) AND "tag_Send_OK" THEN
    InstDB_TSEND_C(REQ := "tag_Trigger", ID := 1, LEN := "tag_Len",
                   DATA := P#DB_SND.DBX0.0 BYTE "tag_Len", CONT := TRUE);
END_IF;

6. Compile and download the program and the connection description DB to the CPU. Go online and watch the instance DBs; the connection must show STATUS = 7000 (idle, connected) before the first send.

Status Code Reference

AdHoc Mode Deep Dive

AdHoc mode is the most common cause of "TRCV_C stays at 7006 forever" or "I receive the first two bytes of every frame as length and the rest of the data looks wrong." The contract is:

• The partner prepends a 2-byte big-endian length to every TCP segment it sends.
• TRCV_C strips the length prefix, copies the payload into the receive DB, and writes the actual number of bytes into RCVD_LEN in the instance DB.
• The receive DB must be sized to the largest single frame the partner will send, not to the cumulative stream size.

If the partner does not send a length prefix, AdHoc must be FALSE and LEN must match the partner's fixed frame size. Mixing the two is the leading cause of garbage on the receive side.

Verification Procedure

1. Loopback test with Hercules. Install Hercules SETUP utility on a Windows PC. Set it to TCP Server on the partner IP/port. Connect the S7-1200 to the PC. Confirm the CPU's TCON DB reports STATUS = 7000 and the embedded TCON completes (you can monitor it in the instance DB's CONNECT structure). Send a known ASCII string from the PLC with TSEND_C; verify Hercules echoes it. Send a reply from Hercules; verify TRCV_C reports NDR and the bytes land in the receive DB at the expected offset.
2. Wireshark confirmation. Capture the link on a managed switch with port mirroring. You should see the TCP three-way handshake from the active side, the data segments, and the FIN on disconnect. If no SYN appears, the CPU is not initiating — the partner is the active side and the S7-1200 ActiveEstablished flag is wrong.
3. Online watch on instance DBs. In TIA Portal go online, open the TSEND_C and TRCV_C instance DBs, and add the instance DB to a watch table. Right-click on STATUS, BUSY, ERROR, NDR, and RCVD_LEN and update them continuously.
4. Partner diagnostic tool. Most third-party devices (Balluff BIS M, Cognex, Keyence, Sick, etc.) ship with a Windows configuration tool that lets you exercise the TCP socket and the application protocol independently. Always verify the partner first; if the partner diagnostic cannot talk to itself or to a known good client, the problem is not the PLC.

Troubleshooting Matrix

Connection ID and Port Sizing

Each S7-1200 CPU has a hard limit on simultaneous OUC connections on the integrated PROFINET port. Smaller CPUs (CPU 1211, 1212) allow 8 active OUC connections; CPU 1214 and 1215 allow 16. The 4-byte ID field accepts values 1 – 4095 and must be unique per active connection regardless of protocol. UDP, TCP, ISO-on-TCP, and SMTP each count against the budget.

For local port selection: setting LocalPort = 0 asks the CPU's TCP/IP stack to bind any free ephemeral port (typically 49152 – 65535 on Windows-style stacks; Siemens uses similar ranges). If your firewall expects a specific source port for outbound rules, set it explicitly to a value outside the ephemeral range — common practice is 2000, 2500, 3000 to keep firewall rules readable.

PUT/GET vs. Open User Communication

For S7-1200 to S7-1200/1500 data exchange, PUT/GET (S7 communication) is almost always the better choice because the protocol carries an application-level acknowledgement:

• PUT writes the partner's DB/M/inputs/outputs; DONE = success.
• GET reads the partner's areas; NDR = success and data valid in the receive DB.
• No TCP socket setup, no ADHOC flag, no LEN arithmetic.

The trade-off is throughput: PUT/GET adds protocol overhead and limits job size to the S7 protocol PDU size (typically 480 bytes in older CPUs, 960 bytes in newer ones). For a 1 Hz status exchange of 50 bytes, that overhead is irrelevant. For a 1 kHz streaming of 8 KB blocks, OUC with TSEND_C/TRCV_C is materially faster on the wire, but you must implement the application-level ack yourself.

Field-Proven Tips

• Always let TRCV_C free-run with EN_R = TRUE. Trying to call TRCV_C conditionally to "save CPU" is a common source of lost frames — the TCP buffer is finite and the partner will retransmit only if its protocol does retries; many do not.
• Use one Connection ID per partner, not per direction. The direction is selected inside the same TCON by the send/receive role of the block.
• Set CONT = TRUE on TSEND_C if the conversation is request/response, otherwise the socket closes on every DONE and the partner must reconnect.
• Never store the REQ signal in a latch. Use a single-cycle pulse from a rising-edge detector or a state machine; otherwise TSEND_C re-sends on every scan.
• For a third-party partner, obtain the exact framing specification (length prefix? delimiter? fixed length? binary or ASCII?). Guesswork on framing is the #1 cause of "I see only the first two bytes and then garbage."
• For the Balluff BIS M family, the parameter protocol uses fixed-length ASCII frames with a CR/LF terminator; disable AdHoc and set LEN to the documented frame size, or use a small custom parser that scans for the terminator inside a 1024-byte rolling window.

FAQ