Resolving WinCC Faceplate Open Failures Across Screen Changes

Faceplate visibility failures in WinCC Unified and WinCC Comfort/Advanced are among the most common runtime defects reported after an S7-400 to S7-1500 (or S7-400 to S7-400) migration. The defect pattern is highly consistent: an operator opens a faceplate from screen A, navigates to screen B without closing the faceplate, and the "open faceplate" command on screen B is silently ignored. The faceplate only becomes operable after the operator cycles through a third screen and returns. This article documents the three engineering root causes of that pattern, the diagnostic workflow to isolate them, and the corrective actions for each case, with explicit attention to faceplate version consistency in TIA Portal V20 and to the binary-tag latch pattern that is the single most common cause.

1. Problem Definition and Observable Symptoms

Symptom bundle as reported in the field and reproducible in any TIA Portal project that follows the standard "open faceplate from process screen" design pattern:

1. Operator presses a configured button on screen A. Faceplate instance opens and displays the correct tag values.
2. Operator triggers a screen change (button, area pointer, or job mailbox) to screen B. The base screen B is rendered correctly.
3. Operator presses the equivalent faceplate-invoke button on screen B. No faceplate is rendered, no error is logged in the diagnostic viewer, and no alarm/event is raised.
4. Operator navigates to a third, unrelated screen and back to screen B. The faceplate-invoke button now functions as expected.
5. Conversely, if the operator closes the faceplate from screen A (using the configured close button or the X button on the faceplate window) before navigating to screen B, the faceplate opens immediately and correctly on screen B.

This pattern is consistent across WinCC Comfort/Advanced V15.1 through V18 (TIA Portal) and across WinCC Unified V16 through V20. The defect is most often introduced during a controller migration, when a previously correctly behaving faceplate population is ported to new HMIs with new PC-RT stations, but it can appear in greenfield projects as well.

2. Root Cause Architecture

Three independent defects produce the same observable symptom. Each must be ruled out in sequence before the next is examined.

3. Root Cause 1: Binary Tag Latch (Most Common)

The binary tag latch pattern is the cause in roughly 70% of field reports. It is the most common because it is the most concise configuration: a single HMI tag, a SET on open, a RESET on close. It is also the most fragile, because it has no awareness of which screen the launch originated from.

3.1 Mechanism in Detail

The faceplate is configured with an "Appearance / Visibility" animation bound to an internal HMI Boolean tag (conventionally named Faceplate_Visible, ShowFaceplate, or similar). The invoke button on every process screen is configured with the event "Click" → "SetBit" → Faceplate_Visible = 1. The faceplate's own close button is configured with the event "Click" → "ResetBit" → Faceplate_Visible = 0.

Step trace on a single shared HMI tag across two screens:

1. t=0 ms: Operator on screen A clicks invoke button. Faceplate_Visible is SET to 1 by the SET event.
2. t=50 ms: Visibility animation evaluates to TRUE. Faceplate instance A is rendered in the picture window.
3. t=2000 ms: Operator triggers screen change to screen B. The visibility animation for faceplate A is no longer evaluated (the picture window is unmounted or the screen B body replaces screen A's body). The tag Faceplate_Visible is still 1 because nothing has reset it.
4. t=2050 ms: Operator on screen B clicks invoke button. The SET event is evaluated against Faceplate_Visible but the tag is already 1. The HMI engine does not re-fire the event because the tag state is unchanged (no 0→1 edge).
5. t=2100 ms: No faceplate is rendered on screen B. The diagnostic viewer reports nothing because no fault occurred.
6. t=15000 ms: Operator navigates to screen C, then back to screen B. The visibility animation may re-evaluate, or the tag may be reset by an unrelated animation. The launch condition re-evaluates cleanly and the faceplate appears.

3.2 Diagnostic Procedure

To confirm the binary tag latch pattern, perform the following in Runtime on the target HMI:

1. Open the HMI tag table view (or WinCC tag browser for Unified) and add a watch on Faceplate_Visible.
2. Click the invoke button on screen A. Confirm the tag transitions 0 → 1.
3. Trigger a screen change to screen B. Do not click any button. Read the tag. It must still read 1.
4. Click the invoke button on screen B. Read the tag. If the value remains 1 with no transition (and no second faceplate is rendered), the binary tag latch is confirmed.
5. As a final confirmation, manually force Faceplate_Visible = 0 from the tag browser. Click the invoke button on screen B. The faceplate now opens.

3.3 Corrective Solutions

Five corrective patterns are in field use. Each has a different trade-off between engineering complexity, scan time, and screen-change resilience.

Solution 1A: Toggle the tag on the invoke event

Configure the invoke button with "InvertBit" instead of "SetBit." The faceplate's close button uses "InvertBit" as well. The tag now toggles on every press, so a second press on a different screen will toggle the visibility OFF, then OFF (or ON, then ON) with edge detection handled correctly. Code fragment for the button event in the Comfort/Advanced configuration dialog:

Event: Click
Function: InvertBit
Tag: Faceplate_Visible

Solution 1B: Use a screen-index tag as a per-screen latch

Replace the single Boolean with a 16-bit integer (INT) tag that encodes both visibility and the originating screen. The invoke button writes (CurrentScreen * 10) + 1. The faceplate's close button writes 0. The visibility animation is bound to a script that returns TRUE only when the tag is non-zero AND the current screen matches the screen stored in the upper bits. This pattern is uncommon in the field because it requires script work, but it scales to N faceplate types without tag multiplication.

Solution 1C: Reset the tag on the screen-change event

Add a "Change picture" event to the source screen that executes ResetBit Faceplate_Visible prior to the picture-change function. This guarantees the tag is cleared on every screen transition, at the cost of one extra PLC scan per transition. The PLC scan load is negligible for a single bit; the engineering cost is a per-screen configuration change.

Solution 1D: Edge-triggered tag (WinCC Unified only)

WinCC Unified V17 and later supports a tag trigger configuration that fires on the 0→1 edge of the tag rather than the steady-state value. Configure the invoke button to SET the tag, but bind the visibility animation to "OnChangeOfTag.Faceplate_Visible" with a script that sets a second internal visibility bit only on the edge. This decouples the trigger from the state and matches modern event-driven SCADA paradigms.

Solution 1E: Scripted faceplate invocation

For Unified projects, write a VBScript or C# script on the invoke button that:

1. Checks HMIRuntime.Tags("Faceplate_Visible").Read().
2. If TRUE, calls HMIRuntime.UI.Screens.Item(ScreenName).ScreenItems("PictureWindow_1").ScreenItems("Faceplate").Close() first, then opens the new instance. This pattern is the most robust but requires scripting discipline and a consistent faceplate container name.

Sub OnClick(ByVal item)
  Dim pw
  Set pw = HMIRuntime.ActiveScreen.ScreenItems("PictureWindow_1")
  If pw.Visible = True Then
    pw.Visible = False
  End If
  pw.Visible = True
  pw.ScreenName = "Faceplate_Motor"
End Sub

4. Root Cause 2: Single Shared Picture Window

The picture window object in WinCC Comfort/Advanced (and the equivalent in WinCC Professional) is a single embedded container that can host one child screen at a time. When multiple faceplate-invoke objects on different process screens all reference picture window number 1, the runtime allocates the first invocation to that window and discards the second.

4.1 Mechanism in Detail

The picture window object is configured on every process screen with a fixed window number (Window 1, Window 2, ... Window 32 in the 16:9 panels; up to 32 windows on a Comfort Panel). Each faceplate type is mapped to a specific window number. If faceplate type "Motor" is mapped to window 1, and the invoke buttons on screens A and B both reference "Window 1 - Motor," then:

1. Screen A is loaded. The invoke button sets the picture window's PictureName to "Faceplate_Motor" and Visible = TRUE.
2. Screen change to screen B. The picture window state is preserved across screen changes in Comfort/Advanced (this is by design; picture windows are global to the runtime).
3. Invoke button on screen B attempts to set the picture window's PictureName to the same value and Visible = TRUE. The runtime sees no state change and does not re-render.

4.2 Diagnostic Procedure

1. Open the screen A configuration. Note the picture window name and number used for each faceplate-invoke object.
2. Open the screen B configuration. Compare the picture window assignment.
3. If both screens use the same picture window number for the same faceplate type, this root cause is confirmed.
4. Alternative confirmation: temporarily configure the invoke button on screen B to open faceplate type "Valve" instead of "Motor." If the valve faceplate opens correctly, the picture window assignment for the motor faceplate is the problem.

4.3 Corrective Solution

Assign a unique picture window number per faceplate type. The standard allocation for a typical process plant project is:

After changing the picture window number on screen B, recompile the HMI and download the full runtime (not a delta). The picture window assignment is part of the runtime image, not a runtime-modifiable property.

5. Root Cause 3: Faceplate Version Inconsistency (TIA Portal V20)

Faceplate versioning was introduced in TIA Portal V16 and extended in subsequent releases to support faceplate version consistency checks. The intent is to allow a faceplate type to be revised without forcing a full re-download of every HMI that uses it. The unintended side effect is that a faceplate instance that was generated against version 1.0 of a faceplate type may be silently desynchronized from version 1.1 if the version was not explicitly released.

5.1 Mechanism in Detail

When a faceplate type is edited in the TIA Portal faceplate editor, the change is recorded as an unreleased version. The instances on every HMI screen continue to reference the prior released version. If the HMI is compiled and downloaded while the faceplate is in an "in edit" state, the following can occur:

• The faceplate type is marked as version-inconsistent in the project tree.
• The HMI compiler emits a warning or, in strict mode, an error.
• The runtime loads the faceplate type with the prior interface signature, but the instance's bound tags may have been renamed or retyped in the meantime.
• The faceplate's launch condition (visibility animation) evaluates against the stale interface and aborts cleanly, producing the same observable symptom as the binary tag latch.

5.2 Diagnostic Procedure

From the TIA Portal project tree:

1. Expand PLC > HMI > [HMI station] > Screens > Faceplates.
2. Look for faceplate types marked with a yellow or red icon. The yellow icon indicates "in edit, not released." The red icon indicates "version inconsistent with at least one instance."
3. Right-click the faceplate type and select "Manage versions." The version manager dialog lists all released versions and the working copy.
4. Compare the working-copy interface to the released version. Pay particular attention to renamed, removed, or re-typed tags.
5. Right-click the faceplate type and select "Check version consistency." TIA Portal reports each instance that is out of sync with the released version.

5.3 Corrective Solution

Per the official TIA Portal V20 documentation on checking and fixing version inconsistencies:

1. Open the faceplate type in the faceplate editor.
2. Reconcile the working copy with the released version: either accept the working copy as the new released version (release it), or revert the working copy to the last released version.
3. If a new release is required, click "Release version" and provide a version comment that documents the interface change.
4. Right-click each inconsistent faceplate instance and select "Update to current faceplate version." The instance is regenerated with the new interface.
5. Recompile the HMI and download the full runtime. Verify that all faceplate types in the project tree are marked with the green (consistent) icon.

6. Diagnostic Workflow Summary

Run the following sequence to isolate the root cause in under 10 minutes for most projects:

7. HMI Tag Configuration Reference

The following HMI tag configuration is the recommended baseline for new WinCC Unified and Comfort/Advanced projects that need to support cross-screen faceplate invocation.

The 250 ms cycle time referenced in the source report is well within the recommended range for a faceplate visibility tag. Acquisition cycle should not exceed 500 ms; faster than 100 ms is unnecessary because human operator response time is on the order of 200 ms minimum.

8. Picture Window Configuration Reference

For WinCC Comfort/Advanced, the picture window object is configured per screen with these mandatory properties:

• Window number: unique per faceplate type. Range 1-32 on Comfort Panels.
• Picture Name: the faceplate screen name. Convention: prefix with FP_ to distinguish from process screens (e.g., FP_Motor, FP_Valve).
• Tag prefix: the HMI tag or PLC DB block prefix that supplies the faceplate's instance data. Conventionally the equipment P&ID tag (e.g., DB100.Motor_01A).
• Adapt to picture: TRUE. The picture window resizes to fit the faceplate screen content.
• Border: TRUE for a modal-style faceplate, FALSE for a sidebar faceplate.
• Close button: configure the faceplate's close button to set Visible = FALSE on the picture window. Do NOT close the picture window; hiding it preserves the tag prefix binding for the next invocation.

9. Cycle Time and Performance Considerations

Increasing the HMI update cycle to 250 ms (as the source report indicates) reduces PLC scan load and reduces HMI-RT CPU utilization, but it has a side effect: the visibility animation re-evaluates at most 4 times per second. If the operator presses the invoke button on screen B within 250 ms of the screen change, the visibility evaluation may not have run yet, and the second SET event may be missed.

Recommended configuration for projects that need to support fast cross-screen faceplate invocation:

10. Verification Procedure

After applying any of the corrective solutions, perform the following verification sequence on the engineering station and on the production HMI:

1. Recompile the HMI project. Confirm zero warnings and zero errors in the HMI compiler output. A persistent warning about faceplate version inconsistency indicates Solution 5 was not completed.
2. Download the full runtime (not delta) to the HMI or to the PC-RT station. The full download is required because the picture window configuration is not a runtime-modifiable property.
3. On the engineering station, open the HMI runtime simulation. Click the invoke button on screen A. Verify the faceplate opens.
4. Without clicking the close button, trigger a screen change to screen B. Click the invoke button on screen B. Verify the faceplate opens immediately.
5. Trigger a screen change to screen C, then back to screen B. Click the invoke button on screen B. Verify the faceplate opens immediately.
6. Close the faceplate on screen B. Verify that the Faceplate_Visible tag has returned to 0 (or that the equivalent state has been cleared) by checking the tag browser.
7. Repeat steps 3-6 for every faceplate type configured in the project. The test must cover every faceplate type because the picture window allocation is per-type.

11. Edge Cases and Field-Reported Anomalies

Edge case 1: Faceplate opens but with stale data. The visibility animation fires correctly but the tag prefix binding is preserved from the prior invocation. Symptom: operator on screen B opens the motor faceplate for motor 02A, but the faceplate displays motor 01A's data. Root cause: the picture window's Tag prefix property was not updated by the invoke button. Corrective: configure the invoke button to set the picture window's Tag prefix property in addition to the visibility property, or use a script to do both atomically.

Edge case 2: Faceplate renders but is positioned off-screen. The picture window is anchored to the upper-left of the process screen. On screens with a different layout origin, the faceplate is rendered outside the visible area. Root cause: picture window position is absolute, not anchored. Corrective: use a screen-relative coordinate system and verify the picture window position on every screen variant.

Edge case 3: Faceplate opens correctly in RT simulation but not on the physical panel. The HMI runtime version on the physical panel is older than the engineering station's compiled runtime. Root cause: full download not performed. Corrective: perform a full download, including the operating system image if the panel firmware is older than the engineering project expects.

Edge case 4: Faceplate works on Monday but fails on Tuesday. The HMI was restarted overnight and a backup configuration was loaded. Root cause: a scheduled restore job is reverting the runtime to a prior backup. Corrective: inspect the HMI's auto-restore and backup configuration. Disable scheduled restore during commissioning. TIA Portal supports scheduled backups via the HMI's "Backup/Restore" settings; these should be coordinated with the runtime deployment schedule.

12. Migration-Specific Notes: S7-400 to S7-1500 (or S7-400 to S7-400)

The source report explicitly references a scenario where an existing S7-400 was replaced. Migration is a high-risk event for faceplate defects for three reasons:

1. DB block number changes: The S7-1500 typically uses different DB block numbers than the S7-400, even if the data layout is identical. The faceplate's tag prefix binding is by DB number and offset; a DB number change is invisible to the faceplate type but fatal to the instance.
2. UDT instance name changes: The S7-1500 supports symbolic UDT instance names. If the faceplate was originally bound by absolute address, the migration to symbolic addressing may break the binding silently.
3. HMI station firmware and configuration: A new PC-RT station is typically deployed alongside the new PLC, with new IP addresses, new HMI connections, and a fresh image. The faceplate population is regenerated from the new project's screen objects. If the faceplate type was edited between the original and the new project, the version-consistency check (per TIA Portal V20 faceplate version management) will flag the inconsistency.

Recommended post-migration verification sequence: repeat the full verification procedure in Section 10 on the new HMI, with a specific focus on the faceplate instances that bound to DB blocks whose numbers were renumbered. A DB block number change must be reflected in the faceplate's tag prefix binding on every screen that uses the faceplate.

13. Frequently Asked Questions