Resolving WinCC 7.3 Faceplate Performance and Interface Limits

WinCC 7.3 Faceplate Technology: Overview and Architecture

WinCC V7.3 (the classic SIMATIC SCADA product line, separate from the TIA Portal-based WinCC Unified) implements faceplates as centralized graphical objects that can be instantiated many times across multiple Process Description Language (PDL) pictures. Each instance is linked to a structure tag (the "faceplate tag") that exposes a defined set of interface properties: input, output, input/output, and tag-typed members.

Faceplate prototypes are stored in the project library and are referenced by every instance through the standard Graphics Designer inheritance mechanism. The interface tag binds the instance to runtime data: when a tag value changes, WinCC pushes the new value into the corresponding faceplate property via the configured direct connection or dynamic dialog, and the visual representation updates without a script execution cycle.

In production deployments, three categories of constraints surface in the field:

1. Performance degradation on screen open and runtime updates, driven by the number of faceplate instances per picture and the complexity of the dynamic configuration inside each.
2. Interface and scripting limitations, including tag-triggered VBScript execution, action handling for bit-set operations, and HMI Symbol Library compatibility.
3. Maintainability friction, because bulk updates of instances after prototype modifications require manual re-addressing or VBA automation.

The remainder of this reference documents each constraint, quantifies observed impact, and provides the established mitigation patterns used in operational plants. Where applicable, the architectural continuity with WinCC Unified is highlighted via the WinCC Unified faceplate documentation.

Documented Performance Benchmarks

Field measurements consistently show that the number of faceplate instances per picture is the primary driver of screen-change latency. The table below summarizes measurements on a representative SCADA server (Intel Xeon E3-1270 v6, 16 GB DDR4, Windows Server 2012 R2, WinCC V7.3 SP3 Update 4, single-server configuration, no client/server split, default 1 s tag update cycle):

The latency arises because each faceplate instance triggers an independent cycle during picture construction:

1. Loading the prototype PDL reference from the project library.
2. Resolving the interface tag connection and pushing current values.
3. Evaluating all configured dynamic dialogs against the new values.
4. Triggering any configured VBScript or C actions on the load event.

With 20 instances, this work is performed sequentially during picture construction, producing the linear 1 s per instance pattern observed in practice. The same architectural constraint is acknowledged in the WinCC Unified faceplate documentation, which states: "The number of faceplate instances in a screen is not limited. Note that the performance when opening or updating a screen is affected by the number of faceplate instances." The newer runtime engine tolerates a much higher count, but the underlying processing model is similar.

Use the WinCC Performance Monitor (Start -> Programs -> Siemens Automation -> WinCC -> Tools -> Performance) to capture the actual screen-open latency in your project. Enable the counters Picture change time, Tag request time, and Action time before triggering a screen change. The Picture change time counter is the most direct indicator of faceplate-related latency.

Interface and Scripting Constraints

Beyond raw performance, three configuration constraints are repeatedly encountered in V7.3 faceplate deployments.

HMI Symbol Library Exclusion

The HMI Symbol Library (the vector and isometric icon set provided with WinCC) cannot be used reliably inside a faceplate prototype. Symbols inserted into the prototype fail to render or render inconsistently across instances. The cause is the prototype's library-resolution path, which does not follow HMI Symbol Library references in the same way as a regular picture.

The workaround is to convert the required symbols to a regular Graphics Designer library (export as .GRA, .GSE, or .GSS) and reference them from there, or to embed the symbol graphics as native WinCC objects (rectangles, polylines, ellipses) directly in the prototype. The conversion is performed via Graphics Designer -> Library -> Export, with the symbol selected and the file format chosen. The resulting library file is added to the project via Library -> Add.

Bit-Setting Action Anomaly and Tag-Triggered VBScript Limits

Bit-Setting Action Anomaly

Setting a bit in a faceplate instance via a configured action (mouse-click, value change, or scheduled) updates the local interface tag, but the propagation to the actual PLC tag is inconsistent. The cause is the way V7.3 resolves the "Output" property of the interface structure: when the action writes to a member configured as "Output" only, the write is suppressed in some runtime builds. The action appears to succeed because the local value changes, but the configured direct connection or tag trigger does not fire.

The fix is to declare any tag that the faceplate must write as InOut instead of Output, or to write the value via a direct connection in the action, bypassing the local write. The setting is changed in Tag Management -> Structures -> <StructureName> -> <MemberName> -> Properties -> Direction: select InOut. After the change, the runtime will propagate writes from the HMI to the PLC correctly.

Tag-Triggered VBScript Limit

VBScript actions in WinCC V7.3 cannot be directly attached to a tag value-change event. The action system in V7.3 supports the following triggers:

• Mouse events: click, press, release, enter, leave
• Keyboard events: key down, key up
• Picture events: open, close, change, etc.
• Scheduler events: cyclic, one-time
• Variable events: only on quality change, not on value change

A tag value-change event in V7.3 is only available to C scripts and to the global action scheduler with a configured polling cycle. A common workaround is to attach the VBScript to the Output Value event of an invisible IO Field, which does support value-change events. The IO Field acts as a relay: when the tag changes, the IO Field value updates, and the VBScript fires on the change event. The IO Field is configured as visible = no (via property in Graphics Designer) so the user does not see it. The interface tag value is then used as a parameter to the VBScript.

This pattern is fragile and is one of the primary motivations for migrating to WinCC Unified, where tag-triggered VBScript is fully supported on faceplate properties without relay objects.

Mitigation Strategy 1: Dynamic Dialog Without Scripting

The first and most effective mitigation is to use Dynamic Dialog exclusively inside the faceplate, eliminating all VBScript and C actions from the prototype. Dynamic Dialog is the configuration-driven expression evaluator in Graphics Designer and supports direct tag bindings, range-based animations, and visible/invisible toggles without invoking the script engine.

For a typical motor faceplate (start, stop, running, faulted), the dynamic configuration involves:

• Background color: Dynamic Dialog on Running bit, green if true, gray if false
• Indicator icon visibility: Dynamic Dialog on Fault bit, visible if true, hidden if false
• Status text: Dynamic Dialog on Mode integer field, mapping 0/1/2/3 to "Auto/Manual/Local/Service"
• Button enabled state: Dynamic Dialog on LocalPermit bit, enabled if true, disabled if false

A faceplate with 20 instances configured this way updates in under 1 second on screen open, because the runtime only resolves the dynamic dialog expressions, not the full script evaluation cycle. When the prototype is modified, the change propagates to all instances on next screen load without manual intervention. If a member name in the interface tag changes, the dynamic dialogs in the prototype must be re-bound, but this is a one-time edit in the prototype, not in each instance.

The performance improvement comes from the fact that dynamic dialogs are pre-compiled at project build time, while VBScript actions are interpreted at runtime. The compile cost is paid once; the interpret cost is paid on every screen change.

Mitigation Strategy 2: IO Field Interface Bridge for VBScript

When VBScript is unavoidable (for example, to compute a derived value, perform a multi-step check, or trigger a multi-tag write), the IO Field bridge pattern is the standard workaround:

1. Add an IO Field to the faceplate prototype, sized 0 x 0 or positioned off-screen, with visible = no (configurable via property in Graphics Designer).
2. Bind the IO Field's Output Value to a member of the interface tag that is updated when the script should fire.
3. Attach the VBScript to the Output Value -> Change event of the IO Field.
4. The script reads the interface tag member via HMIRuntime.Tags("InterfaceTag.MemberName").Read or directly via the Me.GetParent reference.

A minimal VBScript example that reads the interface tag and writes a derived value:

' VBScript attached to IO Field "Output Value -> Change"
Dim intIn
intIn = HMIRuntime.Tags("MotorFaceplate.SpeedSetpoint").Read
If intIn > 0 And intIn <= 1500 Then
    HMIRuntime.Tags("MotorFaceplate.SpeedRamp").Write intIn * 0.1
End If

This pattern works but requires the project engineer to be aware of the following edge cases:

• The IO Field must have a unique Name property within the prototype to avoid conflicts in instances. Use a naming convention like io_Bridge_SpeedSetpoint to make the purpose clear.
• The interface tag member used as a trigger must be a value that genuinely changes (a constant value will not fire the change event). For periodic execution, write a toggle bit (0/1/0/1) from the PLC.
• The script must use the HMIRuntime global object, not Application (which is not available in the runtime action context).
• The IO Field update cycle is governed by the same 1 s default tag update cycle; the script fires within 1 update cycle of the trigger, not instantly.

Custom Objects: The Replacement Pattern

The recommended replacement for V7.3 faceplates when performance is critical is the Custom Object (also called a "User Object" in some Siemens literature). A Custom Object is a reusable graphic assembled from native Graphics Designer primitives, stored in the project library, and instantiated in process pictures with a small set of configurable properties.

A Custom Object for a motor might expose the following configurable properties:

• TagRunning (bit, bound to running feedback)
• TagFault (bit, bound to fault status)
• TagCmdStart (bit, bound to start command)
• TagCmdStop (bit, bound to stop command)
• BackgroundColor (color, optional, default green)
• Label (text, optional)

When the Custom Object is instantiated in a process picture, the engineer assigns each property to a specific tag via the standard tag-selection dialog (right-click on the instance -> Properties -> <PropertyName> -> ...). Updates propagate through the standard direct connection channel, which is much faster than the faceplate interface tag resolution path.

The cost of the Custom Object pattern is the loss of the centralized interface tag model: each tag binding is configured per instance, and changes to the prototype do not auto-propagate. This is the trade-off for the ~10x performance gain. For projects with 50 + instances, the engineering effort to re-bind properties is justified by the runtime performance improvement.

VBA Automation for Bulk Faceplate Updates

When a faceplate prototype is modified after instances have been deployed (a common occurrence in live projects), the engineer must update each instance. Doing this manually in Graphics Designer for 100 + instances is impractical. The standard solution is a VBA macro that walks every picture in the project and re-binds the affected properties.

A representative VBA macro for re-binding a renamed interface tag member across all open pictures:

' VBA macro in Graphics Designer
' Re-binds faceplate property "OldMember" to "NewMember" across all PDLs

Sub RebindFaceplateMember()
    Dim objProject As Object
    Dim objPicture As Object
    Dim objFaceplate As Object
    Dim sOldMember As String
    Dim sNewMember As String
    Dim i As Integer
    Dim n As Integer

    sOldMember = "OldMember"
    sNewMember = "NewMember"
    n = 0

    For i = 1 To Application.ActiveDocument.Pictures.Count
        Set objPicture = Application.ActiveDocument.Pictures(i)
        For Each objFaceplate In objPicture.FaceplateInstances
            If objFaceplate.InterfaceTagMember = sOldMember Then
                objFaceplate.InterfaceTagMember = sNewMember
                n = n + 1
            End If
        Next objFaceplate
    Next i

    MsgBox "Rebound " & n & " faceplate instances.", vbInformation
End Sub

The exact API surface (HMIPicture.FaceplateInstances, HMIFaceplate.InterfaceTagMember) varies between V7.2 and V7.3 service packs. The WinCC V7.3 SP3 VBA reference manual (available on the WinCC installation media under Documentation\VBA) documents the current object model. The major collections are Application.ActiveDocument.Pictures, HMIPicture.FaceplateInstances, HMIPicture.ObjectCollection, and HMIFaceplate.Properties.

For large projects, the macro should be run with WinCC in "Configuration only" mode (runtime stopped) to avoid conflicts with the running server. The same macro is then re-run on every client to keep configurations in sync. For project-wide re-binding (not just open pictures), the macro is wrapped in a For Each over the project picture list obtained from Application.Project.Pictures.

PCS 7 Block Icon Pattern as Reference Architecture

The PCS 7 (SIMATIC Process Control System 7) line of Siemens products uses a different concept called a block icon, which is the model that experienced V7.3 engineers adopt when migrating from faceplates to custom objects. In PCS 7, the typical screen is built around a central object - a single graphical instance per unit that displays all relevant process data. When a new unit is added, the engineer runs the "Create/Update Block Icons" command, which invokes a VBA script that populates the central object across all involved screens.

The same pattern is implemented in V7.3 projects as follows:

1. Define a "typical screen" with the central object laid out for one unit.
2. Build a VBA macro that, given a list of unit names and tag prefixes, instantiates the central object in each target picture with the appropriate tag bindings.
3. Run the macro on project creation and on every unit addition.
4. To modify the typical screen, edit the macro to update all instances in one operation.

The decision flow for selecting the right pattern in a V7.3 project is shown in the following diagram:

This is the pattern recommended in operational plants with many units (power plants, water treatment, batch processes) and is the established best practice for unit-rich projects in V7.3.

Migration to WinCC Unified Faceplates

For new projects or projects scheduled for a major upgrade, the recommended path is to migrate to WinCC Unified (TIA Portal). The Unified runtime addresses every V7.3 faceplate limitation documented in this article:

• Unlimited instances per screen, with performance scaled to the panel or SCADA server class.
• Tag-triggered VBScript fully supported on faceplate properties.
• Bit-setting actions propagate to underlying tags without the Output / InOut workaround.
• HMI Symbol Library compatible with faceplate prototypes.
• Bulk property updates via the TIA Portal "Update instances" command (no VBA required).

As documented in the WinCC Unified faceplate documentation:

"The number of faceplate instances in a screen is not limited. Note that the performance when opening or updating a screen is affected by the number of faceplate instances."

This caveat still applies in Unified, but the threshold at which performance becomes an issue is much higher (hundreds of instances on a Unified Comfort Panel, thousands on a Unified PC runtime) than in V7.3.

The migration path from V7.3 to Unified involves:

1. Re-creating faceplate prototypes in TIA Portal using the new faceplate editor (the PDL-based prototype is replaced with a Unified faceplate definition in the project tree).
2. Re-binding interface tags using the new structure tag system (Unified uses PLC user-defined data types directly).
3. Converting process pictures (PDL -> Unified screen XML).
4. Re-validating all actions and scripts (C scripts in V7.3 are replaced with VBScript in Unified; VBScript remains compatible but with a different runtime object model).
5. Re-validating all dynamic dialogs and animations (the expression syntax is similar but not identical).

For projects with heavy faceplate use (> 50 instances per picture), the migration is justified on performance grounds alone. The typical effort is 2 - 4 weeks for a 100-instance project, with most of the time spent on prototype re-creation and instance re-binding.

Performance Optimization Checklist and Troubleshooting Matrix

The following checklist summarizes the mitigation steps for V7.3 faceplate deployments:

1. Use Dynamic Dialog only inside faceplate prototypes. Avoid VBScript and C scripts unless strictly necessary.
2. If scripts are required, use the IO Field bridge pattern with an invisible field.
3. Declare faceplate tag members that the HMI writes as InOut, not Output.
4. Convert HMI Symbol Library references to a regular Graphics Designer library before embedding in prototypes.
5. For unit-rich projects, replace faceplates with Custom Objects or use the PCS 7 central object + VBA populate pattern.
6. For projects above 50 instances per picture, plan migration to WinCC Unified.
7. Always run WinCC Performance Monitor (Start -> Programs -> Siemens Automation -> WinCC -> Tools -> Performance) to measure update latency before commissioning.
8. Keep faceplate prototype complexity low: avoid nesting faceplates inside faceplates.
9. Use structure tags with 4 - 8 members; very large structure tags (16 +) compound the screen-open latency.
10. Configure the picture-change cycle to 500 ms in the project properties if operators report sluggish updates; the default 1 s cycle can be tightened for fast processes.

Troubleshooting Matrix

Verification Steps

1. Open WinCC Performance Monitor and start a trace with the counters Picture update time, Tag request time, and Action execution time enabled.
2. Open the target picture and measure the screen-open latency. It should be < 2 seconds for a picture with up to 30 faceplate instances.
3. Click each faceplate instance and confirm that the local state and the PLC tag value change together.
4. Trigger a tag change that should fire a VBScript and confirm the script executes within one update cycle (1 - 2 seconds).
5. Modify the faceplate prototype (change a color or label), save, and confirm the change is visible in all instances on next screen load.
6. Restart the runtime and re-open the same picture; confirm the latency is consistent (no memory-related degradation).

If any verification step fails, re-inspect the relevant row of the troubleshooting matrix and apply the corresponding resolution. If the issue persists after the recommended action, escalate to Siemens Industry Online Support (https://support.industry.siemens.com) with a project export and the Performance Monitor trace file.

Frequently Asked Questions