Troubleshooting WinCC Web Client 12-Second APL Faceplate Opening Delays in SIMATIC PCS 7 V8.1

In SIMATIC PCS 7 V8.1 WinCC Web Navigator, a symptom where process overviews load within 1 second while standard APL faceplates (@PG_...) and picture trees (@PTN_...) hang for 12 seconds occurs when faceplate child picture windows are not properly published or cached. APL faceplates dynamically construct their view by loading multiple sub-PDLs (@PG_*_Standard.pdl, @PG_*_View.pdl). If client-side caching is misconfigured, or if Internet Information Services (IIS) forces synchronous re-validation over high-latency networks, the browser blocks waiting for DCOM/RPC timeouts. To resolve this, re-publish all @PG_*.pdl graphics via Web View Publisher, enable client PDL caching, and optimize IIS worker thread settings.

Architectural Anatomy of APL Faceplate Loading in Web Navigator

In SIMATIC PCS 7 V8.1, the Advanced Process Library (APL) provides modular, high-performance faceplates. Unlike legacy monolithic pictures, an APL faceplate is a composite container. When an operator clicks a block icon, WinCC opens the parent window @PG_<BlockType>.pdl (such as @PG_MotL.pdl or @PG_PIDConL.pdl). This parent frame contains multiple nested picture windows that dynamically load child files: @PG_<BlockType>_Standard.pdl, @PG_<BlockType>_Maintenance.pdl, @PG_<BlockType>_View.pdl, and @PG_<BlockType>_Overview.pdl.

On a local OS Client or Web Server running OS Runtime locally, all child PDLs reside in local RAM or high-speed SSD storage, loading in under 500 milliseconds. However, over a WinCC Web Navigator client session, each child PDL and associated C/VBScript trigger must be served via HTTP/HTTPS through Microsoft Internet Information Services (IIS).

Why Process Pictures Load in 1s While Faceplates Hang for 12s

Engineers frequently encounter a baffling discrepancy: massive process overviews containing hundreds of live analog tags open instantaneously (< 1 second), yet a small faceplate renders its top title bar immediately and then freezes completely for 10 to 12 seconds before displaying the setpoint buttons.

The root cause lies in how synchronous network requests interact with un-cached child picture windows:
1. Single vs Multi-File Roundtrips: A process picture is a single large PDL loaded in one continuous HTTP stream. In contrast, an APL faceplate triggers between 4 and 8 concurrent requests for its constituent sub-PDLs.
2. Cache Miss / Revalidation Penalty: If the Web Navigator client is configured to check for newer versions of stored pages on every visit, the browser pauses execution to validate timestamps for every child PDL with the web server.
3. Synchronous C-Script Wait Loops: If a child PDL executes synchronous tag calls (GetTagCharWait() or GetTagDoubleWait()) inside its open-screen event while waiting for server data tags, the browser thread halts until the internal 10-second DCOM/RPC timeout expires.

Client-Side Caching: PDL Cache and Browser Revalidation Locks

Proper client-side caching is the single most critical factor for Web Navigator performance:

The PDL Cache: During session startup, the Web Navigator client downloads published PDL graphics into the local client cache folder: %TEMP%\WebNavigatorClient\Cache\<ServerName>\. When an operator opens @PG_MotL.pdl, the client should render the graphic entirely from this local hard drive cache.
Internet Explorer Cache Setting: If Internet Explorer (or the IE Tab container) has the option 'Check for newer versions of stored pages' set to 'Every visit to the webpage', the browser bypasses the local cache and queries IIS over the network for every child element. This setting must be changed to 'Automatically' or 'Never'.
Cache Size Allocation: Ensure the browser temporary Internet files cache is sized to at least 1,024 MB to prevent eviction of frequently accessed APL faceplate templates.

Web View Publisher Configuration and Faceplate Granularity

The Web Server requires pre-published graphic files generated by the WinCC Web View Publisher:

Open WinCC Explorer on the Web Server (or Master ES).
Launch Web View Publisher from the WinCC toolbar or start menu.
Verify that the publishing scope includes all system pictures (@*.pdl). Omitting @PG_*.pdl or @PTN_*.pdl forces the Web Server to execute on-the-fly graphic translation during live client requests, creating massive CPU spikes and multi-second delays.
Select the option 'Publish all pictures' rather than delta publishing whenever APL library updates or Engineering Station hotfixes have been applied.
Ensure that the target publishing directory permissions allow full read access to the IIS application pool identity (IIS_IUSRS).

IIS Web Server Optimization and Network Latency Tuning

To optimize the host Web Server and IIS pipeline:

Application Pool Recycling: In IIS Manager, ensure the WinCC Web Navigator application pool is configured with private memory limits sufficient to prevent mid-day recycling during peak operational shifts.
HTTP Compression: Enable static and dynamic content compression in IIS to minimize data payload sizes for script files and graphic vectors.
Keep-Alive and TCP Tuning: Verify that HTTP Keep-Alive is enabled in IIS, allowing the Web Client to reuse existing TCP connections for all child PDLs rather than performing redundant TCP handshakes and NTLM authentications for every sub-window.

Diagnostic Matrix: WinCC Web Client Performance Bottlenecks

Use the following matrix to isolate and resolve slow Web Client responsiveness:

Diagnostic SymptomUnderlying Root CauseCorrective Engineering ActionTitle bar in 1s; body in 12sChild PDLs not cached; browser revalidates IISSet IE cache to 'Automatically'; verify %TEMP%\Cache existsAll pictures slow (>10s)High network latency or DNS timeoutAdd Web Server IP/name to local client hosts file; check pingFaceplates fail with red cross@PG_*.pdl omitted from Web PublishingRun Web View Publisher for all @*.pdl files with full publishFast on server; slow on clientNTLM authentication negotiation delayAdd Web Server URL to Internet Explorer 'Trusted Sites' zoneClient CPU spikes to 100%Corrupt ActiveX controls on clientUninstall and reinstall WinCC Web Navigator Client plugin components

Verification

Validate the performance improvement on the Web Client through the following steps:

On the Web Client PC, clear temporary Internet files and close all browser sessions.
Launch Web Navigator Client and connect to the PCS 7 Web Server.
Open the main plant overview picture and verify it displays within 1 second.
Click an analog motor icon to open @PG_MotL.pdl. Confirm that the entire faceplate (title bar, standard view buttons, interlock icons) renders completely in under 1.5 seconds.
Rapidly open three different faceplates (@PG_VlvL, @PG_PIDConL, @PTN_...) in succession and confirm zero stutter or 12-second hangs.

Limitations and Operational Precautions

Adhere to the following operational safeguards:

Never Modify System @ Pictures Directly: Do not edit @PG_*.pdl scripts to introduce custom synchronous delays; use standard APL extension blocks if custom faceplate logic is needed.
ActiveX Security Policy: Ensure corporate group policies (GPOs) do not block or re-scan downloaded WinCC ActiveX controls on every execution.
Network Bandwidth Minimums: While Web Navigator operates efficiently over WAN connections, high-latency links (>150ms roundtrip) require proper client caching to remain responsive.

Engineer FAQ

What browser setting prevents Web Navigator from using its local PDL cache?

Setting 'Check for newer versions of stored pages' to 'Every visit to the webpage' in Internet Explorer forces IIS to re-verify every file, bypassing the local cache. Set this to 'Automatically'.

Can WinCC Web Client performance be improved over VPN or WAN?

Yes. Pre-publishing all graphics, enabling HTTP compression in IIS, adding the server to the Trusted Sites zone, and ensuring client PDL caching is active drastically minimizes WAN latency.

Do I need to republish pictures after modifying an APL block icon?

Yes. Any changes to pictures, block icons, or Master Data Library templates require running the Web View Publisher to update the web server's graphic cache.