S7 ISO-on-TCP Connection: T-Blocks Setup Without PLC Stop

Problem Overview

Field engineers commissioning Siemens SIMATIC S7-300 and S7-400 controllers frequently report a reproducible anomaly: an ISO-on-TCP (RFC 1006) connection works perfectly when the project is downloaded to the CPU in its entirety, but the same connection refuses to establish — or returns the connection status word to a non-zero error code — when a partial download is performed. The typical scenario in the field is a Hot Restart path where the operator must push only a modified FC (function) or only the hardware configuration, because the controlled process cannot tolerate a STOP transition of the PLC.

This article documents the two validated workarounds for this behavior, the hardware compatibility envelope in which each workaround is valid, the exact FBs (FB63 TSEND, FB64 TRCV, FB65 TCON, FB66 TDISCON) that replace the NetPro-configured connection, and the diagnostic procedure for verifying that the connection has been re-established without ever placing the CPU into STOP.

ISO-on-TCP Protocol Fundamentals

ISO-on-TCP is Siemens' implementation of RFC 1006 (Request for Comments 1006, IETF, 1987) running on top of TCP/IP. It provides a reliable, connection-oriented transport that preserves the TSAP (Transport Service Access Point) addressing model inherited from the ISO transport layer. This is what allows a SIMATIC S7 CPU to be addressed by symbolic, application-layer identifiers rather than by raw IP and port alone.

The TSAP is a 2-byte (in compact format) or longer (extended format) identifier. In SIMATIC projects the local and remote TSAPs are configured inside NetPro (STEP 7 V5.x) or inside the Devices & Networks editor of TIA Portal, and the resulting connection description is downloaded as part of the CPU's connection database.

Root Cause: Why Partial Downloads Break the Connection

The ISO-on-TCP connection resource is not part of the user program. It is part of the CPU's connection database, a system data block that is created, owned, and managed by the CPU firmware. The connection entries in this database are populated from two distinct sources:

1. The hardware configuration (HW Config / Devices & Networks), which defines the local interface (IP, subnet, MAC, integrated PN port or external CP).
2. The NetPro / connection configuration, which defines the partner IP, the local TSAP, the remote TSAP, and the connection type.

A full project download writes both sources to the CPU as a single, internally consistent transaction: the firmware tears down any existing connection database, replaces it with the new one, and re-initializes all S7 / open IE / ISO-on-TCP / TCP / UDP sockets. The result is a clean state in which the user program can immediately send and receive.

A partial download — for example Download → Hardware only, or Download → User program to target device only — does not necessarily rewrite the connection database. The behavior depends on the selected object and on the CPU's firmware:

• Downloading only the hardware configuration without selecting the connection entries typically leaves the old connection database intact, but the new IP or subnet may be applied. If the new IP differs from the old one, the existing open ISO-on-TCP connection enters a fault state and the CPU marks the connection as STATUS = 0x0001 (connection already established) or 0x0002 (connection terminated by remote) on the next user read.
• Downloading only the FC / OB / DB block container does not rewrite the connection database at all, but if the user program that uses the connection changes (for example a new connection ID is assigned) the application code can no longer find the connection resource it expects.
• Downloading the connection configuration standalone rewrites the connection database while the user program continues to run. The CPU performs a controlled teardown of the affected connection and a re-init, but the order in which the partner stations and the local CPU are updated matters.

The reported symptom — "connection cannot be established after a partial download" — most often traces to the connection configuration object being excluded from the download set, or being downloaded to one partner before the other partner is updated. The CPU on the side that has been updated attempts to open the connection with the new parameters; the partner CPU still holds the old parameters in its connection database and rejects the open, which surfaces as STATUS = W#16#80E1 (connection setup rejected by remote) on the open IE blocks or, on the partner, as STATUS = W#16#80E2 (local resource shortage) and similar.

Solution A: Programmed Connections with T-Blocks (No NetPro Entry)

The cleanest, most portable workaround is to remove the ISO-on-TCP connection from the NetPro / connection configuration entirely and instead create the connection at runtime from inside the user program. Siemens provides the T-block family (formerly known as the open communication or open IE blocks) for exactly this purpose.

The standard library containing FB63–FB66 is "Standard Library → Communication Blocks" in STEP 7 V5.x, or the SIMATIC_NET_CP / Open_User_Communication library in TIA Portal. The accompanying UDT (User-Defined Type) for the connection description is UDT 65 "TCON_PAR", and the instance DBs for TCON, TSEND, TRCV, and TDISCON are typically FB-typed instance DBs (for example DB65 for TCON, DB63 for TSEND, DB64 for TRCV).

With this approach the connection is not configured in NetPro and is not downloaded as part of the connection configuration. It is born and dies entirely inside the running program. The CPU's STOP-to-RUN transition is irrelevant: the OB100 / OB101 startup routine calls TCON, the connection comes up, and OB1 cycles TSEND / TRCV as required. A partial download of FCs or DBs has no effect on the open IE connection state.

Hardware Compatibility Envelope for T-Blocks

This is the single most common commissioning trap. The T-block family is only supported on the following interface types:

• Integrated PROFINET (PN) interface of the CPU (for example CPU 315-2 PN/DP, CPU 317-2 PN/DP, CPU 319-3 PN/DP, CPU 414-3 PN/DP, CPU 416-3 PN/DP, ET 200S IM 151-8 PN/DP CPU, and the S7-1200 / S7-1500 PN CPUs).
• External CP 343-1 / CP 443-1 modules running a firmware that supports open IE — typically firmware V2.0 or later for the CP 343-1 family, and V2.0 or later for the CP 443-1 family. The CP firmware must explicitly include the open IE / T-block feature; older CP firmware supports only S7 communication and SEND / RECEIVE (PUT / GET) on the S7-300/400 CPs.

UDT 65 "TCON_PAR" — Connection Description Layout

Every TCON call receives its connection parameters through a variable of type TCON_PAR (UDT 65). The structure is:

The compact TSAP form is two ASCII characters interpreted as one byte each (for example TSAP 10.00 → byte1 = 0x10, byte2 = 0x00). The extended form packs the TSAP into a 16-byte field with a length prefix.

Worked Example: S7-300 Active Client to S7-400 Passive Server

The following STL snippet from OB1 calls TCON, then on success uses TSEND and TRCV on the same connection. The instance DB for TCON is DB65; for TSEND, DB63; for TRCV, DB64. The connection description is in DB100 as a UDT 65 variable.

// OB1 - cyclic, called every scan
NETWORK 1  // Request connection on first scan or after error
      A     "FirstScanOrFault"      // user flag, set on OB100 or after TCON error
      FP    "Edge_FirstScan"
      JCN   N1

      CALL  FB65, DB65              // TCON
        REQ   :=TRUE
        ID    :=W#16#0001           // connection ID = 1
        DONE  :=M10.0
        BUSY  :=M10.1
        ERROR :=M10.2
        STATUS:=MW12
        CONNECT:="Conn_100".TCON_PAR // UDT65 in DB100

NETWORK 2  // Send a 20-byte job buffer when TCON is up and request is pending
N1:   A     "JobRequest"            // user flag from upstream logic
      A     "ConnEstablished"        // M10.0 edge from TCON DONE
      JCN   N2

      CALL  FB63, DB63              // TSEND
        REQ   :="JobRequest"
        ID    :=W#16#0001
        LEN   :=20                   // fixed job length
        DATA  :=P#DB101.DBX0.0 BYTE 20
        DONE  :=M20.0
        BUSY  :=M20.1
        ERROR :=M20.2
        STATUS:=MW22

NETWORK 3  // Receive any incoming data
N2:   CALL  FB64, DB64              // TRCV
        EN_R  :=TRUE
        ID    :=W#16#0001
        LEN   :=20
        DATA  :=P#DB102.DBX0.0 BYTE 20
        NDR   :=M30.0
        BUSY  :=M30.1
        ERROR :=M30.2
        STATUS:=MW32
        RCVD_LEN:=MW34

The TIA Portal equivalent uses TSEND_C and TRCV_C (single-instance combined blocks) for the S7-1200 / S7-1500 family; the S7-300/400 with integrated PN still uses FB63–FB66 as above.

Solution B: Partner-Side Download Order (NetPro Path Still in Use)

If the design constraint requires the ISO-on-TCP connection to remain configured in NetPro / TIA Portal Devices & Networks (for example, because the partner is a third-party PLC that requires the S7-300/400 to be the connection owner), the partial-download problem can be resolved by re-ordering the download sequence.

The validated procedure is:

1. Identify which CPU is the active partner (initiates the open) and which is the passive partner (accepts the open). For ISO-on-TCP this is the ActiveEstabl property in the connection configuration; in NetPro it is the "Establish connection actively / passively" checkbox.
2. Download the passive partner first. The passive partner has no open state to maintain, so accepting a new connection configuration is a benign operation.
3. Wait for the passive partner to apply the configuration (typically <5 s; verify by reading the diagnostic buffer for entry "Connection configuration downloaded").
4. Download the active partner. The active partner's new open request will hit the freshly-updated passive partner, and the connection comes up immediately.

Configuration Steps in STEP 7 V5.5 / TIA Portal

The following procedure implements Solution A (T-blocks) in STEP 7 V5.5, which remains the dominant tool for the S7-300/400 installed base.

Prerequisites

• STEP 7 V5.5 SPx (SP2 or later recommended) with the Standard Library → Communication Blocks installed.
• CPU with integrated PROFINET interface or CP 343-1 / CP 443-1 with open-IE-capable firmware (V2.0+).
• IP addresses, subnet mask, and TSAPs documented for both partners.
• Partner CPU reachable on the subnet (verify with ping from the PG or with the online diagnostics in NetPro).

Step-by-Step

1. Open the S7 project in SIMATIC Manager and open the Hardware editor. Confirm that the CPU's PN interface or the relevant CP carries a valid IP address and that the PN/CP is in the same subnet as the partner.
2. In the Standard Library → Communication Blocks, locate FBs 63, 64, 65, 66 and UDT 65. Copy them into the project's Blocks container (drag-and-drop with "Include dependent blocks" checked).
3. Create the connection description DB. Insert a new DB (for example DB100), declare a variable of type TCON_PAR (UDT 65), and fill the fields per the table above.
4. Create instance DBs for TCON, TSEND, TRCV (and TDISCON if used). Each is created automatically when the FB is called with an instance-DB operand in the LAD/FBD/STL editor.
5. In OB1 (or in OB100 for early connection establishment), add the call to FB65 TCON. Wire REQ to a startup flag or a one-shot. The CONNECT input is the UDT 65 variable in DB100.
6. Add FB63 TSEND and FB64 TRCV calls for the cyclic data exchange. Use the same ID as TCON.
7. Compile, download the entire project once, and verify the connection.
8. From this point on, subsequent downloads of FC / DB / OB changes only will not affect the connection, because the connection is owned by the user program, not by NetPro.

Early Connection Establishment in OB100 / Startup

For process-critical applications, move the TCON call into OB100 (warm restart) or OB101 (hot restart) so the connection comes up as part of the CPU startup sequence. OB100 runs once after STOP→RUN, before OB1. The TCON call in OB100 should be triggered unconditionally; the busy/done flags are not relevant during startup because OB100 is non-time-critical.

// OB100 - startup
      CALL  FB65, DB65
        REQ   :=TRUE
        ID    :=W#16#0001
        CONNECT:="Conn_100".TCON_PAR
        DONE  :=M10.0
        BUSY  :=M10.1
        ERROR :=M10.2
        STATUS:=MW12

Diagnostics and Verification

After applying the T-block workaround, verify the connection through three independent channels:

1. Local STATUS word: read DONE, BUSY, ERROR, and STATUS of the TCON instance. A healthy connection returns DONE = 1 and STATUS = W#16#0000 on the first successful call. BUSY = 1 indicates the connection is in progress; wait for DONE or ERROR to settle.
2. Online connection diagnostics: in NetPro or in the Online → Accessible Nodes view, open the connection table. The T-block connection appears with state Established once TCON completes. The interface used (LocalDeviceId) is listed alongside the connection.
3. CPU diagnostic buffer: open the online view of the CPU (target system → CPU Messages) and inspect the diagnostic buffer. A successful T-block connection does not produce a diagnostic entry — the absence of an "open IE" fault entry is itself the positive signal. A failed TCON produces entries with IDs in the W#16#80xx range described in the troubleshooting matrix below.
4. Live data exchange: trigger a TSEND and verify that the partner CPU's TRCV raises NDR = 1 and the received data matches the sent data byte-for-byte. The RCVD_LEN output of TRCV should match the LEN input of TSEND for a fixed-length protocol.

Troubleshooting Matrix: TCON / TSEND / TRCV STATUS Words

Connection ID and Resource Sizing

The S7-300 / S7-400 CPU limits the total number of open communication resources per interface. Practical limits:

Connection IDs must be unique on a per-CPU basis. The conventional assignment is ID = 1 for the first ISO-on-TCP, ID = 2 for the second, and so on, with IDs in the range W#16#0001 to W#16#0FFF typically reserved for open IE / T-block connections. The TIA Portal TSEND_C / TRCV_C blocks on S7-1200 / S7-1500 use a 16-bit connection ID and store the TCON_PAR internally.

Edge Cases and Field-Proven Caveats

TSAP case sensitivity. The ISO-on-TCP TSAP is a byte sequence and is case-sensitive only when the TSAP is interpreted as ASCII. If the local TSAP is configured as S7_01 and the remote is configured as s7_01, the connection will be rejected. Always document TSAPs as exact hex sequences and copy them between stations rather than retyping.

TSAP and routing. An ISO-on-TCP connection that traverses an S7 router (for example across a PN/PN coupler or a PROFINET/PROFIBUS gateway) requires the TSAPs to be unique across all reachable stations. A duplicate TSAP results in the router binding the open to the wrong station. Verify with Online → Accessible Nodes on the engineering station.

Reconnect storms. If the partner CPU has a watchdog or a fast-fail PLC logic that closes the connection on the first error, and the local CPU retries TCON in a tight loop, both stations can enter a reconnect storm that saturates the CP. Add a 1–5 second delay (using a TON timer or a clock-bit-paced edge) between TCON retry attempts.

Hot Restart safety. On a CPU 417 or 416-3 in Hot Restart mode, OB101 is executed on return from power failure. Calling TCON in OB101 is correct. However, the connection is not re-established automatically; the program logic must handle the case where TCON returns ERROR with STATUS = W#16#80C3 (CPU just coming out of STOP). Add a one-cycle delay in OB1 before re-issuing TCON.

PN/PN coupler constraints. When the ISO-on-TCP connection traverses a PN/PN coupler (for example a CU link between two independent PROFINET subnets), the coupler acts as a router and translates TSAPs across the boundary. Configure the TSAPs on each side of the coupler independently, then verify reachability with the engineering station on each subnet.

Watchdog mismatch with T-block timeout. The S7-300/400 CPU's default connection-watchdog timer is 30 s. If a TSEND / TRCV is not serviced within 30 s the CPU closes the connection. The T-block TPDU timeout parameter (in the TCON_PAR extension, firmware V3+ on the CP) can be increased to 60 s or longer for slow polling applications, but this should be documented in the connection log.

Migration Path: From NetPro Connection to T-Block

For existing installations with a NetPro-configured ISO-on-TCP connection that suffers the partial-download problem, the migration is non-disruptive if done in three steps:

1. Add the T-block scaffolding in parallel: copy FB63–FB66 and UDT 65, create the instance DBs, and the connection description DB. Do not enable the TCON call yet.
2. Disable the NetPro connection in the offline project. Download only the connection configuration (in TIA Portal: Download → Connection configuration only). Verify that the connection drops cleanly in the online view.
3. Enable the TCON call in OB1 (or OB100). The connection comes back up under program control. From this point on, the connection is owned by the user program and partial downloads are safe.

The reverse migration (back to NetPro) is possible but not recommended: the NetPro-managed connection is a persistent resource and removing the user program at some later date will close it.

Related Siemens Manuals and Knowledge Base References

• SIMATIC NET: S7-CPs Programming and Operating Manual — Open Communication (TSEND / TRCV / TCON / TDISCON)
• STEP 7 V5.5 — Standard Library: Communication Blocks (FB63–FB66) Reference
• S7-300 CPU 31xC and CPU 31x: Technical Specifications (open IE limits per CPU)
• CP 343-1 Lean / CP 343-1 — Open Communication Block Support (firmware dependencies)
• How do you establish an ISO-on-TCP connection between S7-300/S7-400 stations with FB65 TCON?
• Connection Diagnostics: STATUS Word Decoding for Open IE Blocks
• PROFINET Interface for S7-300 / S7-400: Connection Resource Limits

FAQ