WinCC Unified Faceplates: Pop-up, Interface, V18+ Features

Siemens WinCC Unified (TIA Portal V16 onward) introduced a redesigned HMI engineering model centered on reusable faceplates for Unified Comfort Panels and WinCC Unified PC. Faceplates are centrally stored display and operating objects that can be instantiated many times in a project, parameterized per instance, and edited in a single place. Since V16, the feature set has grown substantially: V17 added screen-object-based creation and parent relative pop-ups, V18 added trends and alarm views inside the faceplate, V19 added dynamic (multiplexed) interface binding, and V20/V21 continued to expand scripting and interface behavior. This reference covers configuration from V16 through V21, including tag/property interfaces, pop-up windows, the HMIWindowFlag byte, and the runtime scripting patterns used in the field.

1. WinCC Unified Faceplate Overview

Faceplates are user-defined groups of display and operating objects that are stored, managed, and edited centrally inside a TIA Portal Unified project. They are not simply operation windows. The defining characteristic is reuse: a single faceplate type can be instantiated in many positions on many screens, and every instance inherits the central edit. Instance-specific differences are exposed only through the two declared interfaces.

WinCC Unified is the HMI engineering target for:

• Unified Comfort Panels (e.g., MTP700 Unified, MTP1000 Unified, MTP1200 Unified, MTP1500 Unified, MTP1900 Unified, MTP2200 Unified) running firmware from V16 onward.
• WinCC Unified PC (SCADA runtime on Windows) for V16, V17, V18, V19, V20, and V21 projects.

WinCC Unified is a separate runtime from WinCC Advanced / WinCC Professional. The two product lines use different tag-prefix mechanics, different scripting APIs, and a different VBScript/JavaScript boundary. Faceplates in Unified are always rendered by the Unified runtime, not by the older WinCC Comfort engine.

2. Faceplate Project Location: V16 vs V17 and Later

The editor window itself is identical across versions; only the navigation changed. The Unified Faceplate types node in V16 was merged into the unified Project Library model in V17 so that the same library workflow could be used for HMI faceplates, PLC user data types, and styles.

3. Faceplate Interface Tabs: Visualization, Tag Interface, Property Interface

Every Unified faceplate exposes three configuration tabs in the editor. Each tab is a strict contract: changing the contract on the type updates every instance in the project.

3.1 Visualization Tab

The Visualization tab is the faceplate's graphical editor. It behaves like a screen, but not every screen control is allowed inside a faceplate. The allowed control set is the subset that can be parameterised through the tag/property interfaces. JavaScript snippet support is enabled in the faceplate context, but the available snippets are limited to faceplate-safe categories such as HMIRuntime, Screen, and Tags.

3.2 Tag Interface

The Tag Interface declares HMI/PLC tag references that the faceplate instance binds to. Internally, the tag is consumed as a faceplate-internal variable. Externally, the consumer (a screen, another faceplate, or a pop-up caller) wires the interface to a real tag or to a nested faceplate interface.

At the call site, the Tag Interface is surfaced in the faceplate instance properties under Miscellaneous → Interface. Each declared tag appears as a row you can wire to a real tag, a constant, or another faceplate interface.

3.3 Property Interface

The Property Interface exposes faceplate internal properties that the caller can override. The two supported property types are Color and Resource list (which covers text lists and graphic lists). Colors drive the faceplate palette; resource lists drive text list and graphic list multiplexing without scripting.

At the call site, the Property Interface is also surfaced under Miscellaneous → Interface, but on a separate sub-section from the tag interface, so you can tell at a glance which fields are tag values and which are styling/text list values.

4. Creating a Faceplate from Screen Objects (V17+)

Starting with TIA V17, you can promote any group of screen objects to a faceplate type without rebuilding it from scratch.

1. Open the screen that contains the objects you want to reuse.
2. Multi-select the objects. Use rectangular selection (mouse drag) or Ctrl+click for individual selection.
3. Right-click the selection and choose Create faceplate.
4. Confirm the faceplate name and the destination in Project library → Types.
5. Open the new faceplate type. The Tag Interface and Property Interface will be pre-populated with candidates based on tag bindings the objects already had.

Only include objects that are genuinely reusable. Decorative borders, screen-specific navigation, or one-off label text are not good faceplate candidates; they should remain on the calling screen and not be promoted.

5. Calling a Faceplate as a Pop-up Window

From V17, a faceplate instance can be opened in a pop-up window directly from a screen event without a separate screen window definition. The most common pattern is a button Click event that fires a JavaScript snippet.

5.1 Required Snippet Structure

Use the snippet category HMIRuntime → Screens → Open faceplate in runtime. The first generated line is the parameter forwarder; the remaining lines configure the faceplate type, the pop-up position, and the window flags.

// Parameters (first line) — must match the faceplate type's Tag/Property Interface
let parameters = {
    Tag1:        { Tag1 },          // wrap tag values in { }
    Property1:   Property1          // properties are passed without { }
};

// Open the faceplate instance as a pop-up
HMIRuntime.Screens.OpenFaceplateInPopup(
    "MyFaceplateType",               // faceplate type name
    "MyInstance",                    // unique instance name
    parameters,
    left, top,                       // pixel offset, or use parent-relative
    HMIWindowFlag                    // combined bitmask (see Section 6)
);

5.2 Closing vs Hiding a Pop-up

Since V17 you can choose to close a pop-up faceplate (deleting the instance and freeing its tag subscriptions) instead of only hiding it. Closing is preferred for memory and CPU; hiding is preferred when the pop-up re-opens frequently and you want to preserve state. The new behavior is exposed through the corresponding snippet category for closing, which removes the instance cleanly.

6. HMIWindowFlag Parameters and System Constants

The HMIWindowFlag parameter on OpenFaceplateInPopup is a single byte where each bit controls a window attribute. You can pass either a numeric bitmask or, more readably, a system constant expression combined with the bitwise OR operator |.

The full system constant list exposed in the TIA Portal selection list is:

• None
• ShowCaption
• ShowBorder
• AlwaysOnTop
• CanSize
• CanMove
• CanMaximize
• CanClose
• AlwaysInParent

6.1 Numeric Bitmask Example

// Show border + Show caption + Can close = 2 + 1 + 64 = 67
let flags = 2 | 1 | 64;
HMIRuntime.Screens.OpenFaceplateInPopup(
    "MyFaceplateType", "MyInstance", parameters,
    200, 150, flags
);

6.2 System Constant Example

// Same result, easier to read and document
let flags = ShowBorder | ShowCaption | CanClose;
HMIRuntime.Screens.OpenFaceplateInPopup(
    "MyFaceplateType", "MyInstance", parameters,
    200, 150, flags
);

6.3 Hiding the Close Button (Common Use Case)

To open a faceplate pop-up without the close button (forcing the user to use a configured OK button inside the faceplate), clear the CanClose bit:

let flags = ShowBorder | ShowCaption;   // no CanClose, no CanMove
HMIRuntime.Screens.OpenFaceplateInPopup(
    "AckFaceplate", "Ack_1", parameters, 220, 180, flags
);

6.4 AlwaysInParent Behavior

Setting AlwaysInParent (bit 7, value 128) prevents the pop-up from being moved outside its parent window. The parent may be the calling screen or the calling faceplate container. This is the recommended flag for confirmation dialogs and value-entry pop-ups because it prevents operators from losing the dialog on a secondary monitor.

7. Redirecting Connection Tags via Script

Sometimes a faceplate instance's tag interface is wired to one set of tags, but at runtime you want to re-target those tags to different process points (for example, switching a faceplate that monitors Motor 1 to monitor Motor 2). The script-side redirect uses the Faceplate.Properties / interface path.

// Re-wire an interface tag named "ProcessValue" on instance "MotorFaceplate_3"
let fp = Faceplate.Properties;
fp.ProcessValue = "DB_Motor_3".ActualSpeed;
// Confirm the new binding in the running dialog
HMIRuntime.Trace("Re-bound to " + fp.ProcessValue);

The runtime resolves the assigned value as a tag reference if it is a string and as a direct value otherwise. This pattern is the foundation of the V19 dynamic interface multiplexing described in Section 10.

8. V18 Faceplate Features: Trends and Alarm Views

TIA V18 extended the faceplate body to host both trend controls and alarm views. The two cases differ in how they are wired through the faceplate's interfaces.

8.1 Real-Time Tag Trends

Real-time trends are configured normally, but the trend source is bound to a Tag Interface tag rather than a real HMI tag. At the call site, the real HMI tag is wired to that interface tag (under Miscellaneous → Interface). The faceplate therefore displays any tag the caller chooses, and the same faceplate type can plot different trends at each instance.

8.2 Historical Data Log Trends

Historical trends cannot be wired declaratively to a data log through the Tag Interface. Instead, the trend is bound to a Property Interface property, and the property is assigned at runtime by script, typically on the Load event of the faceplate.

// In the faceplate's Load event
// Trend control object name + first area (0) + first trend (0)
Trend_control_2.TrendAreas.Item(0).Trends(0).TagName = Interface_Property_1;
// Optional: configure time range, scaling, and line color here

At the call site, the Property Interface value is the configured logging tag name of the data log entry, not the data log name itself.

8.3 Alarm View Inside a Faceplate

Alarm view configuration inside a faceplate is the same as on a normal screen, with one important extension: the filter criteria can be passed through a Property Interface. This lets the same alarm view show different filter sets at different instances (e.g., one faceplate shows alarms for Pump_1, another for Pump_2) without duplicating the view.

9. V17 Faceplate Behavior Enhancements

Several faceplate mechanics were sharpened in V17 and remain the recommended behavior in later versions.

9.1 Parent-Relative Pop-up Positioning

When opening a faceplate pop-up, the left/top coordinates can be either screen-relative (true) or parent-relative (false). With parent-relative positioning, the pop-up tracks the calling faceplate or screen, so if the parent moves the pop-up moves with it. This is the recommended mode for value-entry pop-ups attached to motor or valve faceplates on a multi-screen overview.

9.2 Closing vs Hiding

From V17, a pop-up can be closed, releasing the instance and its tag subscriptions. This is the recommended path for one-shot dialogs because it is significantly more efficient than hide-and-revive. If you need the pop-up to reopen fast and to retain state, hide is still supported.

9.3 Fit-to-Size Format

The faceplate Format property added a Fit to size sub-property with three options:

• None — Scrollbars appear if the content exceeds the configured size; empty space is preserved.
• Fit window in screen — The faceplate always fills 100% of the available screen area at a 1:1 mapping, regardless of the configured size.
• Fit screen in window — The configured screen size is stretched or compressed into the available faceplate area.

9.4 Reading Parent Properties from a Faceplate

A faceplate can read the properties of its container (the screen, or the calling faceplate) using the Faceplate.Parent.Properties.<property name> path. This is useful for inheriting theme colors or layout hints from the parent.

// In the faceplate, read the parent's background color
let parentBg = Faceplate.Parent.Properties.BackColor;
// Apply it to a faceplate-internal element
InternalShape.BackColor = parentBg;

From a pop-up faceplate, only Width and Height of the parent are exposed. This is a documented runtime limitation, not a bug.

10. V19+ Dynamic Interface Multiplexing

Starting with TIA Portal V19, the tag names passed to a faceplate's Tag Interface at the call site can be assigned dynamically. This is the Unified equivalent of the tag prefix in WinCC Professional / WinCC V8, and it is the basis of large faceplate libraries that bind to many process points of the same type.

10.1 Configuration Steps

1. Open the faceplate instance properties on the calling screen.
2. Navigate to Miscellaneous → Interface.
3. On the row for the interface name you want to multiplex, change the Dynamization column from None to Tag Parameter.
4. Bind the parameter to a string tag that contains the runtime tag name (for example, the index of a selected motor).

10.2 Runtime Behavior

When the string tag changes, the runtime re-resolves the faceplate's tag interface to the new tag name. The faceplate itself is the same; only the wiring changes. This enables a single faceplate instance to monitor 50 motors in a carousel-style overview, switching target at runtime without recreating the faceplate.

10.3 Compatibility Notes

Dynamic interface multiplexing requires a Unified Comfort Panel running firmware V19 or later, or WinCC Unified PC V19 or later. Older panels in a V19-multi-project will fall back to the static binding and ignore the dynamization column. Validate runtime behavior on the target firmware, not only in the engineering system.

11. Verification, Commissioning, and Troubleshooting Matrix

12. Field-Proven Conventions

• Version discipline. Faceplate runtime behavior depends on the TIA Portal version that compiled the project, not on the editor you last opened. Re-compile after every portal upgrade.
• Interface naming. Prefix Tag Interface names with the data type semantic (for example, r_ for real, i_ for integer, b_ for boolean) and Property Interface names with col_ or res_. This makes the contract at the call site unambiguous.
• One faceplate per functional object. A motor faceplate, a valve faceplate, a tank faceplate — one type each. Do not build "generic equipment" faceplates that branch by an equipment-type tag. The reuse story collapses, and V19 multiplexing cannot recover it.
• Property vs Tag. If you find yourself passing a color tag as a Tag Interface and then converting it in script to drive BackColor, refactor it to a Property Interface. The runtime is faster and the screen editor experience is cleaner.
• Closing pop-ups. Default to closing, not hiding, for one-shot dialogs. The runtime savings are real on large plants with hundreds of operator pop-ups.

FAQ