Configuring PCS 7 Block Icon Type IDs in WinCC Graphics

Overview

SIMATIC PCS 7 generates block icons in the WinCC Graphics Designer from CFC chart blocks using a hierarchical set of faceplate types. The block icon type is encoded in the picture object name as a numeric suffix preceded by the block type token (for example @VlvL/3 for a horizontal valve or @VlvL/1 for a vertical valve). When the same AS block (e.g. VlvL) must appear in two different orientations on two OS pictures, the OS compiler must be prevented from overwriting the manually edited picture, and the embedded block icon must be relinked to the correct structure tag.

This procedure covers the two supported workflows:

• Native hierarchy workflow — the picture is part of the plant hierarchy and the block icon is auto-generated during OS compilation. Multiple type variants require hierarchy-level configuration and the T401 master picture.
• Non-native hierarchy workflow — the picture is a copy of a standard picture (@PCS7TypicalsAPLVx.pdl family). The block icon is placed manually, the @ prefix is removed from the Type property, and the tag is prefixed with the server name.

Reference: Creating User-defined Block Icons with SIMATIC PCS 7 (Siemens Support, PDF).

Prerequisites

• SIMATIC PCS 7 V8.x or V9.0 engineering station with the WinCC Explorer and Graphics Designer installed.
• CFC chart containing the target block (e.g. VlvL from APL V8.x/V9.0).
• The block icon property Block icon in the CFC block Properties > Block icon is set to the desired faceplate variant (3 for horizontal, 1 for vertical).
• Plant hierarchy configured for the AS program; the picture to host the icon must be assigned to a hierarchy folder (native) or freed from the hierarchy (non-native copy).
• Write permissions on the WinCC project directory and on the GraCS folder of the OS server.
• For the non-native workflow: the @PCS7TypicalsAPLVx.pdl master file in \WinCCProjects\<OS>\GraCS\ as a copy source.

Block Icon Type Encoding and Naming

The block icon name follows the pattern @<BlockType>/<TypeID>. The @ prefix is a marker used by the OS compiler to identify auto-generated block icons. Removing it tells the compiler to leave the object untouched during the next regeneration cycle.

Workflow A — Native Hierarchy with Type 3 Generation

1. Open the CFC chart containing the VlvL block.
2. Right-click the block, choose Properties > Block icon and set the icon type to 3.
3. Save the chart and run the Chart compilation so the AS program and S7-matic interface are consistent.
4. Open the OS project in the WinCC Explorer and trigger OS compilation. The compiler writes a type-3 block icon into the picture that the hierarchy folder points to (for example T401.pdl).
5. Verify in the Graphics Designer that the generated object is named @VlvL/3 with the Type system property set to 3 and the Tag system property pointing to the structure tag (e.g. PT123/VlvL).

When a second picture in the same hierarchy (for example Tank Farm Overview) must show the same block as type 1, the compiler overwrites the manual edit on the next OS compilation. Two safe options are available — Workflow B (non-native copy) or the per-picture disable described in Workflow C.

Workflow B — Non-Native Hierarchy (Manual Copy)

Use this workflow when the picture is a copy of a typical picture and must not be touched by the OS compiler.

1. Copy the desired block icon object from @PCS7TypicalsAPLVx.pdl and paste it into the target picture (e.g. TankFarmOverview.pdl). Use a type-1 prototype for a vertical valve or a type-3 prototype for a horizontal valve.
2. Select the pasted object. In the Dynamic Wizard pane launch Link Prototype to structure or rename existing link.
3. In the wizard dialog, point the prototype to the correct structure tag of the VlvL instance (e.g. PT123/Mon). Confirm the link update.
4. Open the Object Properties window and switch to the System tab. Locate the Type property. Edit the value and remove the leading @ character (e.g. change @VlvL/1 to VlvL/1) or append a random character to break the compiler pattern match.
5. In the same System tab, edit the Tag property and prepend the server name and the :: separator (e.g. OS_SERVER1::PT123/Mon). This guarantees the object is evaluated on the correct OS server when the project is redundant.
6. Save the picture. The block icon now survives any subsequent OS compilation because the compiler no longer recognizes it as a generated artifact.

Workflow C — Disable Block Icon Generation Per Picture

If the picture remains inside the plant hierarchy but must host a manually placed block icon of a different type, the hierarchy regeneration can be switched off for that picture only.

1. Open the picture in the Graphics Designer.
2. Select the picture background (not a child object) and open Properties > Geometry or the Event tab, depending on the PCS 7 version.
3. Locate the attribute Derive the block icons from plant hierarchy and uncheck it.
4. Place the desired block icon manually (drag from @PCS7TypicalsAPLVx.pdl or copy from an existing picture) and link it via the Dynamic Wizard as in Workflow B.
5. Save and trigger a full OS compilation to confirm that the picture is not regenerated.

Using T401 for Cross-Picture Type Variants

The picture T401.pdl is a standard master picture used by the OS compiler to aggregate block icons that have no dedicated plant hierarchy picture. To keep both type-1 and type-3 icons of the same block alive across multiple OS pictures, place the primary (auto-generated) variant in the picture referenced by the hierarchy and the secondary variant in a manual picture produced by Workflow B. The T401 picture is then used for the auto-generation slot only.

1. Confirm that the block Properties > Block icon > S7-matic setting points to T401 as the secondary master.
2. Trigger OS compilation > Generate block icons. Inspect T401.pdl to verify the generated object name and type.
3. For each manual picture, follow Workflow B so the duplicated block icon survives recompilation.

Dynamic Wizard — “Link Prototype to Structure or Rename Existing Link”

This wizard is the canonical way to (re)connect a block icon to a structure tag. It performs three actions in one transaction:

• Reads the prototype type from the pasted object and looks up the matching faceplate in the APL library.
• Rebinds every internal Tag prefix reference to the target structure tag (e.g. PT123/Mon).
• Updates the visible caption, tooltip and process tag references on the object.

If the wizard reports prototype not found, the source @PCS7TypicalsAPLVx.pdl does not match the installed APL version. Reinstall the matching APL revision or copy the prototype from the OS server's GraCS folder.

Property Reference — System Tab

Verification

1. Trigger a full OS compilation with the option Generate block icons enabled. The compiler log must not report any deletion of manual object warnings for the target picture.
2. Open the picture in runtime (WinCC Runtime Start) and confirm the block icon renders with the expected orientation and color state (green = open, red = closed, grey = bad quality).
3. Click the icon to open the faceplate. The faceplate header must display the same structure tag as the source CFC block.
4. Force a value change on the AS side (e.g. VlvL.Mon = TRUE) and verify the icon state updates without requiring a picture reload.
5. Stop and restart the WinCC Runtime to confirm the manual link is persisted across cold restarts.

Troubleshooting Matrix

Best Practices

• Treat the @ prefix as a protected marker: remove it only on the System > Type property of objects that must never be regenerated.
• Document the server name and structure tag inside a comment field of the object so the next engineer can re-link the icon without re-deriving it from the hierarchy.
• Use a single naming convention for manual block icons, e.g. MAN_<Block>_<Type>_<TagSuffix>, to make the manual objects easy to spot in the WinCC Explorer.
• Always run a full OS compilation after editing the Type or Tag properties to make sure the runtime tag mapping is updated.
• For large projects, store the T401.pdl and the manual pictures in version control so the link state is reproducible across engineering stations.

FAQ