WinCC Unified V19 Faceplate Resource List Empty in ES Mode

Problem Overview

In TIA Portal V19 with SIMATIC WinCC Unified, a faceplate that uses a Symbolic IO Field driven by a resource list shows an empty placeholder square during Engineering System (ES) design mode, even though the runtime visualization displays the correct icon set. The pattern is the one most teams adopt when consolidating valve, pump, motor, fan, and damper representations into a single, parametrized faceplate:

1. One faceplate instance per equipment unit on the process screen.
2. A configuration interface (TagPrefix, ObjectType, or a custom interface tag) selects the equipment family.
3. A Symbolic IO Field inside the faceplate references a resource list whose entries map index or bit-pattern values to graphics files.

At runtime, the Symbolic IO Field evaluates the resource list against the configured tag and renders the selected graphic. During design mode, the field collapses to a flat gray rectangle with no indication of the graphic that will appear. Positioning process connections (inlets, outlets, vents, drains, cable entries) becomes guesswork, and pipeline primitives rarely line up with the graphic body on the first iteration.

Affected Versions and Configuration

The issue is reproducible in WinCC Unified V19 inside TIA Portal V19 (Updates 1 through 5 at the time of writing). Components typically involved:

The behavior has been confirmed by Siemens specialists and large end users as an explicit limitation of the V19 engineering preview. According to feedback on Siemens Industry Online Support, the missing feature - rendering the active faceplate variant directly in the editor based on the current configuration tag - is a candidate for delivery in TIA Portal V20.

Architectural Background: Faceplates and Resource Lists

WinCC Unified faceplates are reusable screen objects that expose a typed interface. The interface can include properties, events, and methods. Properties can be bound to tags, scripts, or constants; events fire on operator actions; methods allow reusable logic. The faceplate canvas itself is a layered composition of standard HMI elements (Graphic View, Symbolic IO Field, Button, Bar, etc.).

A resource list is a centralized table that maps a numeric or bit-pattern value to a graphic file. When a Symbolic IO Field is configured with a resource list, the field evaluates the current value of its bound tag at render time, looks the value up in the resource list, and displays the matching graphic. Resource lists are commonly used for state indicators (valve open/closed/fault), mode indicators (manual/auto/service), and equipment-class indicators (valve/pump/fan).

The key architectural fact behind this issue is that resource lists are evaluated only at runtime. The WinCC Unified editor does not simulate tag values for faceplate instances, so any element that depends on a runtime tag will appear blank during design. This includes resource lists, animation triggers that depend on tag values, dynamic SVG swapping, and visibility animations driven by external tags.

The faceplate container itself, on the other hand, does display its static layers (frame, name, units, fixed-position labels) because those are bound to static interface properties or are drawn directly into the canvas without a runtime dependency.

Root Cause

WinCC Unified V19 evaluates the resource list binding only at runtime. In the editor, the Symbolic IO Field is initialized with an empty resource state for three reasons:

• The configuration interface of the faceplate is not yet bound to a tag instance on the screen when the faceplate is first placed; therefore, the resource list lookup has no input value.
• Even after binding, the design surface does not re-evaluate the Symbolic IO Field on every property change. The evaluation is decoupled from the editor's update cycle.
• The resource list contents themselves are not embedded in the design-time preview; only the bounding rectangle of the Symbolic IO Field is shown. The editor cannot render a graphic it has not resolved.

The result is a rectangle that reflects the screen-space footprint of the element but contains no graphic content. The faceplate container, by contrast, displays its static layers because those are bound statically through interface properties.

Reproducing the Issue

1. Open or create a TIA Portal V19 project with a WinCC Unified device (HMI Unified Comfort Panel or Unified PC).
2. Create a faceplate type with a Symbolic IO Field on its Default view.
3. Open the resource list for the Symbolic IO Field and assign graphics files (for example valve_2way.png, pump_centrifugal.png, fan_axial.png) to indexes 0, 1, and 2.
4. On the process screen, place two faceplate instances and bind the configuration tag to 0 on one and 1 on the other.
5. Switch to runtime simulation - both graphics appear correctly and switch as expected.
6. Return to the editor - both instances display an empty square. Move them on the screen: the bounding rectangle is selectable, but the inlet and outlet edges of the graphic are invisible, so pipeline alignment is impossible.

Workaround Strategy Overview

The goal of every workaround is to give the editor something it can render that approximates the runtime appearance well enough to align process connections. Three practical methods are in use. Each is described below with implementation details.

Workaround A - Position-Mark Graphics with Visibility Animation

This is the recommended approach for projects that need a single faceplate type for many equipment families. The idea is to overlay small, semitransparent markers on the inlet and outlet edges of the equipment graphic, then hide the markers in runtime with a tag-driven visibility animation.

Step-by-step procedure

1. Inside the faceplate Default view, draw four small rectangles (or use a single SVG group) at the exact pixel coordinates where the inlet and outlet pipes must connect. Label them: InletTop, InletBottom, OutletTop, OutletBottom.
2. Fill the markers with a high-contrast color (magenta or cyan) and reduce opacity to 30% so they do not dominate the view.
3. Create a project-wide HMI tag of type Bool named @PLCMarker_Visible. Use the @ prefix to mark it as a local HMI tag with no PLC counterpart.
4. In the faceplate interface, add a property ShowPositionMarkers of type Bool and map it to @PLCMarker_Visible at the screen level on each instance.
5. Animate the visibility of each marker with the expression ShowPositionMarkers == 1. The markers render only when the flag is true.
6. To design the screen, set @PLCMarker_Visible = 1, place the faceplate so the markers line up with the pipeline graphics on the page, then set @PLCMarker_Visible = 0 before the runtime test.

The markers are independent of the resource list, so they always display in the editor - even on V19 where the Symbolic IO Field is blank. The markers also remain visible during runtime as long as the flag stays high; setting the flag to 0 hides them before the panel is shown to operators.

SVG reference of a 2-way valve faceplate

The following inline SVG illustrates the geometry of the position markers relative to the bounding rectangle of the Symbolic IO Field. Use it as a sizing guide when porting the workaround to your own library.

Coordinates (40,80) and (280,80) are the exact connection points you must align with your pipeline primitives. Adjust the coordinates to match the actual icon footprint of your equipment class.

Reset script example

Add the following JavaScript snippet to the project's Global script so that the marker flag is forced to 0 on every HMI boot:

// Force position markers off on HMI startup
HMIRuntime.Trace("Resetting @PLCMarker_Visible");
Tags("@PLCMarker_Visible").Write(0);

Place this snippet in the project's Global module under a startup event listener. This eliminates the operator-exposure risk described above.

Workaround B - Default Static Image Bound to Interface

For libraries where the same equipment class is drawn in many variants (for example, a pump with three different impeller styles), you can ship the faceplate with a default graphic that is stored in the faceplate interface as a static image. The design-time editor shows the static image, while the runtime swaps to the resource-list graphic via the Symbolic IO Field.

Procedure

1. Add a "Static design graphic" layer (regular Graphic View element) on top of the Symbolic IO Field in the Default view.
2. Bind the static layer's Graphic property to an interface property of type String called DesignGraphic.
3. Set the visibility animation of the static layer to Runtime == 1 (or any property that is guaranteed 0 in production). Place the static layer at the bottom of the z-order so the Symbolic IO Field renders on top.
4. When placing the faceplate, the editor shows the static image, which the designer can use for alignment.
5. At runtime, the static layer disappears and the Symbolic IO Field takes over with the resource-list graphic.

This method is more robust than the position-mark approach because it does not depend on a project-wide tag. The trade-off is that the designer must remember to set the correct DesignGraphic value when copying faceplates between screens or between projects.

Workaround C - Dedicated Faceplate per Equipment Type

If neither A nor B is acceptable - typically when the project demands WYSIWYG fidelity in the editor - create one faceplate type per equipment family. The Symbolic IO Field still renders blank during design, but the surrounding static graphics (frame, label, connection stubs) are drawn directly into the faceplate canvas, so the editor preview matches the runtime appearance closely.

Library governance overhead grows linearly with the number of equipment classes, so this approach is best for projects with fewer than ten distinct families. For larger libraries, prefer Workaround A and accept the empty editor preview.

Resource List Configuration Best Practices

Regardless of which workaround you adopt, the underlying resource list must be configured correctly. The following settings prevent additional issues at runtime and at design.

Verification Checklist

After applying a workaround, run the following checks before sign-off:

1. Editor preview: open the screen, confirm the markers (Workaround A) or the static graphic (Workaround B) are visible without running the simulation.
2. Runtime simulation: start the WinCC Unified runtime simulator, verify that the resource-list graphic appears and overlays the static layer correctly.
3. Tag reset: confirm @PLCMarker_Visible (Workaround A) is 0 before downloading. Use the HMI tag table to inspect.
4. Compile and download: perform a full rebuild and a panel download. The faceplate type must appear in the consistency check log without warnings.
5. Visibility audit: enable all tag-driven animations in a test runtime and step through every state to ensure markers disappear and the Symbolic IO Field reappears at runtime.
6. Panel firmware check: confirm the panel firmware matches the TIA Portal version (19.0.0.x for V19 projects). Mismatched firmware causes inconsistent behavior between PC simulator and panel.

Troubleshooting Matrix

V20 Roadmap and Migration Path

Based on the Siemens Industry Online Support feedback channel, the design-time preview of faceplate properties (including resource-list-driven Symbolic IO Fields) is a planned improvement targeted for TIA Portal V20. Until V20 ships, the workarounds above are the recommended engineering practices.

For projects that cannot wait for V20, evaluate the WinCC Unified V19 Update 5 or later maintenance release notes on the SIMATIC WinCC Unified V19 system manual entry page - Siemens occasionally delivers editor-side fixes inside maintenance updates that are not announced as major new features.

When migrating to V20, plan the following:

• Re-validate every faceplate with a resource list against the V20 editor to confirm preview fidelity before removing the workaround markers.
• Re-export resource lists if the V20 release introduces new graphic format support or folder conventions.
• Retire Workaround A or B only after a signed-off design walkthrough on the V20 editor; do not strip markers based on assumptions.
• Keep the position-mark graphics in a separate faceplate layer so they can be removed with a single visibility change during the migration.

Best Practices for Faceplate Library Design

1. Decouple connection geometry from graphic content. Always expose inlet and outlet coordinates as explicit interface properties, never derive them implicitly from the graphic bitmap. The position-mark approach relies on this decoupling.
2. Version the faceplate library alongside the project. Use a folder structure such as /Library/Faceplates/V19/ so that V20 migration only affects one folder.
3. Adopt a tagging convention. Use prefixes like @FP_ for faceplate-only project tags to keep visibility animations separate from process tags. Local HMI tags with @ prefix have no PLC counterpart and cannot be accidentally driven by controller logic.
4. Document state maps. For each resource list, attach a table (in the project documentation) mapping index/value to graphic file and equipment state. This avoids guesswork during commissioning.
5. Test on a Unified Comfort Panel. The PC runtime simulator sometimes behaves differently from the panel firmware, especially for SVG rendering. Validate on the actual target device before sign-off.
6. Cap the number of states per resource list. Lists with more than 16 entries are harder to maintain and increase the risk of index drift; split into multiple lists (for example, "equipment class" and "equipment state") when the count grows.
7. Avoid runtime modification of resource lists. Resource list contents are baked into the compiled project; modifying them at runtime is not supported and triggers consistency warnings.

Alternative Platforms Comparison

Engineers migrating from WinCC Professional V17/V18 or from third-party SCADA packages often assume that WinCC Unified inherits the same design-time fidelity. It does not, at least not in V19. Comparable systems behave as follows:

The pattern is therefore not unique to Siemens - several next-generation HMI platforms made trade-offs that delayed full design-time fidelity in favor of runtime performance. The trade-off is expected to reverse in subsequent releases.

Edge Cases and Field-Proven Caveats

• Layer ordering matters. If the position-mark layer (Workaround A) is drawn above the Symbolic IO Field in the z-order, the markers cover the runtime graphic. Place the markers below the Symbolic IO Field so the runtime graphic paints on top.
• SVG with embedded raster. Some SVG files produced by CAD tools embed raster previews that are ignored at runtime but still inflate the compiled project size. Strip raster previews before importing SVGs into the resource list.
• Tag-prefix collision. If two faceplates on the same screen bind to the same ShowPositionMarkers property, toggling the flag affects both. Use one flag per faceplate, or accept that all markers toggle together during design.
• Multi-language projects. Resource lists are language-neutral. If you need different graphics per language, use multiple resource lists and a language-switch script that rebinds the Symbolic IO Field.
• Project upgrade from V18 to V19. Existing faceplates from V18 continue to work in V19 but do not gain the V20 preview. The workarounds apply unchanged to upgraded projects.
• Unified Comfort Panel performance. Each resource list graphic is loaded on demand; on panels with limited RAM (for example, MTP700), keep the number of unique graphics under 200 to avoid out-of-memory errors during runtime.
• Faceplate-type propagation. Changes to the faceplate type in the library are propagated to instances on next compile. If an instance still shows the empty square after a compile, right-click the instance and select Update faceplate type.

Commissioning Procedure

When handing the project over to operations, follow this procedure to ensure the workaround does not leak into the production HMI:

1. Set @PLCMarker_Visible = 0 in the HMI tag table.
2. Compile the project in TIA Portal V19 with the "Compile and check consistency" option.
3. Open the consistency log and confirm zero warnings related to the faceplate type or the resource list.
4. Perform a panel download with the "Overwrite all" option.
5. Restart the panel and confirm the boot sequence completes without errors.
6. Verify on the panel that no markers are visible and that the resource-list graphics appear correctly.
7. Document the workaround in the project handover package, including the marker coordinates and the reset script.