Troubleshooting S7-1200 CPU 1214 OPC Connection Loss with PC

Problem Description

The reported fault involves a fleet of SIMATIC S7-1200 CPUs (CPU 1214, firmware V3.1) communicating with a SIMATIC PC Access OPC server over an Ethernet TCP/IP intranet. The symptoms are characteristic of an orphaned OPC channel that the S7-1200 still considers active:

• OPC DA tag values stop updating on the SCADA or HMI side.
• The TIA Portal online connection remains established and ICMP ping is successful during the outage.
• Connecting an additional TIA online session often coincides with the OPC channel dropping, indicating interaction between concurrent online resources.
• A CPU STOP/RUN cycle (warm restart) immediately restores the OPC channel without any network reconfiguration.
• Only the S7-1200 CPUs lose the OPC link; S7-200 CPUs on the same LAN remain reachable, ruling out a global cabling or switch fault.

The combination of "TIA still online, ping successful, PLC restart fixes it" rules out physical layer problems and points at the application-layer connection state table inside the CPU, or at the OPC server itself, as the failing element.

Affected Hardware, Firmware, and Network Topology

PC Access is used because the network still carries legacy S7-200 controllers; SIMATIC NET alone does not speak the PPI/TCP protocol used by the S7-200 family, so PC Access often remains in the mix for mixed fleets.

Root Cause Analysis

Four independent failure mechanisms map onto the reported symptom set. In field practice more than one is active at the same time, which is why a CPU warm restart recovers the system but the fault then re-occurs after hours or days.

Cause 1 - Saturation of S7-1200 Connection Resources

Every S7-1200 CPU reserves a finite pool of S7 connection resources shared by PG, HMI, S7 routing, OPC, and any user-programmed TSEND_C/TRCV_C/TCON blocks. According to the Siemens S7-1200 system manual chapter "Communication - Connection resources", the maximum number of simultaneously available S7 connections depends on the CPU part number and is constrained by the firmware version. CPU 1214C with FW V3.x supports a maximum in the upper single digit to mid-teen range.

Each PC Access OPC client that holds an active subscription, each HMI panel online, and each TIA online session consumes one of these resources. When the resource table saturates, the CPU can still answer TIA online and ping because those use lower-priority PG/HMI transport paths, but newly arriving connection requests are silently rejected. The symptoms reported - TIA online OK, ping OK, fresh OPC clients fail to add items, restarting the CPU frees resources - are textbook for connection-resource starvation.

Cause 2 - TCP Keep-Alive Timeout in the Network Path

OPC DA is a session-oriented protocol over TCP. If the SCADA host has been idle for tens of minutes, intermediate switches with MAC/PORT-ID aging timers (often 60 to 300 s) or firewalls with idle-timeout ACLs silently drop the flow. The peer socket remains in ESTABLISHED state until the next send(), at which point the TCP stack discovers the failure through retries and RST. The S7-1200 firmware V3.1 does not support per-connection keep-alive tuning; once the OPC server has lost track, the CPU still believes the connection is alive and the next write from PC Access triggers the disagreement.

Cause 3 - PC Access S7-1200 Limitations

PC Access was originally released for the S7-200 family and is supported on S7-1200 only as a compatibility path. Several limitations documented in the PC Access readme apply:

• PC Access uses the S7 communication path (the same path as TIA), not OPC UA. It counts as a "PG/OP connection" on the CPU side.
• PC Access does not expose application-level keep-alive counters or, in older builds, reset its endpoint after a transient network outage. Subscribers that time out are not auto-removed from the server's internal table until the OPC client reconfigures.
• Multiple simultaneous polling groups can open more S7 connections than are visible in the "Project - Stations - PC Access" tree if read/write jobs overlap, exceeding the CPU resource ceiling.

This is why the same PC Access configuration runs stably against an S7-1200 with fewer items but fails in mixed, multi-tag applications.

Cause 4 - Application URI and Certificate Trust on OPC UA Paths

If a migration step has introduced an OPC UA wrapper (for example OPC UA error codes of the OPC Foundation (S7-1500) and the broader OPC UA gateway from SIMATIC NET), connection drops also occur when the Application URI in the client certificate does not match the server-side trust list, or when the certificate chain is broken after the gateway service is restarted. The CPU 1214 V3.1 does not run a native OPC UA server (that capability starts with firmware V4.4 of the S7-1200), so any OPC UA path in this context is hosted externally and must follow the OPC UA application authentication rules.

Connection Resource Limits per CPU 1214C

The exact number of available connections per CPU is product-specific. Use the following table as a planning baseline; always confirm against the S7-1200 system manual for the exact order number that is installed.

Connection-Cost Matrix

For the reported installation, four SCADA clients and one S7 partner plus a single TIA online session already place the CPU at five active connections. TIA re-connections and HMI re-associations can push this above the planning ceiling within the first hours of operation.

Diagnostic Procedure

Perform these steps in order, observing the CPU's online connection table at each transition.

1. Open TIA Portal, go online with the affected CPU using the standard PG/PC interface.
2. Select "Online & Diagnostics" -> "Connection resources" (TIA Portal V13 and later). Note the maximum and currently used count.
3. Open the "Diagnostics" buffer of the CPU. Look for "Connection establishment failed" or "No resources available" event IDs for the S7 connection type.
4. On the PC Access host, stop the PC Access service. Observe whether TIA online and ping still succeed; if they do, the OPC server is the consumer.
5. Issue netstat -ano | findstr 102 on the SCADA host to count TCP sessions against TCP port 102 (Siemens S7 communication). Each established connection that is not used by TIA is an OPC/DDE path.
6. Capture a Wireshark trace filtered on tcp.port == 102 for ten minutes while idle. Look for FIN/RST from the PLC without prior traffic; this confirms the keep-alive theory.
7. Examine the managed switch port for the OPC host. Disable any "MAC aging" or "flow timeout" less than 600 s on the access port that connects to the PC Access server, then repeat the test.

Solution Paths

Apply solutions from least to most invasive. Stop only when "PC restart → 5 day uptime" is observed.

Solution 1 - Migrate PC Access to SIMATIC NET OPC Server

SIMATIC NET OPC (S7 OPC server in the PC software package) is the Siemens-recommended OPC DA server for the S7-1200 and supports server-side connection management that is more robust than PC Access when multiple SCADA nodes and HMIs share the same CPU. The upgrade path is:

1. Install SIMATIC NET V15.1 or later on a dedicated Windows server.
2. Import the S7-1200 station via "Import Station" or "Station Configuration Editor" using the same IP address.
3. Configure an S7 connection set for each CPU 1214 with the property "Active connection establishment = true" so the server initiates the connection.
4. Reduce the S7 connection resource count on each CPU by removing the per-client S7 connections used by PC Access (one connection per SCADA node).
5. Point the four SCADA nodes at the new OPC DA endpoint instead of the per-node PC Access instance.
6. Re-export OPC tags into the SCADA using the built-in OPC DA browser; do not import the PC Access .mdb symbol file.

Reference: Siemens KB 109766709 - Causes of failed OPC UA connection establishment covers the parallel set of root causes that apply to OPC UA gateways built on SIMATIC NET.

Solution 2 - Reduce Active Connection Count

If SIMATIC NET cannot be installed (license or support contract constraints), shrink the number of S7 connections the CPU has to hold at once:

• Bundle the four SCADA clients behind a single OPC server, then expose one aggregated OPC DA tree to the SCADA - count becomes 1 instead of 4.
• Move HMI panels to PUT/GET peer relationships only when the tag count is small, otherwise leave HMIs on HMI-only S7 connections.
• Tighten TIA Portal so that only one engineer can be online at a time (project setting "Number of online connections").
• Avoid overlap between polling-group read jobs in PC Access. Use one polling group per CPU to prevent the OPC server from opening multiple S7 connections to the same target.

Solution 3 - Tune TCP Idle Timeout on the Network

Remove the variable that causes keep-alive disagreements:

• On the managed switch, disable MAC aging on the access port that connects to the SCADA host, or set it to a value above 30 min. Avoid any "Storm control" or "port idle shutdown" feature on that port.
• If a firewall exists between the CPU and the OPC server, raise the TCP idle timeout above 30 min for traffic on TCP port 102.
• Disable any "TCP adjust-MSS" feature that fragments S7 packets below 256 bytes.

Solution 4 - Migrate the OPC Path to OPC UA

CPU 1214C FW V3.1 does not include a native OPC UA server, so the OPC UA path requires an external gateway. Use it as a future-proofing step only after solutions 1 to 3 have been exhausted. Diagnostic guidance for OPC UA-specific failures is documented by Siemens at KB 109766709.

• Use a SIMATIC NET OPC UA server gateway that pulls S7 data and re-exposes it as OPC UA.
• Provision certificates with matching Application URI on both sides (server-side and client-side) of the OPC UA session. A mismatch is documented as a frequent cause in TIA Portal V20 OPC UA error code reference.
• Long-term, plan to replace the V3.1 CPU with a V4.4 or later CPU 1214 that supports a native OPC UA server, eliminating the gateway hop.

Can the PROFINET/Ethernet Port Be Reinitialized in RUN?

There is no S7-1200 firmware V3.1 system function that resets the Ethernet port while the CPU stays in RUN. The CPU does not expose an equivalent of SFBSF01 / SFCS for the PROFINET interface as the S7-300 does. Available options, ordered by side-effect:

• TCP connection reset, not port reset: user programs can call TCON / TDISCON to drop a single Open User Communication connection and re-establish it on the next TCON. This frees the slot in the PLC's internal connection table but is not an Ethernet-port reset.
• Warm restart of the CPU: STOP -> RUN powers down the PROFINET interface for the duration of the startup. This is what the original report does and is the only documented way to release all S7 connections from the CPU side.
• TIA Portal triggered restart: Online -> "Reset and restart" can be used for a STOP-to-RUN sequence from TIA, equivalent to the manual warm restart. This is recommended only in a maintenance window.

Verification Procedure

After each change, observe the system without restart for 72 hours. A correct change should clear all of the following markers.

1. From TIA Portal, open "Online & Diagnostics" -> "Connection resources". "Used connections" stays at or below the count observed before launching TIA online plus the OPC server.
2. OPC DA tag update latency stays constant on the SCADA dashboard over the full 72 hours.
3. The CPU's diagnostic buffer contains no "No resources available" event for connection establishment.
4. Wireshark on TCP port 102 shows no unexpected FIN/RST exchange between the OPC server and the CPU.
5. Power-cycle the managed switch on which the SCADA host is connected while the CPU is running; the OPC channel recovers within 30 s without operator action.

Troubleshooting Matrix

Field-Proven Caveats

• CPU 1214C FW V3.1 is in extended support; firmware updates are no longer released by Siemens for security or compatibility. Plan a hardware migration to FW V4.4 or later for long-term OPC UA support.
• PC Access V1.0 SP6 or later is required to talk to an S7-1200; older PC Access builds cannot establish an S7 connection to the CPU and were a common false-positive in earlier incidents.
• If the SCADA HMI suite is WinCC, configure "OPC channel - update" polling in WinCC to a value above the OPC server's "Cyclical update" rate, otherwise WinCC drops the subscription while the CPU side still holds the resource.