Understanding APL Tag Prefixing and C-Script Execution in WinCC Project Functions

Inside SIMATIC PCS 7 APL project functions such as APL_OnOk, you do not need to concatenate the block tag name with the I/O name because WinCC uses the Picture Window 'TagPrefix' mechanism. When an APL faceplate opens, the faceplate picture window has its TagPrefix dynamically assigned to the full technological block path (e.g., 'Plant1/UnitA/Motor101.'). In WinCC Graphics Runtime, calling any tag function like SetTagChar with a leading period (e.g., SetTagChar(".Teststring", val)) causes WinCC to automatically prepend the active TagPrefix. Manually concatenating the tag name duplicates the path and causes script execution errors.

Architecture of WinCC Picture Window Tag Prefixing

In SIMATIC PCS 7 OS, the Advanced Process Library (APL) achieves 100% modular faceplate reusability across thousands of motors, valves, and analog transmitters through the WinCC Tag Prefix (Variablenpräfix) property.

When an operator clicks a block icon on a process graphic, the system opens a faceplate picture window (PictureWindow) and sets its TagPrefix property to the full hierarchy path of that technological instance followed by a delimiter dot (for example, TagPrefix = "Biores_Area/Fermenter01/Agitator101.").

All views and tabs loaded inside that Picture Window (@PG_MotL_Standard.pdl, @PG_MotL_Overview.pdl) inherit this TagPrefix context.

Why Calling SetTagChar(".Property") Works Directly in APL Functions

The WinCC runtime scripting engine and Dynamic Dialog evaluator enforce a standardized syntax rule:

Whenever any WinCC C-script function (GetTagWait, SetTagChar, SetTagDWord) or VBScript method encounters a tag name string that begins with a period (.), WinCC automatically prepends the TagPrefix of the enclosing Picture Window.
When an APL project function (such as APL_OnOk or faceplate button script) calls:
SetTagChar(".Teststring", szVariableString);
The runtime engine dynamically concatenates:
"Biores_Area/Fermenter01/Agitator101." + ".Teststring" -> resolving correctly to "Biores_Area/Fermenter01/Agitator101.Teststring".

The Mechanics of Tag Duplication and Script Errors

When an engineer unfamiliar with TagPrefix applies traditional WinCC scripting methods inside an APL faceplate:

The engineer queries the object property tagname (yielding "Biores_Area/Fermenter01/Agitator101").
The engineer manually concatenates .Teststring using strcat.
The engineer passes the resulting string to SetTagChar(szValue, szVariableString).
If szValue is resolved in an environment expecting relative names or if passed with a leading dot, or if passed to an internal function that applies TagPrefix automatically, the evaluated tag name becomes:
"Biores_Area/Fermenter01/Agitator101.Biores_Area/Fermenter01/Agitator101.Teststring".
Because this duplicate tag does not exist in WinCC Tag Management, the call fails with error code Tag not found.

Comparing Standard WinCC Scripting vs APL Reusable Functions

The table below contrasts standard absolute scripting against modular APL relative scripting:

| Engineering Dimension | Standard Absolute WinCC Scripting | APL Modular Faceplate Scripting |
|---|---|---|---|
| Tag Target Syntax | "Area/Unit/Pump.Command" | ".Command" (Relative dot prefix) |
| Picture Window Dependency| None (Works in root canvas) | Requires TagPrefix assigned on container |
| Tag Extraction Required | Yes (GetPropChar(..., "tagname")) | No (Handled automatically by TagPrefix) |
| Graphic Reusability | None (Hardcoded to one asset) | 100% Reusable across all block instances |
| Runtime String Operations | High (strcat/strncpy overhead) | Low (Handled at WinCC kernel layer) |
| Typical Function Scope | Custom overview buttons | Standard APL functions (APL_OnOk, @PG_*) |

Syntax Rules for Tag References in Faceplates

Adhere to the following conventions when writing C-actions inside APL faceplates:

Writing to Block I/O Pins: Always format parameter strings with a leading period:
c SetTagDWord(".OS_Perm", dwValue); SetTagChar(".Comment", szText);
Accessing Global System Tags: If reading a global tag that should NOT use the TagPrefix (e.g. @CurrentUser), do NOT include a leading period:
c GetTagChar("@CurrentUser");

Verification

Verify script execution and tag resolution:

Open the WinCC GSC Diagnostics window (apdiag.exe / Output Window) in OS Runtime.
Open the APL faceplate and trigger the custom C-script calling SetTagChar(".Teststring", ...); confirm no tag errors log.
In SIMATIC Manager, open the AS chart online; verify the target block parameter updates immediately.
Open the identical faceplate from a different motor instance; verify the script updates the second motor without cross-talk.

Limitations and Operational Precautions

Review the following safeguards when working with APL C-scripts:

Leading Period Mandatory: Omitting the leading period on a relative tag name causes WinCC to search for an internal tag without a prefix, causing a runtime tag lookup fault.
Buffer Overflows in C: When using GetTagChar or string manipulation in C, always allocate sufficient buffer space (e.g. char szBuffer[256]) to prevent stack memory corruption.
Do Not Hardcode Project Paths: Avoid hardcoding plant hierarchy names in faceplate scripts to preserve modularity.

Engineer FAQ

Why does WinCC treat tags starting with a period differently?

In WinCC, a leading period is the syntactic indicator that the tag is relative to the active Picture Window's TagPrefix. WinCC automatically prepends the container's TagPrefix to the string.

How can I access a global project tag from within an APL faceplate?

Omit the leading period when calling the tag function (e.g. use GetTagChar('@CurrentUser') instead of '.@CurrentUser'). WinCC will bypass the TagPrefix and query the global tag namespace directly.

Where is the TagPrefix property assigned when an APL faceplate opens?

The TagPrefix is assigned dynamically by the APL faceplate opening script (such as APL_OpenFaceplate) when the operator clicks the block icon on the process screen.