WinCC Unified Faceplate Dynamic Text via Property Interface

Problem Overview

Siemens WinCC Unified (TIA Portal V17 and later) faceplates are reusable screen objects that can be instanced on any parent screen of an RT Unified project. A common field requirement is to reuse a single faceplate across multiple parent screens while the title, header, or status text inside that faceplate must always reflect the active screen name. In the pre-faceplate object model (WinCC Comfort/Advanced, V15-V16), the only practical way to feed a string into a faceplate instance was through an HMI tag; a direct script approach like Screen.FindItem(...).Text = Screen.Name was not accessible from inside a faceplate container.

This article documents the supported V17+ workflow using the faceplate property interface with a Configuration String data type, a Loaded-event VBScript, and the parent-screen script that supplies the screen name. The procedure also covers nested faceplate inheritance and the V16 fallback using HMI tags, plus the official Siemens constraint that local text lists cannot be used inside faceplates.

Prerequisites

Architecture: How the Property Interface Carries a String Into a Faceplate

A faceplate in WinCC Unified is a sealed container. The runtime cannot be told to "look up one level" and grab a tag from the parent screen with a generic accessor. The supported way to push data into a faceplate is the property interface: a typed bag of parameters declared on the faceplate type, each of which is mapped to a property of an internal element (text, visibility, color, etc.).

For a dynamic text use case, the relevant property type is Configuration String. Unlike an HMI tag (which carries a live value), a Configuration String is set once at instance creation or via a script and is bound to the faceplate's internal text property. The parent screen's Loaded event is the canonical place to write that string for every faceplate instance on that screen.

Step 1 - Declare the Property Interface on the Faceplate Type

1. Open the faceplate in the TIA Portal project library or directly in the Screens editor.
2. Place a Text box on the faceplate working area; in this example it is named Title.
3. In the Properties pane of the faceplate, switch to the Interface tab and add a new property:

4. Bind Title_name to the Text property of the Title text box. Use the standard faceplate property binding dialog. Once bound, the text box's runtime text is sourced from this property.

Step 2 - Apply the Value Inside the Faceplate via the Loaded Event

The property binding from Step 1 is enough to display whatever default text was set on the interface. To make the text respond to the parent screen, add a small VBScript handler on the faceplate itself (not on an internal element), so it runs when the faceplate instance loads.

1. Select the faceplate working area (click outside any element).
2. Open Events > Loaded.
3. Add the following VBScript:

Sub OnLoaded()
    ' Property Title_name is already bound to the internal text box.
    ' No explicit write is required if the binding is set in Step 1.
    ' This handler exists so you can post-process the value,
    ' e.g. trim a prefix, localize, or fall back to a default.
    If Len(Me.Title_name) = 0 Then
        Me.Title_name = "Untitled"
    End If
End Sub

For most projects this handler is optional. The binding alone is sufficient because the parent screen will write Title_name before the faceplate renders.

Step 3 - Push the Screen Name from the Parent Screen

On the parent screen that contains the faceplate instance, write a Loaded-event script that pulls the screen's own name and forwards it into the faceplate property.

1. Open the parent screen in the Screens editor.
2. Open Events > Loaded on the screen object itself.
3. Insert the VBScript below. Replace FP_Header with the actual instance name of your faceplate on the screen, and Title_name with the property interface name declared in Step 1.

Sub OnLoaded()
    Dim sScreenName
    sScreenName = Screen.Name
    ' Strip an optional project prefix that ends with "_" (e.g. "Main_Home" -> "Home")
    Dim iUS
    iUS = InStrRev(sScreenName, "_")
    If iUS > 0 Then
        sScreenName = Mid(sScreenName, iUS + 1)
    End If
    HMIRuntime.Screens("Main").ScreenItems("FP_Header").Title_name = sScreenName
End Sub

The pattern Screen.Name.replace(/^.+_/, '') from the original question is the JavaScript form. The equivalent in VBScript is the InStrRev + Mid block shown above. Both approaches assume that the developer applies a naming convention like Area_Screen to every parent screen and only the suffix is meaningful for display.

Step 4 - Reuse the Faceplate Without Re-Scripting Each Screen

Once the parent-screen script is in place, copy that script (or a parameterized variant) into the Loaded event of every parent screen. To minimize maintenance, define the screen name in a single place using one of the following approaches:

• Local script function library: create a project function SetFaceplateTitle(sScreen As String) in the Scripts folder and call it from every screen's Loaded event.
• Internal faceplate script + dynamic property: keep the faceplate self-contained by reading HMIRuntime.BaseScreenName from inside the faceplate and assigning it directly to the bound property. This requires V17 property-interface access from a faceplate to the parent, which is supported through the property wiring set in Step 1.

' Project function: SetFaceplateTitle
Sub SetFaceplateTitle(sInstancePath As String, sRawName As String)
    Dim sClean As String
    Dim i As Integer
    i = InStrRev(sRawName, "_")
    If i > 0 Then
        sClean = Mid(sRawName, i + 1)
    Else
        sClean = sRawName
    End If
    HMIRuntime.Screens(Screen.Name).ScreenItems(sInstancePath).Title_name = sClean
End Sub

Step 5 - Handle Nested Faceplates (Inheritance)

If faceplate A opens faceplate B as a popup or embeds B inside its layout, and B's title must reflect B's parent (A's) context, declare the same property interface (e.g., Title_name of type Configuration String) on faceplate A. When you embed B in A, the property interface of B is exposed in A's interface tab. Bind the A-interface property to the A-internal property, and the string flows through:

This is the inheritance mechanism referenced in the original Siemens community answer: a child faceplate inherits the property interface of its parent, so the same string can be cascaded without an additional HMI tag.

V16 Limitation and the HMI-Tag Fallback

On TIA Portal V16 (and earlier), the faceplate cannot reach out to the parent screen. The supported workaround is to use an HMI tag as an intermediary:

1. Declare an HMI tag of type WString in the HMI tags table, e.g. HMI_ActiveScreenTitle.
2. In the parent screen's Loaded event, write the screen name to the HMI tag.
3. Inside the faceplate, bind the text box directly to the HMI tag.

Sub OnLoaded()
    SmartTags("HMI_ActiveScreenTitle") = Screen.Name
End Sub

This avoids any cross-container scripting, but it costs you an HMI tag and a write per screen transition. With V17+, retire the HMI tag and switch to the Configuration String approach above.

Text Lists, Graphics Lists, and Faceplates

A frequent follow-up question is whether a text list or graphics list defined on a parent screen can drive text inside a faceplate. Siemens documents this constraint explicitly:

"Local text lists cannot be used in faceplates. The use of text lists in faceplates is only possible via the property interface of the faceplate or by using a ..."

Source: Basics of text lists (RT Unified) (Siemens TIA Portal Help, V20).

Implications for this article:

• If the title must come from a pre-translated text list, add a WString (or WString array) parameter to the faceplate property interface and feed it from the parent screen. The text list still lives on the parent.
• The same rule applies to graphics lists: assign an index from the parent, bind an Int property in the faceplate, and let the internal element resolve the index to the right graphic.

Verification and Commissioning Checklist

1. Compile the project in TIA Portal. The compiler must report zero errors on the faceplates and zero cross-references that fail to resolve.
2. Start the WinCC Unified RT simulation (or download to the Unified Comfort Panel).
3. Open a parent screen that contains the faceplate instance. The faceplate's title text box must show the suffix of the screen name (for example, Home if the screen is named Main_Home).
4. Navigate to a second parent screen that uses the same faceplate. The title must update without restarting the runtime.
5. If a popup faceplate is used, open it from within faceplate A and verify that the popup title reflects the context string passed through A's property interface.
6. Use the RT Unified trace viewer (under Diagnostics > Trace) to confirm that no HMIRuntime error events are raised during navigation.
7. Validate against a language change: switch the HMI runtime language and confirm that the title is re-evaluated from the parent (Configuration String is a runtime value, not a compile-time constant, so it follows the current language).

Troubleshooting Matrix

Field-Commissioning Notes and Edge Cases

• Long screen names. WinCC Unified faceplate text boxes do not auto-shrink. If the parent screen name produces a string longer than the visible width, enable Auto-size on the text box, or constrain the source with Left(sClean, 32) to match the design width.
• Multi-language projects. Configuration Strings accept localized text through the standard TIA Portal text system. Add a text entry under Project Texts > Faceplate and bind it to the Title_name default. The runtime value set by the parent script overrides the default but only for that instance.
• Pop-up faceplates opened from inside another faceplate. Pass the parent context through the interface as described in Step 5. If a popup is opened from a global button bar (not from inside faceplate A), set the title in the popup's Open event, not its Loaded event, because the Loaded event may fire before the property has been set by the parent script.
• Number of instances on a screen. The V17+ property pass-through has no documented per-screen instance limit, but bundling more than ~50 faceplate instances on a single parent screen can lengthen the Loaded event cycle on Unified Comfort Panels. Profile the startup with the RT trace viewer if startup time is critical.
• Migration V16 -> V17. If you already have an HMI tag-based solution on V16 and migrate to V17, leave the HMI tag in place initially for fallback testing. After confirming the property-interface approach works, remove the HMI tag to free a slot in the HMI tag table.

FAQ