Resolving WinCC RT Disconnected from PLC Comprehensive

Resolving WinCC RT Disconnected from PLC: Comprehensive Troubleshooting

When a Siemens WinCC Runtime (RT) station suddenly reports a disconnected state from the PLC — typically visualized as a yellow triangle with an exclamation mark ("!") on the HMI/SCADA screen — the operator is left blind to the process and production data. This guide walks through the diagnostic and remediation steps that systematically rule out licensing, driver, network, and configuration issues, with an emphasis on multi-station deployments that use redundancy and mixed protocols (TCP/IP and Modbus). The methodology is applicable to WinCC V7/V7.x, WinCC Professional (TIA Portal) RT, and follows the same diagnostic pattern as Siemens' official RT Unified "no connection" procedure.

1. Problem Description and Field Symptoms

In the reported failure mode, three stand-alone WinCC RT PCs were running perfectly for over a year. Suddenly, two of the three stations lost their connection to the PLC, while the third continued operating without interruption. The diagnostic signature was identical on both affected machines:

• Yellow triangle with exclamation point ("!") rendered on the WinCC runtime screen — Siemens' standard "connection lost" indicator.
• License Manager initially flagged the local RT license as "defective."
• License replacement was performed, but the runtime remained disconnected.
• Basic restarts of the RT service, the PC, and the PLC did not restore the link.
• TCP/IP ping from and to the PLC IP addresses succeeded.
• Channel diagnosis under SIMATIC > WinCC > Tools did not surface any blocking error code.
• Redundancy is configured across the stations.
• Mixed protocol: TCP/IP (S7 communication) and Modbus are in use.

This is a classic late-life failure pattern in WinCC installations: the RT layer is fine, the OS network stack reaches the PLC, but the WinCC channel driver layer cannot establish or maintain a logical connection.

2. Root Cause Analysis: Why a Single PC Stays Up While Others Fall

When 2 of 3 identical stations fail simultaneously, the failure is rarely hardware-only — hardware failures tend to be local. The most probable root-cause families, ordered by likelihood for this symptom set, are:

3. Pre-Diagnostic Checklist

Before changing anything, capture a baseline. This is essential when the third working PC exists — it is your reference.

1. Document the WinCC version, build, and hotfix level on all 3 PCs (WinCC Explorer > Help > About). Compare.
2. Record the Automation License Manager (ALM) view on the affected PCs: list of installed licenses, license type (RT, RT-128, RT-512, RT-2048, RT-4096, RT-Redundancy, RT-Client, etc.).
3. Run ipconfig /all on the working PC and on each failed PC. Note the IP, subnet, gateway, DNS, and the order of network adapters.
4. Run ping -t <PLC_IP> from each PC for at least 5 minutes to look for drops, latency spikes, or ARP flapping.
5. From a failed PC, attempt telnet <PLC_IP> 102 (S7) and telnet <PLC_IP> 502 (Modbus TCP). A successful TCP handshake confirms the network path is open; a refused connection localizes the failure to the PLC's application layer.
6. Open Start > Siemens > WinCC > Tools > Channel Diagnosis on a failed PC and on the working PC. Export both logs for comparison.

4. Step-by-Step Diagnostic and Remediation Procedure

Follow the steps in order. Do not skip ahead — each step rules out one cause family and informs the next.

4.1 Step 1 — Validate the License Stack

1. Open Siemens Automation License Manager from the Start menu.
2. Right-click the local PC and select View. Confirm the correct WinCC RT license and the Redundancy license are both present and not in "defective" state.
3. Stop the WinCC RT service: net stop "CCEServer" and net stop "WinCC_RT_Default" (names vary by WinCC version).
4. Delete the cached trust file: C:\ProgramData\Siemens\Automation\<fingerprint>.bin.
5. Reboot the PC. Re-launch the WinCC RT project. Verify the project is no longer in evaluation mode (check the splash banner — "WinCC Runtime - Unlimited" should appear).

4.2 Step 2 — Verify the PG/PC Interface Assignment

This is the single most common cause of "yellow triangle" on otherwise-healthy networks.

1. Open Control Panel > Set PG/PC Interface (the 32-bit version — set_pc_interface.exe).
2. Set the access point S7ONLINE (STEP 7) to the physical Ethernet adapter connected to the PLC subnet. Do not select a virtual adapter, Hyper-V switch, VPN tunnel, or Wireless adapter.
3. If the S7DOS / S7-Protocol Suite is used, also set CP_H1_1 or CP_L2_1 consistently if used.
4. Confirm the same adapter is bound at the OS level: ncpa.cpl > right-click adapter > Properties > check that "SIMATIC S7 Protocol Suite" and "Internet Protocol Version 4" are both ticked, and that no extra VLAN or Hyper-V filter is applied.

4.3 Step 3 — Inspect the WinCC Project Connections

1. Open WinCC Explorer on a failed PC.
2. Navigate to Computer > Properties > Graphics Runtime > WinCC Runtime — Start Up and confirm the active project name matches the one running on the working PC (case-sensitive).
3. Open Tag Management > SIMATIC S7 PROTOCOL SUITE (or your channel driver). For each connection:

4. Save the project to disk and re-deploy from the central project server to the affected stations to overwrite any local drift.

4.4 Step 4 — Channel Diagnosis and Log Review

1. Start > Siemens > WinCC > Tools > Channel Diagnosis.
2. Activate the trace. Filter by your connection name.
3. Look for error patterns:

4. Cross-check the Windows Event Viewer under Applications and Services Logs > Siemens > WinCC for matching timestamped errors.

4.5 Step 5 — Redundancy Health Check

1. In WinCC Explorer, open Redundancy.
2. Confirm the Redundancy Partner entry points to the correct IP and computer name.
3. Open the redundancy log file (default: <ProjectPath>\Redundancy\<station>_*.log). Look for sync events, time-stamp drift, or partner-down messages.
4. Run the redundancy self-test from the Tools menu. It will ping the partner and validate project version parity.

4.6 Step 6 — Service and Firewall Validation

1. Open services.msc and verify the following services are Running and Automatic:

• Siemens Automation License Manager Service (almsrv)
• SIMATIC HMI WinCC RT Default
• CCEServer
• S7DOS Helper Service
• SNMP Service (if used for diagnostics)

2. Open Windows Defender Firewall with Advanced Security. Create inbound rules for TCP ports 102 (S7) and 502 (Modbus) bound to the PLC-facing NIC only.
3. Disable any third-party endpoint security agent temporarily and re-test — some EDR products filter the S7 ISO-on-TCP payload.

4.7 Step 7 — Project Redeployment and Reinstallation

If the above steps do not restore communication, the project file on the affected stations is most likely divergent from the master. Reinstall the WinCC RT project in this order:

1. Stop all WinCC services.
2. Back up the existing project folder <ProjectName>_<PCName> for forensic comparison.
3. Re-deploy the master project from the central project source / TIA Portal server.
4. Re-apply any PC-specific settings (redundancy role, time zone, OPC partner IP).
5. Reboot. Start the RT and verify the connection status icon.

If redeployment fails, escalate to a full WinCC RT uninstall + clean reinstall:

1. Run Control Panel > Programs and Features > Siemens WinCC RT > Uninstall.
2. Manually delete the project folder and C:\Program Files (x86)\Siemens\WinCC\bin residual keys.
3. Re-activate the license, re-deploy the master project, and validate.

5. Special Consideration for Modbus TCP Coexistence

When both S7 (port 102) and Modbus TCP (port 502) channels are used, the channel initialization order in WinCC matters. The first channel launched reserves its socket binding; the second waits. If the S7 channel is the "master" of process data, ensure it is initialized first. In the channel properties, set the Connection startup order accordingly.

For Modbus TCP, common field issues include:

• PLC port 502 already bound by another vendor's HMI — use a non-standard port and configure the Modbus driver accordingly.
• Modbus register base offset of 1 vs 0 — silent data mismatch, not a connection failure.
• Modbus TCP unit ID must match the slave configuration; default 255 in WinCC, default 1 on many PLCs.

6. Redundancy-Specific Failure Modes

WinCC Redundancy adds three failure vectors beyond the single-station case:

1. Time drift between partners: The redundancy algorithm uses timestamps to detect partner liveness. NTP must be active on both. A drift > 5 seconds triggers partner-down events that mimic connection loss.
2. Project version mismatch: A redeploy on one partner that was not followed on the other will cause the affected partner to refuse traffic. The redundancy log will show "Partner project version older/newer".
3. Switchover storm: When the standby's connection drops but the active is up, the standby may keep trying to take over. Disable the role until the underlying connection is restored.

7. Verification Procedure

After each remediation step, perform the following verification. Only proceed to the next step if all checks pass.

1. Connection icon: The yellow "!" should change to a green connection / check mark.
2. Tag status: Pick three process tags and confirm their current values update at the configured cycle rate in the WinCC tag diagnostics window.
3. Channel diagnosis: Trace shows continuous successful PDU exchange, no retry events.
4. Alarm line: Trigger a known alarm at the PLC and confirm it appears on all 3 RT stations within the configured acknowledgment window.
5. Redundancy: Simulate a fail-over by stopping the active RT. The standby should take over within the configured switchover time (default 2 s) and continue receiving PLC data.
6. 24-hour soak: Let the RT run overnight. Verify the next morning that the connection is still up, the archive database has incremented, and the Windows event log has no S7 channel errors.

8. Preventive Maintenance Recommendations

• Maintain a master WinCC project on a central file server; never edit projects locally on RT stations.
• Configure a scheduled task to back up ALM license trust files and the WinCC project folder weekly.
• Pin the PG/PC interface to the physical NIC using Device Installation Settings (prevent Windows from re-binding after updates).
• Defer major Windows updates on HMI stations; test on a sandbox first.
• Document the exact WinCC version, SP, HF, and the project checksum on the engineering cabinet door.
• Apply Siemens Security Advisories (SSAs) for WinCC promptly; many CVEs target S7 communication channels.

9. When the Third Working PC Is the Reference

Use the working PC as a configuration oracle. Diff the following between the working PC and a failed PC:

• set_pc_interface output (export registry hive HKEY_LOCAL_MACHINE\SOFTWARE\Siemens\AUTSW).
• WinCC project folder checksum (certutil -hashfile).
• Installed hotfixes (wmic qfe list).
• Network adapter driver version and advanced properties (energy-saving features, offloads, checksum offload — disable).

The first divergence in this diff is almost always the root cause.

10. Diagnostic Flowchart

11. Frequently Asked Questions