Fixing WinCC WebNavigator V6 Network Overload: Slow Client Access

Problem Definition

On a WinCC V6.0 SP4 runtime station with WinCC WebNavigator V6.1 SP1 installed, plugging the network cable from the WinCC server into the office router causes two reproducible symptoms:

1. Remote WebNavigator clients (Internet Explorer with ActiveX) respond with severe latency when navigating from picture to picture, opening faceplates, or refreshing trend archives.
2. The same uplink that was previously usable for normal office traffic becomes saturated; ordinary web browsing, file shares, and email slow to a crawl.

The symptom survives a cable swap (CAT5e to CAT6), so the issue is not a physical-layer defect. It is a workload problem: WebNavigator is generating more traffic than the router/ISP link can carry, and the round-trip time is collapsing the interactive session.

This article walks the field engineer through root-cause analysis, configuration changes inside the WinCC project, browser tuning on the client, and - if those are insufficient - server-side isolation.

WebNavigator V6.1 SP1 Architecture and Data Path

WebNavigator V6.1 SP1 is a thin-client remote-display extension for WinCC V6. The server component is installed on the same machine as the WinCC runtime. Each remote client establishes an HTTP session to the server, downloads a stub HTML page that contains an ActiveX control, and then exchanges picture data, tag values, alarm states, and script results over a persistent TCP connection on the configured port (TCP/80 for HTTP, TCP/443 if the optional SSL helper is licensed and enabled).

Data movement from server to client falls into four categories, each with different bandwidth and latency profiles:

A healthy single-client WebNavigator session typically holds an average in the tens to low-hundreds of kbit/s range. With 30 globally scheduled scripts - especially those that call OpenPicture(), write SetTag...() values, or load faceplates - the workload can climb by an order of magnitude. On a 2-5 Mbit/s remote uplink this is easily enough to crowd out all other traffic and to push the server CPU past 90% as the C runtime re-evaluates every cycle.

Because every click round-trips through the server before the picture refreshes, the end-to-end response time is bounded by:

T_response = 2 x RTT + T_serialize(server) + T_render(client) + T_ActiveX_init

When T_response crosses roughly 800 ms, the operator perceives the session as broken. The fix is to shrink each term in the sum, not to buy more bandwidth.

Root Cause Analysis: What Saturates the Link

In this case the project contains approximately 30 active scripts in the C-Editor. That is well above the rule-of-thumb ceiling of 8-12 globally scheduled C actions per runtime cycle that WebNavigator V6.x can comfortably serve over a remote link. Three concurrent mechanisms typically push the workload past the link:

1. Globally scheduled C actions. Scripts attached to Global Script rerun on every tag trigger; if any of them call SSMSetText, SetTag..., or load another picture, every connected client observes the change and the server multicasts the resulting bitmap stream.
2. Picture-name length. WebNavigator V6 builds a URL parameter (?Picture=PlantOverview_Faceplate_LineA_Reactor) and the picture-file path on disk is constructed from it. Very long names inflate the URL string and lengthen the parsing time inside the WebNavigator ISAPI DLL on every navigation. Renaming to a short leaf (20 chars or fewer) avoids both problems.
3. ActiveX re-instantiation. If the client browser drops the persistent connection (zombie process, IE crash recovery, or site not in "Trusted Sites"), every reconnect re-downloads the full ActiveX stub (often 4-8 MB on the first load), which competes with normal office traffic for upstream bandwidth.

Browser-Side Performance: Internet Explorer and ActiveX

WebNavigator V6 only runs in Internet Explorer 6/7/8 and requires ActiveX to be enabled for the trusted-sites zone. The first place to look on a slow client is therefore the browser, not the server. The official Notes on Internet Explorer for WebNavigator instructs the operator to add the Web server as a trusted website and enable the ActiveX controls only for the "Trusted sites" zone.

Procedure for every client machine:

1. In Internet Explorer: Tools → Internet Options → Security → Trusted sites → Sites, uncheck Require server verification (https:) for all sites in this zone if the deployment is plain HTTP, then add the WebNavigator server URL.
2. In Custom level..., set Download signed ActiveX controls = Prompt, Run ActiveX controls and plug-ins = Enable, Script ActiveX controls marked safe for scripting = Enable.
3. Disable Enable Protected Mode for the Trusted Sites zone if it is enabled - this is the source of intermittent "Your current security settings prohibit running ActiveX controls on this page" errors.
4. In Advanced, empty the Temporary Internet Files folder and disable Automatically check for Internet Explorer updates; the latter can re-arm an ActiveX reset on slow uplinks.

Modern browser compatibility is its own failure surface. After IE retirement, a default Windows 11 client running the new Edge will fail to instantiate the WebNavigator ActiveX entirely; this is documented as a browser compatibility issue in Microsoft's Q&A. The supported workaround on a fresh client is to enable IE Mode in Edge and add the server to the Enterprise Site List, or to install Internet Explorer 11 from the Windows Features dialog on Windows 10.

Reducing C-Editor Script Load

Thirty C actions is not a small project, but most WebNavigator slowdowns attributed to "too many scripts" are really too many globally-timed scripts that touch picture objects or external I/O. The remediation ladder, in order of impact:

1. Move tag-driven logic out of C-Editor into the PLC. If a script is computing a derived boolean for interlocking, lift it into the controller's ladder or ST. Every C-Editor action that executes per tag-trigger costs the runtime a script context switch, and WebNavigator multicasts the result to every connected client.
2. Collapse closely related actions into a single dispatcher script. Instead of six actions each calling SetTagBit("X", TRUE), write one global function called from a single timer.
3. De-rate timers. Default 250 ms cycle on the hot path is acceptable for an HMI sitting next to the server but lethal when the operator is on a remote uplink. Set hot-tick C actions to 1000 ms or 2000 ms, and reserve the 250 ms cycle for a single watchdog.
4. Audit picture-load triggers. OpenPicture(...) calls inside C actions generate bitmap traffic even when the target picture is already open on the operator's screen. Replace them with conditional if (GetVisiblePicture() != "Target") OpenPicture(...).
5. Strip dead code. The 30 scripts in the project under discussion were all reported as "necessary," but in audit many turn out to be commented-out drafts left in the script library. Run Project → C-Editor → Compile All and review the warning list for unused functions; WebNavigator's runtime does not strip these automatically.

Set a hard target: ≤ 8 globally scheduled C actions and ≤ 100 ms cumulative CPU per cycle. Profile with WinCC Explorer → Tools → Performance Analysis and the integrated C trace (printf-style output to diag.log).

Shortening Picture and Tag Names

Picture names appear in three places that all affect WebNavigator throughput:

1. The Picture= URL parameter.
2. The internal WebNavigator picture cache key.
3. The Windows-side file path under <project>\GraCS\.

The URL parameter is the worst offender because longer URLs slow parsing in the server-side ISAPI handler and inflate the case-sensitive script-log lookups on every navigation. Rename pictures to keep the leaf to roughly 20 characters or less:

The same rule applies to tag names that appear in URL paths or in alarm log filter parameters. Rename inside the project using the WinCC tag management export/import or by editing the relevant configuration files under a controlled migration, then re-export to a staging server before promoting to production.

Network and Server Architecture Changes

If the script cleanup and rename do not bring the round-trip below ~600 ms, isolate WebNavigator from the office network. The customer-supplied constraint "not possible to buy a separate server" rules out hardware separation, but the same effect can be achieved by:

1. Reverse-proxy with rate limit. Put a low-cost device (an industrial router with traffic shaping, or a Linux box running nginx with the limit_req module) between the WinCC server and the office router. Cap the WebNavigator session at, e.g., 2 Mbit/s with a 500 kB burst. This stops one slow client from starving the office link.
2. QoS / DSCP marking. Mark the WebNavigator TCP/80 traffic with DSCP AF31 and the rest of the office traffic with EF/BE. On a managed switch or a router that supports class-based queuing, WebNavigator gets a guaranteed slice without monopolizing the link.
3. Dedicated VLAN on the same physical server. Add a second NIC to the WinCC server and bind the WebNavigator server component to that NIC address only. Office traffic stays on NIC 1, WebNavigator traffic stays on NIC 2, and a static route on the office router forces the WebNavigator uplink out through a separate ISP connection (even a 4G/5G failover is sufficient for a single-client remote-view scenario).
4. WebNavigator diagnostic page. Open http://<server>/WebNavigator/status (when the optional diagnostic page is enabled) and read the live client count and packet-per-second. A single healthy session should show < 50 pps. Anything above 200 pps indicates a runaway script loop, not a network problem.

For the script-loop case the recovery is in WinCC itself: stop the runtime, open Computer → Properties → Startup, and disable hot-key-triggered global scripts until the offending action is located. The C trace will pinpoint the file and line of any script that exceeds 100 ms of CPU per cycle.

Step-by-Step Diagnostic Procedure

Use this sequence when the customer reports the symptom set. Do the cheap things first.

1. Confirm the link. Bypass the office router. Plug the WinCC server directly into a laptop running a packet capture (Wireshark on the laptop NIC). Filter on tcp.port == 80 and confirm that traffic is in fact HTTP and is in fact WebNavigator (look for a WinCC-related User-Agent string in the request header).
2. Measure bandwidth. With the WebNavigator session open, run iperf3 -c server-ip -t 30 -P 4 on the same capture machine. If you cannot push more than 1 Mbit/s through the existing uplink, the uplink itself is under-sized for the workload.
3. Measure CPU on the WinCC server. Open Task Manager or perfmon and watch the WinCC runtime process. If it is above 70% with a single client connected, the runtime is doing too much work and no amount of bandwidth will fix it.
4. Audit C actions. WinCC Explorer → C-Editor → Compile All and read the warning pane. Count globally scheduled actions. Anything > 12 is a red flag.
5. Audit picture names. Export the picture list through the Graphics Designer bulk export or a project-side report. Sort by name length; report any picture longer than 30 characters.
6. Audit the client. On the operator's IE, confirm the server is in Trusted Sites, ActiveX is enabled, and Protected Mode is off for that zone. Clear the Temporary Internet Files cache.
7. Re-test with one isolated client. Disconnect all but one remote client. If that one client is fast, the issue is aggregate load; if it is slow, the issue is script or CPU.
8. Decide.
   Single client slow + CPU high → reduce scripts (Section: Reducing C-Editor Script Load).
   Single client slow + CPU normal → rename pictures (Section: Shortening Picture and Tag Names).
   Single client fast + many clients slow → network architecture (Section: Network and Server Architecture Changes).

Verification Checklist

Field-Proven Caveats and Configuration Limits

• License ceiling. The number of concurrent WebNavigator clients is hard-capped by the WebNavigator license key (1, 3, 5, 10, 25, 50, or 100 clients). The overload symptom can be triggered simply by exceeding the licensed count; the server still serves the extras but each new connection degrades the others. Check WinCC Explorer → WebNavigator → License before blaming scripts.
• Antivirus on the server. Real-time AV scanning of the WebNavigator picture cache (GraCS directory) causes intermittent re-reads and locks that the customer perceives as "the server is slow." Add the WinCC project directory and the WebNavigator working folder to the AV exclusion list.
• Power-saving NIC. Modern server NICs default to Energy Efficient Ethernet. On older switches, EEE and the WebNavigator keep-alive timer disagree; the NIC sleeps mid-session and the client retries. Disable EEE in the NIC advanced properties.
• Time-sync. WebNavigator clients rely on NTP-aligned clocks for time-stamped alarms. A multi-second drift on the server de-syncs alarm bursts and floods the multicast stream with catch-up updates. Point the server at a stable NTP source and disable Windows Time from peer election.
• Firewall DPI cost. If the office router performs stateful inspection with deep packet inspection turned on, every WebNavigator packet is re-validated against the HTTP grammar. On a 100 Mbit/s router that is fine; on a 10 Mbit/s small-office router it is not. Toggle DPI off for the WinCC server IP.
• NetBIOS / SMB broadcast. Misconfigured Windows network discovery on the same VLAN can wake every 30 s and saturate the buffer of the office router. Disable Function Discovery Provider Host and Function Discovery Resource Publication services on the server, or move WebNavigator to its own VLAN as described above.

FAQ