S7-1200 Bidirectional Communication with TSEND_C and TRCV_C

Overview

Two SIMATIC S7-1200 CPUs installed in separate cabinets 30 m apart can exchange process data in both directions over the integrated PROFINET interface (port X1) without any additional hardware. The most flexible approach is the Open User Communication profile using TSEND_C and TRCV_C instructions in TIA Portal. Each of these blocks bundles three lower-level functions: TCON (connection setup), the data transfer itself, and TDISCON (connection termination). Bidirectional data flow is achieved by calling TSEND_C/TRCV_C in both CPUs, with each side playing the role of a passive listener and an active initiator on separate connection IDs.

This pattern is the same one published in the official Siemens application example CE-X17 - Ethernet communication between S7-1200 CPUs, and the implementation steps mirror the procedure described in the SIMATIC S7-1200 Programmable Controller System Manual. The cycle time and link monitoring guidance also aligns with the S7-1200 Easy Book, available at S7-1200 Easy Book (PDF).

Prerequisites, Hardware, and Network Configuration

Before commissioning, gather the following items and confirm versions:

Any S7-1200 CPU with firmware V4.0 or later supports the TSEND_C / TRCV_C instructions. The newer the firmware, the more connection resources and the broader the error diagnostics, so prefer V4.4+ in new installations. The X1 PROFINET interface supports 100 Mbit/s, full duplex, with auto-negotiation and Auto-MDIX, so either a direct crossover cable or a switch can be used. A switch is recommended if any future PROFINET IO devices or HMIs will join the line.

Recommended IP plan:

• CPU 1 (control): 192.168.0.1 / 255.255.255.0
• CPU 2 (power): 192.168.0.2 / 255.255.255.0
• No router, no gateway needed for the 30 m link
• PROFINET device name: plc-control and plc-power respectively

Protocol Selection

Four protocol options are available for CPU-to-CPU traffic on S7-1200. The trade-off table below summarises engineering trade-offs for a 30 m, two-CPU link.

For the cabinet-to-cabinet case described in the source, both TCP and ISO-on-TCP are the most common choices. ISO-on-TCP aligns best with the rest of the SIMATIC stack and lets the same connection carry a length-prefixed payload, which simplifies framing. TCP is preferable when partners from different vendors are involved. For a one-CPU-active, one-CPU-passive setup, declare exactly one side as Active connection establishment = Yes in the connection descriptor; the other side stays passive to avoid simultaneous-open race conditions on the TCP socket.

TIA Portal Configuration and Data Block Design

Each side needs a Connection descriptor in the project tree under Devices & Networks > Connections. The TIA Portal wizard creates a TCON parameter data block automatically when you drag a TSEND_C block into the editor. The connection descriptor parameters are:

The Connection ID is a WORD with range 1-4095. Each TSEND_C/TRCV_C pair on a given CPU must reference a unique ID. For bidirectional traffic, allocate two IDs: 1 for the send direction, 2 for the receive direction. The convention used in CE-X17 is one ID per direction. The S7-1200 supports up to 16 Open User Communication connections on the PROFINET interface, shared between TSEND_C, TRCV_C, TMAIL_C, and other open blocks.

Group all process data that will travel in a single direction into a dedicated global DB. The DB must be a non-optimised block (select Attributes > Optimised block access = off) for TSEND_C to address it with an ANY pointer on firmware older than V4.4. From V4.4 onward, the symbolic VARIANT pointer is preferred and accepts optimised blocks.

Sample data layout for the control cabinet (PLC 1 sends 4 bytes, PLC 2 sends 6 bytes):

// PLC 1 -> PLC 2  (control cabinet to power cabinet)
DATA_BLOCK "DB_ControlToPower"
STRUCT
    bButtons      : BYTE;   // %I0.0 - %I0.7  physical pushbuttons
    bCommands     : BYTE;   // start, stop, reset, jog
    wSetpointPct  : WORD;   // 0-1000 (= 0.0-100.0 %)
    bReserved     : BYTE;   // pad to even
END_STRUCT;
END_DATA_BLOCK

// PLC 2 -> PLC 1  (power cabinet to control cabinet)
DATA_BLOCK "DB_PowerToControl"
STRUCT
    bStatusLights : BYTE;   // %Q0.0 - %Q0.7  indicator lamps
    bMotorState   : BYTE;   // running, fault, ready, etc.
    wSpeedFbk     : WORD;   // 0-1000 (0.0-100.0 %)
    bFaultCode    : BYTE;   // 0 = no fault
    bHeartbeat    : BYTE;   // 0-255 toggling counter
END_STRUCT;
END_DATA_BLOCK

The maximum payload per TSEND_C call is 8192 bytes on firmware V4.x. The recommended payload for the application described is 16-64 bytes, which keeps latency in the low single-digit milliseconds range. The single memory location that represents the status of the partner PLC is, in practice, the receive DB: every successful TRCV_C call overwrites the receive buffer, and the rest of the program reads from that buffer as if it were local I/O.

TSEND_C and TRCV_C Block Reference

Two block families are available. The table below summarises the practical difference.

For most cabinet-to-cabinet applications, TSEND_C / TRCV_C are the correct choice. Use TSEND / TRCV only when the project demands custom connection reuse patterns, for example, when the same TCP socket is shared between multiple protocols.

The two blocks share most of their interface. The input/output declarations are:

For TRCV_C the equivalents are EN_R (enable receive), ADHOC (accept any packet length), and the same DONE, BUSY, ERROR, STATUS outputs.

Program Structure and C-to-PLC Concept Mapping

For engineers transitioning from C to ladder/FBD, the S7-1200 execution model is best understood with a few translations:

A typical Main OB1 for a bidirectional communication node looks like this in FBD. Both TSEND_C and TRCV_C are placed in OB1; nothing about Open User Communication requires a separate block, which keeps the program readable for someone migrating from C.

// OB1 "Main" - segment 1: cyclic send trigger
M0.7 (100 ms clock bit) ----[RE]----(TSEND_C REQ)
"DB_Status".bHeartbeat := "DB_Status".bHeartbeat + 1

// OB1 "Main" - segment 2: write local inputs into send DB
"DB_ControlToPower".bButtons := IB0
"DB_ControlToPower".wSetpointPct := IW2

// OB1 "Main" - segment 3: copy received data into output area
QB0 := "DB_PowerToControl".bStatusLights

// OB1 "Main" - segment 4: receive enable
TRUE ----(TRCV_C EN_R)

Calling TSEND_C in OB1 with a 100 ms clock bit as REQ gives a deterministic send rate. The receive block TRCV_C is left enabled continuously; the user code is notified that fresh data has arrived by the rising edge of DONE, which can be used to latch process values. If the project needs to wait for a partner before proceeding, the pattern is a step chain in an FB: store the wait state in the instance DB, transition on DONE rising edge, and continue execution. This is the S7-1200 equivalent of a C state machine with switch(state) { ... }.

Cycle Time and Timing Analysis

The total time from an input change in PLC 1 to a corresponding output change in PLC 2 is the sum of four contributions:

T_total = T_scan_plc1 + T_send_plc1 + T_net + T_scan_plc2 + T_apply_plc2

Typical values for a 30 m link with 16-byte payload:

For the cabinet-to-cabinet control application, a 100-250 ms update is fully sufficient. If a faster response is required, move the TSEND_C call to a cyclic interrupt OB (e.g., OB35 at 50 ms) and use a high-priority hardware input interrupt to pre-stage the send buffer. The PROFINET update portion on the S7-1200 is hardware-accelerated and adds no measurable application-side latency for Open User Communication.

Detecting a Disconnected LAN Cable

The question raised in the source - "How do I detect if the LAN cable is pulled out so I can re-establish when the cable is put back?" - has multiple solutions. Each has different latency and CPU overhead.

Method 1: Rely on TSEND_C automatic recovery

With CONT = 1, TSEND_C keeps the connection descriptor alive. When the physical link is broken:

1. The internal TCP stack attempts retransmissions (default TCP timeout approximates 30 s, firmware dependent).
2. On timeout, ERROR rises and STATUS returns 16#80A1 (connection error).
3. When the cable is re-inserted, the next rising edge on REQ triggers a fresh TCON attempt.

For faster detection, place a check in OB1: if ERROR is high, set a global CommError flag, log the timestamp, and call TDISCON followed by TCON explicitly to force re-handshake.

Method 2: PROFINET diagnostic interrupts

If the partner CPU is also configured as a PROFINET IO device, you can subscribe to OB82 (diagnostic interrupt) and OB86 (rack failure). The local STATUS word inside these OBs contains the slot number and event code. A typical drop event returns 16#393C for "station failure" and 16#38A4 for "link down".

Method 3: Application-level heartbeat

Add an 8-bit counter (bHeartbeat) in the payload that increments on every send cycle. The receiver compares the new value with the last one and sets HeartbeatOK if the difference is non-zero. If two consecutive cycles show the same value, declare link failure:

// PLC 2 evaluation
IF "DB_PowerToControl".bHeartbeat <> "DB_LastHeartbeat" THEN
    "HeartbeatOK" := TRUE;
    "HeartbeatTimeout" := 0;
ELSE
    "HeartbeatTimeout" := "HeartbeatTimeout" + 1;
    IF "HeartbeatTimeout" > 5 THEN
        "HeartbeatOK" := FALSE;
    END_IF;
END_IF;
"DB_LastHeartbeat" := "DB_PowerToControl".bHeartbeat;

With a 100 ms send rate, five missed cycles is a 500 ms window. This is faster than the TCP retransmission timeout and works for any protocol, including UDP.

Method 4: Read the PROFINET link state register

On S7-1200 firmware V4.4 and later, the IODeviceState system data block exposes the link status of every configured PROFINET device. The state word IODeviceState[1..n].State reads 0 = not configured, 1 = OK, 2 = fault. Poll this in OB1 with a 200 ms clock bit.

Status and Error Code Reference

The STATUS output of TSEND_C and TRCV_C returns standardised codes. The most important values:

Detailed explanations are available in the TIA Portal information system under Instructions > Communication > Open User Communication > TSEND_C. The list above is the subset most frequently encountered on a 30 m cabinet link.

Verification and Commissioning

Follow this checklist before putting the line into production:

1. Online compile: After the project is built, right-click the CPU and select Compile > Hardware and Software (rebuild all). Errors in connection descriptors only show up here.
2. Download to both CPUs: TIA Portal > Online > Download to device. Confirm the IP address and PROFINET name are correct on the target.
3. Watch table: Create a watch table with the send DB, receive DB, and the DONE/BUSY/ERROR/STATUS outputs of TSEND_C and TRCV_C. Force the clock bit and observe DONE toggling once per cycle.
4. Toggle inputs: In the control cabinet, press each button. The corresponding DB_ControlToPower byte should change, and the input should appear in the partner's receive DB.
5. Time the round trip: Set a known value in PLC 1, watch for the change in PLC 2, and stamp the time using a high-resolution clock. The delay should be below 100 ms for the 100 ms clock configuration.
6. Cable pull test: Disconnect the LAN cable at PLC 1. Verify ERROR rises and the CommError flag goes true. Reconnect and verify the link recovers within the configured timeout without a CPU restart.
7. Check PROFINET LEDs: The LINK LED on X1 should be solid green when the cable is connected, off when disconnected.
8. Review diagnostic buffer: Online & Diagnostics > Diagnostics buffer. The first and last communication error event will be logged with timestamp.

Realistic engineering tips from the bench:

• Configure clock memory bytes in CPU properties before the first download. The default is empty, and a forgotten clock bit is the most common reason a cyclic TSEND_C never fires.
• Always add an empty OB82 and OB86 to the program. If they are missing and a PROFINET device goes offline, the CPU goes to STOP. An empty OB82 or OB86 acts as a default handler and keeps the CPU in RUN.
• For long-term reliability in industrial cabinets, use M12 D-coded PROFINET cable with IP67 connectors rather than RJ45. The 30 m run is well within the 100 m segment limit, and the heavier cable is more tolerant of cabinet vibration.
• For deterministic latency, use a managed PROFINET switch (e.g., SCALANCE XC-200) instead of an unmanaged switch. Cut-through switching reduces jitter to below 10 microseconds.
• For cyber-security, enable access protection in the CPU security settings and restrict the web server to read-only. Also disable the PUT/GET server if not in use.

Troubleshooting Matrix

FAQ