Implementing Timed Screen Changes on Siemens Comfort HMI Panels

Overview

Siemens SIMATIC Comfort Panels (TP1200, KTP1200, TP1500, TP1900, TP2200 and the Mobile Panel 277F IWLAN) running WinCC Comfort or WinCC Advanced in TIA Portal do not expose a native timer object inside the HMI runtime. When a screen must advance automatically after a fixed dwell time—typically 10 s on a start screen, splash, or rotating banner—engineers usually reach for a PLC-side timer, but the screen can run the entire sequence locally using the SimulateTag system function and the value-change event of an internal tag. The technique eliminates PLC round-trips, requires no PLC code, and keeps working when the PLC is stopped, disconnected, or being commissioned.

The pattern was first documented for TIA Portal V13 SP1 on a TP1200 Comfort and remains valid in every subsequent release through V19 because the screen-event API and the SimulateTag runtime function have not changed since the Comfort Panel line was introduced.

Prerequisites

• Hardware: any SIMATIC Comfort Panel (typical catalog number family 6AV2 124- for the 12-inch TP/KTP family). The same recipe applies to TP1500, TP1900, and TP2200 Comfort variants.
• Engineering software: TIA Portal V13 SP1, V14, V14 SP1, V15, V15.1, V16, V17, V18, or V19 with WinCC Comfort or WinCC Advanced installed.
• Panel image: Comfort Panel image matched to the TIA Portal major version (e.g., V16 image for V16 projects). Mismatched images refuse to download and report error 1902.
• Project state: at least two screens already configured in the HMI screen tree—the start screen and the destination screen.
• Project access: read/write permission on the engineering station and, where the panel enforces secure projects, the corresponding HMI device certificate.
• Runtime state: the panel should be in Transfer or in normal Online mode with the project running; no special add-ons are required because SimulateTag is a core system function.

Why the HMI Runtime Has No Native Timer

The WinCC Comfort/Advanced runtime is intentionally event-driven. Every visual reaction is bound to an event source:

• Screen events: Loaded, Cleared, Focus, Leave.
• Tag events: Value change, Upper limit violated, Lower limit violated.
• User events: Press, Release, Click.
• System events: connection loss, recipe events, alarm events, scheduled tasks (only on PC Runtime).

There is no Tick or Timer event in the panel firmware. The scheduler in WinCC Runtime PC can run jobs by time-of-day, but the embedded Comfort Panel firmware does not, so the only practical way to drive a cyclic trigger from inside the HMI is to use SimulateTag, which writes a value into an HMI tag every N × 200 ms. The tag's own value-change event then becomes a periodic event source that the screen-change logic can react to.

Architecture: SimulateTag as a Soft Clock

The flow on the start screen looks like this:

1. The runtime fires the Loaded event of the start screen.
2. The screen event invokes the SimulateTag system function, passing the HMI tag, a cycle count, and the value to write.
3. Every cycle × 200 ms, the runtime overwrites the tag with the configured value.
4. The tag's Value change event fires each time the value toggles.
5. The Value change event is bound to the ActivateScreen system function with the destination screen number.

Inline styled SVG of the runtime flow:

Step-by-Step Configuration

Step 1 – Declare the Cyclic Tag

Open the HMI tag table (HMI tags → Default tag table or a user-defined table) and create a new tag with the following properties. The tag must live in the HMI memory (not the PLC), because SimulateTag writes only to local HMI tags.

The acquisition cycle of the tag determines how often the runtime polls for changes. If it is coarser than the SimulateTag cycle, value-change events will be missed. The default 200 ms value is the safe choice for any cycle setting up to 50.

Step 2 – Bind SimulateTag to the Loaded Event of the Start Screen

1. In the project tree, open the start screen (for example Screen_1).
2. In the properties pane select Events.
3. Expand the Loaded event group.
4. Click the plus icon and add a new function call.
5. From the system function list select SimulateTag.
6. Wire the parameters as follows:

   Parameter	Value
   Tag	HMI_ScreenTimer
   Cycle	50 (50 × 200 ms = 10 000 ms)
   Value / bit pattern	TRUE toggling, or an alternating 0/1 pattern, depending on firmware dialog

The Loaded event fires once every time the runtime opens the screen, so the timer automatically restarts whenever the user returns to Screen_1.

Step 3 – Trigger the Screen Change on Value Change

1. Stay on the same screen properties and switch to the Events view of the tag, not the screen.
2. In the HMI tag table, select HMI_ScreenTimer and open the Events tab.
3. Add a function on Value change.
4. Select the ActivateScreen system function.
5. Set the target screen number (e.g., 2 for Screen_2) or browse to it by name.

On the very first toggle written by SimulateTag, the runtime loads the destination screen. Because SimulateTag keeps writing, you typically want the destination screen to call StopTagSimulation on its own Loaded event so that the source tag stops oscillating in the background.

Cycle Parameter Reference

The cycle argument is expressed in units of 200 ms. The Comfort Panel firmware accepts a range of 1 to 255; values above 100 are uncommon but valid for minute-scale dwell times.

Verification Procedure

After compiling and downloading the project, perform these checks before declaring the screen change complete.

1. Start the runtime and confirm Screen_1 is the initial screen. Use Project → Properties → Runtime → Start screen to verify.
2. Open the HMI tag online monitor (Online → Tag simulation / Monitor) and watch HMI_ScreenTimer toggle at the expected interval.
3. Time the interval with a stopwatch from the moment the screen opens. The value-change event should fire near the requested dwell time; ±200 ms is acceptable due to acquisition jitter.
4. Confirm Screen_2 loads automatically.
5. From Screen_2, return to Screen_1 (e.g., via a button calling ActivateScreen "Screen_1") and confirm the timer restarts.
6. Cycle power on the panel and verify the timer runs without a PLC being online.

Alternative Implementations

When the SimulateTag technique is not appropriate (for example because the project is later migrated to WinCC Runtime Professional on a PC, where different system functions apply), use one of the alternatives below.

Troubleshooting Matrix

Edge Cases and Field Notes

Multiple timer screens. If more than one screen uses a timed jump, give each its own internal tag (for example HMI_SplashTimer, HMI_DemoTimer) so the cycles do not interfere. Sharing one tag across multiple Loaded events causes only the most recently loaded screen's cycle to be honored, because SimulateTag is a singleton-style operation per tag.

Stopping the simulation. Call StopTagSimulation on the destination screen's Loaded event to free the simulated tag. This avoids drift in tag acquisition and prevents the tag from oscillating forever in the background, which can affect polling performance on large projects.

Performance impact. Comfort Panels update tag values in the cyclic OB1 of the runtime. One SimulateTag-driven tag adds negligible load (well under 0.1 % CPU on a TP1200). Avoid driving more than ~20 simultaneous simulated tags on the same panel; beyond that, screen refresh latency can become visible at 100 ms and above.

Migrating to WinCC Unified. Comfort Panels do not migrate directly to WinCC Unified; Unified Panels (MTP/MTP Pro series) use a different system function set. SimulateTag is replaced in Unified by JavaScript-based timers in the screen controller. Treat this article as valid only for Comfort Panels (WinCC Comfort/Advanced).

Security. If the project enforces user administration, the auto-screen-change will still run when the user logs out—screen events are not user-scoped. If that is undesirable, bind ActivateScreen on the value-change event to a screen guarded by a permissions check, or wrap the logic in a custom function that evaluates the current user role before jumping.

Tag types. Bool, Int, and Word tags all work with SimulateTag. Use Bool for the smallest overhead. Real tags are supported but the value pattern (alternating between two reals) is harder to interpret when monitoring.

Firmware and Software Compatibility

• Tested on TP1200 Comfort running image V13 SP1, V14, V15.1, V16, V17, V18.
• SimulateTag behavior is unchanged from firmware V13 SP1 onward.
• Engineering side: any TIA Portal ≥ V13 SP1 with WinCC Comfort or WinCC Advanced.
• WinCC Basic (used for KTP400 Basic and other Basic Panels) does not include SimulateTag. Migrate to Comfort hardware or use a PLC-side timer.

FAQ