WinCC v6 Tag Prefix for Reusable Motor Popup Faceplates

Overview

Reusing a single popup Picture Window as a faceplate for 40+ motors in WinCC V6 is the canonical use case for the Tag Prefix property. The motor overview screen hosts one Picture Window object per visible row, but the PDL loaded inside the Picture Window is shared. When the operator clicks a motor, a short ANSI-C action pushes the structure-tag instance name (e.g., MOTOR001) into the Picture Window's Tag Prefix and toggles Visible. Inside the popup PDL, every tag is referenced by suffix only (e.g., .ACTIVATION, .CMD, .State). WinCC concatenates Prefix + Suffix at runtime, producing fully qualified reads and writes such as MOTOR001.ACTIVATION.

This pattern collapses 40+ popup designs into one, eliminates duplication of C-scripts and graphics, and centralizes faceplate maintenance. It also generalizes to valves, drives, conveyors, and any other object that maps cleanly to a UDT-style structure tag. The same mechanism is preserved in WinCC V7 and is the conceptual ancestor of the Faceplate type in TIA Portal / WinCC Professional, which extends the model with multi-instance tag prefixes, container events, and a typed Property interface.

Prerequisites

• Runtime: WinCC V6.0 SP4 or later. The Tag Prefix mechanism was introduced in V6.0 and is unchanged in V6.2 and V6.2 SP2. Verify the build in WinCC Explorer → Help → About; record the build number and KB install ID for audit purposes.
• Authoring tools: WinCC Explorer with Graphics Designer, Tag Management, and the ANSI-C editor (not VBScript). C-scripts are required to call SetTagPrefix and SetVisible at runtime; VBScript in V6 does not expose these picture-window APIs directly.
• Project state: Structure tag type defined, structure instances created, and motor overview PDL saved at least once. The Tag Management editor must be opened at least once per project to generate the internal tag database consumed by the Graphics Designer.
• License budget: Each Picture Window instance on a screen counts against the WinCC Runtime license. Set Computer → Properties → Runtime → Number of Picture Windows to a value at or above the maximum number of simultaneously visible popup slots. Under-provisioning causes WinCC to silently drop Picture Windows in Runtime and produce a generic "Pictures are not displayed" system event.
• Popup screen allocation: If the popup is opened as a modal Picture Window (always-on-top with input focus), confirm the Graphics Designer Window Properties → Independent flag is set so the popup does not share the parent's input focus chain.

Architecture: Structure Tags, Picture Windows, and the Tag Prefix Concept

The pattern is built on three components that are unaware of each other at design time and become bound only at runtime.

Three engineering rules follow from this binding model:

1. The prefix is per-instance, the suffix is per-faceplate. Author the popup once with suffix-only references. Drive the prefix from whichever motor object fires the click event.
2. The prefix is text, not a tag. It is a string concatenated to suffix text by the runtime tag resolver. A structure tag of the wrong type will therefore silently fail with a "Tag not found" diagnostic in the WinCC diagnostics window.
3. Dot placement is a project convention. The dot is neither mandatory nor syntactic; it is purely a separator that prevents MOTOR001 from running into ACTIVATION. Pick one rule for the project and enforce it via naming policy.

Defining the Motor Structure Tag

The motor structure is the contract between the controller (PLC), the WinCC tag database, and the popup faceplate. Author it once, instantiate 40+ times, and let both the overview screen and the popup bind to the same instance names.

Open Tag Management → right-click → Add New Structure Type. The minimum field set is below; expand to match the process. Tag names are case-sensitive in WinCC and on the controller, so pick a casing convention (upper-snake is conventional for SCADA tags).

Instantiate the structure 40+ times: MOTOR001, MOTOR002, … MOTOR042. The naming convention should match the controller's instance DBs (typically DB1001 for MOTOR001, etc.) so the same string works as a tag-prefix source in the C action and as a DB reference in the controller project.

Configuring the Picture Window and Faceplate

The motor overview PDL carries the visible row grid and one Picture Window object that hosts the popup. The popup itself is a separate PDL. Author them in this order:

1. Author the popup PDL (e.g., MotorPopup.Pdl). Place one I/O Field, one toggle button, one status text field, and one current bar. Reference tags by suffix only, including the leading dot. The runtime will prepend the Tag Prefix to every suffix reference inside the Picture Window.

   I/O Field "Status":  Tag = ".State"     Direct connection → Text output
   I/O Field "Current": Tag = ".Current"   Bar output, scale 0–20 A
   I/O Field "Name":    Tag = ".Name"      Text output (16 chars)
   Toggle Button:        Tag = ".ACTIVATION" Toggle in C-action
   Static Text "Fault":  Tag = ".Fault"     Visibility 0/1

2. Add the Picture Window to the motor overview PDL. Insert → Smart Object → Picture Window. Configure:
   • Picture Name: MotorPopup.Pdl
   • Tag Prefix: leave empty at design time. The C action fills it at runtime.
   • Independent Window: enabled (input focus decoupled from parent).
   • Window Border: enabled (draggable for the operator).
   • Visible: unchecked, hidden until first click.
3. Add the motor row smart object. One smart object per motor row, configured to call a C-action on mouse click. Pass the motor name to the action as the UserData property (see next section).
4. Generate the runtime tag database. WinCC Explorer → Tools → Compile OS (or Tag Management → right-click → Compile). This step is required so the suffix references resolve in the Picture Window context.

C-Script Implementation: SetTagPrefix and SetVisible

Two C-scripts drive the runtime. The first is the click handler on the motor object; the second is the toggle handler inside the popup.

Click on motor object (mouse action, ANSI-C):

// WINCC:TAGNAME_SECTION_START
#define TAG_PREFIX "MOTOR001"
// WINCC:TAGNAME_SECTION_END

// C-action body
{
    SetTagPrefix(lpszPictureName, "PopupSlot", TAG_PREFIX);
    SetVisible(lpszPictureName, "PopupSlot", TRUE);
    SetForeground(lpszPictureName, "PopupSlot");
}

For 40+ motors, do not hard-code 40 actions. Pass the motor name through the smart object's UserData field and assemble the prefix string at runtime. WinCC passes the user data as the lpData argument to the C action:

// WINCC:TAGNAME_SECTION_START
// WINCC:TAGNAME_SECTION_END

// Mouse action: lpszPictureName = "MotorOverview.Pdl"
//               lpszObjectName  = "Motor_1" ... "Motor_42"
//               lpData          = "MOTOR001" ... "MOTOR042" (set in object properties)
{
    char szPrefix[64];
    strncpy(szPrefix, (char*)lpData, sizeof(szPrefix) - 1);
    szPrefix[sizeof(szPrefix) - 1] = '\0';

    SetTagPrefix(lpszPictureName, "PopupSlot", szPrefix);
    SetVisible(lpszPictureName, "PopupSlot", TRUE);
    SetForeground(lpszPictureName, "PopupSlot");
}

Toggle button inside the popup (mouse action, ANSI-C):

// Click on the toggle button flips the activation bit
{
    BYTE  byValue = 0;
    char  szTag[128];

    // Build the fully qualified tag name from the current Tag Prefix
    // (GetTagPrefix returns a pointer valid for the lifetime of the picture)
    const char* szPrefix = GetTagPrefix(lpszPictureName);
    if (szPrefix == NULL) return 1;

    snprintf(szTag, sizeof(szTag), "%s.ACTIVATION", szPrefix);

    if (GetTagByte(szTag, &byValue) == 0) {
        byValue = byValue ? 0 : 1;
        SetTagByte(szTag, byValue);
    }
    return 0;
}

The toggle function uses GetTagPrefix to recover the active prefix from inside the Picture Window, then writes a single bit. The trailing dot in the prefix convention is critical: with the dot in the prefix, the concatenation reads MOTOR001 + .ACTIVATION; with the dot in the suffix, it reads MOTOR001 + ACTIVATION. The suffix variant requires the GetTagPrefix call to return a dot-terminated string. Pick one rule, document it, and grep for violations during code review.

SetTagPrefix / GetTagPrefix / SetVisible reference

Function prototypes and behavior are documented in the WinCC scripting reference shipped with the installation; the C-API header apdefap.h declares them. Refer to the WinCC V6 manual section "ANSI-C function descriptions → Tag Prefix" for the full signature list and the related SetPropBOOL / GetPropChar properties on the Picture Window object. The full WinCC V6 documentation set is available from Siemens Industry Online Support, and the SIMATIC HMI product family page lists the active manuals and hotfixes.

Dot Placement: Prefix vs Suffix

Both placements work because the concatenation is purely textual. The decision is driven by what else the prefix is used for. Use the following decision tree:

Concretely:

• One structure per object, one Picture Window: Put the dot in the prefix. The popup's references are clean alphabetic suffixes (ACTIVATION, State). This is the most common case and the one the original task describes.
• One object with multiple structures, or multiple nested Picture Windows building up the prefix from different parts: Put the dot in the suffix. The prefix is the raw instance name (e.g., MOTOR001, LICA01), and the suffix carries both the structure delimiter and the member name (e.g., .MV, .Hi2). Suffixes can also encode a level, e.g., _LVL joined to Hi2, giving LICA01_LVL.Hi2.

The dot's position does not affect WinCC's resolver; it affects only the readability of the popup and the recoverability of the prefix from outside the Picture Window. Whichever rule is chosen, write it into the project's Naming and Tagging Convention document and review the .pdl XML for mixed use during code review.

Multi-Structure and Nested Picture Window Cases

Real plants rarely have a one-to-one mapping between motor objects and structures. A single motor may carry an MV (measured value) structure and a separate LVL (level alarm) structure, both addressable through the popup. The Tag Prefix mechanism supports this in two ways:

1. Switch the prefix per popup invocation. The motor's click action can open two Picture Windows side by side, one configured with prefix MOTOR001 (for the MV structure) and one with prefix MOTOR001_LVL (for the LVL structure). The two PDLs share the same suffix set, but WinCC resolves the tags against the right instance.
2. Override the suffix in inner C-scripts. The inner toggle button can read the current prefix, append _LVL, and write the resulting qualified name. This is rarely needed but is supported through the same GetTagPrefix + snprintf pattern shown in the toggle script.

Nested Picture Windows inherit the prefix of their parent, but the inheritance is one level deep in V6: a Picture Window inside a Picture Window will receive the outer prefix as its starting state, but a SetTagPrefix call on the inner window overwrites it. Treat each Picture Window as owning its own prefix and set it explicitly when entering a nested popup.

Verification, Diagnostics, and Common Faults

Verify the implementation in three layers: design-time, in-Runtime, and via diagnostics events.

1. Design-time check (Graphics Designer): Open the popup PDL directly (File → Open → MotorPopup.Pdl). All I/O fields should display #### or a quality error, because no prefix is set. This is correct. If a field shows a real value while editing the popup, the tag was hard-coded with a full name and the design was compromised.
2. Runtime check (GDI / WinCC diagnostics): Open the WinCC diagnostics window (Start → Programs → Siemens Automation → WinCC → WinCC Diagnostics). Trigger a click and watch for events 1101 ("Tag not found") or 1102 ("Tag set with error"). A clean run produces no errors and the I/O fields populate within one update cycle (~250 ms by default).
3. Online tag test: Use Tag Management → right-click → Properties → Read on MOTOR001.ACTIVATION to confirm the bit toggles after clicking the toggle. If the tag toggles in the database but the popup I/O field does not update, the field is bound to a different instance or the picture-window prefix has not been refreshed.

Migration Notes: WinCC v6 to v7 / TIA Portal

The Tag Prefix mechanism is preserved in WinCC V7 (V7.0 SP3, V7.2, V7.3, V7.4) without API changes. The same SetTagPrefix, GetTagPrefix, and SetVisible functions are available, the picture-window attribute is in the same place, and existing C-ports compile without changes after a project upgrade. The WinCC V7 manual is published in the WinCC V7 documentation list on Siemens Support.

In WinCC Professional (TIA Portal), the model is generalized into the Faceplate type with a Property interface. Each property is a typed tag binding (BOOL, INT, REAL, STRING) that the faceplate container fills at instantiation. The Tag Prefix survives as a back-compat path for projects migrated from V6/V7, and is exposed in the Faceplate container's Properties → Tag Prefix field. New TIA Portal projects should prefer Faceplate properties over raw prefix concatenation because properties give typed compile-time validation; the prefix path is still useful for retrofit and migration scenarios. Refer to the SIMATIC HMI documentation set and the TIA Portal Help → "Working with Faceplates → Configuring the Faceplate Interface" for the property-bag authoring flow.

For WinCC Unified (V17+), the faceplate concept is further formalized as a JavaScript/TypeScript-controlled widget with a typed property bag and events. The raw string prefix is no longer the primary binding mechanism; properties are mandatory. The V6/V7 code in this article continues to work when those projects are opened in V7.5, and the prefix values are preserved across an export/import round trip into Unified via the legacy tag-prefix importer.

FAQ