Troubleshooting Slow WinCC Graphic Screen Changes on Engineering Stations: Temp Cache and Dynamic Scripts

When specific WinCC plant graphic screens (such as Raw Mill or Cement Mill PDLs) suffer severe loading delays during runtime on a SIMATIC PCS 7 Engineering Station, the bottleneck is caused by high-density dynamic properties with high-frequency cyclic triggers, unresolved tag connections, or bloated Windows %TEMP% cache directories. Cyclic C-scripts or VBS actions polling at 250 ms or 500 ms force synchronous network queries on every graphic element. To eliminate the delay, convert cyclic scripts to Tag Triggers or Picture Cycle triggers, delete accumulated temp files from %TEMP%, and increase the WinCC Screen Cache size in Computer Properties.

Mechanics of WinCC Graphic Rendering and Picture Activation Latency

In SIMATIC WinCC Runtime, opening a process picture (*.pdl) triggers a multi-stage loading sequence executed by pdlrt.exe:

The binary picture file is retrieved from disk or memory cache.
Static vector elements, bitmaps, and ActiveX controls are instantiated.
The Data Manager (CCDataMgr.exe) registers all tag variables referenced by dynamic dialogues, scripts, and direct connections.
All initial script actions (C-actions and VBS actions) execute cycle 0 to establish initial colors and values.

If a large plant graphic contains hundreds of individual motors, valves, and instruments, inefficient script design multiplies execution time exponentially, causing noticeable 5 to 15 second screen freezes.

Cyclic Triggers vs Event-Driven Tag Triggers in Graphics Designer

The single most destructive engineering flaw in WinCC graphic design is utilizing fast cyclic triggers on dynamic properties:

Cyclic 250 ms / 500 ms: A property set to evaluate cyclically forces the graphics runtime engine to execute that C-script or VBS action four times every second, regardless of whether the process value has changed.
The Queue Congestion Effect: If a cement mill picture contains 150 drive icons, each running two cyclic scripts, the graphics thread must process 1,200 script evaluations per second on that single screen. The script queue congests, locking the user interface during screen transitions.
The Solution: Always bind dynamic properties to Tag Change (Event-driven) triggers. The script executes strictly when the controller updates the tag value, dropping background CPU utilization to near zero.

Impact of Unresolved Tags and Network Timeout Retries

A secondary driver of severe screen opening delay is unresolved tag links:

If equipment was deleted from CFC or renamed, but the graphic icon retains references to the obsolete tag path, the WinCC Data Manager attempts to query the tag across the network.
Each missing tag triggers a network timeout (typically 2 to 5 seconds per batch) before defaulting to bad quality.
Running the WinCC Cross-Reference editor identifies and purges all dead tag references across plant PDLs.

The Role of Windows %TEMP% File Accumulation in Graphic Caching

During continuous engineering and runtime testing on an Engineering Station:

WinCC, STEP 7, and SQL Server generate thousands of temporary scratch files in C:\Users\<User>\AppData\Local\Temp and C:\Windows\Temp.
When pdlrt.exe caches decompressed picture files, file system traversal across a directory containing 50,000+ stale temporary files introduces disk I/O bottlenecks.
Purging the %TEMP% directory immediately restores OS-level file handle throughput.

Comparative Performance Matrix: Dynamic Graphic Trigger Types

The following table compares execution performance across different dynamic animation methods in WinCC:

Dynamic Animation MethodCPU UtilizationNetwork BandwidthScreen Load LatencyRecommended PracticeTag Trigger (Upon Change)Ultra-low (Event-driven)Minimal (Only on value change)Instantaneous (< 500 ms)Standard for all plant graphicsDynamic Dialog (Direct Tag)Minimal (Native C++ core)EfficientInstantaneous (< 200 ms)Best practice for simple color/state dynamicsCyclic Trigger (250 ms)Extreme (Constant polling)High (Constant tag query)Severe (Several seconds lag)Avoid completely on complex screensCyclic Trigger (Picture Cycle)Moderate (Standard 1-2 s)ModerateMinorAcceptable for non-critical analog clocksVBS Action with Tag ReadLow (If using Tag Trigger)EfficientFastIdeal for complex multi-variable calculations

Step-by-Step Optimization Workflow for Slow WinCC PDL Screens

Follow this maintenance sequence to resolve slow picture loading:

Purge Temp Directories: Close WinCC Runtime and SIMATIC Manager. Open Windows Run (Win + R), type %temp%, and delete all files. Repeat for C:\Windows\Temp.
Audit Picture Triggers: Open the slow PDL in Graphics Designer. Press Ctrl + A to select all objects. Use the Dynamic Dialog / Script Filter to locate all properties using 250ms or 500ms cyclic triggers. Convert them to Tag Trigger (Upon Change).
Check Cross-Reference: In WinCC Explorer, run Cross-Reference. Search for unreferenced or non-existent tags. Reconnect or delete orphaned links.
Increase Screen Cache: In WinCC Explorer, right-click the Computer object -> Properties. In the Graphics Runtime tab, increase the Picture Cache setting (e.g., from 10 to 30 pictures) to keep frequently viewed mill screens resident in RAM.
Monitor Diagnostics: Open apdiag.exe -> Diagnostics Window. Load the slow screen; confirm zero script errors or unresolved variable warnings.

Verification

Confirm performance improvements through these benchmarks:

Screen Switch Timing: Transition from an overview screen to the Raw Mill picture. Verify the screen loads in under 1.0 second.
Task Manager CPU Audit: In Windows Task Manager, verify CPU usage of pdlrt.exe remains below 5% while displaying the dense mill graphic.
APDIAG Output: Confirm the APDIAG output window displays zero Tag not found or Script overflow warnings.
Memory Stability: Perform 50 rapid screen switches; confirm WinCC private working set memory remains stable without memory leaks.

Limitations and Operational Precautions

Observe the following engineering constraints:

Standard Picture Overwrite: Never modify standard PCS 7 system pictures (e.g. @screen.pdl, @overview1.pdl) directly; always make modifications in user-created plant screens to avoid losing changes during OS compilations.
Commercial Accuracy Disclaimer: Software order numbers (MLFBs), package structures, and hardware capacity prerequisites vary across PCS 7 versions and hardware platforms. System integrators must confirm exact software entitlements and licensing requirements against the official Siemens Catalog CA 01 and obtain an authorized Siemens distributor quotation prior to purchasing.

Engineer FAQ

Can deleting files in %TEMP% harm WinCC or PCS 7?

No. Files in %TEMP% are temporary runtime scratch files. System-critical locked files cannot be deleted by Windows, while removing stale caches improves overall file system performance.