S7-1200 TCP TSEND Stuck After TRCV: Root Cause and Fix

Problem Overview

An S7-1200 CPU 1214C using the TCON, TSEND, and TRCV instructions to exchange HEX frames with a third-party device over a raw TCP connection (192.168.255.2 ↔ 192.168.255.1, port 10001) executes the first transaction successfully. After the first TSEND/TRCV cycle, the second TSEND request never completes: the DONE bit does not latch and BUSY remains cleared while ERROR momentarily pulses high. The same scenario works flawlessly when tested against a PC running a terminal emulator (e.g., HyperTerminal, PuTTY) on the same port.

This is one of the most common support cases on the S7-1200 platform because the failure is silent and only appears after the first transaction. The root cause is almost always missing handshake sequencing between the receive and send instructions, not a fault in the physical connection or the partner device.

Affected Hardware and Firmware

Reference: SIMATIC S7-1200 Programmable Controller System Manual (entry ID 109478121).

How TCP Behaves on a Single S7-1200 Connection ID

The Transmission Control Protocol is connection-oriented and full-duplex. A single established connection allows independent, simultaneous data flow in both directions, governed by the TCP state machine (LISTEN, SYN-SENT, ESTABLISHED, FIN-WAIT, CLOSE-WAIT, etc.). See RFC 793 and the IANA assignment database for protocol numbers.

On the S7-1200, a single TCON instance with one connection ID is therefore technically sufficient to send and receive on the same socket. The TSEND and TRCV blocks reference that ID and the same active connection descriptor. The constraint is not the wire protocol; it is the way the firmware schedules the TSEND/TRCV job buffer.

Root Cause: Overlapping Job State on a Single Connection

Each TSEND and TRCV call is a stateful job. Internally, the firmware uses two job slots per connection ID: one for transmit, one for receive. The blocks expose the following status outputs that must be polled every cycle:

The failure mode in the reported case is created when the application triggers the second TSEND while the previous TRCV job is still flagged as active, or when the rising edge of REQ is masked by an already-latched internal request. The firmware rejects the new transmit request silently, returns STATUS = W#16#80A1 ("Connection or channel is currently busy processing a job") or W#16#8085 ("No new job was started because a job is already active"), and clears BUSY before DONE is set.

Three concrete variants produce the symptom:

1. Latched REQ with no edge: REQ of TSEND is wired to a tag that is already TRUE. TSEND only accepts a rising edge of REQ; a level-driven REQ does not restart a job.
2. Overlapping jobs: A second TSEND REQ is issued before TRCV has signalled NDR (or before DONE from the previous TSEND has been acknowledged).
3. Connection descriptor corruption: The same connection ID is reused by two independent TCON DBs, causing the firmware to swap descriptors on the second call. This is the only variant that requires separate TCON instances.

TSEND / TRCV Parameter Reference

All values are taken from the Siemens function-block help in TIA Portal. The exact same interface applies to TSEND_C / TRCV_C (the "Compact" variants that bundle the TCON setup).

Common STATUS Codes (W#16#...)

Full list in the TIA Portal online help, "Status codes for TSEND / TRCV / TCON". Most relevant values:

Reference: Siemens KB entry 67196808 — "Why does TSEND/TRCV not work the way I expect?" and the TIA Portal integrated block help.

Solution: Implement a Strict TX/RX State Machine

The reliable pattern on a single TCON ID is to drive the application from explicit states and to gate each new request on the successful completion of the previous one. The sequence required by the original poster is:

1. Establish the connection once with TCON. Latch TCON.DONE into a static tag (iConnEstablished).
2. Enable TRCV continuously with EN_R = TRUE. On NDR, copy the buffer to the application DB and raise iRxComplete.
3. Compare transmitted and received data. If they match, raise iTxPending and generate a single rising edge of TSEND.REQ.
4. On TSEND.DONE, clear iTxPending. Do not re-trigger REQ until the next TRCV.NDR has been consumed.

In SCL this is implemented as a small CASE-of-INT state machine. The same logic in ladder is a chain of mutually exclusive rungs gated by an EQ on the state tag.

SCL Skeleton (TIA Portal V16+)

// Persistent tags (retain not required)
iState         : INT  := 0;   // 0=Idle, 10=WaitTcon, 20=WaitRx, 30=Compare, 40=SendAck, 50=WaitSendDone
iConnEstablished : BOOL;
iRxComplete    : BOOL;
iTxPending     : BOOL;
iCompareOk     : BOOL;

CASE iState OF
  0:  // Idle: start connection
      "dbTCON".REQ := TRUE;            // call TCON in DB instance
      iState := 10;

 10:  // Wait for TCON done
      IF "dbTCON".DONE THEN
         iConnEstablished := TRUE;
         "dbTCON".REQ := FALSE;
         iState := 20;
      ELSIF "dbTCON".ERROR THEN
         iState := 90;                  // error handling
      END_IF;

 20:  // Enable TRCV, wait for NDR
      "dbTRCV".EN_R := TRUE;
      IF "dbTRCV".NDR THEN
         iRxComplete := TRUE;
         iState := 30;
      ELSIF "dbTRCV".ERROR THEN
         iState := 90;
      END_IF;

 30:  // Compare rx data with tx data
      iCompareOk := memcmp("dbRx".RxBuf, "dbTx".TxBuf, "dbTx".TxLen) = 0;
      IF iCompareOk THEN
         iState := 40;
      ELSE
         iState := 80;                  // mismatch path
      END_IF;

 40:  // Send ACK on the same connection
      "dbTSEND".REQ := FALSE;           // ensure clean edge
      iTxPending := TRUE;
      iState := 50;

 50:  // Rising edge of REQ, wait for DONE
      "dbTSEND".REQ := iTxPending AND NOT iTxPendingEdge;
      iTxPendingEdge := iTxPending;
      IF "dbTSEND".DONE THEN
         iTxPending := FALSE;
         "dbTSEND".REQ := FALSE;
         iRxComplete := FALSE;
         iState := 20;                  // back to waiting for next reply
      ELSIF "dbTSEND".ERROR THEN
         "dbTSEND".REQ := FALSE;
         iState := 90;
      END_IF;

 80:  // Mismatch handling (re-send, log, etc.)
      ;

 90:  // Error handling: capture STATUS, optionally call T_RESET / TDISCON
      iLastStatus := "dbTSEND".STATUS;
      ;

END_CASE;

The key invariants are:

• TSEND.REQ is a single rising edge, never a sustained level. Reset REQ to FALSE in the same cycle that observes DONE.
• A new transmit is never armed until TRCV.NDR has been observed for the current cycle and the data has been processed.
• The status from the first cycle's TSEND.DONE is latched into iTxPending := FALSE only after the application has consumed the receive buffer.

Alternative: Use Multiple Connection IDs for Pipelining

If throughput is more important than simplicity, the application can open two (or more) connections to the partner on different local port numbers and use one TSEND / TRCV pair per connection ID. Each ID has its own job slot, so a second transaction on ID 2 can start while ID 1 is still mid-receive. This requires:

• One TCON DB per connection, with distinct ID values and distinct LocalPort or RemotePort values.
• Matching TSEND/TRCV instances wired to the correct ID.
• Application-level multiplexing (sequence number) in the payload so that the partner can correlate replies.

This approach is described in the Siemens application example "Open User Communication with S7-1200 / S7-1500" (entry ID 109744691), available on the Siemens support portal.

Verification Procedure

1. Watch table: monitor dbTCON.DONE, dbTSEND.DONE, dbTSEND.BUSY, dbTSEND.ERROR, dbTSEND.STATUS, and dbTRCV.NDR. Confirm that DONE pulses for one cycle, that BUSY returns to FALSE between jobs, and that STATUS = 16#0000 on completion.
2. Online & Diagnostics: open the CPU's connection diagnostics. The connection should be in state ESTABLISHED, not LISTEN or CLOSED.
3. Wireshark: capture on the PC side. Filter on tcp.port == 10001. Verify that each application cycle produces exactly one PSH/ACK frame in each direction, and that there are no RSTs (which indicate the firmware dropped the connection).
4. Partner echo test: have the third-party device run a loop-back. Trigger two sends in succession from the PLC; both should appear as outgoing PSH/ACK frames.
5. Stress test: drive 1000 transactions from the PLC at the maximum cycle rate. All DONE pulses must be observed and STATUS must never be non-zero.

Diagnostic Flow When the Symptom Returns

Best Practices for S7-1200 Open User Communication

• Always use TSEND_C/TRCV_C for new projects. They include the connection setup and status query inside a single block, removing most sequencing errors.
• Generate REQ with a rising-edge helper tag (REQ := Trigger AND NOT TriggerOld; TriggerOld := Trigger;) instead of latching the trigger.
• Keep EN_R of TRCV permanently TRUE. Let the firmware handle the receive window; toggling EN_R will lose data.
• Reserve a static receive DB of the maximum expected frame size. Re-using the same buffer for every cycle prevents stale-data faults.
• Always latch the first non-zero STATUS observed in error state into a separate tag for commissioning. The error pulse is one cycle long and is easy to miss in online watch tables.
• For raw TCP where the partner application expects a single transaction per cycle, do not pipeline by default. Add pipelining only after the deterministic path is proven.
• On FW 4.2 and earlier, ensure that the partner IP is in the same subnet as the CPU's IP. Routing across gateways on S7-1200 requires the CPU to be configured as a router in TIA Portal (only available on newer FW and with security settings adjusted).

HyperTerminal Cross-Check (Why It Works on the PC)

When the same scenario is tested with a PC running HyperTerminal, the PC terminates the TCP connection as a generic socket: the application is free to call send() and recv() in any order, and the OS scheduler handles buffering. The PLC firmware, by contrast, exposes a strictly stateful job interface. The fact that HyperTerminal works is therefore evidence that the link layer is healthy, not that the PLC's state machine is correct.

Summary

A single TCON connection ID on the S7-1200 is fully bidirectional at the TCP level, but the user program must sequence each TSEND and TRCV explicitly. A single TSEND that is followed by a TRCV that is not awaited will leave the connection in a state where the next TSEND request is rejected with STATUS = 16#80A1 or 16#8085, and the DONE bit is never set. Drive REQ with a clean rising edge, gate each new transmit on the previous receive having produced NDR, and the connection remains stable for unlimited transactions.