Resolving WinCC Professional Runtime S7-1500 Connection Failures

Problem Overview: WinCC Professional Runtime Loses Connections to S7-1500 PLCs at Startup

Engineers commissioning mid-size WinCC Professional Runtime SCADA stations on TIA Portal V13 SP1 (Update 9 and similar builds) frequently encounter a class of fault where the runtime starts, but a subset of the configured S7-1500 CPU connections remains unreachable. The HMI project typically contains a heterogeneous mix: multiple S7-1500 controllers, an OPC channel, and legacy S7-300 stations on PROFIBUS or Industrial Ethernet. The symptom is that 1–6 of the 12 configured HMI connections fail to come up after the WinCC Runtime service is started, while the same project was verified end-to-end in the engineering station. A recurring field workaround is to launch TIA Portal with no project loaded, run "Update accessible devices" from the "Online access" tree, and then restart the WinCC Runtime — after which all 12 connections establish cleanly.

This article consolidates that workaround, the underlying PG/PC interface configuration that drives it, the access-point selection rules for download vs. deployment, and the verification steps needed to make the fix permanent. A parallel set of guidance is included for projects that have since migrated to WinCC Unified Runtime on TIA Portal V17/V18/V19/V20, where the same root cause produces a different visible alarm.

Affected Software Versions and Configuration Scope

The patterns below were confirmed against the following baseline. Operators on later service packs should still observe the same root causes because the PG/PC interface layer, the S7ONLINE access point, and the WinCC Runtime channel DLLs are largely unchanged across TIA Portal V13 → V20.

Root Cause Analysis: Why the Runtime Cannot Reach Some S7-1500 CPUs at Startup

Three independent defects converge in this fault pattern. Each must be ruled out in turn; the runtime symptom is identical (channel shows red, no cyclic data) but the corrective action differs.

RC-1: PG/PC Interface bound to .TCPIP.Auto.1

The most common cause in TIA Portal V13 SP1 is the PG/PC Interface assignment. If the access point "S7ONLINE" is assigned to <Networkcard>.TCPIP.Auto, the S7DOS / S7ONLINE helper dynamically picks a subnet, and on multi-NIC engineering stations (or stations with Hyper-V/VMware virtual adapters, VPN tunnels, or Wi-Fi enabled) the discovery broadcasts can leave the S7-1500 CPUs in a different broadcast domain. The fix is to bind S7ONLINE to a fixed entry:

• Open Control Panel → Set PG/PC Interface (the 32-bit applet, not the modern Windows setting).
• Under Access Point of the Application, select S7ONLINE.
• In the Interface Parameter Assignment Used list, choose <Networkcard>.TCPIP.1 (the explicit, static entry), not <Networkcard>.TCPIP.Auto.1.
• Click OK and restart the WinCC Runtime service (or reboot for V13 SP1).

The explicit binding forces the S7 communication stack onto a single, predictable NIC, which is what the WinCC Runtime's internal S7 channel expects when it walks its connection list at startup.

RC-2: Accessible Nodes Cache Is Empty on the Target Station

WinCC Professional Runtime in TIA Portal V13 does not perform a full DCP/ARP discovery sweep against every configured connection at boot. Instead, it relies on the accessible nodes cache that was last populated by the engineering station. If the runtime host was never the engineering station, the cache is empty, the S7-1500 CPUs are not yet resolved to IP addresses, and a subset of connections times out. Opening TIA Portal with no project and running Online → Update accessible devices (or Online access → [NIC] → Update accessible devices) populates the cache so that the WinCC Runtime can resolve the targets during its connection walk. The user's reported workaround — opening TIA Portal with no project, updating accessible devices, then starting the runtime — is exactly the cache-priming sequence.

RC-3: Access Point Mismatch Between Download and Target Stations

When the runtime archive is downloaded to the engineering station, the project stores the access point that was active during download (typically S7ONLINE on the engineering NIC). Moving the same runtime archive to a different target station and starting it with that stored access point fails, because the access point does not exist on the target. The fix is to ensure the download is performed with the access point set to S7ONLINE (a Windows-wide symbolic name, not a per-NIC name) so that the target station resolves it to its own PG/PC Interface assignment at start time.

Step-by-Step Resolution Procedure

1. Verify the engineering station inventory. Confirm the exact number of S7-1500, S7-300, and OPC connections in the project tree (Devices & networks → [HMI_RT] → Connections). Record it. This is your "all 12" baseline.
2. Set the PG/PC interface. Launch Set PG/PC Interface from Control Panel. Select S7ONLINE as the access point and <Networkcard>.TCPIP.1 as the interface. Do not select ...TCPIP.Auto.1.
3. Prime the accessible-nodes cache. Open TIA Portal V13 SP1 with no project. In the project tree, expand Online access, expand the active NIC, and click Update accessible devices. Wait for the scan to complete and for every S7-1500/S7-300 to appear with its IP and PROFINET name.
4. Start the WinCC Runtime. Launch WinCC Runtime Manager, then start the configured runtime. Verify in the Runtime diagnostics that all 12 connections reach the green state. Note the channel name and connection name for any red connections.
5. Re-export the runtime for the target station. With the project still open on the engineering station, choose HMI_RT → Compile → Software (rebuild all), then Download to target system → Filesystem. The download must be performed with the S7ONLINE access point active on the engineering station.
6. Deploy to the target station. Copy the runtime archive to the target PC. On the target, open Set PG/PC Interface and confirm S7ONLINE is bound to <Networkcard>.TCPIP.1 on the target's own engineering NIC. Start the runtime; all 12 connections should come up.
7. Persist the fix. Export the PG/PC interface assignment from the engineering station (Set PG/PC Interface → Export…) and import it on the target station. This removes the per-station drift that re-introduces RC-3 after every rebuild.

Verification Matrix

Equivalent Procedure for WinCC Unified Runtime (TIA Portal V17–V20)

Stations that have been upgraded from WinCC Professional to WinCC Unified Runtime encounter a similar connection-loss symptom, but the alarm surface is different and the workaround is platform-side. Siemens documents the no-connection workflow for Unified at the official TIA Portal help portal.

1. Open the WinCC Unified Runtime station's diagnostics overview. The system alarm list contains entries of the form "Connection '<name>' is disconnected" with a cause code that maps to one of: physical layer (cable, plug, LED), IP layer (subnet, gateway, S7-1200/1500 protection), or TLS/OPC-UA layer.
2. For physical-layer alarms, verify the patch cable seating, the switch port LED, and the CPU's LINK LED. Replace the cable if any LED is dark when both ends are powered.
3. For IP-layer alarms, confirm that the Unified station, the S7-1200/1500, and any switch in the path are in the same subnet, that no duplicate IP exists (run arp -a), and that the PLC's Connection mechanisms allow GET/PUT from the HMI's IP if the project uses the legacy S7 channel rather than the symbolic optimized block channel.
4. For TLS/OPC-UA alarms, confirm that the Unified station trusts the PLC's certificate (export from the PLC's Web server or TIA project, import into the Unified station's Certificate management under Runtime settings).
5. After every corrective action, restart the Unified Runtime service from WinCC Unified Configuration → Runtime → Restart. Do not rely on a hot reload of connections — Unified intentionally tears down and re-establishes only the affected channel, so a full service restart is the only deterministic way to clear stale TLS sessions.

For the canonical Siemens procedure, see Procedure if there is no connection (RT Unified) — TIA Portal Help.

Parameter Reference: PG/PC Interface and S7ONLINE

System Alarms and Channel Diagnostics

When the WinCC Runtime starts and a connection fails, two diagnostic surfaces are available. Use both; the Runtime's own alarm log gives the channel-level error code, while the PLC's diagnostic buffer gives the CPU-side reason.

• WinCC Runtime alarm log (gray/white box on the Runtime screen if configured): entries such as "Connection 'PLC_1500_03' interrupted" and "Connection 'PLC_1500_03' re-established". The interruption is logged with the channel DLL return code; common values are 0x00000001 (partner not found), 0x0000000A (timeout), and 0x00000033 (resource error). All three resolve to PG/PC interface or access-point misconfiguration in this fault class.
• S7-1500 diagnostic buffer (online via TIA Portal): entries under Communication show the source IP and the reject reason. "Connection was rejected — access protection active" indicates the PLC's connection-mechanism list is filtering the HMI's IP; "TLS handshake failed" indicates a Unified/OPC-UA certificate problem.

Preventive Hardening for New Deployments

1. Disable all secondary NICs on the engineering and target stations. Wi-Fi, Hyper-V virtual switches, and VPN tunnels each create a route that TCPIP.Auto can wander into. If a virtual NIC is required, exclude it from the Accessible nodes scan by setting the access point to a specific .TCPIP.1 entry.
2. Use PROFINET device names, not raw IP addresses, in the WinCC connection list. The PROFINET name is resolved at startup, which is faster and survives IP renumbering.
3. Pin the S7-1500 firmware. The discovery behavior changed subtly between S7-1500 firmware V1.x, V2.x, and V3.x. If the engineering station must talk to a mixed fleet, keep the engineering TIA Portal at a version that supports the lowest firmware in service.
4. Centralize the PG/PC interface. Use a Group Policy startup script that imports a known-good SetPgPcInterface.xml on every engineering and target station. This eliminates the per-station drift that re-introduces RC-3 after every rebuild.
5. Document the access point in the project header. In Project properties → Runtime settings, add the S7ONLINE access point name and the bound NIC to the project comment. This is what a field engineer will read first when the next startup alarm appears at 03:00.

Frequently Asked Questions