Using Multiple Structure Tags in WinCC Faceplate Pop-up Windows

Overview

Siemens WinCC (TIA Portal, Comfort Panels, Runtime Advanced, and WinCC RT Professional v7.5 SP1) supports the reuse of a single picture (PDL) or faceplate (FTP) across many process objects by binding tag names through a picture window's Tag Prefix property. The challenge arises when the same pop-up window must display data from two or more different structure tag instances simultaneously — for example, a motor block, a valve block, and an analog instrument block referenced from one diagnostic pop-up. The picture window prefix model only natively forwards a single tag prefix, so additional mechanism is required to address the second and subsequent structure instances.

This reference documents the three documented techniques for addressing multiple structure tags in a single WinCC pop-up or faceplate pop-up: leaving the picture window Tag Prefix empty and using fully-qualified struct.member names, using the @NOTP add-on to bypass the configured prefix on selected tags, and the @NOSP / @NOP server-prefix add-ons for distributed multi-user systems. The article also documents the official WinCC Unified (RT Unified) configuration of a faceplate invoked as a pop-up, which provides an alternative for TIA Portal V17 and later projects. Every claim in the runtime behavior section is derived from the WinCC v7.5 SP1 information system ("Requesting tags without prefix") and the Siemens TIA Portal Help documentation.

Prerequisites

• Siemens TIA Portal with WinCC RT Professional v7.5 SP1 or compatible, OR a TIA Portal project with WinCC Unified (V17 / V18 / V19 / V20) and an RT Unified runtime.
• At least two structure tags already created in the HMI tags table (e.g., Motor_1, Valve_1, AI_1) — each containing a comparable set of members (e.g., .Setpoint, .ActualValue, .Status).
• A picture window (PictureWindow object) in the calling screen.
• A pop-up picture (.pdl) and a faceplate definition (.fpt) configured in the project.
• Compilable project state (no unresolved tag references in the cross-reference).

Understanding Picture Window Prefix Behavior

When a picture window is placed on a process screen, the picture window's Tag Prefix property accepts a string that is prepended to every unqualified tag name inside the embedded picture. The runtime concatenates the prefix with the tag name at the point of evaluation. This is the mechanism that lets a single faceplate instance address Motor_1.Setpoint, Motor_2.Setpoint, etc., without duplicating graphics: each instance is just a picture window with a different prefix.

The Server Prefix property performs the same function for cross-server tag names in distributed HMI systems where tags live on partner servers rather than the local project. The two prefixes can be used independently or stacked, in the form [ServerPrefix::][TagPrefix::]tagname.

Because only one tag prefix and one server prefix can be configured per picture window, the runtime provides three documented tag add-ons that override the inherited prefix on individual tag references within the picture. These add-ons can be used inside any dynamization (direct tag connection, script, animation, faceplate property, or property of an object), but they are not valid in the picture window's Tag Prefix or Server Prefix property fields themselves.

Tag Add-on Syntax Reference

Configuration Variants Compared

Step-by-Step: WinCC v7.5 SP1 / RT Professional

Variant A — No Tag Prefix (Fully-qualified references)

1. Open the calling screen (the process screen that contains the picture window).
2. Select the picture window object and clear the Tag Prefix property — leave the field empty.
3. Open the pop-up picture (PDL). For every tag connection inside the pop-up that needs to read from a structure, enter the fully-qualified name, e.g. Motor_1.Setpoint, Valve_1.Setpoint, AI_1.Setpoint.
4. Compile the project. The cross-reference must show three tag references inside the pop-up, one for each structure member.
5. Use the simulator or the online runtime to confirm the three values update independently when you change each structure's data block.

Variant B — One Tag Prefix + @NOTP:: for the other structures

1. Set the picture window's Tag Prefix to the dot-terminated prefix of the primary structure, e.g. Motor_1..
2. Inside the pop-up, references to the primary structure are written without prefix: Setpoint, ActualValue, Status.
3. For each additional structure, prefix the tag name with @NOTP::, for example @NOTP::Valve_1.Setpoint, @NOTP::AI_1.Setpoint.
4. Compile and verify in the cross-reference that Motor_1 resolves through the prefix and that Valve_1 / AI_1 are referenced as fully qualified names.

Variant C — Server prefix and tag prefix stacked

1. On the picture window, populate Server Prefix with the partner-server name terminated by ::, e.g. ServerB::.
2. Set Tag Prefix to the structure prefix on that server, e.g. Plant1.Motor_1..
3. For tags that are not on ServerB or not under the inherited prefix, use @NOSP:: (drop server prefix only) or @NOP:: (drop both) on the individual tag reference.
4. Confirm that the HMI client runs its own project; otherwise @NOSP and @NOP are silently ignored and the tag is read with the prefix applied, which will fail at runtime.

Passing the Structure Name to the Pop-up

The pop-up is typically shown from a faceplate instance. To pass a different structure tag to the same pop-up from a single faceplate type, the recommended pattern is:

1. Add an interface tag of type String to the faceplate, e.g. PopupStruct, holding the structure name (for example Valve_1).
2. In the faceplate, build the pop-up tag reference by concatenating the string with the member: @NOTP:: + PopupStruct + .Setpoint. If the concatenation is performed in a script, store the result in an internal tag and read that internal tag in the pop-up — remember that the add-on only takes effect on tag references, not on internal variables used as intermediates.
3. At the moment the pop-up is called, populate the interface tag with the structure name of the object that the user clicked on. The pop-up then resolves the second structure without recompilation.

Verifying the Configuration

1. In the project tree, right-click the HMI device and choose Compile > Software (rebuild all). The compile log must show no errors of the form "Tag not found" or "Prefix could not be resolved".
2. Open the cross-reference (right-click on a structure tag → Cross-reference). Confirm that the pop-up picture is listed as a user of every member of every structure it is supposed to read.
3. Start the WinCC Runtime and trigger the pop-up from at least one faceplate instance of each structure type (motor, valve, AI). For each trigger, confirm that the values shown in the pop-up match the values of the originating structure, not of a sibling instance.
4. Change a value in one structure (e.g., Motor_1.ActualValue) from the PLC. Confirm that the value updates only in the pop-up instance triggered by Motor_1 and not in the instance triggered by Valve_1.
5. If a standard server is in use on a multi-user system, deliberately attempt to use @NOSP:: or @NOP:: and confirm in the trace that the add-on has no effect — this is the documented limitation and the correct behavior.

WinCC Unified (RT Unified) — Faceplate as Pop-up

On TIA Portal V17 and later with WinCC Unified, the faceplate-as-pop-up model is configured through the Unified faceplate interface rather than the legacy @NOTP add-on syntax. The general flow, per the Siemens TIA Portal Help ("Configure faceplate as pop-up (RT Unified)", V20 documentation set), is:

1. Create the main faceplate type, e.g. Faceplate_1, in the faceplate editor.
2. Create a second faceplate type that will act as the pop-up, e.g. Popup_1.
3. Define the same interface tags on both faceplate types. The interface tag of the pop-up is automatically populated with the value of the corresponding interface tag of the calling faceplate at the moment the pop-up opens.
4. From the main faceplate, trigger the pop-up by a button or script that opens Popup_1. The data flow is one-to-one through the interface, so the same pop-up can show data from a motor, a valve, or an AI block simply by changing which faceplate instance opens it.
5. To show data from a second structure in the same pop-up, add a second interface tag on the pop-up and bind it to a property of the calling faceplate. If the calling faceplate needs to forward a value from a sibling structure, expose that sibling structure as a separate interface tag on the calling faceplate and bind the pop-up's second interface tag to it.

Reference: Configure faceplate as pop-up (RT Unified) — TIA Portal V20 documentation

Troubleshooting Matrix

Best Practices and Field-Proven Constraints

• Pick Variant A (no prefix, fully-qualified names) when the pop-up needs to read from a small, fixed set of structures and you want to keep the cross-reference readable.
• Pick Variant B (one prefix + @NOTP overrides) when the pop-up is dominated by one structure and only occasionally shows data from others.
• Avoid mixing @NOTP:: and a real prefix in the same property of the same object: a single tag connection accepts one prefix, and the add-on must be the only prefix for that connection.
• When migrating a v7.5 SP1 project to WinCC Unified, replace the picture window prefix mechanism with faceplate interface tags. The @NOTP add-on syntax is part of the Comfort / RT Professional runtime and is not used in Unified faceplate properties.
• Document the chosen variant in the HMI tag naming convention. Standard Siemens naming usually reserves the prefix field for the most frequently referenced structure and uses @NOTP:: for outliers.