Resolving WinCC 6.2 Client-Server Screen Flipping Mirroring

Symptom summary: A Siemens WinCC V6.2 station is configured as a WinCC server, with one or more WinCC clients attached over TCP/IP. An operator on one client changes the active screen (for example, opens Overview.Pdl from a navigation button). Without warning, the WinCC server monitor and every other connected client follow that change and display the same picture. Operators on unrelated screens lose context; alarms are still displayed but the work area shifts unexpectedly. The system is not technically failing: all clients remain online, all tag subscriptions succeed, and the server's process data archive continues logging. The misbehaviour is purely a screen-navigation mirroring effect.

This article walks through the engineering root cause in WinCC 6.2, the diagnostic procedure to confirm it, the configuration changes that eliminate the mirror, and the verification checks that prove the fix is stable under load. It applies to WinCC V6.2 SP3 and later 6.x service packs. WinCC 7.0, 7.2, 7.3 and TIA Portal WinCC Professional follow the same conceptual model but the dialogs and C/B-script syntax differ; the principles in this article remain valid as a reference.

1. Problem Statement and Reported Symptoms

The reported architecture is a single WinCC server plus multiple clients on a LAN, with the screen-flipping propagation observed in both directions: client-to-server and client-to-client. Two key facts from the report drive the diagnosis:

• The client stations are "clients without projects" - they reference the server's published package rather than holding a full local copy of the WinCC project.
• Navigation between pictures is implemented through "internal tags" - in other words, an internal WinCC variable carries the destination picture name and a script or property binding uses it to drive a picture window.

When the navigation variable is configured as an internal tag in WinCC Explorer, it is local to the host station by default. However, a "client without project" inherits tag definitions from the server package. If a tag is promoted to a server tag (i.e., its scope is set so the server publishes it), every client reads the same value simultaneously. Writing the navigation tag from one client therefore changes the value seen by the server and every other client, and every station executes the same screen change.

2. Root Cause Analysis

WinCC V6.x tags have two orthogonal properties:

1. Type - Internal, Process, or External tag.
2. Scope - Local (station-scoped) or Shared (server-scoped, replicated to all clients).

The default scope for a newly created internal tag in WinCC Explorer is local. If the operator - or, more commonly, the integrator who built the navigation - later right-clicks the tag in WinCC Explorer, opens Properties and selects "Available throughout the system" (or alternatively uses the Tag Management dialog to promote it), the tag is automatically pushed to the server's tag list. WinCC 6.2 then includes it in the server's published package. From that moment, every client without a project receives the tag's value updates over the WinCC internal channel, and every client reading that tag executes the same property or script binding at the same time.

A common trigger is the integrator testing on the server first and then deploying the package to the clients: the navigation works locally during server-side testing, but the moment a client is attached, the screen changes echo everywhere because the tag was created on the server and inherited the server scope. Even a "client with project" can show the same problem if the integrator copied the server's tag into the client project with shared scope enabled.

3. WinCC 6.2 Client-Server Architecture Recap

WinCC V6.x supports three relevant station roles in a distributed topology:

• WinCC Server - hosts the project, the process database, the archive, and the runtime data manager. Tags declared with shared scope are stored here and broadcast.
• WinCC Client with project - has its own WinCC Explorer with a local copy of the project. It can define local-only tags and pictures that do not exist on the server.
• WinCC Client without project - holds no project files. At runtime it downloads the package published by the server (referenced via the server's computer name in the client configuration tool) and runs the same pictures, scripts and tag connections.

Because a client without project has no local WinCC Explorer, the only way it can have a "local" variable is to use the special WinCC client-local namespace prefix @Local::. Any tag name beginning with @Local:: is automatically given a separate value per station: the server's copy of @Local::NavPicture is different from client A's copy and different from client B's copy. This is the canonical way to do per-station screen navigation.

The @Local:: prefix is documented in the WinCC Information System under "Internal Tags - Local Computer" and is supported in all WinCC V6.2 service packs as well as V7.x. See the Siemens Industry Online Support portal entry index for "WinCC V6" for the linked manual PDFs.

4. Confirming the Root Cause: Diagnostic Procedure

Before changing any configuration, prove that the tag is shared and that the propagation is on that tag. Run the following diagnostic sequence in WinCC Explorer on the server while a client is connected.

4.1 Inspect the tag's scope

1. On the server, open WinCC Explorer and expand Tag Management > Internal Tags.
2. Locate the tag driving the picture window (typical names: Navigation, ActivePicture, PictureName, NavPdl).
3. Right-click the tag and choose Properties.
4. In the General tab, inspect the option "Available throughout the system". If the box is ticked, the tag is shared.

4.2 Trace the value in runtime

1. On the server, open WinCC Tag Simulator or WinCC Online Trend Control and add the suspect tag.
2. On a client, click a navigation button that changes the picture. Observe the trend on the server.
3. If the trend on the server mirrors the client's value update, the tag is shared. The replication latency is typically 200-500 ms on a healthy LAN; larger values indicate network pressure.

4.3 Inspect the package published by the server

1. On the server, open Server Data in the computer properties (right-click the server computer name in WinCC Explorer > Properties).
2. Switch to the Package tab. Confirm that the suspect tag appears in the package - this is the formal declaration that the server is publishing it.
3. If the tag is listed under the package, remove it and re-test. Removing a tag from the package is harmless if the tag is not used elsewhere on the server.

5. Solution Options

Three fix paths are available. Choose one based on whether the navigation must persist per-station or whether the system legitimately requires synchronized navigation.

5.1 Preferred fix: per-station @Local:: tag

Use a tag whose name begins with @Local:: as the picture window's picture name source. The server's runtime and every client runtime get their own memory cell.

Implementation:

1. In WinCC Explorer, create a new internal tag named, for example, @Local::NavPdl with type Text tag, 8-bit character set and length 32.
2. Open the navigation picture window's Process > Picture Name property binding and select the new tag.
3. Replace every C-script or VBScript that wrote the old Navigation tag with the same write to @Local::NavPdl. Syntax in C: SetTagChar("@Local::NavPdl","Overview.Pdl");. Syntax in VBS: HMIRuntime.Tags("@Local::NavPdl").Write "Overview.Pdl".
4. Recompile the project on the server and activate runtime.

This is the safest fix because no server-side change of scope is required and no other consumer of the tag is affected.

5.2 Demote the shared tag to local scope

If the integrator prefers to keep the tag name unchanged for traceability, demote it back to local scope.

1. On the server, open the tag's properties and uncheck "Available throughout the system".
2. Open Computer > Properties > Package on the server and remove the tag from the published package.
3. Restart WinCC Runtime on the server.
4. If the clients are "clients with project", open the local tag in their WinCC Explorer and confirm it exists locally; if not, copy it locally.
5. If the clients are "clients without project", they will receive the tag through the package as before; the difference is that the server no longer mirrors the writes. Confirm that the tag's Direction in the package is set to read/write on the client.

5.3 Replace tag-driven navigation with direct picture calls

If the picture window navigation is implemented as a generic framework where the tag carries the destination name, replace the framework with explicit calls. This eliminates the shared-variable path entirely and is the most robust solution for a multi-station system.

For each button, replace the indirection with a direct OpenPicture call:

• VBS on click event: HMIRuntime.BaseScreenName = "Overview.Pdl" or HMIRuntime.ActiveScreen.ScreenItems("MainWindow").Screen = "Overview.Pdl".
• C script: OpenPicture("Overview.Pdl"); for a base screen change, or SetPictureName(lpszPictureName,lpszObjectName,"Overview.Pdl"); for a picture window embedded in the current screen.

Use this approach when the picture name is static and known at compile time. Avoid it when the destination picture must be data-driven (for example, selected by the operator from a list).

6. Verification Procedure

After applying one of the fixes above, run the following sequence to confirm the propagation is gone.

1. Activate runtime on the server and at least two clients (recommended: 1 server + 3 clients to match the field architecture in the report).
2. On client A, click a navigation button to Overview.Pdl.
3. Confirm: client A changes to Overview; server and clients B and C remain on their previous picture.
4. On client B, click a navigation button to Alarm.Pdl. Confirm: client B changes; server and clients A and C remain.
5. On the server, open WinCC Online Trend Control with the navigation tag. Confirm: the server's value does not change when a client clicks a navigation button.
6. Repeat the same test under load: force a value-change storm on a process tag (for example, a 100-ms oscillating tag) and re-verify navigation is still local.
7. Verify alarm visibility remains unaffected: trigger an alarm on the server and confirm that it appears on every client regardless of which picture is on top.

7. Configuration Parameter Reference

The following table lists the parameters that affect screen-mirroring behaviour in WinCC 6.2 and their default settings.

8. Performance and Bandwidth Considerations

Shared tags are not free. Each subscription on the server produces a UDP-multicast packet on the LAN each time the value changes. With a fast oscillating tag (for example, a position feedback at 100 ms), a single shared tag can produce ten packets per second per subscribed client. In a 1 + 8 client architecture with five oscillating shared tags, the server pushes 400 packets per second. The WinCC internal channel is engineered for this rate, but misconfigured systems frequently trigger network-team escalations.

The @Local:: namespace never crosses the network. Even if the tag name has the prefix, the WinCC runtime manages it in a per-process memory pool and never publishes it. This makes @Local:: the correct choice for any navigation, mode, or operator-state variable that has no business being shared.

9. Edge Cases and Field-Proven Caveats

9.1 @Local:: tag length limits

WinCC V6.2 limits tag names to 32 characters including the @Local:: prefix. Use short picture-name tags such as @Local::NavPdl rather than verbose names. If you exceed the limit, the tag is created silently as a global tag and the per-station isolation is lost.

9.2 Picture Tree Manager interaction

If your project uses the Picture Tree Manager for central navigation, the picture name is driven by an internal structure tag managed by the tool. This tag is normally shared by design. If you replace it with a per-station variable, you break the picture tree. Treat picture tree navigation as a special case and document it explicitly.

9.3 Redundant server pair

If the server is part of a redundant WinCC server pair, the partner server takes over within 5-30 s. The @Local:: value on the failed server is lost on failover because it lived only in that process's memory. Operators must re-navigate after a failover. If this is unacceptable, persist the navigation state to a server tag and rehydrate on picture load.

9.4 Clients with project versus clients without project

A "client with project" defines its own WinCC Explorer. Internal tags created there are local by default and never propagate unless explicitly promoted. A "client without project" only inherits what is in the server package. If the integrator creates an internal tag on a "client with project" and that tag is also defined on the server, the client's value is overwritten by the server broadcast unless the tag is excluded from the package. Verify the package list on the server.

9.5 C script versus VBS script tag access

C scripts use GetTagChar/SetTagChar for text tags; VBS uses HMIRuntime.Tags(...).Read/.Write. Both honour the @Local:: prefix. The script type is not a factor in propagation.

10. Cross-Reference to WinCC V7 and TIA Portal WinCC Professional

The behaviour is conceptually identical on WinCC 7.x and TIA Portal WinCC Professional (WinCC Unified differs in its multitag concept, but the local-namespace idea persists via "HMI tags in the area pointer for screen navigation" and user-defined local data blocks). The diagnostic procedure remains the same:

1. Identify the tag driving picture change.
2. Inspect its scope (local vs HMI-device-wide vs cross-device).
3. If shared, change to local or use the @Local:: prefix equivalent.
4. Verify on multiple runtime instances.

The Siemens WinCC V6 manual set (function manual, configuration manual and communication manual) describes these scoping rules in detail. The official entry point is the Siemens Industry Online Support entry index for "WinCC V6", where the V6.2 SP3 manual collection and the readme PDFs are downloadable.

11. Quick Reference: Decision Flow

The following SVG summarises the decision flow when a screen-flipping mirror is reported.

12. Troubleshooting Matrix

13. Commissioning Checklist

When commissioning a new WinCC 6.2 client-server deployment, add the following to the Site Acceptance Test plan to prevent recurrence:

1. Generate a tag-scope report from WinCC Explorer (File > Export > Tag List with column "Scope") and store it in the project documentation folder.
2. For each tag whose name does not start with @Local:: and whose scope is "Available throughout the system", record a justification in the project's design document.
3. In the runtime test plan, include a step "Operator on client A navigates to screen X; server and other clients do not change." Repeat with at least three distinct picture names.
4. Verify under load: with at least 1000 process tags updating and at least one redundant pair in standby, run the navigation test and confirm no propagation.
5. Update the disaster-recovery runbook to include re-navigation after a server failover if the navigation state is held in @Local:: variables.

14. Frequently Asked Questions