Creating Modal Operator Message Popups in WinCC V7 and WinCC Unified

Operator-driven confirmations are a recurring requirement on HMI/SCADA systems. The operator must acknowledge a state change (recipe select, valve open, motor start) before the PLC executes the action, and the runtime must block all background input until the operator commits or cancels. This article documents the canonical approach in Siemens WinCC for both the classic V7/SCADA line and the TIA Portal-based WinCC Unified line, and shows how to wire the popup to tag bits, events, and screen-window controls so that the underlying process screens are fully locked while the dialog is on top.

1. Overview of the Two Popup Models

WinCC exposes two structurally different popup mechanisms. Selecting the right one determines which system functions, scripting language, and tag types you can use.

The Siemens entry point for Unified is the scripting example Opening and closing a screen in a pop-up window (RT Unified). The same call surface also covers the classic OpenScreenInPopup / ClosePopup pattern used in WinCC V7 since V7.3.

2. Prerequisites

1. Engineering: TIA Portal V17, V18, V19, V20, or V21 for Unified; WinCC V7.4 SP1 or later for the classic line. V17+ is recommended for the latest OpenScreenInPopup signature changes.
2. Runtime: WinCC Runtime Unified V17+ (PC or Comfort Panel) or WinCC RT Professional / WinCC V7.x runtime license.
3. PLC connectivity: A configured HMI connection to the S7-1500/1200/300/400 or a third-party controller with a tag mapping that exposes the operator-request bits.
4. Screen: A separate faceplate or screen for the operator message (e.g. Popup_OperatorMessage) – do not embed the prompt inside the process screen, or the modal layer logic becomes ambiguous.
5. Tags (minimum set):
   • OP_Trigger_Word (Word) – the message ID or selection index written by the AS.
   • OP_Request (Bool) – request line set by the AS, reset by the HMI once the operator commits.
   • OP_Result_Word (Word) – HMI→AS result register (Acknowledge / Cancel / Button-1..N).
   • OP_Popup_Active (Bool, internal) – HMI-side flag that drives the screen-window visibility.

3. Popup Architecture in WinCC

The general flow is identical on both lines. The AS sets a request, the runtime detects it on a scheduled event or a tag change, opens a popup that visually covers the process screen, locks input on every background control, waits for operator action, writes the result back to the AS, and closes itself.

3.1 Sequence Diagram

3.2 Why the Background Must Be Locked

The original requirement – "I should not be able to click on the background buttons" – is the defining property of a modal dialog. In WinCC Unified, the runtime handles this for you when you call OpenScreenInPopup() with a modal flag. In WinCC V7, there is no built-in modal layer; you must implement it with a full-screen invisible button on top of the process picture, or by using the layer system. Both patterns are covered below.

4. Step-by-Step: WinCC Unified (TIA Portal V17–V21)

4.1 Build the Popup Screen

1. In the TIA project tree, expand HMI → Screens and add a new screen, e.g. Popup_OperatorMessage.
2. Insert a Text Field bound to a multilingual text list keyed on OP_Trigger_Word so the same popup screen shows every operator message.
3. Insert two or more Buttons (e.g. Acknowledge, Cancel, plus optional option buttons). Place them in the lower third of the screen.
4. Set the screen's Window Properties → Position to a fixed centered position. Width/height are part of the OpenScreenInPopup call.

4.2 Configure the Trigger Event

Open the Scheduler or any screen's Events → Tag value change for OP_Request and attach a ValueChanged event to a JavaScript function:

// Script attached to OP_Request → ValueChanged
import * as UI from "HMIRuntime.UI";

export function OnOpRequestChanged(tag) {
    if (tag.Value === true && Tags("OP_Popup_Active").Read() === false) {
        Tags("OP_Popup_Active").Write(true);

        UI.OpenScreenInPopup("Popup_OperatorMessage", {
            screenName: "Popup_OperatorMessage",
            width: 480,
            height: 240,
            modal: true,            // blocks background input
            headerVisible: true,
            title: "Operator Action Required",
            backgroundColor: 0xFFEEEEEE
        });
    }
}

4.3 Wire the Buttons

Each button's Click event writes a unique code into OP_Result_Word, clears the request, and calls ClosePopup:

import * as UI from "HMIRuntime.UI";

export function OnAcknowledge_Clicked() {
    Tags("OP_Result_Word").Write(1);
    Tags("OP_Request").Write(false);
    Tags("OP_Popup_Active").Write(false);
    UI.ClosePopup("Popup_OperatorMessage");
}

export function OnCancel_Clicked() {
    Tags("OP_Result_Word").Write(99);  // 99 = cancel
    Tags("OP_Request").Write(false);
    Tags("OP_Popup_Active").Write(false);
    UI.ClosePopup("Popup_OperatorMessage");
}

4.4 PLC-Side Acknowledgement

The AS must read OP_Result_Word, react to the code, and then either keep the request low (normal flow) or set a follow-up code. Reset the request only after the AS has read the result, otherwise the RT can fire the popup twice in quick succession.

5. Step-by-Step: WinCC V7 / WinCC Professional (Classic)

5.1 Use OpenScreenInPopup in VBS

Since WinCC V7.4, the runtime exposes HMIRuntime.BaseScreen.OpenScreenInPopup. The signature in VBS is:

Sub OnClick_Trigger()
    Dim sPictName, sPopupName, lWidth, lHeight
    sPictName  = "Main_Process.PDL"
    sPopupName = "Popup_OperatorMessage.PDL"
    lWidth  = 480
    lHeight = 240

    ' Opens the popup; second arg = modal flag (1 = yes)
    HMIRuntime.BaseScreen.OpenScreenInPopup sPictName, 1, sPopupName, lWidth, lHeight
End Sub

The popup window name is generated by the runtime and returned through the FindChildByName / GetParentWindow interface. Close it with:

Sub OnClick_Close()
    Dim objPopup
    Set objPopup = HMIRuntime.ActiveScreen.FindChildByName("PopupWindow_0")
    If Not objPopup Is Nothing Then
        objPopup.Close
    End If
End Sub

5.2 Manual Modal Layer (V7.0–V7.3)

For older projects that cannot use OpenScreenInPopup, build a modal layer manually:

1. Place a transparent full-screen rectangle on layer 0 of the process picture.
2. Bind its Visible property to OP_Popup_Active.
3. Place the popup picture in a Picture Window on layer 10. Layer 10 is above the transparent rectangle on layer 0 only if the rectangle is below it; the picture window therefore intercepts all clicks first.
4. Disable every button on the process picture while OP_Popup_Active = 1 by adding a script on the Click event: If HMIRuntime.Tags("OP_Popup_Active").Read Then Exit Sub.

6. Modal Behavior and Screen Locking

Two design rules apply regardless of runtime:

1. Source of truth lives in the PLC. The HMI reflects OP_Request; the PLC owns the lock. This keeps multi-client / web-client deployments in sync.
2. Disable, do not just hide. A button set to Invisible while the popup is up can still receive the click on a thin invisible border, producing phantom actions. Use Enabled = 0, or – in Unified – rely on the modal flag.

7. Result Word Encoding

A single Word tag carries the operator's reply. Encoding is application-specific, but a consistent layout simplifies PLC logic.

8. Verification

Before sign-off, exercise the dialog with the following checks on the real runtime, not just the simulator:

1. Modal lock test: Set OP_Request = 1 from the PLC. While the popup is visible, attempt to click a button on the underlying process screen. The button must not trigger any tag change.
2. Multi-popup test: Trigger the same request twice within 200 ms. The runtime must not stack two popups; the second trigger must be ignored while OP_Popup_Active = 1.
3. PLC reset test: With the popup open, force OP_Request = 0 from the PLC. The popup must close (idempotent) and OP_Result_Word must remain 0 (operator did not confirm).
4. Loss of connection: Disconnect the HMI connection. The popup should time out after the configured retry count and the AS should fall back to its default (typically Cancel).
5. Multilingual test: Switch runtime language. The popup text must follow the active language, not the engineering default.
6. Audit trail: Each Acknowledge must produce one alarm/event in the WinCC Alarm Control. Verify with the operator log filter.

9. Troubleshooting Matrix

10. Field-Commissioning Notes

• Update cycle: For critical operator messages, set the cycle of OP_Request to 250 ms on the connection. Higher cycle values delay the popup by up to one cycle and confuse operators into clicking twice.
• Picture window reuse: A single Popup_OperatorMessage screen serving many message IDs keeps the engineering footprint small but increases the text-list size. Beyond ~50 distinct messages, split into role-specific popups (e.g. Popup_Recipe, Popup_Motor, Popup_Valve).
• Auditing: Configure an alarm class for operator actions with a retention of at least 30 days; many regulated industries (food, pharma) require 1 year.
• Performance: On a Unified Comfort Panel MTP1500, expect 50–80 ms to draw the popup from the moment the tag change fires. On a PC runtime, this drops to < 20 ms.
• Re-entrancy: If your process can raise a second request while the first popup is still open (e.g. motor start while a recipe is being confirmed), buffer the requests in a small queue on the AS side, not in the HMI. The HMI is a single-threaded UI; the AS can sequence.

11. Related Siemens Resources

• Opening and closing a screen in a pop-up window (RT Unified) – TIA Portal Help V21
• Siemens FAQ 24325381 – How do you generate user-defined operator input messages in WinCC?
• Siemens FAQ 25166621 – Trigger an additional operator input message when a message is acknowledged

FAQ