Resolving WinCC Comfort Stealth State in UDT Faceplate Animations

1. Problem Summary

A TP1500 Comfort panel running firmware V17 and configured in TIA Portal V18 Update 3 displays a transient red color on a symbolic I/O field inside an UDT-based faceplate. The red appearance is visible for less than 1 second and is not correlated with any real process fault. The animation variable is sourced from a UDT tag that the PLC never sets to 0, yet the HMI renders the "0 = fault" state. The PLC program is verifiably correct, the tag is configured as "output only" inside the faceplate, and both an HMI and PLC full rebuild fail to clear the symptom.

This phenomenon is referred to here as a stealth state: a brief, un-commanded visual transition that the engineer cannot reproduce by tracing the PLC logic. The root cause is not an HMI bug, not a WinCC Comfort defect, and not a faceplate configuration error. It is a classic read/write race condition between the PLC cycle and the HMI acquisition cycle.

2. Environment and Configuration

3. Root Cause: PLC-HMI Race Condition

The PLC programmer writes the status variable through a multi-step code pattern. A typical pattern looks like the following ST snippet (representative, not a quotation from the source project):

// Step 1: clear to "fault"
#statusWord := 0;

// Step 2: evaluate process and overwrite
IF #bPermissive_OK AND NOT #bFault_latched THEN
    #statusWord := 16#0001; // 1 = permissive OK
END_IF;

IF #bMotorRunning THEN
    #statusWord := 16#0002; // 2 = running
END_IF;

IF #bWarning THEN
    #statusWord := 16#0004; // 4 = warning
END_IF;

Even when the PLC is otherwise free to read the value, the cycle-time math is unforgiving:

• PLC OB1 cycle: 20 ms
• HMI acquisition: 500 ms
• PLC cycles inside one HMI sample window: 500 / 20 = 25 cycles

The HMI does not wait for a "stable" value. It requests the tag once every 500 ms and stores whatever the PLC presents at that moment. If the HMI request lands between the line that sets #statusWord := 0 and the next line that overwrites it with a non-zero constant, the panel renders red. The window is narrow (microseconds in the example), but with 25 PLC cycles per HMI sample and with thousands of such tags across many faceplate instances, the probability of at least one collision per minute is non-trivial.

This is exactly the situation described in the source case. The PLC trace tool cannot catch it because the trace function in TIA Portal records values at OB1 boundaries. The transient lives entirely inside one OB1 cycle and is overwritten before the next cycle completes, so the trace never observes it.

4. Why the Fault Is Invisible to PLC Traces

Many engineers first attempt to prove the bug does not exist by adding a TIA trace on the tag. The trace returns a clean, monotonically non-zero sequence. The conclusion "the PLC is innocent" is correct on a logical level but misleading on a physical level: the trace is a sampling instrument, and a sampling instrument can miss any transient that is shorter than its own sample period.

Three independent clocks govern the system:

The 500 ms HMI cadence is the bottleneck. Lowering it to 100 ms reduces the chance of capturing the transient by 5x, but also quadruples network load on the S7 connection. Raising it to 2 s increases the chance of a flash by 4x. The PLC cycle time is fixed by the user program and cannot be slowed down to solve the perception problem.

5. Diagnostic Procedure

Use the following steps to confirm the race-condition theory before applying a fix. Skipping this step leads to misapplied solutions (e.g., rebuilding the HMI project pointlessly).

1. Stop the PLC. Open TIA Portal online → "Go to STOP".
2. Force the tag to a non-zero value via a watch table. Use Modify with the value 1 or 2.
3. Run the HMI only (PLC in STOP, HMI in RUN). Watch the symbolic I/O field. If the red flash disappears, the bug is in the live PLC logic, not in the faceplate or the wiring.
4. Restart the PLC in RUN. Allow normal process activity. The red flash returns.
5. Add a temporary HMI tag that mirrors the suspect tag with a 100 ms acquisition period. If the 100 ms version flashes more often, the cause is a transient that the 500 ms window is sampling.
6. Insert a 1-second pulse on the tag in the PLC (e.g., IF "Clock_1Hz" THEN #statusWord := 0; END_IF;). The red flash on the HMI becomes observable at a fixed cadence, confirming that the HMI is genuinely rendering the value 0 when the PLC writes it.
7. Remove the pulse once the diagnosis is complete.

6. Solution 1: Restructure the PLC Write Logic

The most robust fix is to eliminate the transient at the source. Replace the "clear-then-overwrite" pattern with a single, deterministic assignment.

// Defensive single-pass assignment
#statusWord := 16#0000; // default to fault

IF #bWarning THEN
    #statusWord := 16#0004;
ELSIF #bMotorRunning THEN
    #statusWord := 16#0002;
ELSIF #bPermissive_OK AND NOT #bFault_latched THEN
    #statusWord := 16#0001;
END_IF;

The difference is subtle but critical: in the original pattern, the assignment to 0 is committed to the variable for a measurable microsecond before being overwritten. In the structured IF-ELSIF pattern, the compiler emits a single MOV instruction with a conditional source, and the variable never holds 0 unless all conditions are false.

For ladder logic, the equivalent is to use a single coil that is energized by parallel branches, rather than a reset coil followed by set coils.

7. Solution 2: Adjust the HMI Acquisition Cycle

If restructuring the PLC is not feasible (for example, the tag originates in a third-party library block that cannot be edited), the next-best fix is to desynchronize the HMI acquisition from the PLC cycle.

In TIA Portal, open the HMI tag properties and switch the acquisition mode from Cyclic in operation to Cyclic continuous, with a period that is not an integer multiple of the PLC cycle time. With a 20 ms PLC cycle, avoid 100 ms, 200 ms, 400 ms, 500 ms and 1000 ms. Use a value like 170 ms or 330 ms. The non-harmonic relationship reduces the probability that the HMI request lands on the same micro-window every cycle.

8. Solution 3: Add Fault State Latching on the HMI

If the tag legitimately transitions through 0 during start-up or during an internal sub-block evaluation, the HMI side can be hardened so that a brief red flash is never visible to the operator.

1. Open the faceplate in the TIA Portal HMI editor.
2. Locate the symbolic I/O field that is misbehaving.
3. In the Properties → Animations tab, change the background color animation to evaluate the tag on a debounced basis.
4. Add a hidden HMI tag that holds the last stable non-zero value, written from a script that filters out sub-100 ms excursions.

For step 4, the simplest implementation is an HMI VBScript scheduled on the 500 ms acquisition event:

' Filter stealth zeros out of the displayed value
Dim raw, displayed
raw = SmartTags("statusWord_raw")
If raw = 0 Then
    ' ignore, keep previous displayed value
    Exit Sub
End If
SmartTags("statusWord_displayed") = raw

Bind the faceplate animation to statusWord_displayed instead of the raw tag. The HMI now shows the last valid state whenever the PLC briefly returns to 0.

For a full reference on configuring the property animation, see the official TIA Portal documentation: Configuring property animation of the 'Bool' type (RT Professional) — TIA Portal V21 documentation.

9. Solution 4: Review In/Out Parameter Usage

If the faceplate consumes the status word through an InOut parameter of an instance DB, additional reading-side hazards can compound the race condition. Two official Siemens support entries address this:

• Entry 109476062 — Why is the value of an InOut parameter of an instance DB not displayed correctly?
• Entry 109478253 — How do you access InOut parameters of an instance DB in the user program?

Recommended action:

1. Inspect the FB that backs the faceplate. Identify any parameter declared as InOut that flows into the status word.
2. If the parameter is used purely for display (the HMI only reads it), change it to a Input parameter. The PLC cycle is then guaranteed to settle the value before the next HMI read.
3. If the parameter is genuinely bidirectional, wrap the read in a temporary copy at the top of OB1 and pass the copy to the faceplate. This guarantees the HMI always reads a consistent snapshot.

10. Solution 5: Full Rebuild and Re-test

After applying one or more of the solutions above, perform a full rebuild of both the PLC and the HMI project. The order is critical:

1. Compile the PLC program (Project → Compile → Software (rebuild all)).
2. Download the PLC hardware configuration and software to the CPU.
3. Compile the HMI project (Project → Compile → HMI (rebuild all)).
4. Download the RT to the TP1500 Comfort panel.
5. Perform a complete panel restart from the loader.

A partial download or a delta compile can leave stale faceplate versions in the panel image, which produces animation glitches that look similar to the stealth state but have a different root cause (corrupt faceplate instance cache).

11. Verification Steps

12. Troubleshooting Matrix

13. Prevention Checklist

• Establish a coding standard that forbids the var := 0; var := final; pattern in ST, FBD, and LAD.
• Configure all HMI tags with a non-harmonic acquisition period relative to the PLC cycle.
• Use Input parameters on faceplate FBs for read-only data; reserve InOut for truly bidirectional data.
• Set the UDT start value to a valid non-zero state to avoid start-up red flashes.
• Document the HMI acquisition period and the PLC cycle time on the HMI tag comment for future maintenance engineers.
• When commissioning a new faceplate, force a 1-second pulse on every animated tag and confirm the HMI behavior is intentional before sign-off.

14. Frequently Asked Questions