S7-300 to S7-1200 Open IE Communication: Scaling from 2 to 6 Slaves and Eliminating 13-Second Response Delays

A CPU 315-2 PN/DP that exchanges data with six S7-1200 controllers over Open IE Communication (TCP, ISO-on-TCP, or UDP) frequently exhibits sub-second response times with two slaves but degrades to 10–15 second update cycles once the topology is extended. The root cause is almost never the Ethernet cable; it is a combination of serialized polling, suboptimal TCON setup, blocked receive jobs, and connection resource exhaustion on either the S7-300 master or the S7-1200 partners. This reference walks through the exact configuration that Siemens documents in their Open IE Communication examples, explains why each parameter matters, and provides a step-by-step methodology that takes the 13-second delay down to < 200 ms per cycle.

1. Problem Statement and Symptoms

The reported scenario is:

• Master: SIMATIC S7-300, CPU 315-2 PN/DP (6ES7 315-2EH14-0AB0 or -2EH13-0AB0).
• Slaves: Six SIMATIC S7-1200 CPUs (typical mix: CPU 1214C DC/DC/DC, 6ES7 214-1AG40-0XB0).
• Protocol: Open IE Communication via the integrated PROFINET interface of the CPU 315-2 PN/DP.
• Program basis: Siemens sample "Open IE Communication Data Exchange S7-300 – S7-1200", originally written for two slaves.
• Observed symptom: All six slaves eventually communicate, but the handshake/refresh cycle is approximately 13 seconds, regardless of payload size (a few bytes per direction).

The 13-second figure is diagnostic in itself. A 1 Gbit/s PROFINET interface with six 100 Mbit/s S7-1200 partners will never introduce 13 seconds of wire time. The delay is being created inside the S7-300 cycle, the connection establishment logic, or the S7-1200 receive job sequencing. The remainder of this article classifies each of those layers.

2. Hardware Identification and Connection Resources

Before any TCON parameter is touched, the actual installed hardware must be confirmed, because the connection budget of every CPU is firmware-dependent.

2.1 S7-300 CPU 315-2 PN/DP Connection Budget

The CPU 315-2 PN/DP integrated PROFINET interface supports a maximum of 16 S7 connections for Open IE (TCP/ISO-on-TCP/UDP) communication in parallel, of which several are reserved by the operating system for online, HMI, routing, and web server. The figures below are taken from the Siemens S7-300 CPU 315-2 PN/DP manual, edition 09/2018, and apply to firmware V3.3.x:

For the six-slave use case, six Open IE user connections are required on the master side — comfortably below the 16-connection ceiling. The bottleneck is therefore not the S7-300 master itself unless the program also opens an HMI panel and an engineering PG online session in parallel.

2.2 S7-1200 CPU Connection Budget

The S7-1200 is the binding constraint for multi-slave Open IE topologies. The maximum number of Open IE connections per CPU, taken from the S7-1200 Programmable Controller System Manual (article ID 109751634, edition 04/2019), is shown below:

For the 1214C and larger variants, 8 simultaneous Open IE connections are available. Six of those are consumed by the S7-300 master, leaving two for an HMI panel, the TIA Portal online session, or a second master. This is workable but tight; if the system later adds an HMI panel, you must reserve at least one connection for it before the master and open only five slave links.

3. Open IE Communication Architecture

Open IE Communication in the SIMATIC world refers to the family of TCON, TSEND, TRCV, TCONFIG, TDISCON, and T_RESET blocks from the "Communication Blocks" section of the SIMATIC standard library. Three transport modes are supported:

For S7-300 to S7-1200 handshakes, ISO-on-TCP (B#16#12) is the most common choice because every frame carries a 4-byte length prefix that allows the receiver to fully populate a TRCV data view even when the application polls on a long interval. Plain TCP is acceptable but requires the application to manage frame boundaries itself.

4. Root Cause Analysis: Why Response Time Climbs to 13 Seconds

Five distinct root causes produce the "13-second response time with 6 slaves" symptom. Each is reproducible and each can be detected from the program and the online diagnostics without packet capture.

4.1 Serialized TCON Call Pattern

The most common cause. The Siemens sample program for two slaves is built around an OB1 cycle that sequentially calls TCON for slave 1, waits for the connection to be established, then calls TSEND, then TRCV, then repeats for slave 2. When that pattern is naively extended to six slaves and the connections are re-established every cycle (i.e., the TCON block is called on every OB1 pass with REQ = TRUE and the connection is then torn down with TDISCON at the end of the cycle), the S7-300 spends almost all of its time in connection establishment rather than data transfer. A typical ISO-on-TCP three-way handshake on a 100 Mbit/s link costs 30–80 ms; multiplied by 6 partners and an additional 1-second TCP keep-alive window, the cycle stretches to 5–10 seconds even when no data is being exchanged.

4.2 TRCV with Length = 0 Stuck Pending

If TRCV is configured with LEN = 0 (ad-hoc length) and the receive job is started but no data is delivered within the configured ad-hoc timeout, the block sits in DONE = 0, ERROR = 0, STATUS = 0x7000 indefinitely. The next TSEND on the same connection can still proceed, but many implementations wait for the receive to complete before issuing the next send. With six partners and a slow partner, the chain stalls for 8–10 seconds per round.

4.3 TCON Connection-ID Collision

When the same connection ID is accidentally reused between two TCON calls, the second call returns STATUS = 0x80A7 and the previous connection on that ID is implicitly torn down. The result is a constant re-connect loop on one of the slaves, visible as a 10–15 s "blink" in the partner availability.

4.4 S7-1200 OB1 Priority Lower Than Expected

The S7-1200 default OB1 priority is 1. If the S7-1200 program places the TCON/TRCV blocks inside a low-priority cyclic OB (e.g., OB200) and the cycle time of the S7-1200 rises to 200 ms, the receive side of the handshake lags the master's send rate. Six lagging slaves queue up to roughly 6 × 200 ms = 1.2 s, which on its own does not produce 13 s, but combined with 4.1 it does.

4.5 Watchdog / Keep-Alive Misconfiguration

Siemens default keep-alive for ISO-on-TCP is 30 seconds. If the S7-300 watchdog byte TCON_IP_V4.WatchdogTime is left at W#16#0000 (default 30 s) and the S7-1200 side sets it to a higher value, the master's TSEND returns STATUS = 0x80B5 "Connection terminated by remote partner" after 30 s of silence. The "silent" period is created by OB1 buffering; the result is a 30-second stall and a reconnect that adds another 1–2 s on top.

5. TCON Configuration for Multiple Slaves

The Siemens sample program uses a single TCON block per partner and a single TRCV/TSEND pair per partner. The connections must be established once in OB100 (restart OB) and then left open for the lifetime of the program. The corrected approach is reproduced below.

5.1 Per-Slave Connection ID and Hardware ID Assignment

Every TCON instance on the S7-300 must be assigned a unique ID in the range 1..65535. The PROFINET interface hardware ID is taken from the device configuration (e.g., HW_ID = 256). A common workable assignment for six slaves is:

Each slave listens on the same remote port (2000) but the master uses a different local port per connection (2000..2005). The PROFINET stack treats each (local IP, local port, remote IP, remote port) tuple as a unique connection endpoint, so no collision occurs.

5.2 CONNECT Structure (UDT 65 / TCON_IP_V4)

The CONNECT parameter of TCON must point to a TCON_IP_V4 data block initialised exactly once during startup. A minimal example for slave 1:

DATA_BLOCK DB200 "Slave1_Connect"
{ S7_read_only := 'FALSE' }
VERSION : 0.1
  STRUCT
    InterfaceId    : BYTE  := B#16#01;   // PROFINET interface 1
    Length         : BYTE  := B#16#40;   // 64 bytes total CONNECT length
    ConnectionType : BYTE  := B#16#12;   // ISO-on-TCP (RFC 1006)
    ActiveEstabl   : BYTE  := B#16#01;   // 1 = active, 0 = passive
    LocalTSAPHi    : BYTE  := B#16#00;
    LocalTSAPLo    : BYTE  := B#16#00;   // Local TSAP = 00.00 (any)
    RemTSAPHi      : BYTE  := B#16#01;
    RemTSAPLo      : BYTE  := B#16#01;   // Remote TSAP = 01.01 (must match S7-1200)
    TSelect        : DWORD := DW#16#FFFFFFFF; // TPDU size: any
    TPDU            : BYTE := B#16#0A;   // 1024 octets
    LocalIP[1..4]  : BYTE  := 10,0,0,1;  // S7-300 PROFINET IP
    RemIP[1..4]    : BYTE  := 10,0,0,101;// S7-1200 #1 IP
    LocalPort      : WORD  := W#16#07D0; // 2000 decimal
    RemPort        : WORD  := W#16#07D0; // 2000 decimal
    Spare1..12     : BYTE  := 12(#00);
  END_STRUCT;
END_DATA_BLOCK

The ActiveEstabl flag determines which side initiates the three-way handshake. The convention is: the master always acts as active. Setting both sides to active causes a connect storm and the 13-second symptom reappears.

5.3 OB100 Restart Logic

The TCON call must be made once in OB100 (warm restart) and only re-issued if STATUS = 0x80A7 or 0x80C8 is observed. A common OB100 skeleton:

// OB100 — Restart / Warm Restart
// Issue one TCON per slave and never repeat unless disconnected.
      SET;
      S     "conn1_active";   // bit memory for handshake latch
      S     "conn2_active";
      S     "conn3_active";
      S     "conn4_active";
      S     "conn5_active";
      S     "conn6_active";

// Issue six TCON calls in parallel (no SEQUENTIAL cascade)
      U     "conn1_active";
      =     L 0.0;
      CALL  "TCON_DB" , DB100 // instance DB for slave 1
         REQ     := L 0.0
         ID      := 1
         CONNECT := "Slave1_Connect".CONNECT
         DONE    := "conn1_done"
         BUSY    := "conn1_busy"
         ERROR   := "conn1_err"
         STATUS  := "conn1_status";
// repeat with ID=2..6 and corresponding CONNECT DBs

OB100 runs once on power-up and once on stop-to-run transition. After the connections are up, OB1 only needs to call TSEND and TRCV.

6. S7-1200 Partner Configuration

Each S7-1200 must act as the passive connection endpoint. The TIA Portal configuration procedure (also valid in STEP 7 V5.5 with the S7-1200 add-on profile) is:

1. Open the S7-1200 device configuration in TIA Portal.
2. Open "Properties > General > PROFINET interface > Ethernet addresses" and assign a static IP (e.g., 10.0.0.101/24) — never use DHCP for industrial data exchange.
3. Add a new "Open User Communication" connection under "Devices & Networks"; the wizard will create a TCON instance DB on the S7-1200 side.
4. Set connection type = ISO-on-TCP.
5. Set the S7-1200 as passive partner (ActiveEstabl = 0).
6. Set the local TSAP on the S7-1200 to match what the S7-300 expects (in the example above: 01.01 = 0x01 0x01).
7. Set the local port to 2000 and the remote (S7-300) IP to 10.0.0.1, remote port to 2000..2005 (whatever the master uses for that slave).
8. Disable the S7-1200 web server if not in use, to free one Open IE resource.
9. Compile and download to the S7-1200.

The exact TIA Portal V17+ property navigation is documented in the Siemens TIA Portal Help portal (online) under "Editing devices and networks > Configuring connections > Open User Communication". An additional reference for related PROFINET / PROFIBUS direct data exchange configuration is the Siemens TIA Portal V20 direct data exchange example; while that article specifically covers PROFIBUS DP, its connection-table procedure is structurally identical to the Open IE workflow.

7. Handshake Cycle Optimization

Once the connections are persistent, the cycle time of the data exchange is dominated by three parameters: the S7-300 OB1 cycle, the S7-1200 OB1 cycle, and the TRCV polling interval. The targets are:

• S7-300 OB1 cycle: ≤ 50 ms (verified via OB1_PREV_CYCLE tag, address OB1.PREV_CYCLE_TIME in ms).
• S7-1200 OB1 cycle: ≤ 20 ms (typical default for a 1214C with a small program).
• TRCV poll interval: equal to the OB1 cycle, but the receive job should be re-armed immediately after each DONE event, not on a timer.

A reference OB1 fragment that demonstrates the correct re-arming sequence on the S7-300 is:

// OB1 — cyclic data exchange with 6 slaves
// Assumes connections already up (DONE flags from OB100 are all TRUE).
// One TSEND and one TRCV per slave; TRCV is re-issued the same cycle it completes.

      A     "conn1_done";
      JCN   N1;
      // First frame received — re-arm TRCV immediately
      L     0;
      T     "trcv1_id";
      CALL  "TRCV_DB" , DB110
         EN     := TRUE
         ID     := 1
         LEN    := 32             // expected payload length in bytes
         DATA   := P#DB120.DBX0.0 BYTE 32
         NDR    := "trcv1_ndr"
         BUSY   := "trcv1_busy"
         ERROR  := "trcv1_err"
         STATUS := "trcv1_status";

      // Send reply only if new data arrived (NDR rising edge)
      U     "trcv1_ndr";
      FP    "trcv1_ndr_fe";
      =     L 0.0;
      CALL  "TSEND_DB" , DB111
         REQ    := L 0.0
         ID     := 1
         LEN    := 32
         DATA   := P#DB120.DBX32.0 BYTE 32
         DONE   := "tsend1_done"
         BUSY   := "tsend1_busy"
         ERROR  := "tsend1_err"
         STATUS := "tsend1_status";

N1:   // repeat for ID=2..6 with DBs 112/113, 114/115, 116/117, 118/119, 120/121

Note that there is no per-cycle re-issue of TCON. Once "conn1_done" is set, TCON is never called again unless the link goes down and is detected by a watchdog tag (see Section 10).

8. Polling vs Event-Driven Communication

The 13-second symptom in the original report typically hides a poll-on-error pattern: the master only re-issues TSEND after it has detected an ERROR on the previous TRCV, and the wait between error-detection and re-issue is a 10 s timer. Eliminating the timer and re-arming TRCV on the rising edge of NDR collapses the cycle to the OB1 period.

The two architectural choices and their trade-offs are summarised in the table below.

For the S7-300 to S7-1200 use case described in the question (handshaking of a few process bytes per partner), the "Poll on OB1, persistent connection" pattern is the correct choice. The resulting cycle time is OB1_300 + OB1_1200 + 2 × Ethernet_RTT, which for a healthy 100 Mbit/s link is < 100 ms per slave. With six slaves, the worst-case cycle is approximately 600 ms; the observed 13 s is therefore always a code problem, never a wire problem.

9. Connection Resource Planning Worksheet

Before deployment, complete the following table to ensure no partner exceeds its Open IE budget. Each "Yes" consumes one connection on the S7-1200 side.

If the subtotal approaches the per-CPU ceiling, the project must either upgrade the S7-1200 (1214C is the minimum recommended for six-slave master use) or split the slave network across two S7-300 masters.

10. Diagnostic and Verification Procedure

To prove that the 13-second delay has been resolved, perform the following checks in order. Each step lists the data point to capture, the expected value, and the corrective action if the value is wrong.

1. Capture OB1 cycle time on the S7-300. In TIA Portal, add the S7-300 to the online connection, open "Diagnostics > Cycle time" and read the minimum, maximum, and current cycle. Expected: ≤ 50 ms. If the maximum exceeds 150 ms, the OB1 program is too heavy; move the Open IE calls into a faster OB (e.g., OB35) or split the program.
2. Capture OB1 cycle time on every S7-1200. Online > Diagnostics > Cycle time. Expected: ≤ 20 ms.
3. Inspect TCON status words. Online monitor the DONE, BUSY, ERROR, and STATUS tags of every TCON instance. Expected: DONE=TRUE, BUSY=FALSE, ERROR=FALSE, STATUS=0x0000 for all six. Any non-zero STATUS at steady state is a fault that must be interpreted (see Section 11).
4. Time-stamp a write/read round trip. In the S7-300, write a 4-byte counter to slave 1, then read it back. Use RD_SYS_T (SFC1) to bracket the operation. Expected round trip on a single slave: < 30 ms. Total for six slaves in sequence: < 200 ms. If the round trip exceeds 1 s, the TCP stack is not reusing connections (Section 4.1 root cause).
5. Run a 24-hour soak test. After commissioning, leave the system in cyclic exchange for at least 24 h and log the S7-300's OB1_PREV_CYCLE maximum. If the maximum drifts above 100 ms, the system is leaking connections (TCON is being called too often); revert to the OB100-only establishment pattern.
6. Capture connection statistics from the S7-300 PROFINET interface. Online > Diagnostics > PROFINET > Statistics. Confirm exactly six ESTABLISHED connections, zero LISTEN, zero CLOSE_WAIT, zero TIME_WAIT older than 60 s.

11. Common Fault Codes and Recovery

The following TCON/TSEND/TRCV status codes are encountered when scaling the Siemens sample from two to six slaves. Sources: SIMATIC S7-300/400 Standard and System Functions manual (entry ID 109751634 cross-reference) and the TIA Portal online help for the communication blocks.

12. Frequently Asked Questions