Resolving WinCC 6.2 Picture Load Delays After v6.0 Migration

After migrating a Siemens WinCC project from V6.0 to V6.2, the runtime may load some process pictures (PDL files) in 10 seconds or more while otherwise identical pictures on the same project open in under one second. Communication parameters (ping latency, cycle time, connection status) often check out, and even disconnecting the Ethernet cable from the affected PLC may not change the delay. This article documents the diagnostic flow, the most common root causes, and the field-proven remedies that have been validated against WinCC V6.2 SP3 deployments running on Windows XP Professional SP3 and Windows Server 2003.

1. Problem Description

WinCC V6.2 (released 2008) introduced a redesigned picture cache, a new migration tool, and tighter integration with the SIMATIC logon framework. When a V6.0 project is opened with the V6.2 Migration Tool, every PDL is recomputed and re-saved, and every connection, tag prefix, and server assignment is rewritten. In most cases the result is invisible to the operator. In a documented subset of projects, however, a small percentage of pictures exhibit one of the following symptoms:

• First picture open after WinCC Runtime start: 10-30 seconds.
• Subsequent opens of the same picture: 1-3 seconds.
• Other pictures with similar tag count open in under 0.5 seconds.
• Disabling the Ethernet adapter to the affected PLC has no effect on the slow pictures.
• Ping latency to the affected PLC is unchanged (2-4 ms in the canonical case), confirming that the network is not the cause.

Two of the three pictures used as controls in the canonical case opened in under 1 second despite reading from PLCs on the same subnet. The third picture, which read from a PLC on a separate router but with the same cycle-time budget, took 12-18 seconds to open. This signature is characteristic of a project-structure problem, not a network problem, and it is reproducible on demand by an operator with no special tools.

2. Cycle Time and Communication Budget

Before opening WinCC Explorer, take five minutes to capture the live communication state. The two numbers that matter most for a V6.2 runtime are the acquisition cycle and the cycle time. The acquisition cycle is configured in the tag properties and determines how often the runtime requests an update from the PLC. The cycle time is the measured wall-clock time that the runtime actually needs to read the configured tags. The relationship is governed by the formula:

Cycle time = (Acquisition cycle / 1000) * (Tag count * Bits per tag / Link bandwidth) + Fixed overhead

The "20% of acquisition cycle" rule of thumb referenced in the canonical case is a conservative engineering target: if the cycle time exceeds 20% of the acquisition cycle, the runtime will not be able to keep up with the configured update rate and the operator will see stale values. For a 1-second acquisition cycle, the budget is 200 ms. The canonical case shows 17-18 ms, which is well within budget for a 1-second cycle.

To capture the live values, open WinCC Explorer > Tools > Channel Diagnosis and enable the live trace. The trace shows every tag request and every response, with millisecond timestamps. Save the trace to a CSV file and check that no individual request exceeds 50 ms; if any request is over 50 ms while the network ping is under 4 ms, the bottleneck is the PLC CPU or the SIMATIC NET stack, not the network.

3. Initial Diagnostic Checklist

Before opening the Migration Tool again, walk through the following checks. They take less than ten minutes and rule out the most common false leads.

1. Open WinCC Explorer > Tools > Diagnostic Files and review the most recent WinCC_Sys_<timestamp>.log and WinCC_Diag.log files. Look for WCCRT: connection lost or WCCRT: tag timeout lines that match the timestamp of the slow picture open.
2. Open Control Panel > SIMATIC > WinCC > Connections and confirm the channel unit (e.g. MPI, TCP, Industrial Ethernet) and the partner address for the slow picture. The channel unit suffix is part of the tag prefix in V6.2; a mismatch here causes the runtime to perform a full connection-establishment cycle on every picture open.
3. Start Task Manager > Performance and watch disk I/O on the WinCC project directory while opening a slow picture. V6.2 first opens a picture file from the project directory and only then consults the picture cache. If the project lives on a network share or a slow RAID volume, the first-open penalty can exceed 15 seconds even on otherwise idle pictures.
4. From the WinCC server, ping the affected PLC and the default gateway of the PLC subnet. The case study referenced in the field report shows ping times of 2-3 ms to the PLC and 4 ms or less to the router, which eliminates the network as a primary cause.
5. Open Computer > Properties > Start Up in WinCC Explorer and confirm that the Start Picture for the affected process is not the slow picture itself. If it is, the runtime is forced to load the slow picture on every cold start and the 10-second delay is paid once per start, which is the most common reason for a project to be perceived as "broken" on the operator console.

4. Network and Communication: Ruling Out the False Trail

The most common mistake when investigating slow picture open times is to assume the delay is network-bound. Three independent measurements confirm that the network is not the bottleneck in the canonical case:

When disconnecting the Ethernet cable from the slow pictures does not reduce the delay, but disconnecting it from the fast pictures also does not change their 0.5-second open time, the network has been excluded. At this point the investigation should pivot to project-internal causes: tag prefix resolution, server assignment, picture dependencies, and global script C-actions.

5. Root Cause: Tag Prefix Re-Resolution

The single most common cause of 10-second picture delays in migrated V6.2 projects is a redundant tag-prefix resolution path. In WinCC V6.0, a tag could be configured with one of two channel assignment modes. V6.2 changed the default behavior. When the migration tool rewrites the tag structure, it can leave dangling references to channel units that are no longer active on the runtime system. The runtime then performs a full connection re-establishment on every picture open, which is visible in the diagnostic files as a series of connection state-transition lines that span 8-12 seconds.

To confirm this root cause:

1. Open WinCC Explorer > Tag Management > SIMATIC S7 PROTOCOL SUITE > [affected channel].
2. Right-click the connection and select Properties > Connection.
3. Note the Connection Name and the Partner (PLC) Address. The internal V6.2 representation must match the V6.0 source. If the migration tool has appended a numeric suffix (for example, S7CONN_1 becoming S7CONN_1_2), the tag prefix is broken.
4. Open the tag list and inspect the configuration panel for the tag prefix. A tag whose channel unit no longer exists on the runtime system is flagged in the tag list.
5. Open the Tag Management > Internal Tags folder and search for tags that share the name of an external tag. V6.2 will silently prefer the internal tag over the external tag if the names collide, which causes the runtime to wait for a value that the internal tag will never provide.

6. Root Cause: Picture Cache and PDL Re-Compilation

WinCC V6.2 introduced the Picture Cache service, which buffers compiled pictures in memory to avoid the per-open compile penalty. When a picture is opened, the runtime checks the cache; if the picture is not present, it is loaded from disk and compiled by the Graphic Engine. The first load always pays the compilation penalty, but subsequent loads are served from RAM.

Two migration-related defects cause the Graphic Engine to re-compile a picture on every open:

• Event-linked C-scripts referencing renamed global script functions. V6.0 supported shorter function names than V6.2. Migration does not always rename them, so a picture with an OnOpen event calling a function with the legacy name will compile cleanly but fail at runtime, triggering the Graphic Engine's fallback path which re-evaluates the picture tree from scratch.
• Dynamic dialog boxes pointing to tags that now require a server prefix. V6.0 tags were local by default; V6.2 requires Server::Tagname for cross-server tags. A dynamic dialog that references Tag_X directly after migration will silently resolve to a zero-length string and the picture will continue to wait for a value that never arrives.

To verify, open the slow picture in Graphics Designer, right-click the background and select Properties > Events. Every C-action and VBS-action listed there must compile without warning. Warnings are shown in the status bar at the bottom of the Graphics Designer.

7. Root Cause: Global Script C-Actions

If the slow picture is part of a process picture tree that loads auxiliary pictures, the delay is often inherited from a global C-action defined in Global Script > C-Actions > Project Functions. Migration of V6.0 C-actions to V6.2 is performed by a separate translator that is not always invoked. The symptom is a 5-15 second delay on the first global action invocation, visible in the diagnostic files as a delayed action execution line.

The fix is to manually trigger the C-action translator:

1. Close WinCC Runtime.
2. In WinCC Explorer, right-click Global Script > C-Actions > Project Functions and select Rebuild All. This forces a full recompile of every C-action in the project.
3. Confirm that the resulting compiled file in the project \library folder has a timestamp newer than the source file. If it does not, the translation failed; restore the V6.0 source from backup and retry.
4. Open the compiled library in a hex editor and confirm that the function names are no longer truncated. Truncated names indicate a V6.0 source file with a long function name that the V6.2 translator could not resolve; rename the function in the source and rebuild.

8. Diagnostic Toolchain

Siemens provides three Knowledge Base entries that document the recommended diagnostic flow for V6.0 to V6.2 migrations. They are the authoritative starting point for any new investigation:

• Siemens Knowledge Base entry ID 22892165 - "How do you perform diagnostics in WinCC V6?"
• Siemens Knowledge Base entry ID 22089969 - "What information is required when contacting the WinCC hotline?"
• Siemens Knowledge Base entry ID 22892720 - "WinCC V6.0 to V6.2 migration: known issues"

Each of these entries documents a diagnostic bundle that exports the contents of the WinCC diagnostic files, the relevant registry entries under HKLM\SOFTWARE\Siemens\WinCC, and the contents of the project \library folder into a single archive. The bundle is the fastest way to escalate a delay issue to Siemens technical support with all required context.

9. Step-by-Step Resolution Procedure

The following procedure resolves the slow-picture issue in the majority of migrated V6.0 → V6.2 projects. Each step should be performed in order, with a verification after each step.

Step 9.1 - Verify Picture Cache Configuration

1. Open Computer > Properties > Graphics Runtime in WinCC Explorer.
2. Confirm Picture Cache Active is enabled. The default cache size in V6.2 is documented in the V6.2 installation manual and should be left at the installed value unless memory pressure forces a reduction.
3. Confirm the Cache Mode is appropriate for the runtime topology. Transient mode is suitable for single-user projects; Persistent mode is required for multi-user server-client configurations to survive a client disconnect.

Step 9.2 - Rebuild Tag Prefix Structure

1. Open Tag Management and select all tags used by the slow picture.
2. Right-click and choose Update Tag Properties > Re-Resolve Prefix. This V6.2 command re-evaluates the tag prefix against the current channel unit list.
3. Save the project and restart the WinCC Runtime.

Step 9.3 - Re-Compile the Slow Picture

1. Open the slow PDL in Graphics Designer.
2. Select File > Save As and save the file to a new name in the same project directory.
3. Open the new PDL and confirm the open time. The case study in the field report showed that copying the elements to a new PDL did not resolve the issue; this is because the project-level tag prefix problem persists. Saving the file to a new name in contrast forces the Graphic Engine to generate a fresh internal GUID for the picture, which bypasses the corrupted cache entry.

Step 9.4 - Rebuild Global Script Library

1. Close the WinCC Runtime.
2. In WinCC Explorer, expand Global Script > C-Actions > Project Functions.
3. Right-click the root node and select Rebuild All.
4. Wait for the compile dialog to complete. The duration scales with the size of the global script library.
5. Re-open the slow picture and measure the load time.

10. Verification

After applying the procedure above, verify the fix with the following checks:

• Slow picture open time: should drop to under 1.5 seconds on first open and under 0.4 seconds on subsequent opens.
• Diagnostic files: connection state-transition lines should be absent for the duration of the picture open.
• WinCC cycle time: should remain under 18 ms. If the cycle time spikes after the fix, the tag prefix re-resolve has over-allocated tags; increase the update cycle on the slow picture's tags from 1 s to 2 s.
• Memory: monitor the WinCC Runtime process working set. A continued growth after the fix indicates that the picture cache is evicting entries; increase the cache size and re-verify.
• Operator console: walk to the operator console and open the slow picture manually. The open time should be under 1.5 seconds. If the operator console is on a different subnet or behind a remote desktop session, run the test on the local console first; a slow open on the local console is a project issue, a slow open on a remote console is a remote-desktop issue.

11. Troubleshooting Matrix

The following matrix maps the most common symptoms to the most likely root causes and the recommended first-action.

12. Edge Cases and Field Notes

Three additional edge cases have been observed in production deployments.

12.1 - Multi-Client Configurations

On a WinCC server-client configuration with more than four clients, the slow-picture issue can reappear on the clients even after the server has been fixed. The cause is a misconfigured Server Prefix on the client. V6.2 introduced a default server prefix for all tags on the client. If a client was upgraded from V6.0 without resetting the prefix, it will attempt to resolve every tag on the local client and then on the server, doubling the resolution time. The fix is to open Computer > [Client] > Properties > Server and confirm that Preferred Server is set to the actual server name, not localhost.

12.2 - Pictures with Embedded ActiveX Controls

ActiveX controls registered with the V6.0 runtime are not always re-registered with the V6.2 runtime. A picture that embeds a third-party ActiveX (for example, a trend viewer or a custom numeric input) will hang for 10-20 seconds while the runtime attempts to instantiate the unregistered control. The fix is to re-register the OCX file with regsvr32 /i <path>\Control.ocx in an elevated command prompt. The runtime must be restarted after registration. To identify the offending control, open the slow picture in Graphics Designer and use the View > Object List command. The list shows the class ID of every embedded control; cross-reference the class ID with the list of registered controls in regedit under HKCR\CLSID.

12.3 - Pictures with Direct Hardware Access

Some V6.0 projects configured the Hardware channel for direct I/O access. The Hardware channel was a legacy interface in V6.0 and was carried forward in V6.2 only when explicitly selected during installation. A picture that references a Hardware tag will display "No connection" in V6.2, but the runtime will still attempt to initialize the channel for a number of seconds before giving up. The fix is to confirm that the SIMATIC NET Hardware Channel component was selected during V6.2 installation; if not, re-run the installation in modify mode and add the component.

13. Prevention for Future Migrations

To prevent the slow-picture issue from reappearing on future V6.0 → V6.2 migrations, follow the rules of thumb below:

• Always back up the project \library folder and the \GraCS folder before running the migration tool. The migration tool replaces the GraCS folder only when a PDL has changed; unmodified PDLs keep the V6.0 binary header, which can cause a runtime mismatch.
• Run the V6.2 Migration Tool on a copy of the project, never on the live project. The tool modifies the source *.pdl files in place and is not reversible.
• After migration, run Project > Consistency Check from the WinCC Explorer menu. The consistency check does not detect every tag-prefix issue, but it does detect the most common re-resolution loop.
• Schedule the migration during a planned outage and load the migrated project in Simulation mode for at least 24 hours before connecting to the live PLCs. Simulation mode runs the Graphic Engine without the channel DLL, so it surfaces Graphic-Engine-only issues (event scripts, dynamic dialogs, picture cache misses) without the network noise.
• Maintain a migration log: for every picture that takes more than 2 seconds to open after migration, record the picture name, the tag prefix, the channel unit, and the cycle time. Patterns in the log surface the root cause faster than ad-hoc investigation.
• After every migration, export the project to a fresh *.zip archive and store the archive on a network share that is backed up nightly. The migration tool is not reversible; the archive is the only way to roll back.

14. Commissioning and Acceptance Checklist

The following checklist is suitable for a V6.0 to V6.2 migration acceptance test. Each item should be signed off by the commissioning engineer and the customer's representative.

1. Project opens in Graphics Designer without warning dialogs.
2. Tag Management consistency check reports zero errors.
3. Global Script "Rebuild All" completes with zero errors.
4. All 20 most-frequently-used pictures open in under 1.5 seconds on first open and under 0.5 seconds on subsequent opens.
5. WinCC cycle time is under 20% of the configured acquisition cycle for every tag prefix.
6. Alarm logging is functional on every configured alarm class.
7. User administration is functional on every configured authorization level.
8. Redundant server failover (if configured) completes within 30 seconds without operator intervention.
9. Picture-by-picture test: for every picture in the process picture tree, open the picture, wait 5 seconds, and close the picture. Record the open time in the migration log.
10. 24-hour burn-in: run the project in Simulation mode for 24 hours. The Runtime should not crash, the cycle time should remain within budget, and the memory working set should not grow by more than 10%.

15. Frequently Asked Questions