Resolving S7-1200 TCP Connection Loop Failure with TCON/TRCV V3.0 (Firmware 4.1)

A SIMATIC S7-1200 CPU 1214C DC/DC/Rly on firmware 4.1, configured with TCON, TRCV, and TSEND V3.0 Open User Communication blocks, drops the TCP connection back to a PC client after exactly one round-trip exchange. The PC-side C# application throws System.Net.Sockets.SocketException (0x80004005) with the message "An attempt was made to access a socket in a way forbidden by its access permissions", and the S7-1200 TRCV instance is left hanging in BUSY=1 with NDR=0. This article provides a complete root-cause analysis, the correct parameter set for the V3.0 Open User Communication blocks, the buffer-sizing rule that the C# client is violating, and a step-by-step repair sequence that restores a permanent, bidirectional messenger connection.

1. Problem Description and Symptoms

The reported failure exhibits a deterministic, repeatable signature on every cycle of the user program:

1. The C# client opens a Socket against the S7-1200 server IP (e.g. 192.168.0.1) on port 2000 and successfully completes the three-way handshake.
2. The client transmits its first message; the S7-1200 acknowledges receipt and the TSEND reply of "helloworld" returns DONE=1 on the S7 side.
3. The client attempts to send a second message on the same socket. The WinSock stack returns 0x80004005 with a "socket access permissions" error and the socket descriptor is invalidated.
4. On the S7-1200, the TRCV instance remains in BUSY=1, never transitions to DONE, and NDR never sets — meaning the second client message never reaches the user program.
5. If the C# application tries to re-open a fresh Socket, the OS may refuse the bind on port 2000 with the same error until the TIME_WAIT timer expires (default 240 s on Windows).

Two separate but interacting bugs are present: one in the PC client (improper socket lifecycle), and one in the PLC program (incorrect TRCV length and AdHoc configuration). Fixing only one side is insufficient — both must be corrected for a stable, permanent connection.

2. Affected Hardware and Firmware

3. Error Code Reference

4. Root Cause Analysis

Three independent defects combine to create the loop-failure symptom. Each is documented separately so the engineer can verify which is present in their project.

4.1 Defect 1 — C# client re-creates the socket per message

The most common pattern in PC-side messenger code is to wrap every Send/Receive in a using (var client = new TcpClient(...)) block. Each iteration of the loop opens, binds, sends, and disposes the socket. The Windows TCP/IP stack keeps the four-tuple (local-IP, local-port, remote-IP, remote-port) in TIME_WAIT for 240 s after the close, so the next iteration's Bind() on the same local port collides with the still-resident tuple and WinSock returns EACCES (0x80004005).

The correct pattern is to instantiate one Socket (or TcpClient) for the lifetime of the messenger session and call Send and Receive on that single instance. Reconnection logic should live in a separate try/catch outside the send/receive loop and only fire on a real SocketException.

4.2 Defect 2 — TRCV configured for fixed length, not AdHoc

The S7-1200 TRCV V3.0 block has two operating modes controlled by the LEN input:

• Specified length mode — LEN > 0. The block accumulates bytes until exactly LEN bytes have arrived, then sets NDR=1. If the partner sends fewer or more bytes, the block stays in BUSY indefinitely and never releases NDR.
• AdHoc mode — LEN = 0. The block receives exactly one telegram per call. The first 4 bytes of the telegram are interpreted by the S7 firmware as the length prefix of the user's payload, and the remaining bytes are copied into the DATA receive area. NDR sets after every successfully decoded telegram.

AdHoc is the only mode that supports variable-length PC-to-PLC messaging. The reported project had TRCV_LEN = 1, which is neither specified-length (the PC sent more than 1 byte) nor AdHoc, so TRCV could never finish the receive and stayed in BUSY.

4.3 Defect 3 — TSEND reply and TRCV are sequenced in the same OB1 cycle

The PLC code triggers TSEND (the "helloworld" reply) and TRCV in the same OB1 scan, and the EN_R input of TRCV is tied to a flag that is reset on the rising edge of NDR. When TSEND completes first, the user logic de-asserts EN_R before TRCV has had a chance to consume the second client message, so the second message is lost. TRCV must be called with EN_R = TRUE continuously, and the user's edge-detection on NDR must use the NDR pulse (one cycle) without disturbing EN_R.

5. TCON / TRCV / TSEND V3.0 Configuration

The Open User Communication blocks of S7-1200 firmware 4.x are configured by a single connection description data block generated by the TIA Portal wizard. The wizard writes a TCON_DB (e.g. TCON_DB_1) with the structure TCON_IP_v4. The field map for V3.0 is:

5.1 TCON block wiring

Output interpretation:

• DONE = 1 — connection is up; safe to start TSEND / TRCV.
• BUSY = 1, DONE = 0 — connection establishment in progress; keep REQ = 1.
• ERROR = 1 — read STATUS for the diagnostic code. Common values are 16#80A1_0000 (ID conflict), 16#80C3_0000 (interface not ready), 16#80C4_0000 (partner not yet ready).

5.2 TSEND block wiring

5.3 TRCV block wiring (with AdHoc mode)

Output NDR is a one-cycle pulse on successful receipt. RCVD_LEN reports the number of payload bytes (excluding the 4-byte length prefix) actually received in that telegram.

6. Buffer Sizing — Why 1024 Bytes

The S7-1200 Open User Communication blocks allocate the receive-side internal buffer from the LEN input at the time TRCV is called. In AdHoc mode, the block declares a working buffer of 1024 bytes per active connection; RCVD_LEN can never exceed 1020 (1024 minus the 4-byte length prefix). The C# client must therefore split any outgoing payload larger than 1020 bytes into multiple 1020-byte frames, each prefixed with its 4-byte length header.

For messenger-style traffic (command-and-reply text), keep every frame under 1020 payload bytes. A safe engineering limit is 512 bytes per frame, which leaves margin for protocol overhead and avoids TCP receive-window stalls on slow links.

7. C# Client-Side Implementation Reference

The pattern below avoids the four bugs that produced the reported failure (re-binding per loop iteration, missing frame prefix, no keep-alive, and ignoring the socket-error class). It is provided as a verified reference, not as a substitute for the customer's full application code.

using System;
using System.Net;
using System.Net.Sockets;
using System.Text;
using System.Threading;
using System.Threading.Tasks;

public class S7Messenger : IDisposable
{
    private readonly IPAddress _plcIp;
    private readonly int _plcPort;
    private Socket _socket;                 // single instance for the whole session
    private readonly object _ioLock = new object();
    private CancellationTokenSource _cts;

    public bool IsConnected => _socket != null && _socket.Connected;

    public S7Messenger(string plcIp, int plcPort)
    {
        _plcIp = IPAddress.Parse(plcIp);
        _plcPort = plcPort;
    }

    public void Connect()
    {
        _socket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp)
        {
            NoDelay = true,                  // disable Nagle for low-latency messenger traffic
            ReceiveTimeout = 5000,
            SendTimeout = 5000
        };
        _socket.Connect(new IPEndPoint(_plcIp, _plcPort));
        _cts = new CancellationTokenSource();
    }

    public string Exchange(string request)
    {
        lock (_ioLock)
        {
            byte[] payload = Encoding.UTF8.GetBytes(request);
            byte[] framed  = new byte[4 + payload.Length];
            byte[] lenBytes = BitConverter.GetBytes(IPAddress.HostToNetworkOrder(payload.Length));
            Buffer.BlockCopy(lenBytes, 0, framed, 0, 4);
            Buffer.BlockCopy(payload, 0, framed, 4, payload.Length);

            _socket.Send(framed);                                    // one Send, one Socket

            byte[] hdr = new byte[4];
            int read = 0;
            while (read < 4)
            {
                int n = _socket.Receive(hdr, read, 4 - read, SocketFlags.None);
                if (n == 0) throw new SocketException((int)SocketError.ConnectionReset);
                read += n;
            }
            int respLen = IPAddress.NetworkToHostOrder(BitConverter.ToInt32(hdr, 0));
            if (respLen <= 0 || respLen > 1020) throw new InvalidOperationException("Bad reply length");

            byte[] body = new byte[respLen];
            read = 0;
            while (read < respLen)
            {
                int n = _socket.Receive(body, read, respLen - read, SocketFlags.None);
                if (n == 0) throw new SocketException((int)SocketError.ConnectionReset);
                read += n;
            }
            return Encoding.UTF8.GetString(body);
        }
    }

    public void Dispose()
    {
        try { _cts?.Cancel(); } catch { }
        if (_socket != null)
        {
            try { _socket.Shutdown(SocketShutdown.Both); } catch { }
            _socket.Close();
            _socket = null;
        }
    }
}

8. Step-by-Step Resolution Procedure

Apply the steps in order. Each step has an independent verification check so the engineer can stop as soon as the connection stabilises.

Step 1 — Verify the S7-1200 firmware and block versions

1. Online → CPU → Online & Diagnostics → General: confirm firmware V4.1.
2. In the project tree, expand Program blocks → System blocks → Communication. Right-click TCON, TRCV, TSEND → Properties → Information → Version: each must show 3.0.
3. If the version is 2.0, right-click the block in the program → Replace with type → TCON_V3 (or TRCV_V3 / TSEND_V3) and recompile.

Step 2 — Generate the TCON_DB with the wizard

1. Open the TCON instance and click the wrench icon on the CONNECT input.
2. Select Partner: unspecified → TCP → Passive connection.
3. Set Local port = 2000, leave Remote address = 0.0.0.0, Remote port = 0.
4. Accept the wizard → a new TCON_DB_1 is created with the structure from the table in section 5.

Step 3 — Configure TRCV in AdHoc mode

1. Set the LEN input of TRCV to a constant 0.
2. Wire EN_R to a tag that latches TRUE on TCON.DONE and resets only on TDISCON.DONE or a deliberate stop command.
3. Create a dedicated ReceiveDB with ARRAY[0..1023] OF BYTE and point the DATA input at it.

Step 4 — Frame the C# client messages with a 4-byte length prefix

Apply the framing shown in the reference implementation in section 7. Without the 4-byte length prefix, the S7-1200's AdHoc TRCV cannot decode the payload and the next receive will appear stuck or be reported as a length error.

Step 5 — Reuse a single Socket on the C# side

Refactor the PC application so that the Socket (or TcpClient) is created once on application start, in a Connect() method, and disposed only on application exit. Wrap all Send/Receive calls in a single lock block to serialise them.

Step 6 — Add a reconnection watchdog

1. In the PLC, after TCON.DONE = 0 for more than 5 s, call TDISCON (REQ, then wait for DONE), then re-trigger TCON.REQ.
2. In the C# client, on any SocketException with SocketError in {ConnectionReset, NetworkUnreachable, ConnectionAborted, NotConnected}, close the socket, wait 1 s, and call Connect() again.

9. Verification and Commissioning Checks

With the project reloaded to the CPU and the C# client rebuilt, run the following verification matrix. All checks must pass before the messenger is considered field-ready.

10. Diagnostic Watch Table (Suggested)

Drop this watch table into the project for live troubleshooting. Right-click in the PLC tag table and create the following tags.

11. Cross-Reference Notes

• For S7-1200 firmware 3.x projects, the equivalent blocks are TCON_V2, TSEND_V2, TRCV_V2. The AdHoc behaviour is identical, but STATUS codes for length errors are W#16#8086_0001 in V3.0 and W#16#8086_0000 in V2.0.
• For S7-1500 with block V4.x, additional parameters BUSY_TYPE and EXT_STATUS are available; the framing on the wire is unchanged.
• For UDP, use TUSEND and TURCV; no AdHoc mode exists because UDP is datagram-oriented. The same framing rule (4-byte length prefix) does not apply — UDP preserves message boundaries natively.
• For the same messenger pattern on S7-1500, the on-board PROFINET interface hardware ID is typically 0 to 2 instead of 64; the value is always read from the system constants of the selected interface.

Refer to the SIMATIC S7-1200 Programmable Controller System Manual, entry ID 109741656, chapter "Open User Communication", for the canonical TCON_IP_v4 structure and the full STATUS code list. The TIA Portal online help for the TCON/TSEND/TRCV V3.0 blocks also contains the wizard screenshots referenced in Step 2 of section 8.

FAQ