WinCC PDLCache Picture Cache: Configuring Client Picture Cache in Multi-User Projects

Picture cache misconfiguration is one of the most common causes of slow screen change times in WinCC V6 multi-user (client/server) projects. When the PDLCache is not correctly wired to the symbolic computer name of the server package, the client always fetches pictures from the server, even when the Use Cache option is set to Always. The result is a 5-20 second per-screen penalty on every picture change. This reference covers the correct directory layout, registration steps, network prerequisites, and verification procedure for WinCC V6.0 SP3 (and compatible service packs such as HF2 / HF7) running on Windows Server 2003 / Windows XP SP2 environments.

1. What the PDLCache Actually Does

The Picture Cache (PDLCache) is a local replica of the server's GraCS directory that the WinCC Client consults before requesting a process picture over the network. When a picture exists locally and the cache is enabled, the runtime resolves the picture from the local disk and only fetches dynamic content (tags, scripts) from the server. This typically reduces picture-change time from several seconds to under 500 ms on large process screens with thousands of objects.

Two conditions must be true for the cache to be used:

1. The picture file (.pdl) must physically exist in the cache directory on the client disk.
2. The cache directory path must be linked to the symbolic computer name of the server package that the client is currently logged into.

If either condition fails, the runtime transparently falls back to the server copy of the picture, with no warning in the standard Diagnose logs. This silent fallback is what makes the problem difficult to diagnose.

2. Required Directory Structure

The WinCC Information System states the layout explicitly. The standard location is:

Where:

• <WinCC installation directory> is typically C:\Program Files\Siemens\WinCC on Windows XP / Server 2003.
• <Symbolic computer name of the package> is the name that appears in the Computer list of the client, in the form ProjectServer_<ServerName>(<ServerName>). This is the identifier that WinCC uses internally to match the local cache folder to the active server connection.

For example, if the server's computer name is MyComputer, and the server is listed in the client's computer list as ProjectServer_MyComputer(MyComputer), then the cache directory must be:

3. Locating the Symbolic Computer Name

To find the exact symbolic name expected by the cache:

1. On the client, open WinCC Explorer.
2. Right-click the Computer node and select Properties.
3. Open the General tab on the server entry.
4. Note the value shown in the Computer Name / Symbolic Computer Name field. This is the exact string that must be used as the cache sub-folder name.

On legacy V6 systems this is also visible from the SIMATIC Shell right-click menu on the server entry. The same string must be used when registering the package on the client.

4. Step-by-Step Configuration

4.1 Prerequisites

• WinCC V6.0 SP3 or later (HF2, HF7, or equivalent) installed identically on server and client.
• Server and client in the same IP subnet (or routed with no firewall filtering of TCP/UDP used by WinCC).
• Static IP addresses on both ends. DHCP leases are not supported for production SCADA nodes.
• Both machines resolvable by computer name and by IP. Verify with ping <ServerName> and ping <ServerIP>.
• Identical local administrator accounts or properly configured domain accounts with write access to the WinCC directories.

4.2 Procedure

1. On the server, open the WinCC project and compile the OS (Options → OS Project Editor → Compile). Note the output window for any picture resolution errors.
2. Copy the entire <ProjectPath>\GraCS folder from the server to a staging location on the client (e.g. D:\Pictures\Source). Use the WinCC Explorer Duplicate function or a robocopy that preserves timestamps. Do not copy into ..\WinCC\bin directly during this step.
3. Create the cache root directory on the client. If you follow the default convention, it is C:\Program Files\Siemens\WinCC\bin\PDLCache. If you use a custom location, create something like D:\Pictures\PDLCache.
4. Create a sub-folder whose name exactly matches the symbolic computer name found in step 3. Example: D:\Pictures\PDLCache\ProjectServer_MyComputer.
5. Copy all .pdl picture files from the staging location into this sub-folder. Ensure the file timestamps match the server so the client does not detect a "newer" picture and refetch.
6. On the client, open the computer's Properties → Runtime tab in WinCC Explorer.
7. Set Use Cache to Always (or to According to Picture if per-picture cache control is enabled via the picture's Properties → Miscellaneous tab).
8. If the cache is not in the default ..\WinCC\bin\PDLCache folder, fill the Path field with the directory above the symbolic-name sub-folder. For D:\Pictures\PDLCache\ProjectServer_MyComputer, the path is D:\Pictures. Do not include PDLCache in the path field.
9. Save, then restart the WinCC runtime on the client.

4.3 Verification

1. Stop the WinCC runtime on the client.
2. Edit a copy of one cached .pdl in the local cache directory: add a static text field with a value such as "LOCAL CACHE". Save.
3. On the server, edit the same picture in the original GraCS directory and add a different static text such as "FROM SERVER". Do not copy this version to the client cache.
4. Restart runtime on the client, then open the picture.
5. If the cache is correctly configured, the "LOCAL CACHE" text is visible. If the cache is misconfigured, the "FROM SERVER" text is visible and the cache is not being used.

This is the same diagnostic the original field report used (adding a text label with the computer name) and remains the most reliable visual test.

5. Network Pre-Checks That Frequently Break the Cache

Even with a correct directory layout, the following network conditions cause the client to silently refetch pictures. They are listed in the order they should be verified.

5.1 NIC Auto-Negotiation

Auto-Detect on the network adapter is a known source of sporadic WinCC communication issues. Force a fixed speed and duplex that matches the switch port:

• 100 Mbps Full Duplex for 100BASE-TX segments.
• 1 Gbps Full Duplex for Gigabit segments.

Apply the same setting on both server and client. Mismatched speed/duplex on the two ends causes late collisions and retransmissions that the WinCC picture loader interprets as slow responses.

5.2 Hosts File and Name Resolution

On Windows XP / Server 2003, WinCC name resolution is order-dependent. Configure the network adapter's TCP/IP properties so that the hosts file is consulted first, then DNS. Verify entries:

Add explicit entries:

192.168.10.11   SCADASRV
192.168.10.12   SCADACLIENT

Both forward (name → IP) and reverse (IP → name) lookups must succeed. Use ping -a <IP> to confirm reverse resolution.

5.3 SIMATIC Shell Configuration

On the client, the SIMATIC Shell must point to the correct server. Open SIMATIC Shell from the desktop or Control Panel, navigate to the server project, and ensure the path is accessible. If the shell shows a red icon or the path is unreachable, the picture cache is bypassed because the runtime cannot establish the package context.

5.4 DNS and Active Directory

Workgroup environments without a domain must rely on the hosts file and NetBIOS. If a domain is used, the DNS server must be reachable from the client and must resolve the server's FQDN. Winsock timeouts on slow DNS responses delay every picture load and may make the cache look ineffective.

5.5 Anti-Virus Exclusions

Real-time AV scanners on Windows XP / Server 2003 are known to interlock the GraCS and PDLCache directories, adding 200-2000 ms per file open. Add the following to the AV exclusion list on the client:

• C:\Program Files\Siemens\WinCC\bin\PDLCache\*
• D:\Pictures\PDLCache\* (or whichever custom path is in use)
• C:\Program Files\Siemens\WinCC\bin\*.dll

Disabled real-time scanning only on these paths, not on the entire WinCC directory, to retain baseline protection.

6. Diagnose Directory Review

The WinCC Diagnose folder records the runtime state but rarely surfaces cache-related warnings by default. After the runtime is stopped, inspect:

Search for the strings PDLCache, PictureCache, Computer list, and package. In particular:

• Lines containing CS_OpenServer confirm the server connection was established.
• Lines containing CS_GetServerPath confirm the symbolic name was resolved.
• Lines containing CS_PictureCache or CMN_PDL confirm the cache lookup was attempted.

If the log shows picture loads originating from the server path (\\<Server>\<Project>\GraCS\...) after the cache was configured, the symbolic-name sub-folder is almost certainly misnamed or the path field is pointing one level too high.

7. Common Misconfigurations and Fixes

8. Performance Impact Quantification

Typical picture load time improvements after enabling a correctly configured PDLCache on a Windows XP / Server 2003 client-server pair:

The 5-10x improvement on medium and large pictures is the primary reason PDLCache is enabled by default on production WinCC multi-user projects.

9. Field-Test Sequence (Recommended Order)

1. Confirm Use Cache = Always on the client computer's runtime properties.
2. Verify the symbolic computer name by inspecting the Computer list entry on the client.
3. Build the path ..\bin\PDLCache\<SymbolicName> (or custom equivalent) and populate it with a complete copy of the server GraCS directory.
4. Set the Path field to the directory above the symbolic-name sub-folder, or leave blank if the default ..\bin\PDLCache is used.
5. Perform the visual indicator test (modify a single .pdl locally with a static "CACHE" text) to confirm the cache is consulted.
6. If the cache is still bypassed, work through the network pre-checks in section 5 in order, then re-test.
7. Inspect the Diagnose logs for any package registration or path resolution errors.

10. Known Limitations on V6.x

• PDLCache caches picture files only. Tag values, archive values, and dynamic script outputs are always fetched from the server.
• Picture modifications on the server are detected by timestamp comparison. After a server-side edit, the client refetches the modified picture on next access.
• PDLCache does not replicate faceplate instances or library elements. These are resolved from the server or local library path.
• On WinCC V6, the maximum number of cached pictures is bounded by the available disk space on the client; there is no internal cap.
• Cache is not used in Use Cache = No mode, even if the .pdl exists locally.