Siemens Unified HMI: Word Tag Bit Dynamization Troubleshooting

Engineers migrating a TIA Portal project from a Comfort Panel (WinCC RT Advanced) to a Unified Comfort Panel (WinCC Unified runtime) frequently encounter a silent failure: a Word tag configured with a trigger bit continues to raise discrete alarms correctly, but the same tag no longer changes the color, visibility, or other property of a screen object. The trigger fires, the alarm logs, the PLC value is correct, yet the bound property never updates. This article documents the architectural cause, three field-proven remedies, and a migration checklist that prevents the issue at the project-planning stage.

Problem Summary

A trigger bit inside a 16-bit Word tag is observed for two distinct purposes in WinCC engineering:

1. Alarm triggering - each bit position can be assigned to a separate alarm row with its own message text and class.
2. Property dynamization - the value of a tag drives a state list (color, visibility, fill level, position, flashing).

On a Comfort Panel, both subsystems can interpret the trigger bit. On a Unified Panel, only the alarm subsystem does. The dynamization subsystem evaluates the entire Word as an integer and looks for that integer in a configured value list. Bits set inside the Word are not decomposed into individual states.

Architecture: Trigger Bits in Comfort vs Unified

A trigger bit is a notification mechanism. It tells the HMI runtime that the value of the tag has changed and that the property bound to the tag should be re-evaluated. In the WinCC RT Advanced dynamization dialog, the engineer was offered a per-bit state table: pick bit 0, assign color green, pick bit 1, assign color yellow, and so on through bit 15. The runtime then read the Word, masked off each bit position, and applied the configured state.

WinCC Unified redesigns the dynamization property. The dialog exposes a value list - the engineer types the integer values that the property should react to (1, 2, 3, 4, 5, ...) and assigns a state to each. The runtime reads the Word and looks for the integer in that list. If the value matches, the corresponding state is applied. If the value does not match, the property falls through to the default state, which is typically the configured initial value of the property.

The trigger bit mechanism is unchanged. It is still the way the HMI decides when to poll the PLC for a refresh. What has changed is what the runtime does with the value after the refresh.

Root Cause: Why Dynamization Evaluates Integer Value, Not Bit Position

The trigger bit and the state selector are two independent concepts in the Unified runtime. Concretely, for a Word value of 0x0005 (binary 0000 0000 0000 0101, bits 0 and 2 set):

If the engineer had originally configured state values 1, 2, 4, 8 (one for each bit), the integer 5 is not in that list, and the property stays at its previous state. If the engineer reconfigures the state list to 1, 2, 3, 4, 5, 6, 7, 8 (all combinations), the property will react but cannot distinguish "bit 0 and bit 2 set" from "value 5 written directly." For mutually exclusive bits this is acceptable. For overlapping bits it is not, because two simultaneous states collapse into one integer value.

This behavior is documented in the WinCC Unified manual as a value-based dynamization model. The Comfort Panel's bit-level shortcut was a runtime convenience that has not been re-implemented in the Unified object model.

Step-by-Step Diagnosis

1. Open the affected screen in the TIA Portal HMI editor.
2. Select the screen object whose property is not updating. In the Properties window, expand the relevant property (for example, Appearance > Background color or Visibility).
3. Confirm the property is bound to a tag of data type Word, Int, or UInt. Confirm the trigger configuration is set to Trigger bit with a selected bit number.
4. Open the HMI tag editor. Force the value of the tag to 1, then 2, then 4, then 8 using the HMI tag simulation table or the PLCSIM Advanced software.
5. Observe whether the property updates. If only the values 1, 2, 4, 8 produce a state change and 3, 5, 6, 7 do not, the runtime is in integer-evaluation mode. The trigger bit is recognized; it is the state selector that is missing.
6. Force the value to 0 (all bits cleared). The property should fall back to the default state or the initial property value.
7. Switch to the runtime diagnostic viewer (Control Panel > System > Diagnostics) and confirm the tag is being acquired. If the tag is not in the acquired-tags list, the connection is broken; fix that first before re-testing the dynamization.

Solution A: Value-Based Dynamization with Mutually Exclusive Bits

If the PLC writes only single-bit values (never two bits at the same time), the Unified value-based dynamization is the cleanest approach. Configure a state list with the values 1, 2, 4, 8, 16, 32, 64, 128 and assign the required appearance to each state. The PLC enforces mutual exclusion.

// TIA Portal - Value list configuration
Tag:    HMI_Tag_Color (Word)
Trigger bit: 0

States:
  Value 1    -> Color: Green       (status OK)
  Value 2    -> Color: Yellow      (status warning)
  Value 4    -> Color: Red         (status fault)
  Value 8    -> Color: Blue        (status manual)
  Value 16   -> Color: Gray        (status offline)
  Value 32   -> Color: Orange      (status maintenance)
  Value 64   -> Color: Purple      (status calibration)
  Value 128  -> Color: Cyan        (status test)

Add an interlock in the PLC so that writing a new state automatically clears the previous one. The example below uses SCL on an S7-1500 / S7-1200 controller:

// SCL - Mutually exclusive single-bit writes (S7-1500)
IF "i_WriteNewState" > 0 AND "i_WriteNewState" <= 8 THEN
    "DB_Status".HMI_ColorBits := 0;                              // clear all bits
    "DB_Status".HMI_ColorBits.%X0 := "i_WriteNewState" = 1;
    "DB_Status".HMI_ColorBits.%X1 := "i_WriteNewState" = 2;
    "DB_Status".HMI_ColorBits.%X2 := "i_WriteNewState" = 4;
    "DB_Status".HMI_ColorBits.%X3 := "i_WriteNewState" = 8;
END_IF;

This is the lowest-overhead solution: no scripts, no extra tags, and the property is updated by the runtime's native value-list evaluation. Recommended when the application owns the PLC code and the flags are guaranteed to be mutually exclusive.

Solution B: VBScript Bit-Mask Evaluation

When two or more bits can be active simultaneously, the value-based approach collapses because the integer representation no longer maps to a single state. The next option is a VB script that performs a bitwise AND against the mask of each bit and returns a state value that the dynamization list can resolve.

In WinCC Unified, attach a script function to the property's dynamization column. The runtime evaluates the function on every trigger change of the source tag and uses the return value as the state index for the value list.

' WinCC Unified - VBScript function for bit-mask color dynamization
Function Color_Bits(ByVal item)
    Dim wColor : wColor = item
    Dim nState : nState = 0

    If (wColor And 1)   <> 0 Then nState = 1   ' bit 0 - status OK
    If (wColor And 2)   <> 0 Then nState = 2   ' bit 1 - status warning
    If (wColor And 4)   <> 0 Then nState = 3   ' bit 2 - status fault
    If (wColor And 8)   <> 0 Then nState = 4   ' bit 3 - status manual
    If (wColor And 16)  <> 0 Then nState = 5   ' bit 4 - status offline
    If (wColor And 32)  <> 0 Then nState = 6   ' bit 5 - status maintenance
    If (wColor And 64)  <> 0 Then nState = 7   ' bit 6 - status calibration
    If (wColor And 128) <> 0 Then nState = 8   ' bit 7 - status test

    Color_Bits = nState
End Function

Pair the script with a value list in the dynamization column:

// Value list for the script-driven state tag
Value 0 -> Default (no color change)
Value 1 -> Color: Green
Value 2 -> Color: Yellow
Value 3 -> Color: Red
Value 4 -> Color: Blue
Value 5 -> Color: Gray
Value 6 -> Color: Orange
Value 7 -> Color: Purple
Value 8 -> Color: Cyan

Solution C: Restructure to One Int Tag per State Slot

The most portable and least error-prone approach is to remove the bit-packing entirely. Define one Int per state slot in the PLC data block, write the state index directly into each Int, and bind each Int to its own dynamization property. This is the pattern Siemens engineering recommends for screens with many status objects.

Each Int tag is bound to a single color or visibility dynamization with a clean value list. The PLC becomes the single source of truth for the state index, and the HMI simply maps an integer to a state.

// SCL - State write helper for 90 Int slots
FUNCTION "fbWriteStatus" : Void
VAR_INPUT
    i_ObjectIndex : Int;     // 1..90
    i_State       : Int;     // 0..8
END_VAR
VAR_TEMP
    s_Path : String;
END_VAR
BEGIN
    // Bounds check
    IF i_ObjectIndex < 1 OR i_ObjectIndex > 90 THEN RETURN; END_IF;
    IF i_State < 0 OR i_State > 8 THEN RETURN; END_IF;

    CASE i_ObjectIndex OF
         1: "DB_Status".StatusObject_01 := i_State;
         2: "DB_Status".StatusObject_02 := i_State;
         3: "DB_Status".StatusObject_03 := i_State;
        ...
        90: "DB_Status".StatusObject_90 := i_State;
    END_CASE;
END_FUNCTION

The tradeoff is PLC memory (180 bytes for 90 Int objects) and tag count in the HMI tag editor (90 tags instead of 1). On a Unified Comfort Panel with a recommended tag budget of several thousand tags, 90 tags is negligible. The runtime cost is zero script execution and zero bit-mask evaluation - the panel simply reads an Int and matches it to a state.

Migration Checklist from Comfort to Unified

1. Inventory all HMI tags that drive a Comfort Panel bit-level dynamization. In TIA Portal, use Project > Cross-references and filter for the dynamization property column. The output lists every tag bound to a property.
2. For each tag, decide: is the bit pattern truly mutually exclusive in the PLC, or can two bits be set at once? Read the PLC code, do not assume. If mutually exclusive, keep the Word and apply Solution A. If not, apply Solution B or C.
3. If the Comfort Panel used a 16-bit Word with 16 status flags, evaluate Solution C. The engineering cost is one data block edit plus 16 HMI tag bindings. The runtime cost is zero.
4. Confirm that trigger bits are still configured where the tag is acquired on a non-default cycle. In Unified, the standard acquisition cycle is 1 s; trigger-bit acquisition can be sub-100 ms if the PLC scan allows. Without a trigger bit, the property may update only once per second.
5. Verify that discrete alarms using the same Word tag still work after migration. The alarm subsystem evaluates trigger bits independently from the dynamization subsystem, so alarms typically continue to function without changes.
6. Test edge cases: all bits cleared, all bits set, individual bits toggled at 100 ms intervals, two bits toggled simultaneously.
7. Document the chosen solution for each affected tag in the project comments. Future maintenance engineers will need to know whether the value list is a state map, a script is decoding bits, or the PLC is sending raw state indices.

Performance and Limits on Unified Comfort Panels

Beyond the recommended tag count, the runtime's tag manager starts to drop updates on the panel. Beyond the VBScript evaluations per second threshold, script execution falls behind the trigger cadence and the panel shows stale data. Solution C is preferred for screens with more than 200 status objects because it removes script overhead entirely.

The 90 x 4 case (90 status objects with 4 color states each) is well within the budget for every Unified Comfort Panel model. The solution that scales best is Solution C - 360 Int tags, no scripts, no bit-masking, predictable behavior. For an S7-1500 with a 1 ms OB1 cycle, writing 360 Int values per second is negligible.

Verification Steps

1. Force a Word value of 1 in the HMI tag simulation table. Verify the bound property updates to the state assigned to value 1 (Solution A) or to the state returned by the script (Solution B).
2. Force a Word value of 5 (binary 0101, bits 0 and 2 set). With Solution A and a value list of 1, 2, 4, 8, the property falls back to the default. With Solution B, the script returns the priority bit's state. With Solution C, the bit-packed word no longer exists and the test is moot.
3. Toggle a bit at 100 ms intervals using a PLC flag pulse generator. Confirm the property updates within 200 ms on the panel.
4. Run the panel through a power-cycle and verify that the initial state of each property matches the PLC's initial value at startup. A common migration error is leaving the property's initial value at the TIA Portal default instead of binding it to the PLC's startup value.
5. Open the runtime diagnostic viewer and confirm no script errors are logged. If VBScript errors appear, the bit-mask function is being called before the tag has been acquired for the first time; add an initialization guard that returns the default state when the tag value is uninitialized.
6. Inspect the HMI tag's update time in the diagnostics viewer. The "Last update" timestamp should be within the trigger cycle of any PLC value change. A timestamp that is older than 1 s indicates the trigger bit is not firing.

Troubleshooting Matrix

Common Pitfalls and How to Avoid Them

Assuming the bit-level Comfort behavior carries over. The most common mistake is to migrate the project and assume the dialogs behave the same. They do not. Audit every dynamization property that uses a Word tag before commissioning the Unified Panel.

Using Real or DInt tags for status flags. The Unified runtime evaluates Real values as floating-point numbers. A list of 1, 2, 4, 8 will not match 1.0, 2.0, 4.0, 8.0 on all firmware versions because of precision handling. Use Int or Word for status flags and reserve Real for analog values.

Neglecting the initial value of the dynamization property. A Word tag with a startup value of 0 will leave the property at its initial value until the PLC writes a non-zero value. If the PLC starts in a fault state, the property may show the wrong color for several seconds after power-on. Bind the initial value of the property to a known safe state or force a value-list entry of 0.

Forgetting the trigger bit on a Word whose low byte changes. A Comfort Panel often used bit 0 as a global "any change" trigger for the entire Word. The Unified runtime does not auto-promote bit 0 to a global trigger. Configure the trigger bit deliberately: bit 0 for change on the low byte, bit 8 for change on the high byte, or a single dedicated "update" bit in the PLC.

Confusing the acquisition cycle with the dynamization cycle. The acquisition cycle is how often the HMI polls the PLC. The dynamization cycle is how often the runtime re-evaluates the value list. On the Unified runtime these are independent. A 1 s acquisition with a 100 ms dynamization will still leave the property stale for up to 1 s after a PLC change.

Related Siemens Documentation

• WinCC Unified - Configuration Manual - official configuration reference for the Unified runtime, dynamization model, and value lists.
• TIA Portal V18 Unified Help - integrated help portal for the V18 engineering environment.
• WinCC Unified - VBScript Reference - scripting language reference for the Unified runtime.
• SIMATIC Unified Comfort Panels Operating Instructions - hardware limits, performance budgets, and panel-class specifications.

FAQ