Dynamizing Faceplate Properties via VBS in TIA Portal WinCC

Dynamizing Faceplate Properties via VBS in TIA Portal WinCC

1. Problem Statement: One Screen Window, Four Process Groups

A typical configuration in a plant where four heating-cooling groups are mirrored across a single overview screen is the root motivation for the question. The engineer wants:

• One reusable faceplate type per valve, pump, or motor (no copy-pasted graphics).
• One screen window containing those faceplate instances, draped over a single template.
• The visibility, color, value, and animation of each faceplate property driven by the HMI tags of the currently selected group (Group 1, Group 2, Group 3, Group 4).
• Runtime control via VB script, so swapping to Group 2 simply reroutes the tag references and no engineer edits four near-identical screens.

The naïve approach is to right-click a faceplate property, choose Dynamization, bind it to a tag, then reassign that tag from a VBS script at runtime. TIA Portal and WinCC RT Professional do not allow the engineer's expectation because the Dynamization entry stores a static configuration handle, not a runtime-mutable reference. Three accepted patterns substitute for it.

2. Why the Static Dynamization Property Is Not Runtime-Mutable

In TIA Portal's engineering view, when you right-click a faceplate property under Properties > Animations > Dynamization, the IDE records the binding inside the screen XML and recompiles the screen binary on save. At runtime, the faceplate container resolves the binding once during load and caches it. VBS code running inside the HMI process exposes the value of the property through wrapper objects, but does not expose the configuration binding itself.

This is by design: WinCC RT Professional precomputes event subscriptions and tag update subscriptions during the screen build so that the runtime data engine can route thousands of property changes per screen cycle without re-evaluating bindings. Mutating these bindings would invalidate the registered subscriptions and force a partial reload of the screen, which the runtime cannot perform mid-cycle.

3. Architecture: Faceplate Type, Faceplate Container, Faceplate Instance

Three terms need precise separation before any code is written.

• Faceplate type – the reusable master template that defines properties, the property interface, the screen layout, and the scripts. Stored in the project library under Faceplates.
• Faceplate container – the on-screen instance of that type. Each container occupies a position and a size in the parent screen and owns one live configuration of the property interface.
• Faceplate instance – sometimes used interchangeably with "container" in casual documentation; strictly it refers to the per-event context passed to VBS through the Parent object of a faceplate script.

When a VBS function executes inside a faceplate type (added under Scripts > Faceplate scripts), the Parent property of the faceplate object gives you a handle back to its own container. From that container you may Read or Write properties, query the tag prefix, or push values into container-tag properties. This is the routing primitive that lets one script reach its own runtime container.

Official Siemens guidance for this construct lives in the TIA Portal help system: Accessing properties of the faceplate container with a script (RT Unified), with the parallel Example: Creating a script in the faceplate type (Panels, Comfort Panels, RT Advanced, RT Professional) step-by-step showing where to insert the script.

4. Alternative 1: Script-Based Dynamization in Lieu of a Tag

The first substitute is to replace the tag on the Dynamization entry with a VB script. The IDE surfaces this as the entry type "Dynamic" > "Script" > "" then script name. The runtime calls the script whenever the property needs re-evaluation, passing Item as the property descriptor and Reason as the trigger cause. Code inside the script returns the value to be displayed; this is essentially a virtual tag.

The pattern for the four-groups / one-window case becomes:

1. Define a single HMI integer tag SelectedGroup (1..4) on the screen.
2. For each valve property (PositionX, Color, Visibility, BackColor, TooltipText), open Properties > Animations > Dynamization > Dynamic and bind to a VB function rather than a tag.
3. Inside the function, read SmartTags("SelectedGroup") and dispatch to the matching group-scoped tag.

Snippet illustrating this dispatch in WinCC Professional V14 SP1 syntax (a portion only – see Section 9 for a complete, compilable block):

Function Compute_PositionX(ByVal Item, ByVal Reason)
    Dim g, prefix
    g = CInt(SmartTags("SelectedGroup"))
    Select Case g
        Case 1: prefix = "Group1"
        Case 2: prefix = "Group2"
        Case 3: prefix = "Group3"
        Case 4: prefix = "Group4"
        Case Else: prefix = "Group1"
    End Select
    Compute_PositionX = SmartTags(prefix & "_Valve_PositionX")
End Function

This approach has one decisive advantage: the dynamic evaluation happens server-side at every change of SelectedGroup, so the faceplate never recompiles.

5. Alternative 2: Property Tag Prefix with a Runtime-Writable Text Tag

The second substitute is described in the original Siemens reply: "In animation tab, you can select animate property and assign a tag of text type to the property tag prefix." The mechanism is configurative, but the prefix tag itself is a regular HMI tag you can rewrite at runtime.

5.1 Configuration-time setup

1. Open the faceplate type and add the property you intend to make dynamic (e.g., ValveState, type INT) to the interface.
2. Inside the type, drop an IO field on the property's screen representation and bind its Value to ValveState.
3. Back in the engineering view, drag the faceplate onto the parent screen to create four containers, one per group. Select container 1, open the Properties pane, and under each tag-style property (e.g., Tag prefix on the binding row that points to ValveState), choose Animate > Tag.
4. Bind to an HMI tag of type Text. Convention: name it Container1_Prefix, default value "Group1_".
5. Repeat for containers 2–4, each pointing to its own prefix tag.

5.2 Runtime rerouting

From any VBScript with execution rights (faceplate script, screen script, or global script), simply overwrite the text tag:

WinCC RT Professional tears down the prefix expansion, re-resolves Container1_Prefix + "ValveState" = Group3_ValveState, and subscribes the IO field to the new tag. The faceplate remains unchanged, no recompilation, no screen reload.

6. Alternative 3: Driving Container Properties from Outside via VBS Parent Object

The third substitute is what Siemens refers to under "Accessing properties of the faceplate container with a script". A faceplate script can read and write its container's properties using the Parent object. Symmetrically, a global script or screen script can walk into a container and modify its properties if the container exposes a script entry point or a script on its property interface.

The key calls are summarized in the table below.

Common use case: a global VBS function reads the new group selection, then walks all faceplate containers of one screen via HMIRuntime.Screens("Main").ScreenItems, and calls Property("GroupContext") = SmartTags("SelectedGroup") on each. Inside the faceplate type, a property change event (OnPropertyChanged) re-reads GroupContext and reroutes internal lookups.

Sub OnPropertyChanged(ByVal Item, ByVal Reason)
    Dim parentObj, ctx
    Set parentObj = Item.Parent
    ctx = CInt(parentObj.Property("GroupContext"))
    ' Use ctx to read group-specific HMI tags 
    SmartTags("_currentGroupContext") = ctx
End Sub

This keeps the dynamization flow (which tag writes which property) rigid and engineering-stable; the variable part (which group is currently selected) is a single integer pushed through one property, with no screen edits required when the process grows from four to eight groups.

7. Creating Scripts Inside the Faceplate Type

To add a VBScript inside a faceplate type in TIA Portal V14 SP1 or V20, follow the documented procedure.

1. In the project tree, open the faceplate type (e.g. Faceplate_Valve).
2. Switch to the Scripts editor.
3. In the configuration area, locate Scripts > Faceplate scripts.
4. Double-click Add VB script, or use the keyboard shortcut Ctrl+J to open the object list and pick an event such as OnPropertyChanged.
5. Implement the function. Use SmartTags to read or write HMI tags; use Item.Parent to navigate to the container.
6. Compile via the ribbon and save the project.

The form factor of the script declaration is fixed; renaming OnPropertyChanged to something else makes the IDE silently ignore it. The two parameter names Item and Reason are likewise not free choice.

Templates and naming locations are walked through in the official TIA Portal V20 example. In V14 SP1 the procedure is identical; the menu captions and the location of Faceplate scripts match within the same editor pane.

8. Implementation Pattern: One Window, Four Groups

Putting the three alternatives together, the cleanest engineering pattern for the user's stated case is a hybrid.

When the operator presses the "Group 3" button, SetActiveGroup(3) writes:

SmartTags("SelectedGroup") = 3
SmartTags("Valve_A_Prefix") = "Group3_"
SmartTags("Valve_B_Prefix") = "Group3_"
SmartTags("Valve_C_Prefix") = "Group3_"

Every faceplate container that subscribes Valve_A_Prefix + "PositionX" now reads Group3_Valve_A_PositionX. No screen recompilation, no XML hand-edit, no manual modification of "Dynamization".

9. Complete Compilable VBS Examples

9.1 Global script: Switch group active context

'==========================================================
' Module: Global script - Runtime group switching
' TIA Portal V14 SP1 / V20, WinCC RT Professional
'==========================================================
Sub SwitchGroup(groupIndex)

    Dim prefixes, i
    prefixes = Array("Group1_", "Group2_", "Group3_", "Group4_")

    If groupIndex < LBound(prefixes) Or groupIndex > UBound(prefixes) Then
        SmartTags("System.Diagnostics.LastError") = "InvalidGroupIndex"
        Exit Sub
    End If

    Dim pfx
    pfx = prefixes(groupIndex - LBound(prefixes))

    ' Re-bind container tag prefixes - one row per faceplate instance
    SmartTags("Valve_A_TagPrefix") = pfx
    SmartTags("Valve_B_TagPrefix") = pfx
    SmartTags("Valve_C_TagPrefix") = pfx
    SmartTags("Pump_1_TagPrefix")  = pfx
    SmartTags("Pump_2_TagPrefix")  = pfx

    ' Push integer context (used by script-based dynamizations)
    SmartTags("SelectedGroup") = groupIndex

    ' Audit trail
    SmartTags("System.Diagnostics.LastSwitchUTC") = Now
End Sub

9.2 Faceplate script: Read its own GroupContext property

'==========================================================
' Inside faceplate type > Scripts > Faceplate scripts
' Trigger: OnPropertyChanged on "GroupContext"
'==========================================================
Sub OnPropertyChanged(ByVal Item, ByVal Reason)
    Dim ctx
    Select Case Item.Name
        Case "GroupContext"
            ctx = CInt(SmartTags("SelectedGroup"))
            ' Cache for this instance for downstream dispatches
            SmartTags("_LocalCurrentGroup") = ctx

            ' Apply business rules locally
            SmartTags("_LocalState") = SmartTags("Group" & CStr(ctx) & "_Valve.State")

    End Select
End Sub

9.3 Screen script: Force re-evaluation of one property

' Trigger: Press of a manual diagnostic button
Sub TriggerManualRefresh()
    SmartTags("Header.Diagnostics.RefreshPulse") = 1
    ' The Pulse tag triggers OnPropertyChanged on every faceplate
    ' that subscribes the "RefreshPulse" index
End Sub

10. Verification and Commissioning Procedure

Once the dynamization is wired through one of the three patterns, validate in this order. Each step has an objective pass criterion.

1. Compile check. Compile the HMI project. Investigate any warning of the form "Instance property tag prefix could not be resolved" – it indicates a missing or misnamed HMI tag.
2. Offline simulate. Use RT Simulation with PC-based Runtime or open the WinCC RT Professional viewer. Drag the project, start the runtime, and load the screen.
3. Initial state: SelectedGroup = 1, all prefix tags at "Group1_". Verify the valve positions read Group1_Valve_*.
4. Switch to Group 2 via the header button. Within one second the prefixes should show "Group2_" and the panel should reflect the values of Group2_Valve_* without any UI element losing focus.
5. Stress: cycle through Groups 1 through 4 once per second over five minutes. Memory footprint in RT Diagnostics should remain flat; if it climbs, a script is allocating objects without Set obj = Nothing.
6. Disconnect: under Tools > Simulation > Deactivate, stop PLC connection, verify faceplate properties default to bind-default values (a fixed value, not a leftover from the last group).
7. Reconnect: confirm PLC tags repaint the faceplate within the configured refresh cycle (default 250 ms in WinCC RT Professional).

Document the test evidence (screen captures + log) in the SAT report so the same test sequence is repeatable after a TIA Portal upgrade.

11. Troubleshooting Matrix

12. Best Practices and Field Cautions

• Separate switch-control logic from value logic. Group switching is an integer; values are tag-bound. Mixing them inside one script often introduces off-by-one bugs at the boundary.
• Always initialize prefix tags in the Initialize event. A blank prefix resolves to "" and the binding evaluates to the literal name, which is hardly ever what an operator wants at first power-up.
• Keep prefix strings constant length across groups. If Group 1 uses "G1_" and Group 2 uses "Process_Group_2_", downstream visualization tools that sort by tag name will fail.
• Avoid Me. dereferences in a global script. Global scripts have no Parent; they need explicit HMIRuntime.Screens(...).ScreenItems(...) addressing to reach containers.
• Keep faceplate type scripts short. VBS inside faceplates executes on the UI thread; long loops will lengthen the screen refresh cycle. Anything that needs to crunch math should run in the scheduler instead.
• Test after every TIA Portal upgrade. TIA Portal V16 introduced new faceplate-container methods; V17 added multi-language prefix tag text. Verify that the migration tool did not desynchronize prefix tag widths.
• Use the centralized text-list mechanism for prefixes if the panel is going through translation. A hardcoded "Group3_" prefix in VBS will be untranslated.
• Edge case: 4 vs. 8 groups. The pattern scales linearly. The reason this is mentioned is that early designs sometimes hard-code "If g=1..4" – replace with a configured array groups() from the HMI text list.

13. Reference Material

• Accessing properties of the faceplate container with a script (RT Unified) – TIA Portal V20 Siemens docs: documents the Parent object and the read/write surface of container properties.
• Example: Creating a script in the faceplate type (Panels, Comfort Panels, RT Advanced, RT Professional) – TIA Portal V20 Siemens docs: end-to-end walkthrough, including the "Add VB script" path and Ctrl+J shortcut for the object list.