Reusing and Duplicating Block Icons Across Multiple WinCC Pictures in SIMATIC PCS 7

To reuse a block icon across multiple WinCC pictures in SIMATIC PCS 7 without it being deleted during OS compilation or causing Loop-in-Alarm navigation deadlocks, copy the generated block icon to the target picture, remove the leading '@' character from its 'type' property, and set the 'Relevant' (Relevance) property to 'No' on the duplicate copy. Removing the '@' prevents the OS Compiler from overwriting or deleting the icon, while disabling 'Relevant' prevents dual-path collective alarm escalation and navigation errors.

Mechanics of OS Compilation and Automatic Block Icon Generation

In SIMATIC PCS 7 Operator Stations, process screens are typically generated automatically based on the technological Plant Hierarchy (PH). When the engineer runs the Compile OS wizard with the option Create/update block icons checked, the compiler inspects all CFC charts assigned to each hierarchy folder, reads the template block icons from @PCS7TypicalsAPL.pdl (or @PCS7Typicals.pdl), and automatically instantiates the icons into the designated process picture (.pdl).

Often, process operational requirements dictate that a single physical actuator (such as a primary feed pump or emergency shutoff valve) must appear in multiple process overview and detail pictures (e.g., both the Tank Farm Overview and the Reactor Detail picture).

Simply copying and pasting a generated block icon between screens introduces two critical system defects:
1. Deletion During Re-Compilation: During the next OS compilation with Picture Tree update enabled, the compiler checks the Plant Hierarchy. Finding an icon whose type attribute begins with @ in a picture outside its primary hierarchy folder, the compiler considers it an orphaned object and deletes it or resets its properties.
2. Loop-in-Alarm Navigation Lockup: In WinCC, every block icon contributes to the plant hierarchy's collective value / group display (Sammelanzeige). If two active icons exist for the same CFC block and both have the property Relevant = Yes, an incoming alarm routes up the hierarchy tree through two separate picture paths. When the operator clicks the alarm in the alarm line or clicks the group display (Loop-in-Alarm), the WinCC navigation script encounters an ambiguous target destination and stalls.

Block Icon Properties and Collective Display Hierarchy Matrix

Understand how specific block icon attributes govern OS Compiler behavior and runtime navigation:

Property NameProperty CategoryDefault Value on Generated IconRequired Value on Secondary / Copied IconImpact on System BehaviortypeSystem@MotL/1 (Starts with @)MotL/1 (Remove leading @)Stripping @ protects the icon from being modified or deleted by the OS CompilerRelevant (Relevanz)Collective Display / HierarchyYes (Ja)No (Nein)Setting to No detaches the duplicate from the group display tree, fixing Loop-in-AlarmtagGeneralPlant/Area/DevicePlant/Area/Device (Unchanged)Retains connection to the CFC block structure tagstagStructureGeneralMotLMotL (Unchanged)Identifies the APL or custom block structure typeserver nameSystemStandard BPC CallStandard BPC Call (Unchanged)Retains standard faceplate opening functions

Engineering notice: Only the primary master icon placed in the parent hierarchy picture should have Relevant = Yes.

Step-by-Step Procedure for Duplicating Icons Across Process Screens

Follow this verified procedure to duplicate block icons safely across pictures:

Copy Primary Block Icon:
* Open the primary picture generated by OS compilation in Graphics Designer.
* Select the target block icon, right-click, and select Copy.
Paste and Reposition in Secondary Picture:
* Open the destination secondary process picture (e.g., Overview_Area_B.pdl).
* Select Edit > Paste and place the icon at the desired screen coordinates.
De-register from Automatic Compiler Sweeps:
* Right-click the newly pasted icon and open Properties.
* Under the System property group, locate the property type.
* Change the value from @MotL/1 to MotL/1 (delete the leading @ character).
* This flags the object as a static user-customized element, instructing the OS Compiler never to delete or re-create it.
Disable Group Display Relevance:
* Under the Group Display or Hierarchy property group, locate the property Relevant.
* Change the attribute from Yes to No (or 1 to 0).
* Save the picture.

Resolving Loop-in-Alarm and Group Display Navigation Conflicts

When an alarm is generated in WinCC Alarm Logging, clicking the Loop-in-Alarm button queries the @PictureHierarchy database table to find the primary picture containing the alarming device.
* If a copied icon retains Relevant = Yes, the Picture Tree Manager attempts to highlight the icon in two pictures simultaneously. In multi-monitor systems, this can cause the overview area horn silencing logic to fail to clear.
* By setting Relevant = No on all secondary instances, the WinCC Basic Process Control engine only registers the primary picture in the group display hierarchy. Clicking Loop-in-Alarm consistently opens the primary technological picture, while clicking either the primary or secondary icon directly on screen opens the standard faceplate without conflict.

Verification

Verify multi-picture icon behavior:
1. Run Compile OS on the Engineering Station with Create/update block icons enabled.
2. Confirm that the copied icon in the secondary picture is not deleted after compilation finishes.
3. Activate WinCC Runtime.
4. Verify that the secondary icon displays dynamic live values (color changes, status icons, running state) identical to the primary icon.
5. Trigger an alarm on the associated CFC block.
6. Click the Loop-in-Alarm button in the top alarm toolbar: Confirm that WinCC navigates directly to the primary picture without delay or script errors.
7. Click the copied icon in the secondary picture: Confirm that the standard faceplate opens properly.

Limitations and Operational Precautions

Because removing the @ prefix detaches the icon from the OS Compiler, future modifications made to the master template in @PCS7TypicalsAPL.pdl (such as new visual styles or library upgrades) will not automatically propagate to the secondary copied icon. You must update copies manually.
Never set Relevant = No on the primary icon located in the technological parent picture; doing so removes the unit from the area group display hierarchy entirely.
Limit the duplication of complex block icons in dense overview pictures to prevent excessive cyclic GDI handle consumption on client PCs.

Engineer FAQ

What happens if I forget to remove the leading '@' from the type property?

During the next OS compilation where 'Create/update block icons' is executed, the OS Compiler will detect an icon outside its assigned hierarchy folder and delete it from the secondary picture.

Can I use different icon variants for the primary and secondary icons?

Yes. For example, you can use variant 1 (@MotL/1 - detailed icon with text and buttons) in the detail picture, and variant 2 (MotL/2 - compact icon without buttons) in the secondary overview picture.

Does duplicating block icons consume additional WinCC archive tags or AS Process Objects?

No. Block icons only visualize existing process tags and structure variables. Reusing them on multiple pictures does not consume additional AS or OS Process Objects.