WinCC Client Picture Loading: PDL Cache, Server Graphics, and Performance Tuning

Siemens WinCC (TIA Portal and WinCC V7.x) splits runtime picture storage between the WinCC Server's GraCS directory, the Client's local GraCS directory, and the server-side PDLCache folder. Misconfiguration of these locations produces tag connection loss, slow picture change times, and silent fallback to server pictures when an engineer expected local loading. This reference documents the precedence rules WinCC uses when resolving a .pdl file, how the standard server property and Server Prefix behave in multi-server topologies, and how to commission a client that mixes local graphics with remote tag sources.

1. WinCC Client Runtime Picture Architecture

A WinCC Client does not host tag archives or its own image of the process data when configured as a Client without its own project. All picture data, tag connections, and archive sources originate from one or more paired WinCC Servers. Picture Description Language (.pdl) files compiled at project design time can exist in three locations at runtime:

When the WinCC Explorer starts, it registers picture paths in the order defined in the Computer properties dialog. For a WinCC Client, three picture paths are usually listed: the local GraCS, the Server Prefix path (which resolves through the server's GraCS), and the PDLCache path. The WinCC runtime loader reads these paths in the order they appear and selects the first match for a given picture name.

2. Picture Loading Precedence Logic

The WinCC documentation states that a client first checks its local directory for a .pdl and, if the file is not present, opens the server picture. In practice the resolution is more nuanced because picture changes are nested and the start picture can pre-select a server path.

The actual precedence order applied by the WinCC runtime picture cache is:

1. The picture currently displayed on the server (the one last opened by the server's active picture in the navigation tree) is the preferred source. The client inherits the server's current screen for the root picture.
2. Nested picture windows that call OpenPicture("Name.pdl") resolve through the active Server Prefix's GraCS directory if the parent picture was opened from the server.
3. If the parent picture is opened locally (start picture on the client), the runtime searches the local GraCS first and only falls back to the server GraCS when the file is missing.
4. The PDLCache directory is consulted as the last fallback. If present, it acts as a read-only cache that mirrors the server's GraCS contents.

This behavior explains the field observation that a start picture loaded from the server tends to keep all nested pictures on the server even if the client has a local copy. The runtime does not re-resolve the path on every picture change; it inherits the path context from the first picture open.

3. Local GraCS vs Server Pictures — Why the Tag Connection Breaks

Local GraCS files open measurably faster than the server equivalents because the client does not need a remote file open through Server Prefix. The trade-off is that any tag inside a local picture is referenced without a Server Prefix, so the tag resolution context is local to the client project. If the client project does not define that tag (or defines it with a different data type), the picture displays ##### in I/O fields, the bar/needle of a slider, or static initial values in trend views.

The Server Prefix is the text that WinCC prepends to tag names when communicating with a remote server. It is configured per server in Server Data in the WinCC Explorer of the client. Standard default prefixes look like Server1::, Server2::, etc. A picture with a tag reference such as Server1::Motor_RPM will resolve only on a client that has a Server Prefix Server1 bound to a live server carrying that tag.

To run local pictures and still consume server tags, two options are supported:

1. Configure the Server Prefix manually in the Server Data dialog of the client. The client knows the tag is prefixed and routes the request to the remote server.
2. Set the Standard Server property on the client. Any tag request without an explicit prefix is automatically routed to the standard server. This is the typical setting for a single-server project.

Copying the entire GraCS folder from the server to the client does not by itself produce a working configuration. The picture opens locally (fast), but tag prefixes inside the picture still reference the server name. If Standard Server is not set or the configured server does not match the prefix, tag values stop updating.

4. PDLCache Folder — Recommended Mechanism

The PDLCache folder is created and maintained automatically by the WinCC Server the first time a client opens a picture whose source is on the server. From that point, every picture change request from any client is answered from the cache if available. The cache:

• Mirrors the compiled .pdl files served by the server's GraCS directory.
• Carries the Server Prefix with each picture because the source picture is the same file used by the server.
• Is shared between all clients connected to that server; the server's PDLCache reduces network traffic and picture open latency by up to 60% for first-open pictures on a cold client.

Enable PDLCache via the server's computer properties:

1. Open WinCC Explorer on the server.
2. Right-click Computer » Properties » Graphics tab.
3. Tick Use PDL Cache and confirm the cache path (default <Project>\PDLCache).
4. Restart the WinCC Runtime on the server and reconnect all clients.

The PDLCache folder is the only mechanism that works correctly when the client connects to more than one server, because the cache is per-server. Each server populates its own PDLCache, and the client routes picture requests through the Server Prefix that is bound to the live tag context.

5. Standard Server Property and Multi-Server Scenarios

The Standard Server property is a single boolean per server entry on the client. If a client has two configured servers (Server A and Server B) and only Server A is marked as standard, then any tag without a prefix in a server-side picture is routed to Server A. Tags that exist only on Server B must be referenced with an explicit prefix, for example ServerB::Tank_Level.

Setting the Standard Server to None (no standard server) is supported, but every tag in every server-side picture must carry an explicit prefix. The runtime will fail to resolve unprefixed tags with error 1001 Tag not found written to the WinCC diagnosis file WinCC_Sys_<computername>_<timestamp>.log.

6. @Screens — System Screens Explained

WinCC uses the at-sign prefix (@) as a marker to identify system screens. System screens are generated and updated by the WinCC OS Project Editor (PCS 7) or by Basic Process Control (BPC) and are never authored by hand in the Graphics Designer. Examples include:

• @Overview.pdl — generated area overview
• @Alarm.pdl — PCS 7 alarm summary view
• @Trend.pdl — PCS 7 trend group display
• @PG_Overview.pdl — Picture generator output

The runtime treats @ screens identically to normal pictures for file resolution, but it enforces that the calling picture must reference them by their full name including the at sign. Copying an @ screen to the client GraCS folder does not work because the screen is regenerated on the server by the project editor and may contain server-specific archive and tag references that the client cannot resolve.

The @ sign is purely a naming convention — the file is still a normal .pdl file. There is no separate @ screen engine and no special loader. The benefit of the marker is twofold: it prevents operators from accidentally editing a system screen, and it lets the OS Project Editor overwrite these files safely on each compile without overwriting engineer-authored screens.

7. Client with Own Project vs Client without Own Project

WinCC distinguishes two client operating modes. The selection governs whether picture files are local, remote, or hybrid.

To configure a Client with its own project:

1. On the server, export the server package: right-click the server in WinCC Explorer » Server Data » Export Server Package. This creates a .pck file with the project configuration, tag list, and archive definitions visible to the client.
2. Copy the .pck file to the client.
3. On the client, in the local WinCC project, import the package: Server Data » Import Server Package.
4. Author the client-specific .pdl files locally and reference the imported server tags with their full Server Prefix name (e.g. Server1::Motor_RPM).
5. Compile the client project and start runtime.

The server package mechanism means that the client can hold the full set of available tags and archives locally, even though the actual values continue to come from the live server. This is the configuration that supports a training simulator: a separate server with simulated values can be paired to the same client, and the operator screens run unchanged because the prefix is the same.

8. Multi-Server Picture Loading — Inserting Multiple Server Data

For a client that connects to several servers, each server must be added to the client's Server Data. The Server Prefix in the picture file must match the prefix in the client's server data, otherwise the picture opens but the tag is not found.

The runtime opens a picture with prefix Server2:: only when Server2 is online and the picture name exists in the Server2 GraCS or in PDLCache on Server2. If the server is offline, the picture opens but the tag references return 1001 Tag not found.

9. Performance Tuning Parameters

The following parameters in the WinCC project file wincc_projects_ps<computername>.ini and the registry govern picture loading behavior:

10. Troubleshooting Matrix

11. Commissioning Procedure for a New Client

Follow this sequence to commission a client that loads a mix of local and server pictures reliably.

1. Install WinCC Runtime on the client machine. Match the version (and update level) to the server. Mismatched .pdl versions cause open errors and the runtime logs 1401 Picture cannot be opened.
2. On the server, export the server package for the client and copy the .pck file to the client.
3. On the client, open WinCC Explorer, create a project (or open the existing client project), and import the server package under Server Data.
4. Add the client to the server's Computer list and grant the appropriate operator rights.
5. Enable PDL Cache on the server.
6. Copy the start picture to the client GraCS folder only if a custom design is required. Otherwise, leave GraCS empty on the client and rely on PDLCache.
7. Start the server runtime, then start the client runtime. The client login screen should appear within 5–15 seconds depending on the network latency.
8. Open each operator screen once. The first open populates the PDLCache. Subsequent opens load from cache.
9. Verify tag updates by changing a process value on the server (e.g. via a simulator) and confirming the I/O field on the client updates within the configured acquisition cycle (default 1 s).
10. Trigger an alarm on the server and confirm the client's alarm line shows the same message text and color within 2 s of the trigger.

12. Differences Between WinCC V7 and TIA Portal WinCC

The PDLCache mechanism and Server Prefix handling described in this reference apply to WinCC V7.x and WinCC Professional (TIA Portal) running in a distributed server-client configuration. For WinCC Unified (TIA Portal), the picture cache behavior is implemented on the Unified runtime, but the Server Prefix concept is replaced by the HMI tag connection with a connection name. The picture file extension .pdl remains, but the project layout differs.

13. Diagnostic Log Locations

The following log files are the primary sources for diagnosing picture loading problems on a WinCC Client:

To increase log verbosity for picture-related diagnostics, set the registry value HKLM\SOFTWARE\Siemens\WinCC\RT\Diagnostics\Level to 3 and restart the runtime. The default value is 1 (errors only).

14. Field-Proven Best Practices

• Always use PDLCache for plants with more than one operator station. The cache is invisible to the operator and dramatically reduces picture open time on warm clients.
• Do not mix local and server pictures for the same screen on the same client. Pick one source per picture and stick to it. Mixing produces the start-picture / nested-picture mismatch described in section 2.
• Keep the WinCC version (including HF / update level) identical on every server and client in the plant. A client on V7.4 SP1 connecting to a server on V7.5 will load pictures from PDLCache but the .pdl compile target may differ, producing log entries for 1401 errors.
• Set Standard Server deliberately. Do not leave it on the first server in the list by accident. If a client genuinely uses more than one server, set the most-used server as standard and qualify all other tags with explicit prefix.
• After any change to server tag names, re-export the server package and re-import on every client. The local GraCS pictures still reference the old tag names until the package is refreshed.
• For PCS 7 plants, never delete @ screens from the client GraCS. The OS Project Editor expects to find and update them.

15. References to Official Siemens Documentation

For project-specific configuration, refer to the WinCC V7.x documentation set in the Siemens Industry Online Support portal. The manuals that govern the behavior described in this reference include:

• Siemens Industry Online Support — WinCC documentation index
• WinCC V7.5 SP2 — Configuration Manual (graphics runtime, server-client)
• WinCC V7.4 — Communication Manual (server packages, Server Prefix)
• PCS 7 OS — Administration Manual (system screens, OS Project Editor)
• WinCC/Connectivity Pack — Server package export/import

Verify the exact error code returned for a given failure mode against the WinCC V7.x error code reference in the manual listed above. The codes 1001 and 1401 referenced in this article are stable across V7.4 and V7.5.