Configuring Siemens PCS 7 APL Multi-Instance Faceplates

Overview

Siemens PCS 7 Advanced Process Library (APL) faceplates are operator-controlled display objects rendered on the WinCC Operator Station (OS). Multi-instance faceplates allow a single composite operator display to reference several Operator Control & Monitoring (OCM) blocks at once, so that one faceplate pop-up aggregates the parameters and limits of multiple field-related blocks (for example, a coupled motor and its associated interlock, permissive, and feedback blocks).

The architecture differs in two important ways from custom WinCC graphics:

• Block Icons are strictly single-instance. A given block icon can only be associated with a single block; there is no concept of multi-instance block icons in the APL.
• Faceplates can be multi-instance provided the OCM blocks all reside on the same CFC chart and share a common naming root with an underscore-prefixed suffix for the secondary blocks.

This article documents the field-proven implementation rules from the APL Style Guide and the PCS 7 Program Instructions for Blocks manual, and provides the procedural steps, parameter syntax, and verification checks needed to wire a multi-instance faceplate that connects cleanly to the underlying CFC blocks.

Prerequisites

Before attempting a multi-instance faceplate build, the engineering station (ES) and operator station (OS) must be configured to a known-good baseline.

Block Icons vs. Faceplates — Architectural Boundary

Understanding the boundary between block icons and faceplates is the single most common source of confusion in multi-instance work.

Block Icons — Single-Instance Only

When a block icon is generated, three paths exist that each write the tag-prefix relationship into the icon's tag connections:

1. Automatic generation during an OS compile via the Create/Update Block Icons option.
2. Manual execution of the Graphics Designer Dynamic Wizard with a tag entered into the wizard dialog.
3. Manual placement of a block icon from the APL WinCC library where the wizard was run on a connected tag.

Each of these paths tags the icon with the associated block instance name only. When the dynamic wizard encounters a tag, it strips every prefix in front of the structure delimiter dot and replaces the resulting prefix with the block tagname. Concretely, if the user supplies the string Plant.Unit1.Motor1.Input1 to the wizard and the block tagname is Plant.Unit1.Motor1, the icon's connection writes Plant.Unit1.Motor1.Input1 — only the dot suffix is preserved.

If the wizard is launched with no tag selected or entered, it strips the prefix away from everything in front of the structure delimiter dot. This is why a wizard-driven block icon cannot simultaneously resolve multiple block instances.

Faceplates — Multi-Instance Capable

Faceplates do not enforce the single-instance rule because their connections are not bound to a single block icon prefix. Instead, every variable connection inside a faceplate is a relative path that the OS runtime resolves against the instance prefix passed when the faceplate is opened. Provided all referenced OCM blocks are visible in the same CFC and follow the underscore-suffix naming convention, the runtime can resolve them at faceplate open time.

Naming Convention for Multi-Instance Faceplates

The APL Style Guide defines the naming rule that makes multi-instance resolution work: the secondary OCM block instance names must begin with the base block instance name and carry a unique underscore-suffixed identifier.

Base Block Name

The base block is the OCM block that owns the standard faceplate parameters. Its instance name is what the user enters as the tag root when the block icon is wired (for example Motor on the CFC chart).

Secondary Block Names

Each additional OCM block on the same CFC that the faceplate should aggregate must follow the rule:

<BaseBlockName>_<UniqueSuffix>

For example, given a base MotL block instance named Motor, secondary blocks might be:

Parameter Tagging Syntax

Inside the multi-instance faceplate, every variable connection uses a relative path that the OS runtime resolves against the base block's instance prefix.

Base Block Parameters

Parameters sourced from the base block are tagged with the standard leading-dot notation:

.Parameter

Examples:

• .SP_EXT — external setpoint on the MotL block
• .PV — process value
• .LMN — manipulated value / output
• .MSG_LOCK — message lock state
• .MO_PV — motor process value for the standard faceplate

Secondary Block Parameters

Parameters sourced from a secondary OCM block use the suffix and underscore followed by a dot and the parameter name:

_<Suffix>.Parameter

Using the example suffix Widget referenced in the field report:

• _Widget.PV — process value from secondary block Motor_Widget
• _Widget.SP_INT — internal setpoint from secondary block
• _Perm.QCTL — permissive output from Motor_Perm
• _Fbk.VAL — feedback value from Motor_Fbk

The runtime resolution order is:

1. Take the base block's full instance tagname (for example Plant.Unit1.Motor).
2. For each connection, append the leading dot or underscore suffix segment plus the parameter name.
3. Resolve to Plant.Unit1.Motor.PV for a base parameter or Plant.Unit1.Motor_Widget.PV for a secondary parameter.

Step-by-Step Implementation

Follow this sequence to wire a working multi-instance faceplate.

1. Plan the CFC Chart Structure

1. Open the target CFC chart in SIMATIC Manager / PCS 7 Engineering.
2. Place the base OCM block (MotL, VlvL, AnL, DigMon, MotSpdCL, PIDConL, etc.) on the chart and assign its instance name (for example Motor).
3. Place every secondary OCM block that the faceplate must reference on the same chart.
4. Apply the underscore-suffix naming rule to each secondary block (for example Motor_Perm, Motor_Fbk).
5. Wire the inter-block signals (permissives, interlocks, feedback) on the chart in the normal PCS 7 manner.

2. Compile the CFC and Resolve Warnings

1. Run Charts > Compile on the CFC chart.
2. Review the compile log for "Block instance name already exists" or "Duplicate suffix" warnings.
3. Verify in the S7 Program that the instance DBs are generated with the correct hierarchical names (for example DB1003 = Motor_Widget).

3. Trigger an OS Compile

1. In SIMATIC Manager, open the OS and select OS > Compile OS.
2. Enable the Create/Update Block Icons option.
3. Confirm that the wizard reports Motor as the base prefix and lists Motor_Perm, Motor_Fbk as related instances (the OS compile treats them as siblings of the base block).
4. Allow the OS compile to complete and check the OS compile log for any unresolved tag references.

4. Open or Create the Multi-Instance Faceplate

1. Open WinCC Explorer and launch the Graphics Designer.
2. Open the APL faceplate template that matches the base block type (for example the MotL faceplate @MOTL_DEFAULT.PDL or its custom variant).
3. Duplicate the faceplate and rename it with the project naming convention (for example Motor_Multi.PDL).

5. Wire Secondary Block Connections

1. Identify the additional I/O fields, status indicators, or command buttons that should display data from secondary blocks.
2. Open the property dialog for the target object (right-click > Properties > Output/Input).
3. Replace the default tag (typically .PV) with the suffixed form (for example _Widget.PV).
4. For each secondary block reference, confirm that the suffix exactly matches the secondary instance name (case-sensitive on most OS builds).

6. Configure the Faceplate Trigger

1. On the process picture, the block icon calls the faceplate by passing the base block instance name as the tag prefix.
2. If you have built a custom faceplate (not the standard APL one), open the block icon's Properties > Events > Mouse Click and configure the Open Faceplate action with the base instance name.
3. Do not run the block-icon dynamic tagging wizard against the custom faceplate; configure the connections manually per the suffix syntax.

Verification

After wiring, run the following checks before declaring the faceplate operational.

Troubleshooting Matrix

Differences from PCS 7 Standard Library (Pre-APL)

Engineers migrating from the classic PCS 7 Standard Library faceplates should note the following behavioral changes:

• The classic "Multi-Instance" checkbox that appears on standard library faceplates does not exist on APL faceplates; the multi-instance capability is instead achieved through the suffix naming rule.
• The classic block-icon single-instance rule was enforced at faceplate generation; in APL it is enforced at the wizard/compile stage, which means a misconfigured custom faceplate will not fail until runtime tag resolution.
• The classic @-prefixed internal tag style is replaced by the leading-dot notation; mixing the two styles within one faceplate is unsupported.

Best Practices and Field Tips

1. One faceplate per base block type. Avoid creating a new faceplate per asset instance. Define the multi-instance faceplate once and let the OS runtime resolve the suffix per call.
2. Suffix dictionary. Maintain a controlled vocabulary of suffixes (for example _Perm, _Intlk, _Fbk, _Ovrd) to keep the faceplate logic predictable across the plant.
3. Limit suffix count. Empirical observation shows that more than five secondary blocks per faceplate degrades the operator's situational awareness. Group related OCM functions into auxiliary faceplates if the count grows.
4. Avoid overlapping suffixes. If Motor_Widget1 exists, do not also create Motor_Widget12 — the underscore-delimited runtime parser may mis-parse trailing characters in some PCS 7 SP revisions.
5. Keep all OCM blocks on the same CFC. Cross-chart faceplate references fail at OS compile time and are not always surfaced with a clear diagnostic.
6. Use the OS compile report. Always read the os_compile.log for "unresolved faceplate connections" warnings before commissioning a new faceplate.
7. Lock the wizard. After manually wiring the suffix references, set the faceplate property BlockIconWizard to disabled so that a future wizard run does not strip your suffixes.

Edge Cases and Migration Considerations

Mixing APL and Classic Blocks

If the base block is a classic PCS 7 block (for example an older MOT_SPEED from the Standard Library) but a secondary block is APL, the faceplate suffix mechanism still works because the OS runtime resolves suffixes against the instance DB symbol regardless of the block's library origin. The reverse — APL base with classic secondary — is also valid but the parameter name must match the classic block's I/O naming.

Chart-in-Chart (CIC) Instances

When OCM blocks are encapsulated inside a chart-in-chart block type, the instance name visible at the OS layer becomes the chart instance name. Apply the suffix rule to the inner blocks only if the chart is being broken out, otherwise the chart-in-chart instance itself is the base.

Type-Based vs. Instance-Based Faceplates

APL faceplates are type-based: the same PDL serves every instance of a given block type. The multi-instance suffix mechanism is instance-based only at the parameter-connection level. Do not attempt to fork the faceplate per instance — the OS would treat each fork as a new type and you would lose the type-based memory and copy protection of the runtime.

Acceptance Checklist

Before signing off the multi-instance faceplate for production, confirm each item:

• All secondary OCM blocks reside on the same CFC as the base block.
• Every secondary block instance name follows the <Base>_<Suffix> rule.
• Every secondary suffix is unique within the chart.
• Every faceplate secondary connection uses the _<Suffix>.Parameter syntax (no hard-coded prefixes).
• No block-icon wizard has been run against a multi-instance custom faceplate.
• OS compile reports zero unresolved tag references for the faceplate.
• Operator authorization for the controlling area matches across all secondary blocks.
• Verification table checks all pass on the running OS.