How to Integrate APL Faceplate Elements from @PCS7ElementsAPL.pdl into Custom WinCC Faceplates

How to Integrate APL Faceplate Elements from @PCS7ElementsAPL.pdl into Custom WinCC Faceplates

To integrate APL graphic controls—such as APL_OP_BUTTON or csoIOAnaSP copied from @PCS7ElementsAPL.pdl—into custom WinCC faceplates, you must configure the invisible 'stUser' authorization object, link property tags with strict case sensitivity, and ensure structure prefixes are assigned correctly. Classic elements from @pcs7elements.pdl rely on simple direct tag connections, whereas APL controls execute standardized internal C-scripts that depend on @pcs7_apl_styleguide.pdl, the active user authorization level, and valid .Status1 / .OS_PermLog tag interconnections.

Table of Contents

Architectural Differences: Classic @pcs7elements vs APL @PCS7ElementsAPL

In SIMATIC PCS 7, creating custom faceplates for proprietary equipment or third-party skids requires incorporating standardized operational controls (buttons, analog setpoint fields, alarm icons, and status indicators).

Engineers transitioning from the legacy PCS 7 Standard Library to the Advanced Process Library (APL) frequently encounter inactive or unresponsive controls when copying objects from the template libraries:
* Classic Controls (@pcs7elements.pdl): Legacy controls operate via simple, direct WinCC dynamic dialogs or basic C-scripts. They do not evaluate multi-tiered operator permissions, SIMATIC Logon user classes, or dynamic status words.
* APL Controls (@PCS7ElementsAPL.pdl): APL objects (such as APL_OP_BUTTON, csoIOAnaSP, csoStMode) are highly sophisticated visual components. They rely on an underlying C-script framework (apdefap.h, standard APL project functions), reference global style guides (@pcs7_apl_styleguide.pdl), and evaluate compound 32-bit status words (.Status1, .Status2, .OS_PermLog).
* If copied into a custom picture without the supporting APL infrastructure, APL elements default to an inactive, greyed-out, or unclickable state.

The Role of the Invisible 'stUser' Configuration Object

The most common reason an APL_OP_BUTTON appears disabled—even after removing the PermissionTag link—is the absence of the stUser object:

  • In standard APL faceplates (such as @pg_apl_pidconl_standard.pdl), an invisible graphic object named stUser resides in the screen background.
  • The stUser object monitors Windows user login events via SIMATIC Logon and the WinCC User Administrator.
  • When an operator logs in, stUser reads the user's authorization level (e.g., Level 5: Process Controlling, or Level 6: Higher-Ranking Process Controlling).
  • It then iterates through all registered operational controls in the faceplate and dynamically sets their Permission or Operable properties to TRUE or FALSE.
  • If your custom faceplate lacks the stUser object, or if the unique object name of your APL_OP_BUTTON is not listed within the stUser object's property list, the control remains permanently locked in its default un-operable state.

Strict Case Sensitivity in WinCC C-Scripts and APL Property Tags

A subtle but pervasive technical pitfall in WinCC graphic development involves character case sensitivity:

  • WinCC Tag Management: The core WinCC database is largely case-insensitive when resolving tag names directly in dynamic dialogs (e.g., Motor1.autmodop resolves the same as Motor1.AutModOp).
  • WinCC ANSI C-Scripts: The C-script interpreter (pdlrt.exe) and APL internal functions are strictly case-sensitive!
  • In APL controls, button scripts execute functions like GetTagDWord or evaluate structure tags using dynamic string concatenation:
    c char szTag[255]; sprintf(szTag, "%s.AutModOp", lpszStructurePrefix); SetTagBit(szTag, 1);
  • If the block output in CFC was generated as .AutModOp and the engineer configured .autmodop in the object properties, or vice-versa, the C-script fails to find the tag, logs an error in APDIAG, and leaves the button disabled.

Step-by-Step Procedure to Implement APL_OP_BUTTON in Custom Faceplates

To successfully embed and operate an APL_OP_BUTTON inside a custom faceplate:

  1. Copy the APL Elements and Supporting Objects:
    * Open @PCS7ElementsAPL.pdl in Graphics Designer.
    * Copy the required APL_OP_BUTTON instance into your custom faceplate (e.g., @pg_custom_motor.pdl).
    * Open a standard APL faceplate (e.g., @pg_apl_valvel_standard.pdl) and copy the invisible stUser object into your custom faceplate.
  2. Assign a Unique Object Name:
    * Select the button and assign a distinct name (e.g., btn_ManualMode).
    * Select the stUser object, open Properties, and add btn_ManualMode to its monitored object list.
  3. Configure Button Properties:
    * Permission: If using dynamic operator permissions from the CFC chart, connect PermissionTag to .OS_PermLog. If bypassing permission checks, set PermissionTag to 0.
    * Authorization Level: Set the required authorization level (typically 5 or 6).
    * BinLink Connections: Under Links, connect BinLink 1 to the exact case-sensitive tag name (e.g., .ManModOp).
  4. Structure Prefix Integration:
    * Faceplates in PCS 7 are opened inside WinCC Picture Windows (@Faceplate.pdl) with a assigned Structure Prefix (the CFC block tag name, e.g., Plant1/Unit2/Motor12).
    * Ensure all tag connections in the faceplate use the dot-notation prefix (e.g., .AutModOp, .Status1) so the Picture Window prepends the structure prefix dynamically at runtime.

Comparison of Classic vs APL Faceplate Control Requirements

The table below compares the engineering requirements between classic @pcs7elements and modern APL @PCS7ElementsAPL faceplate objects.

Engineering ParameterClassic Controls (@pcs7elements.pdl)APL Controls (@PCS7ElementsAPL.pdl)Underlying FrameworkWinCC Standard Library scriptsAPL Style Guide (@pcs7_apl_styleguide.pdl)User AuthorizationDirect WinCC User Admin property checkDynamic evaluation via invisible stUser objectPermission ManagementHardcoded or simple boolean tags32-bit double words (.OS_PermLog, .OS_Perm)Case SensitivityTolerant in simple dynamic dialogsStrictly Case-Sensitive in all C-scriptsOperating WindowsSimple dialog popupsStandardized sub-windows (@pg_apl_oa_*.pdl)Visual StylingStatic 2D bordersModern 3D ergonomic styling matching APL standards

Verification

To confirm that APL controls operate correctly in the custom faceplate:
1. Open apdiag.exe (C:\Program Files (x86)\Siemens\WinCC\uTools\apdiag.exe) and set focus on the Output Window.
2. Launch WinCC Runtime on an OS Client or ES. Log in with an operator account possessing Authorization Level 5 and 6.
3. Click the block icon to open your custom faceplate.
4. Verify that the APL_OP_BUTTON is visually enabled (clear text, active border styling, not greyed out).
5. Click the button: verify that the operating window opens or the commanded tag toggles state in the CFC chart.
6. Check APDIAG: confirm that zero C-script execution faults, missing tag warnings, or type mismatch errors are logged.

Limitations and Operational Precautions

  • Never edit master template files @PCS7ElementsAPL.pdl or @pcs7_apl_styleguide.pdl directly; always work on custom copies with unique prefixes (e.g., @pg_custom_*.pdl).
  • Modifying APL faceplate C-scripts without compiling WinCC project functions can cause runtime engine thread locks in pdlrt.exe.
  • Verify that operator permissions configured on the CFC chart (OS_Perm) do not conflict with the authorization levels configured in WinCC User Administrator.
  • If migrating from legacy Standard Library to APL, do not mix classic and APL controls within the same faceplate view; visual styling and font scaling will clash.

Engineer FAQ

Why did my APL_OP_BUTTON become active only after copying the stUser object?

The stUser object is the authorization engine in APL faceplates. Without stUser, the faceplate script cannot determine the logged-in user's rights and defaults to locking all operational controls in a safe, disabled state to prevent unauthorized process manipulation.

Does tag name case matter when connecting APL objects?

Yes! While the WinCC tag database itself can resolve tags regardless of case, APL faceplates rely on ANSI C-scripts that use string comparison and dynamic tag querying. C-scripts are strictly case-sensitive; calling .autmodop instead of .AutModOp fails silently.

Where can I find the standard APL Style Guide documentation?

Siemens publishes the complete 'PCS 7 Advanced Process Library (APL) Style Guide' (Siemens Industry Online Support ID 43705259), which documents object properties, faceplate dimensions, font standards, and C-script templates.

Technical References

Related Articles

Related Tags

  • APL
  • @PCS7ElementsAPL
  • Faceplate Design
  • stUser
  • Case Sensitivity
6 respuestas