Resolving S7-300 CPU Connection Resource Exhaustion with WinCC

Symptom pattern: an S7-300/400 station in a multi-PLC Ethernet network works normally with the engineering station (PG) and one WinCC HMI. When a second or third WinCC station is added, the PG can no longer establish an online connection to that specific CPU, while the other PLCs on the same subnet remain reachable. The WinCC runtime stations themselves may stay online, but STEP 7 reports connection errors (0x0311, 0x0312, 0x0335) and the HMI diagnostic buffer fills with "connection aborted / resource exhausted" entries.

This article documents the field-proven resolution path, expands the source case with the underlying CPU resource model, and provides verification steps so the same fault does not return when the plant grows by another HMI client.

1. Root Cause: S7 Connection Resources Are a Fixed CPU Budget

Every S7-300 CPU has a hard-coded maximum number of S7 communication resources. These resources are shared by:

• PG (programming device) online connections
• OP/HMI (WinCC, WinCC flexible, ProTool) connections
• S7 communication (PUT/GET, BSEND/BRCV, USEND/URCV) for CPU-to-CPU exchange
• Other S7 connections (e.g., OPC server routing, SNMP, web server on newer 31x-2 PN/DP)

When the configured reservations plus dynamic connections exceed the CPU maximum, the connection manager rejects the new request and may evict the least-recently-used connection. The PG is usually the first to be dropped because it is a low-priority resource and its keep-alive interval is long.

1.1 CPU Connection Resource Reference Table (S7-300)

Source: S7-300 CPU 31x Manual (Entry ID 13684403). The default STEP 7 reservation is 1 PG + 1 OP/HMI; everything else is dynamic. The 12-connection figure quoted in the source case is typical for a 315-2 PN/DP or 317-2 PN/DP where the user has left the default 1+1 reservation and is hitting the dynamic ceiling on a specific CPU because the dynamic pool was already consumed by the first WinCC station's tag traffic.

1.2 Why Only One CPU Is Affected

The source case notes that "only this CPU had the problem and the others with the same settings not." This is the classic fingerprint of resource exhaustion: the affected CPU's connection manager has already allocated resources to ongoing long-lived sessions (the first WinCC station's cyclic read/write jobs, the diagnostic WinCC's tag polling, plus the PG's pending online session). Each session holds its resource until the partner closes it cleanly. If a previous session was not closed correctly (WinCC crash, network blip, runtime stop), the CPU still keeps the resource booked for the keep-alive timeout (default 30 s on WinCC V7, 10 s on WinCC Professional TIA Portal).

The other PLCs in the same network have fewer concurrent clients and therefore enough headroom. This is why the issue appears localized even when every CPU is configured identically.

2. Diagnostic Path Before Touching Any Configuration

Always capture the live state before changing parameters. Two tools give the most direct evidence.

2.1 Read the Online Connection List from STEP 7

1. In SIMATIC Manager, right-click the CPU and select Target System > Online > Diagnostics (or use the Accessible Nodes browser).
2. Open Diagnostics > Connection Overview. The dialog enumerates every active S7 connection to this CPU and the partner IP/TSAP.
3. Sort by Established time. Any connection that persists longer than the keep-alive interval without a partner endpoint is the leak.

Compare the count against the CPU's maximum from the table in §1.1. If the displayed active count equals the maximum, the next request is queued or rejected.

2.2 Read the CPU Diagnostic Buffer

1. From the same online dialog, open CPU > Diagnostic Buffer.
2. Filter for event IDs:
   • 0x0311 — "Communication: connection interrupted"
   • 0x0312 — "Communication: no resources available"
   • 0x0335 — "Communication: connection configuration error"
3. Note the partner IP and the timestamp. A burst of 0x0312 at WinCC startup confirms the resource ceiling is the issue.

3. Solution A: Reserve Connection Resources for WinCC

The Siemens-recommended remedy is to make the OP/HMI connection count explicit and reserved. Reserved resources are guaranteed, even when a third-party client (PG, OPC, web) tries to claim them in parallel.

3.1 STEP 7 V5.x Procedure (SIMATIC Manager)

1. Open the S7 project and select the affected CPU in the component view.
2. Open the Hardware Configuration (HW Config) and double-click the CPU.
3. Switch to the Communication tab.
4. Increase Reservations for OP Communication from 1 to N, where N is the total number of WinCC stations that will hold a permanent connection to this CPU. In the source case, set N = 3 (two main WinCC + one diagnostic).
5. Optionally adjust Reservations for S7 Standard Communication if the CPU exchanges data with other S7-300/400 stations via PUT/GET.
6. Save, recompile the hardware, and download to the CPU. A stop/start is required for CPU 31x; the change is not hot-reloadable.

3.2 TIA Portal Procedure (STEP 7 V16+)

1. In the project tree, open Devices & Networks and double-click the CPU.
2. In the inspector window, choose Properties > Communication.
3. Under Connection resources, set the OP/HMI reservation field to the required number of WinCC stations.
4. Compile and download. The new value takes effect after a CPU restart.

3.3 Recommended Reservation Planning Formula

Required OP reservation = (Number of WinCC stations)
                          + (Number of WinCC RT redundancy partners, if used)
                          + 1 spare for engineering / diagnostic HMI

Required S7 comm reservation = (Number of PUT/GET partners)
                              + (Number of BSEND/BRCV partner channels)

Sanity check:
   PG reserved + OP reserved + S7 reserved <= (Max S7 connections - 2)
The "-2" leaves headroom for one OPC browsing session and one ad-hoc PG.

For the source case (one CPU, three WinCC stations, one PG, no S7-to-S7), the minimum safe configuration is: PG = 1, OP = 3, S7 = 0, total = 4 of the available 12-16. Plenty of margin, but the symptom would still appear if the OP count stayed at 1 because STEP 7 would only guarantee one WinCC slot and let the other two fight over the dynamic pool.

4. Solution B: Verify and Tune the WinCC Side

Adjusting the CPU is half the fix. The WinCC side also has configurable connection parameters that interact with the resource budget.

4.1 WinCC Connection Cycle Time and Update Time

Each WinCC tag poll does not consume a new connection; the connection is multiplexed. However, the number of tags per second drives the CPU's user-interface load. Reference: Communication Resources for S7-300/400 (Entry ID 22091965).

If the diagnostic WinCC station polls hundreds of tags every 250 ms, the CPU spend time servicing those requests and may backlog the PG's online request. The remedy is to:

• Increase the diagnostic station's default update cycle to 1 s or 2 s.
• Group tags into a single read job using the S7 driver block (channel unit S7-ISO-on-TCP).
• Disable unused tag connections in the WinCC tag management.

4.2 WinCC Channel Diagnostics

WinCC logs connection status to <InstallDir>\WinCC\diagnose\ConnectionStatus.log. Open this after the next fault window to confirm whether the partner CPU reported the rejection. The Siemens WinCC Information System documents the path in WinCC V7 Diagnostics (Entry ID 16689010).

5. Wireshark Capture for Verification

For an engineer who wants packet-level proof, the S7comm dissector in Wireshark exposes the connection establishment handshake and the resource-exhausted reason code. The protocol reference is the Wireshark S7comm Wiki page.

5.1 Capture Filter

tcp port 102 and host 192.168.10.42

(Port 102/TCP is the ISO-on-TPK transport; S7comm rides on TPKT/COTP. Replace the IP with the affected CPU.)

5.2 What to Look For

• S7COMM frames with Function Group 2 (Userdata) containing Item Count = 0 after a CR TPDU (Connection Request) — the CPU is rejecting the partner's request because the connection table is full.
• A COTP DR TPDU (Disconnect Request) with Disconnect Reason = 0x0002 ("Invalid TSAP") or 0x0004 ("Resource shortage").
• Multiple parallel CR TPDU attempts from one PG within a few seconds — the PG is retrying because the CPU will not accept the new connection.

5.3 Inline Decoding Tip

Right-click any S7comm frame, choose Decode As, and force s7comm if Wireshark does not auto-detect on port 102 alone. Older firmware variants use port 2000 or 2001; check the CPU's port configuration under Properties > Communication > S7 Connection.

6. Firmware-Specific Considerations

6.1 S7-300 Firmware V3.3+ on PN/DP CPUs

From firmware V3.3 onwards, the integrated PROFINET interface supports up to 16 S7 connections. The reservations tab in HW Config exposes the same fields as V3.2. There is no change in behavior for the resource-exhaustion scenario. The fix is identical.

6.2 S7-400 (CPU 41x)

S7-400 CPUs scale from 16 (CPU 412) to 64 (CPU 417) connections. The same reservation mechanism applies via HW Config > CPU Properties > Communication. The default reservations on S7-400 are also 1+1.

6.3 S7-1500 (Out of Scope but Related)

S7-1500 inherits the same model but raises the ceiling to 64 connections (CPU 1511) up to 256 (CPU 1518). The reservation dialog is at Properties > Communication > Connection resources in TIA Portal. S7-1500 also adds the Connection diagnostics web page that lists every active partner with its keep-alive counter, which is invaluable for spotting the leaking session in real time.

7. Why One CPU and Not Its Siblings?

The source question was: "Why only this CPU had the problem and the others with the same settings not." Three field-validated reasons:

1. Asymmetric client load. The affected CPU is the one that hosts the tags of interest for the diagnostic WinCC station. The other CPUs carry only the main WinCC's tag set, so their connection count is lower.
2. Stale connection from a previous session. If the diagnostic WinCC was ever force-killed (Task Manager, BSOD, power loss), the CPU's connection manager held the resource for the keep-alive timeout. Repeated crashes stack these ghost sessions until the budget is gone.
3. PC station routing. A WinCC station using SIMATIC S7-PLCSIM or an OPC scout client on the same machine opens additional connections that the engineer may not be aware of. STEP 7's Accessible Nodes view will list them but only on the same subnet.

8. Tag Quantity Versus Connection Count

Tags and connections are independent budgets. The source user wondered whether the number of tags is part of the problem. It is — but only on the response-time and CPU scan-load axis, not on the connection-count axis. If a diagnostic WinCC polls 800 tags at 100 ms, the CPU spends measurable OB1 time servicing the requests and the PG can experience sluggish online browse. This is solved by raising the update cycle, not by adding connections.

For a rigorous breakdown of tag-pacing under the S7 driver, see the Siemens Performance FAQ Communication Resources for S7-300/400 and the WinCC channel "S7 Protocol Suite" chapter in the Information System.

9. Preventive Configuration for Multi-WinCC Networks

For a new project with N WinCC stations, set the CPU reservations up front using the formula in §3.3. Then add a small Excel sheet in the project folder:

Document the keep-alive timeout in WinCC and the S7 connection timeout in STEP 7 so the on-call engineer has a single reference.

10. Verification Procedure

After downloading the new reservation, run this checklist:

1. From the PG, Accessible Nodes → ping all CPUs. Confirm 100% reachability.
2. Open an online view on the previously failing CPU. Confirm the connection establishes within 3 s.
3. Start all three WinCC stations simultaneously. Watch the CPU diagnostic buffer for 5 minutes. No 0x0312 should appear.
4. Force a WinCC station crash (kill the WinCC.exe process). Wait 60 s. Restart WinCC. The connection must re-establish and the resource count must return to the same value. This proves no ghost session leaked.
5. Run a Wireshark capture on port 102 for 60 s during normal operation. Confirm the connection count matches the reservation table in §3.3.

11. Troubleshooting Matrix

12. Summary

The source case is a textbook example of S7 connection-resource exhaustion on a CPU 31x with default 1+1 reservation. Adding a third WinCC station pushed the dynamic pool past the available headroom on one CPU because that CPU was hosting all the diagnostic tags and one or more ghost sessions from prior crashes. The fix is to make the OP/HMI reservation explicit and equal to the number of permanent WinCC partners, then verify with the CPU diagnostic buffer and the Wireshark S7comm dissector. With the reservation in place, the PG and all three WinCC stations can coexist on the same CPU indefinitely.