Configuring Faceplate Pop-up Tag Interfaces in TIA Portal V17

Configuring Faceplate Pop-up Tag Interfaces in TIA Portal V17

When a WinCC Unified faceplate is opened as a pop-up from another faceplate, the child instance inherits the full tag interface of the calling parent. Unlike a pop-up opened directly from a screen—where you can wire any UDT tag of your choice to each interface property—the faceplate-to-faceplate call forces the child to accept the parent's complete interface. This behavior is by design in WinCC Unified and is preserved from TIA Portal V16 through V18, even though faceplate dependency handling was tightened in V17. Engineers who maintain large library faceplates with many UDT members therefore see unnecessary tags flowing into child pop-ups, which complicates scripting, expands the property surface, and inflates the runtime data footprint.

This reference explains the architecture behind that inheritance, walks through the V17 release/dependency workflow that affects parent and child faceplates when one is edited, and documents the configuration-script workaround that lets a child faceplate expose only the UDT members it actually consumes. The article is written for HMI engineers maintaining reusable faceplate libraries on SIMATIC WinCC Unified (TIA Portal V17 Update 4 and later, also valid for V18).

WinCC Unified Faceplate Architecture in TIA Portal V17

WinCC Unified treats faceplates as typed objects: a faceplate type is authored once in the project library (or master copies library), and each call on a screen instantiates a type instance. The type defines:

• The tag interface — a typed contract of PLC tags the instance must expose (HMI tags, raw PLC tags, or UDT-tagged PLC points).
• The property interface — configuration-time parameters such as colors, limits, and visibility flags, settable per instance.
• The event interface — runtime signals emitted from the faceplate back to the calling screen or parent faceplate.

When the same faceplate type is reused across screens and inside other faceplates, the engine guarantees that every caller supplies the same tag shape. The contract is binary in V17: an instance is either compatible with the type or it is not. There is no partial-fit mode at the tag level. That constraint is what produces the inheritance behavior discussed in this article.

Tag Interface Inheritance: Parent Faceplate to Pop-up Child

Two distinct call paths exist for opening a faceplate as a pop-up:

The asymmetry comes from how the WinCC Unified runtime resolves references. A screen holds its own connection to the PLC; a faceplate instance does not. A faceplate only knows the tags exposed by the tag interface that was wired to it when it was placed on the screen. When a child faceplate is opened in a pop-up from within the parent, the child has no independent PLC connection — it must reuse the parent's wiring. The runtime therefore lifts the parent's interface wholesale and rebinds it onto the child.

Figure 1 — Screen-level pop-ups allow selective per-property binding; faceplate-level pop-ups force wholesale inheritance of the parent's tag interface.

Why Selective Tag Binding Is Not Directly Supported

From the runtime engine's perspective, the inherited interface is not "extra data" — it is the only path the child has to reach the PLC. The tag interface is materialized as a fixed set of references at type-instance time; once a parent faceplate is configured, the child has no way to ask for a subset because it has no alternative PLC handle to read from. Removing members at the child would require the child to acquire its own connection, which would violate the encapsulation model of faceplate re-use.

Three architectural decisions sit behind this behavior:

1. Single point of authority. One faceplate instance owns one PLC connection. The runtime cannot multiplex two connection paths into the same instance.
2. Type compatibility. All instances of a given faceplate type are interchangeable. A pop-up child must be indistinguishable from a screen-placed instance so the same script logic works in both contexts.
3. Library governance. A faceplate type released in a master copies library must compile against every calling context without per-caller modification. Partial interfaces break that contract.

Configuring a Pop-up from a Screen

When the call originates on a screen, configuration is straightforward. Add a button or event source, attach a "Open faceplate in pop-up" system function, and in the configuration dialog assign each interface property to an independent HMI tag or PLC tag.

1. In the screen editor, select the trigger element (e.g., a button).
2. Open Properties → Events → Click and add the "OpenFaceplateInPopup" system function.
3. Select the faceplate type from the library.
4. Wire each interface entry to a tag. UDT members are accessible by navigating the tag browser to the structured type.
5. Set pop-up properties: position, size, title, modal/ non-modal, close behavior.

Because the screen holds its own PLC connection, every interface slot can be wired to a distinct tag. This is the path that engineers familiar with the dialog expect — and the one that is conspicuously absent on faceplate-to-faceplate calls.

Configuring a Pop-up from Another Faceplate

The configuration dialog for a faceplate-level call is similar but the tag selection tree is restricted to the parent's own interface. Steps:

1. Open the parent faceplate type in the faceplate editor.
2. Add a trigger element (button, IO field, graphic view) at the location where the pop-up should originate.
3. Attach the "OpenFaceplateInPopup" system function to the trigger event.
4. Select the child faceplate type from the library.
5. For each interface entry of the child, the tag browser shows only the parent faceplate's interface members. Select the appropriate parent property for each child property.
6. Set pop-up geometry and close behavior.

The dialog presents the parent's interface as the source list. Selecting a parent member for one child property does not alter any other property — each entry is wired independently. The full set of parent tags remains implicitly available to the child at runtime regardless of which subset you explicitly map. This is the source of the perceived "extra tags" problem.

Version Management Workflow in V17 — Child vs. Parent

TIA Portal V17 changed the dependency model for faceplate types. Every released faceplate type carries a version number that becomes part of its generated name in the runtime. When a child faceplate is re-released, the parent's reference to it must be updated because the parent's internal call invokes the child by type name plus version. The following state machine applies:

Figure 2 — Three-state dependency model. V17 enforces a "release then update types" sequence whenever a child is re-versioned.

Step-by-step Release Workflow

1. Edit the child faceplate type and complete all interface, property, and script changes.
2. Right-click the child type in the library tree and choose Release version. V17 prompts for unused copy cleanup and dependency propagation.
3. Open the parent faceplate type. The editor displays the child as "In Work" if it is the type being edited or "non-default version instantiated" if it is referenced from a library.
4. Right-click the parent and select Release version. For multiple parent faceplates, right-click the type folder and select Release all to mass-commit.
5. Right-click the project library root, choose Update types → Project to propagate the latest versions into the project consumers.
6. Recompile the HMI. Any remaining "Inconsistent" markers indicate an interface signature change that requires manual re-binding in the parent.

Configuration Script Workaround for Selective Tag Binding

Because the dialog will not let you exclude parent tags, the only way to surface a minimal set on the child is to filter inside the child via configuration scripts. The principle: load the parent's interface members into a private property bag inside the child, and only publish the ones the child actually consumes through its own property interface.

WinCC Unified configuration scripts are JavaScript snippets attached to faceplate events (Loaded, PropertyChanged, etc.) and configuration-time properties. Use them to read parent members from the inherited interface and forward selectively into child-internal properties that downstream graphic elements reference.

Pattern: Forwarding a Subset of Parent Tags

1. Define a private property on the child faceplate for each parent tag the child actually uses (e.g., PropSpeed, PropCurrent).
2. Attach a Loaded event script on the child container. The script reads the inherited parent tag values and writes them into the private properties.
3. Subscribe to property-change events on the inherited interface to keep the private properties live without polling.
4. Bind the visible graphic elements (numeric IO fields, trend views) to the private properties instead of the inherited interface tags.

Example JavaScript Skeleton

The WinCC Unified runtime exposes the inherited parent interface through Faceplate.Parent.Properties (approximate API; verify against your installed V17 build's API reference in the TIA Portal help). The following skeleton illustrates the forwarding logic:

// Configuration script attached to the child faceplate's "Loaded" event
// Reads inherited parent tags and forwards only the required members
// into the child's private properties.

(function () {
    // Define the subset the child actually consumes
    var requiredMembers = ["Speed", "Current", "Temp"];
    var parentIface = Faceplate.Parent.Properties;

    // Initial copy on load
    requiredMembers.forEach(function (name) {
        var p = Properties.Item("Prop_" + name);
        if (p !== null && parentIface.Item(name) !== null) {
            p.Value = parentIface.Item(name).Value;
        }
    });

    // Subscribe to live updates from the parent
    parentIface.OnPropertyChanged = function (name, value) {
        if (requiredMembers.indexOf(name) !== -1) {
            Properties.Item("Prop_" + name).Value = value;
        }
    };
})();

Pattern: Hiding Unused Members

Even after forwarding, the child still receives every inherited tag — you have only relocated the binding target, not removed the members. If the goal is purely to clean the engineering view (not to reduce runtime memory, which is unaffected because the tags were never duplicated), add visibility logic: bind graphic elements only to the private properties so the inherited members have no visual representation and no script reference. They remain accessible from the script if needed but are invisible in the engineering tree.

Property Interface Limitations: Why Text Box Text Cannot Be Directly Bound

The configuration script mechanism is necessary because WinCC Unified does not permit direct dynamic linking between property interface values of a faceplate and certain intrinsic properties of contained graphic elements — most notably the Text property of a text box or IO field, and the Tooltip property of arbitrary elements.

For example, a faceplate property LabelText cannot be wired to a text box's Text field through the property interface dialog. The configuration interface restricts which element properties are exposed as bindable targets. The workaround is identical in spirit to the tag-forwarding approach: load the property value into the element through a script.

Workaround Snippet

// Configuration script on the text box "Loaded" event
// Mirrors a faceplate property into the text box Text field

(function () {
    var lbl = Properties.Item("LabelText");
    var tb  = Screen.FindItem("./TextBox_1");

    function apply () { tb.Text = lbl.Value; }
    apply();

    lbl.OnPropertyChanged = function (n, v) {
        if (n === "Value") { tb.Text = v; }
    };
})();

Siemens' official sample project "Hello LauraW" demonstrates the property-to-text-box pattern end-to-end and is referenced in the engineering documentation set that ships with TIA Portal V17 Unified Faceplates (entry ID 109812366).

Implementation Walkthrough: Pop-up Child with Filtered Interface

The following procedure builds a parent/child faceplate pair, demonstrates the inherited-interface behavior, and applies the configuration-script workaround so the child exposes only the required subset.

Prerequisites

• TIA Portal V17 Update 4 or later (V17.0.0.4+), Update 7 recommended.
• WinCC Unified Runtime version 17.0.x compatible with the engineering build.
• PLC with a UDT UDT_PumpData containing at least Speed (Real), Current (Real), Temp (Real), Flow (Real), Pressure (Real), Run (Bool), Fault (Bool).
• HMI tag HMI_Pump_DB bound to a UDT_PumpData instance.
• Project library with a parent faceplate type PumpOverview (already authored).

Step 1 — Author the Parent Faceplate

1. In the project library, open faceplate PumpOverview.
2. Open Tag Interface and add seven entries, one per UDT member, named Tag_Speed, Tag_Current, etc.
3. Place a button labeled "Details…" on the faceplate.
4. Attach Click → OpenFaceplateInPopup and select the child type PumpDetail.
5. Map each child interface property to the corresponding parent tag interface entry.

Step 2 — Author the Child Faceplate

1. Create a new faceplate type PumpDetail in the project library.
2. Add tag interface entries identical to the parent (or a superset — it must include all parent entries for the call to compile).
3. Add three private properties: Prop_Speed, Prop_Current, Prop_Temp of type Real.
4. Place three IO fields and bind them to Prop_Speed, Prop_Current, Prop_Temp respectively.
5. On the faceplate container's Loaded event, add the forwarding script from Section 7.
6. Compile the type.

Step 3 — Place the Parent on a Screen

1. On screen Overview, drag PumpOverview from the library.
2. For each tag interface slot, bind the corresponding member of HMI_Pump_DB.
3. Compile and download.

Step 4 — Verify Inheritance Behavior

1. Start the runtime. Open the screen.
2. Trigger the Details… button. The child pop-up opens.
3. In the runtime tag diagnostics, observe that all seven UDT members are referenced from the child instance, even though only three are bound to IO fields.
4. This is expected: inheritance is unconditional, the script workaround only masks it from the engineering tree.

Step 5 — Apply the Workaround

1. Ensure the script from Section 7 is attached to the child container's Loaded event.
2. Add a PropertyChanged script on each parent interface tag to mirror the live update path.
3. Recompile and redownload.
4. Re-trigger the pop-up. The three IO fields show live values; the four other inherited tags are bound but unrendered.

Troubleshooting Matrix

Verification and Acceptance Test

Before promoting a parent/child faceplate pair to production, run the following acceptance test on the target runtime:

1. Compile clean. Both types compile without warnings. Inconsistent indicators absent on every instance.
2. PLC path test. Force each UDT member from the PLC simulator and confirm the corresponding IO field on the child pop-up reflects the new value within one refresh cycle (typically 100 ms for Unified).
3. No-side-effect test. Verify that forcing a UDT member that the child does not display does not error in the runtime log.
4. Version test. Re-release the child, run the release workflow on the parent, and confirm Update types → Project resolves the dependency without re-binding prompts.
5. Script log test. Open the runtime trace and confirm the Loaded script on the child fires exactly once per pop-up open and never on screen change.
6. Long-run stability test. Open and close the pop-up 1,000 times. No memory growth > 5 % over the runtime baseline.

Field-Proven Caveats

• The version release workflow in V17 is one-directional: a parent released before its child is re-released cannot be auto-updated. Always release children first.
• Renaming a faceplate type triggers a full type-number change. Plan renames in maintenance windows; every consumer project must run Update types → Project after a rename.
• Configuration scripts execute in the HMI runtime thread, not the PLC scan. Long-running scripts in a Loaded event can delay pop-up rendering; keep the script to a single, idempotent pass.
• The property-event workaround for text boxes works at runtime but does not appear in the engineering preview unless you trigger a screen refresh. Verify visually on the runtime, not in the TIA Portal preview.
• If your project uses master copies library instead of project library, the dependency update target differs. Right-click the master copies folder instead of the project library root.

Standards and Documentation References

• SIMATIC WinCC Unified Engineering V17 — Faceplates chapter (TIA Portal Help, integrated).
• TIA Portal V17 Readme — release notes covering the V17 dependency update for faceplate types (entry ID 109791313).
• SIMATIC WinCC Unified System Manual V17 — runtime architecture and tag binding model (entry ID 109795421).
• WinCC Unified scripting reference — object model for Faceplate, Properties, and Item() access.