WinCC Professional Visibility Animation Flicker on Screen Change

Affected product: SIMATIC WinCC Runtime Professional (TIA Portal V14 / V14 SP1 / V15 / V15.1 / V16 / V17 / V18 / V19 / V20)
Symptom: Objects configured with visibility animation (bit=1 visible, bit=0 invisible) briefly appear at full opacity for approximately 0.3–1.5 s immediately after a screen change, then fade or snap to the invisible state.
Tag state: The controlling HMI tag is measured to be constant 0 during the flicker window.

1. Problem Description

A WinCC Professional screen contains graphic objects (rectangles, circles, text fields, IO fields, symbolic IO fields, trend views, alarm views, faceplates, etc.) configured with a Visibility dynamic animation. The typical expression used in the source project is:

When the operator changes the active screen using a button, a screen window, or an alarm/event that triggers a screen change, the following sequence is observed at runtime:

1. The destination screen loads.
2. For approximately 0.3 s to 1.5 s, every animated object is rendered in its default (engineering) state — in this case fully visible.
3. After the first acquisition cycle of the configured tag, the animation evaluates to 0 and the objects are hidden.
4. The operator perceives a one-frame to multi-second flicker.

The tag value itself does not change during this interval; an online trace with a debugger or a momentary script (Trace(tag)) confirms the bit is held at 0 the entire time. This rules out PLC-side logic, tag-prefix mapping, and acquisition jitter as the root cause.

2. Root Cause Analysis

WinCC Runtime Professional renders a screen in two distinct phases during a screen change:

The flicker is the visual gap between Phase A and Phase B. During Phase A, the object is rendered with the engineering default of its dynamic property — in this case Visible = True. The animation only suppresses the object after Phase B completes its first evaluation cycle.

The duration of the visible glitch is governed by:

• The configured acquisition cycle of the controlling tag (default 1 s in WinCC Professional; settable to 100 ms, 250 ms, 500 ms, 1 s, 2 s, 5 s, 10 s, 30 s, 1 min, 5 min, 10 min, 1 h).
• The animation cycle of the screen (default 100 ms; the interval at which the runtime re-evaluates all dynamic expressions on the active screen).
• CPU load, RAM, GPU compositor workload, and the number of simultaneously evaluated dynamic objects on the destination screen.
• Communication load on the WinCC HMI tag connection (S7-1500 / S7-1200 / S7-300/400 / OPC UA / Modbus TCP) used for the tag.

3. Solution

3.1 Primary fix — invert the engineering default

1. In the TIA Portal project tree, open the affected screen in the WinCC Professional editor.
2. Select every object that has a Visibility animation bound to a tag.
3. In the Properties > Miscellaneous pane (or Properties > Appearance > Visibility in newer portal versions), clear the check box Visibility so the static default reads Invisible.
4. Confirm that the dynamic expression is still configured: typically the formula field reads Bit = 1 or 'Tag' == 1 under the Animation node of the same property group.
5. Recompile the WinCC Professional RT and re-download / re-deploy to the runtime PC or Panel.
6. Trigger the screen change and verify the object never appears during the transition window.

3.2 Secondary fix — reduce the animation cycle

If a residual flicker is still visible because the animation cycle is coarser than the frame rate, shorten the screen update interval:

1. Select the screen background or the root of the screen in the editor.
2. Open Properties > Animations > Update cycle (or in V17+ Properties > General > Refresh).
3. Change the cycle from 1 s (default) to 250 ms or 100 ms for the destination screen only. Do not change the project-wide default unless required, as this multiplies CPU load across all active screens.
4. For tag acquisition, set the Acquisition cycle of the HMI tag to 100 ms if the upstream PLC is on PROFINET IRT or high-speed EtherNet/IP. For S7-1500 connections via SIMATIC S7-1500 channel, 100 ms is supported and recommended for status / control bits.

3.3 Tertiary fix — bind to a local, non-PLC tag for instantaneous startup

If a tag is sourced from a slow bus (PROFIBUS, MPI, Modbus RTU, OPC DA over DCOM), the first read at screen load can dominate the gap. Bind the visibility animation to an internal HMI tag instead of a process tag, and have a script or the PLC write the value of the process tag into the internal tag via SetTag in a global scheduler (or in the PLC using a data record transfer on screen change). This is the standard pattern for HMI-side interlocks where the PLC scan time is irrelevant.

3.4 Eliminate redundant dynamic expressions

Each dynamic expression contributes to the Phase B evaluation time. Review the screen for objects whose dynamic expression is functionally identical to the static default; if a value never changes, remove the animation entirely and rely on the static default. This is documented in the official WinCC Screen basics (RT Professional) reference under Working with screen objects.

4. Verification

1. Compile the project and deploy the RT image.
2. Start WinCC Runtime Professional in RT with simulation mode and reproduce the original screen change sequence.
3. Capture a screen recording at 30 fps and inspect the frames between t=0 (click) and t=1.5 s (animation cycle boundary). No frame should show the animated object at full opacity.
4. Open the WinCC RT channel diagnosis (Start > SIMATIC > WinCC Runtime Professional > Channel Diagnosis) and confirm tag acquisition jitter < 50 ms.
5. For multi-screen projects, use the Performance tab in the RT diagnostic window. CPU load should remain below 60 % on the runtime PC; values above 80 % indicate that the animation cycle reduction is masking an underlying performance issue.
6. Force the controlling PLC tag to 1 via the PLCSIM or real PLC and confirm the object appears without flicker.

5. Parameter Reference

6. Edge Cases and Field-Proven Caveats

6.1 Screen windows and faceplates

WinCC Professional supports screen windows and faceplates that can be instantiated at runtime. Each faceplate instance is a fully independent dynamic context. The default visibility rule (3.1) must be applied to every tag, button, and graphic inside the faceplate body, not just the faceplate root. Forgetting this is the most common source of residual flicker in a faceplate that hosts a visibility-animated icon.

6.2 Visibility animation chained with appearance animation

If an object is set to Invisible via the static default and additionally has an Appearance animation bound to a separate tag, the appearance animation will not run while the object is invisible. This is the correct semantic. If you need to flash the object using an appearance animation, sequence the logic in the PLC so the visibility tag is set true first and the appearance tag follows in the same OB1 cycle (or use a single script that writes both tags in order).

6.3 Animation triggers on a Touch / Pro tool button

Buttons with an Activate event on press can momentarily toggle a shared bit. If the visibility animation is bound to that same bit, the object will flash. Use a dedicated internal bit, e.g. HMI_VisBit_ObjectX, and write to it from the button's Press event, leaving the Release event free for the actual control function. Avoid binding animations to the same bit that the button toggles for process control.

6.4 OPC UA vs. SIMATIC S7 channels

For OPC UA connections, the WinCC RT Professional OPC UA client uses the subscription's publishing interval rather than the tag acquisition cycle. Minimum publishing interval is 100 ms; below that, the channel can drop subscriptions. If a flicker is observed only on OPC UA-bound tags, verify the OPC UA server's MinPublishingInterval and set the WinCC acquisition cycle to at least that value.

6.5 Runtime on virtual machines

WinCC Runtime Professional is officially supported only on physical hardware or hypervisors with full passthrough GPU and a fixed CPU reservation. When the runtime is hosted on a VM with oversubscribed CPU or no GPU, Phase A can stretch from a typical 200 ms to 1+ s, which amplifies the flicker. Confirm with Task Manager > Details > CCEServer.exe and CCRTMgr.exe that the WinCC processes are on High priority and pinned to physical cores.

6.6 WebNavigator and thin client load

When publishing screens via WinCC WebNavigator or WinCC/WebUX, the visible glitch is also observed client-side. The fix (3.1) applies identically, but the animation cycle of the client is governed by the Web Server configuration in TIA Portal, not the runtime PC. The recommended client refresh interval is 1 s; values below 500 ms overload the WebUX service.

7. Diagnostic Checklist

8. Best Practices Summary

• Default state rule: The engineering static default of any dynamic property must represent the safe / fallback state. For visibility, this is always Invisible when the animation is on a one-hot bit, and always Visible when the animation is on an error / fault bit.
• Use internal HMI tags for animations whose purpose is purely cosmetic or UI-state, decoupling them from PLC scan time.
• Reserve high-speed acquisition (100 ms) for tags that drive operator-safety-relevant animations (E-stops, valve states, motor running). Use 500 ms–1 s for low-priority status.
• Consolidate dynamic expressions into a single C / VB script bound to a custom property when more than 3–4 dynamic expressions target the same logical state. This reduces Phase B evaluation time.
• Document the animation rule in the project HMI style guide. Siemens does not enforce this rule in the TIA Portal compiler; it is a project discipline item that should be reviewed in code inspection.

9. Related Official Documentation

• Screen basics (RT Professional) — TIA Portal V20 documentation
• Siemens Industry Online Support — TIA Portal / WinCC knowledge base (search term: "visibility animation default state")