Resolving WinCC Faceplate ChangeValue Event Not Firing in TIA

Problem Overview

The "Change in value" (ChangeValue) event on a Siemens WinCC faceplate property is a long-standing source of intermittent failures in TIA Portal projects. Engineers configure the event in the faceplate type, bind the property to a PLC tag (HMI tag pointing to a controller address), and expect the configured script or function list to execute every time the value changes. In many real-world configurations—particularly with S7-1500 CPUs paired with Comfort Panels running WinCC RT Advanced or Professional—the event silently fails to fire, leaving the operator screen out of sync with the controller, scripts not executing, and dynamic visualization elements frozen at their last value.

The most commonly reported symptoms are:

• Event fires when a local I/O field on the same faceplate writes the value, but does not fire when the value is updated by another faceplate instance or by a controller-side write.
• Event fires in PLCSIM / WinCC simulation but not on the real TP1200 Comfort / TP1500 Comfort / TP700 Comfort panel.
• Event fires once after compilation/download but never again until the screen is re-opened.
• Event does not fire at all, even though the HMI tag value is verifiably updating on the screen.

None of these symptoms produce an error code, alarm, or diagnostic buffer entry. The issue is behavioral, not logged, which makes the root cause hard to locate without a structured diagnostic approach.

Affected Versions, Panels, and CPUs

The ChangeValue event anomaly has been reproduced across a wide range of TIA Portal versions, both in legacy WinCC RT Advanced / Professional and in modern WinCC RT Unified projects. The following matrix summarizes confirmed field behavior:

Root Cause Analysis

There are three distinct root causes that produce this symptom. They are easy to confuse because the runtime behavior looks identical from the operator's point of view, but each requires a different fix.

Root Cause 1: Internal-Tag Loopback Safety Mechanism

WinCC Runtime contains a built-in safety mechanism that suppresses ChangeValue events when the value change originates from another internal HMI tag whose own ChangeValue event feeds back into the cycle. The purpose of the mechanism is to prevent scripts from recursively calling each other in tight loopback chains, which historically caused Runtime freezes and memory growth.

Consider the following configuration, which the safety mechanism blocks:

• Internal HMI tag HMI_Tag_01 has a "Change in value" event that writes to internal tag HMI_Tag_02.
• Internal HMI tag HMI_Tag_02 has a "Change in value" event that triggers a script.

When HMI_Tag_01 changes, the engine updates HMI_Tag_02 internally, but the script on HMI_Tag_02 is not executed because the change is being driven from another internal tag's event chain.

Root Cause 2: Cross-Instance Faceplate Update Timing

The most common failure mode reported in the field is the cross-instance case: two faceplate instances of the same faceplate type share a tag. Faceplate A writes the tag through a button or I/O field, and Faceplate B is expected to react to the new value via its ChangeValue event.

On a Comfort Panel running WinCC RT Advanced V14 SP1, Faceplate B's screen refresh happens, the I/O field inside Faceplate B displays the new value, but the event script does not execute. This is a documented behavioral inconsistency in the Advanced faceplate engine: when the value change is propagated from a sibling faceplate on the same screen, the event dispatcher treats it as a "redundant update" and skips the trigger.

The distinguishing test for this root cause is simple: change the value directly through an I/O field on the same faceplate and the event fires; change the value from another faceplate instance and the event is skipped.

Root Cause 3: Acquisition Cycle vs. Event Dispatch

HMI tags are sampled according to their configured acquisition cycle. If the PLC tag changes twice within a single acquisition cycle, WinCC only sees the last value and only one ChangeValue event is dispatched. If the change is so brief that it is sampled, written to the screen property, and re-sampled before the event dispatcher has registered the property as "changed," the event is dropped. This is the "timing error" symptom that has been observed particularly on heavily loaded Comfort Panels with multiple faceplate instances.

For S7-1500 connections the default acquisition cycle is 1 s. For direct keys or fast process values, set the cycle to 100 ms or use "Cyclic continuous" mode to ensure no transitions are missed.

Symptom Diagnostic Matrix

Use the following decision matrix to identify the active root cause before applying a fix:

Workarounds and Solutions

Workaround A: Use an External (Controller-Bound) Tag

When the source of the value change is a PLC tag, ensure the HMI tag is configured as an external tag pointing to the controller address, not as an internal tag whose value is set from another internal tag's event. This bypasses the loopback safety mechanism without disabling it project-wide.

1. Open PLC tags > Show all tags.
2. Locate the tag that drives the faceplate property.
3. Confirm the "Connection" column points to the S7-1500 / S7-1200 CPU (e.g., S7_Connection_1).
4. If the tag is "Internal", delete it and re-add it as an external tag on the appropriate DB or process image address.
5. Rebuild the project and re-download to the panel.

Workaround B: Function-with-Parameters Pattern

When the trigger must cross faceplate instance boundaries on a Comfort Panel, wrap the value-change logic in a project-wide function and pass the faceplate interface variables as parameters. The function is then called from the I/O field's "Change in value" event. This pattern is far more reliable than placing a script directly on a faceplate property.

// VB-style script invoked from I/O field ChangeValue event on the faceplate property
// 'FaceplateProperty' is a faceplate interface property of type Int
// 'FunctionName' is a project function defined under "Scripts > Project Functions"

Sub OnChange(ByVal item)
    Dim vCurrent
    vCurrent = item.OutputValue
    Call FunctionName(vCurrent)
End Sub

The function then receives the value as a parameter, not as a direct tag read, which decouples it from the faceplate's internal tag event chain.

Workaround C: Reduce Acquisition Cycle

1. Open the HMI tag's properties in the project tree.
2. Under Acquisition mode select "Cyclic continuous" instead of "Cyclic in operation".
3. Set the Acquisition cycle to 100 ms (or shorter if the panel CPU can sustain it).
4. For very fast signals, mark the tag as a "Limit value monitoring" tag with a small deadband so that equal consecutive values do not produce redundant events.

Workaround D: Use a Positive-Edge Tag

For "value changed" notifications where only the transition matters, expose a Boolean "Pulse" tag from the PLC that the controller sets to TRUE for one cycle on the event. The Comfort Panel's ChangeValue event will fire reliably on every rising edge of the pulse, regardless of the underlying value being constant.

// Structured Text in the S7-1500 - generate a 100 ms pulse on value change
IF ActualValue <> LastValue THEN
    Pulse := TRUE;
    LastValue := ActualValue;
END_IF;

// Timer to clear the pulse after one scan / 100 ms
TON_Pulse(IN := Pulse, PT := T#100ms);
IF TON_Pulse.Q THEN
    Pulse := FALSE;
END_IF;

On the HMI side, the faceplate listens for the ChangeValue event on Pulse (Boolean), not on the integer process value.

Modern Alternative: Interface Events in WinCC RT Unified

For projects targeting TIA Portal V17 or later and running on Unified Comfort Panels, MTP devices, or PC Runtime, the legacy property-level ChangeValue model is replaced by interface events declared on the faceplate type itself. Interface events are first-class members of the faceplate's interface and are interconnected to instance-specific functions of the function list or to scripts on each faceplate instance.

Official reference: Configuring an interface event in the faceplate type (RT Unified) and the worked Example: Configuring and using an interface event (RT Unified).

Declaring an Interface Event

1. Open the faceplate type in the editor.
2. Open the Interface tab in the Inspector window.
3. Under Events, click the plus icon to add a new event, e.g. ValueChanged.
4. Declare the event signature (parameters, if any) in the same way as a PLC function block event.
5. Inside the faceplate, on the property that should raise the event, configure Properties > Events and select the interface event from the dropdown to "raise" it.

Interconnecting the Interface Event to an Instance

1. Place an instance of the faceplate on a screen.
2. Select the instance and open Properties > Events in the Inspector.
3. Under the ValueChanged event, attach a function list or a JavaScript-style script.
4. Use the Inspector to map the interface event parameters to the function arguments.

This mechanism is robust because the event is raised by the faceplate type itself, not by the property's underlying HMI tag. It is not subject to the legacy acquisition-cycle or loopback-safety constraints.

Verification Procedure

After applying any workaround, verify the fix with the following sequence:

1. Compile the project (Project > Compile > Software (rebuild all)).
2. Start the WinCC Runtime simulator and load the screen containing the faceplate.
3. Trigger a value change three different ways:
   • Direct write from a local I/O field on the same faceplate.
   • Write from a sibling faceplate instance on the same screen.
   • Write from the PLC (force the tag in PLCSIM or use a watch table on the real CPU).
4. Confirm the script executes in all three cases. Add a temporary HMIRuntime.Trace("Event fired: " & value) call to confirm dispatch.
5. Open the HMI diagnostic screen (if available) and verify no dropped events in the "Events" log.
6. If the test fails on the simulator but succeeds on the panel, you are looking at an acquisition-cycle issue (RC3), not a logic issue.

Best Practices and Field-Engineering Recommendations

• Prefer interface events over property-level ChangeValue for any new project, especially on Unified Runtime. They are first-class citizens of the faceplate contract and survive version upgrades cleanly.
• Decouple logic from faceplate properties using project functions. The function-with-parameters pattern (Workaround B) is portable across TIA Portal versions and across RT Advanced / RT Unified.
• Never chain internal HMI tags in a way that one tag's ChangeValue event writes to another internal tag. If you must chain logic, use a single script on the source tag and use local script variables, not additional HMI tags.
• Document the acquisition cycle in the HMI tag's comment field. This makes future debugging dramatically easier.
• For S7-1500 projects, prefer symbolic addressing with optimized DBs and the standard 100 ms HMI acquisition cycle. Symbolic addresses survive download changes far better than absolute addresses.
• For Unified PC Runtime, the event dispatcher is separate from the tag polling; events fire as soon as the script raises them, not on the acquisition cycle. This is a major reason why migrating legacy faceplates to Unified often "fixes" the symptom automatically.
• For SIMATIC CPG Template users, the template's faceplate library includes proven interface-event patterns that can be used as a reference for new faceplate designs.

Related Siemens Documentation

• TIA Portal V20 Help: Configuring an interface event in the faceplate type (RT Unified)
• TIA Portal V20 Help: Example - configuring and using an interface event (RT Unified)