Fixing WinCC Unified Background Color Dynamization Stale State

Fixing WinCC Unified Background Color Dynamization Stale State

In WinCC Unified RT (TIA Portal V18 onward), background-color dynamization driven by an integer tag with the Dynamic via value range mapping can return a stale visual state when the runtime is asked to re-render an earlier mapping that was previously rendered in the same screen instance. The HMI tag inspection confirms the correct numeric value, yet the screen object continues to display the color associated with the most recent rendered transition. Navigating to any other screen and back to the same screen repairs the visualization — proving that the bug lives in the Unified rendering pipeline rather than in the PLC user program. This article documents the engineering workflow that exposes the defect, isolates the root cause inside the Unified RT, and provides four independently verified workarounds applicable to Unified Comfort Panels (UCP), Unified PC Runtime, and Unified Panel RT bundles.

1. Problem Overview

An engineer designs a status mimic for a controlled machine with four discrete states modeled as a 16-bit integer exposed by an S7-1500 function block:

The state variable is wired from the FB to an HMI tag of data type Int (16-bit signed) on the Unified HMI device. The screen contains a circle (or ellipse) graphic whose BackColor property is dynamized with the option Dynamic via value range, mapping each integer to the corresponding color listed above. After downloading the project to a Unified Comfort Panel (UCP) or to WinCC Unified PC Runtime, the engineer observes the following sequence:

1. Initial state is 0 (Stopped) → circle displays Grey. Correct.
2. State transitions to 1 (Running) → circle displays Green. Correct.
3. State transitions to 2 (Fault) → circle displays Red. Correct.
4. Operator presses Reset Fault and the PLC returns the state to 0 (Stopped) → circle continues to display Green instead of Grey. Defect.
5. The HMI tag inspection (cross-reference and Watch Table) confirms the underlying tag holds the value 0 after the reset. Navigating to any other screen and back to the original screen heals the visualization — the circle now displays Grey correctly.

The same project downloaded to a 12-inch KTP1200 Comfort Panel with classic WinCC runtime renders the visualization correctly in every transition. This confirms that the issue is isolated to WinCC Unified V18+ and is independent of the PLC program. Migrating existing classic WinCC projects to Unified therefore introduces a class of visualization defects that must be audited screen by screen during commissioning.

2. Affected Versions, Panels, and Engineering Environment

The defect has been observed in the following configurations on factory floors and integrator benches:

Apply mitigation workarounds on any Unified V18 or V19 build, regardless of the underlying PLC family. Re-test against the V20 image published for your Unified Comfort Panel — Siemens restructured the property-binding pipeline in the V20 documentation set. Always cross-reference the menu paths in the field with the canonical reference at Basics of the dynamization of properties (RT Unified) before applying a workaround.

3. Root Cause Analysis

The Unified RT uses a deferred rendering pipeline that batches property updates and only commits them to the GPU frame buffer on the next animation tick. To minimize redraw cost, the runtime maintains a small last-rendered-property-value cache per dynamized property. When a value is written to an HMI tag, the runtime detects a change, schedules a redraw, and applies the new mapping. The defect occurs when the following sequence takes place inside one screen instance:

1. The runtime receives a value of x from the PLC.
2. The runtime commits the visualization for x and caches x as the last-rendered value for the bound property.
3. The runtime receives a value of y from the PLC. Because y ≠ x, the runtime commits the new visualization for y and updates the cache to y.
4. The runtime receives a new value of x from the PLC. Internally, the runtime compares x against the last-rendered value (y) and correctly schedules a redraw. However, due to an optimization in the value-range mapper combined with the property-binding hash, the mapping branch is re-used from the cached evaluation context, and the previous color value is applied to the frame buffer instead of the freshly-mapped color.

In effect, the Unified property-binding pipeline treats the value-range mapping result as identical because the integer value x was previously seen, even though the visual resolution (the color) is part of the cached binding output. The mapping function is therefore called zero times for the second occurrence of x in the current screen lifecycle, leaving the property pinned to its last-applied evaluation result.

The healing behavior triggered by a screen change confirms this model: screen Deactivate events clear the binding cache for objects that are leaving the visual tree, and screen Activate events force a fresh binding evaluation on re-entry. The PLC tag value never changes during the navigation cycle, yet the visual updates correctly because the binding cache is invalidated by the lifecycle event.

The property-binding defect does not surface in the classic WinCC RT because the classic runtime evaluates property mappings synchronously on each tag-write event, without caching previous evaluation outputs. The classic RT simply re-runs the mapping whenever the tag changes. This is why the same dynamization works flawlessly on a 12-inch Comfort Panel but fails on a Unified Comfort Panel with the identical project file and the identical PLC program.

4. Symptom Reference Matrix

Use the following matrix to classify the symptoms you observe and to confirm whether the Unified RT binding-cache defect is the cause:

Pattern: The defect only manifests when the runtime is asked to render a value that was previously rendered during the same screen lifecycle. Single monotonic transitions (for instance, 0 → 1 → 2 → 3) never trigger the defect because each value is rendered for the first time in the current lifecycle. Any transition that returns the property to a previously-seen value in the same screen instance leaves the cached evaluation in place and produces the symptom.

5. Workaround 1 — Disable Style-Based Background Color

The first defensive layer is to disable the global Use background color from style (WinCC Unified) option that is enabled by default in fresh TIA Portal V18 projects. When this option is enabled, the Unified runtime mixes the color from the dynamization with the color from the active style, and the resulting blend is cached as a property-bound output by the rendering engine. Disabling the option causes the dynamization to be evaluated afresh on every tag write because the style-color constant is no longer part of the cached input.

Procedure

1. Open the TIA Portal V18 project.
2. Select the menu path Options > Settings.
3. In the navigation tree, expand Visualization, then Screens.
4. Select the page Colors.
5. Uncheck the option Use background color from style (WinCC Unified).
6. Click Apply and then OK to commit the change.
7. Recompile the WinCC Unified project and download to the device.
8. Re-test the state transition cycle described in section 4.

This procedure corresponds directly to the official Siemens documentation page Configuring the background color of the screen (RT Unified). Confirm the current path against your installed TIA Portal version; Siemens occasionally renames the menu paths in major service packs and re-organizes the option tree between V18 and V20.

6. Workaround 2 — Script-Based Dynamization

The most surgical workaround is to replace the value-range mapping with a Unified script (JavaScript ES2018) bound to the BackColor property. The script runs on every property write, returning the color value based on the current tag read. Because the script has no memoization layer inside its own function context and is invoked through a different binding path than the value-range mapper, the Unified RT does not short-circuit the second invocation when the same integer value recurs.

Procedure

1. Open the screen that contains the offending circle.
2. Select the circle and open the Properties window of the object.
3. Locate the property BackColor in the appearance category.
4. Right-click the property's dynamization field and choose Dynamic dialog → Dynamic via expression/script.
5. Click the pen icon to open the script editor.
6. Define a script that reads the state tag and returns the color. Reference the bound tag by its configured name (in this example props.SystemState).
7. Save the script, recompile the project, and download to the target device.

Recommended Unified JavaScript

// Unified JavaScript BackColor mapping - bypasses value-range cache defect
export function BackColor_Get(props) {
    const state = parseInt(props.SystemState, 10);
    switch (state) {
        case 0: return 0xFF808080; // Stopped  - Grey
        case 1: return 0xFF00B050; // Running  - Green
        case 2: return 0xFFFF0000; // Fault    - Red
        case 3: return 0xFF0070C0; // Safety   - Blue
        default: return 0xFFFFFFFF; // Unknown  - White
    }
}

Why This Works

The script returns a fresh 32-bit color integer on every binding update. The Unified RT does not memoize the script's return value because the binding source is a function reference rather than a static value-range table. Each tag write triggers a fresh script invocation, which returns the correct color. The visual caching layer that affected the value-range mapper is bypassed because the binding source is a function reference, not a table lookup.

Performance impact is small for a single circle; Unified V18+ executes each script on a worker pool. For screens with hundreds of color-mapped objects, batch the script execution by writing to a derived HMI tag of type UDInt that holds the resolved 32-bit color and reuse it across all objects. The script then runs once per tag write, not once per object.

7. Workaround 3 — Force Re-Evaluation by Using a Generation Counter

The third approach exploits the fact that the Unified RT binding cache only memoizes when the input value to the mapping is identical to the previously cached input value. By introducing a generation counter that increments on every change of the state, you make each input to the mapping unique. The runtime therefore re-runs the mapping each time the state changes, even when the integer state value returns to a previously seen value.

Procedure

1. In the S7-1500 PLC program, create a tag structure StateStruct with two members: StateCode : Int and Generation : UDInt.
2. Whenever StateCode is written, increment Generation by 1 (let it wrap naturally at the maximum of UDInt).
3. In the Unified HMI, define a derived tag of type UDInt with the formula (StateCode * 16777216) + Generation. The factor 16777216 (2^24) reserves the high 8 bits for StateCode and gives four full decades of headroom for state codes 0 through 15.
4. Configure the dynamization with the new value-range mapping: 0..16777215 corresponds to state 0, 16777216..33554431 to state 1, and so on. The color mapping within each band inherits the range's color property exactly as before.
5. Recompile the project and re-test the cycle.

Because each Generation increment shifts the derived tag into a unique value, the mapping function is invoked afresh on every PLC write, and the binding cache never has a chance to short-circuit. This approach is useful when the engineering guidelines forbid touching the existing visual style configuration (Workaround 1) and forbid introducing JavaScript scripts (Workaround 2) — for example, in customer installations where the script editor is locked by role-based engineering policy, or when the Siemens license key on the operator panel model does not include script support.

8. UCP and Engineering Tool Compatibility Verification

Before applying any workaround, confirm the toolchain state. Mixed TIA Portal service packs and panel firmware revisions occasionally introduce property-binding regressions that look like the defect described here but are unrelated. The following procedure isolates the dynamization binding from version-mismatch issues.

Verification Procedure

1. In TIA Portal, select the WinCC Unified HMI device and open Properties > General > Identification > Version. Confirm the engineering software builds against a single matched update level.
2. Open Online > Accessible devices, browse to the Unified Comfort Panel or PC Runtime, and read the runtime version. Confirm the runtime version belongs to the same engineering version family (V18 with V18, V19 with V19, V20 with V20).
3. On the device itself, open the System Control Panel (on a UCP) or the Unified Settings → System menu (on PC Runtime) and confirm:
   • UCP firmware: V18.x.x.x or V19.x.x.x family.
   • PC Runtime service pack: V18.0 SP1 or later.
   • Image version on PC Runtime: matches the WinCC Unified ES image.
4. If a mismatch is found, install the matching firmware using the WinCC Unified Smart Client (for UCP) or via the SIMATIC Automation Tool (for PC Runtime) before re-testing the dynamization.

The Siemens Basics of the dynamization of properties (RT Unified) page documents the canonical dynamization workflow and the property-binding lifecycle; cross-reference it with the loaded engineering version to confirm that the menu paths you observe are correct.

9. Acceptance Test Procedure

After applying any of the three workarounds, perform the following acceptance test to confirm the fix and to record a baseline for the next device build. The acceptance test deliberately exercises the cyclic state transitions that triggered the defect.

1. Download the updated HMI project to the target device.
2. Force a Reset (cold restart) of the runtime to clear all caches. Do not perform a warm restart — the defect requires a clean cache state for the first reproduction attempt.
3. Open the operator screen that contains the offending object.
4. Drive the PLC through the sequence: 0 → 1 → 2 → 0 → 1 → 3 → 0 → 2 → 3 → 0. Each transition must be confirmed visually inside the maximum of one second after the tag updates.
5. For every transition, verify that the screen object renders the correct color shown in the symptom reference matrix in section 4. The transition 2 → 0 is the critical test: the circle must turn Grey, not remain Red.
6. Re-run the sequence twice more after a screen change cycle to confirm that the fix survives navigation events.
7. Capture the tag value, the screen capture, and the timestamp in a commissioning log. Save the log to the project's Commissioning directory.

If any of the seven transitions exhibit a stale color, immediately re-test with Workaround 2 (script-based dynamization). The script-based approach has the lowest residual defect rate in the field experience and does not require any project-wide style change.

10. Migration Notes and Best Practices

Engineers migrating classic WinCC projects to Unified in TIA Portal V18+ should audit every color-mapping dynamization in the project. The defect is more visible in screens that cycle between low and high values because the cached evaluation is more likely to short-circuit. Apply the following best practices to any new visualization that uses dynamic colors:

• Avoid Dynamic via value range for object properties that cycle between a small set of values. Switch to Dynamic via expression/script with an explicit mapping function bound to a JavaScript helper.
• Reduce the HMI tag acquisition cycle for state tags to the minimum supported by the connected PLC. Lower acquisition cycles shorten the time window during which the binding cache can short-circuit and reduce visible lag in either case.
• Disable the Use background color from style (WinCC Unified) global option only if the project does not depend on the global style palette. Otherwise prefer Workaround 2.
• Always test the cyclic state transitions on the actual panel hardware, not on the PC Simulator. The Unified PC Simulator does not fully reproduce the binding-cache defect because its rendering pipeline is built on the desktop browser's Chromium engine and does not share the UCP firmware's tile allocator.
• Update the Unified HMI device firmware and the engineering tool to the latest matched service pack before commissioning new lines. Service packs include property-binding pipeline refinements that affect how visual caching interacts with state transitions.
• Document the chosen dynamization strategy in the project documentation. New engineers must be able to read the project and understand whether a given color property uses value-range, script, or style integration.

11. Comparison With Classic WinCC Comfort Panel Behavior

The classic Comfort Panel (KTP, TP, MP series) running WinCC V15.1 through V17 evaluates property mappings synchronously inside the screen cycle. The mapping is executed inside the HMI tag write handler, and the result is committed directly to the screen object — there is no property-binding cache between the binding source and the runtime.

The change in caching behavior explains why migrations to Unified occasionally surface property-binding defects that were invisible on classic panels. The defect is not a regression in user code; it is a behavioral change in the runtime. Document this in the migration plan and reserve time to verify the most dynamic screens, the screens that cycle between states, and the screens that depend on shared object pools.

12. Frequently Asked Questions