Resolving WinCC Loop-in-Alarm Failing After OS Project

Resolving WinCC Loop-in-Alarm Showing Disconnected Tags After Project Duplication

Problem Overview

The "Loop-in-Alarm" (sometimes written "Loop In Alarm") function in SIMATIC WinCC (TIA Portal) and SIMATIC WinCC Runtime Advanced / Professional is designed to navigate from an active alarm entry in the Alarm Control directly to the process picture that represents the source of that alarm. In PCS 7 / WinCC environments this is the foundation of operator guidance: clicking Loop-in-Alarm should open the relevant unit overview, highlight the offending block icon, and present live tag values from the AS (Automation Station).

The failure pattern reported on duplicated Operator Stations (OS) is:

• On the Engineering Station (ES), where the project is authored, Loop-in-Alarm works correctly: clicking the toolbar icon (or double-clicking the alarm row) opens the assigned picture, the plant-hierarchy buttons become highlighted, and tag values render normally.
• On the target OS, after the project has been transferred using the WinCC Project Duplicator (or "OS Project Duplicator"), clicking Loop-in-Alarm opens the correct picture window, but the picture content shows no live tag values. Visually it appears as "No connection to WinCC Runtime" — the same picture, opened through normal navigation on that OS, still renders tag values correctly.

The differential behavior — same picture works via direct navigation but not via the Loop-in-Alarm event on the same OS — is the diagnostic fingerprint of a configuration item that is reset or omitted by the duplication process rather than a hardware/connection fault.

Root Cause Analysis

Three interrelated configuration elements participate in the Loop-in-Alarm resolution path. Each is sensitive to the duplication process in a different way:

1. Tag Prefix Scope

Loop-in-Alarm evaluates the alarm's source location and concatenates it with the active picture's tag prefix to resolve which AS connection and which tag namespace to display. The WinCC Project Duplicator preserves prefix definitions but, in well-known edge cases, fails to rebind them to the correct runtime picture window when the picture is opened through the Loop-in-Alarm event handler instead of a button action that explicitly sets the prefix.

Diagnostic question: does the same picture open correctly when navigated manually (button click or hierarchy click) but render blank when opened via Loop-in-Alarm? If yes, the prefix is not being propagated to the Loop-in-Alarm-invoked picture window.

2. Plant Hierarchy Binding

Loop-in-Alarm relies on the plant hierarchy (unit / area hierarchy in the WinCC Configuration Studio) to find the picture associated with the alarm's source location. After duplication, the hierarchy database is normally preserved, but any path that referenced local file resources, custom DLLs, or scripts compiled against the ES path can fail silently on the target OS.

3. Compiled Scripts and HighLightBlockIcon

Each picture that participates in Loop-in-Alarm typically contains a HighLightBlockIcon event on the @AlarmOneLine.PDL or its parent. If this C / VBS script is marked "changed" (yellow lightning bolt in the Graphics Designer object properties) rather than "compiled" (green lightning bolt), the runtime skips it on the duplicated OS even though it executes correctly on the ES.

Affected Versions and Products

The Loop-in-Alarm event itself is documented as available on Basic Panels, Panels, Comfort Panels, RT Advanced, and RT Professional per the TIA Portal V20 events documentation.

Diagnostic Procedure

Before applying fixes, isolate which of the three root-cause groups applies to your project.

Step 1 — Confirm Differential Behavior

1. On the duplicated OS, navigate to the picture manually (hierarchy button, configured navigate button, or direct URL).
2. Confirm that tags render and update with live values.
3. Open the Alarm Control, select an active alarm whose source picture is the same picture from step 1.
4. Click the Loop-in-Alarm toolbar icon.
5. Confirm that the picture opens but tags do not update.

If step 5 reproduces the fault, root cause is the Loop-in-Alarm resolution path — not network, AS connection, or licensing.

Step 2 — Inspect the Alarm Control Properties

Open the Alarm Control object on the overview picture. In the Properties dialog, inspect the General tab:

• Action on double-click: confirm it is set to 1 - Loop In Alarm (not 0 - No action).
• Function Name: confirm the configured C / VBS function name.
• Picture Name / Parameter: confirm the picture name string passed to the function.

According to the standard configuration, the Function Name should be either:

• OpenPicture (single string parameter) — used when the project does not use the Basic Process Control (BPC) option, or
• LoopInAlarm — used when BPC is enabled.

Mismatching these two (for example configuring OpenPicture on a BPC-enabled project) causes the picture to open but the prefix / hierarchy context to be lost.

Step 3 — Compare Compiled Scripts Between ES and OS

1. On the ES, open @AlarmOneLine.PDL in the Graphics Designer.
2. For each sample block icon, open Object Properties » Events » Miscellaneous » HighLightBlockIcon.
3. Inspect the lightning bolt indicator:

• Green: the script has been compiled and is part of the runtime project.
• Yellow: the script has been changed but not recompiled since last compilation; the runtime on the OS will silently drop this handler.

4. If yellow, open the script editor and recompile (menu: Compiler » Compile, or just close and reopen the picture).
5. Re-transfer the project to the target OS using Project Duplicator.

Step 4 — Inspect Tag Prefix Definition

On the duplicated OS, open the picture that fails and inspect the picture window properties. Confirm that the tag prefix field contains the expected value (typically the area name from the plant hierarchy). A common pattern after duplication is that the prefix is set to a literal string in the ES authoring but is left empty on the OS runtime, causing tag reads to return invalid handles.

If the prefix is dynamic (set by a C / VBS action on the navigate button), the Loop-in-Alarm handler does not call that action — it bypasses the navigation script. The fix is to either:

• Move prefix assignment to the picture's Open event so it executes regardless of how the picture is invoked, or
• Set the prefix statically in the picture properties, accepting that the same picture cannot be reused across multiple areas.

Solution

Apply the following corrective steps in order. Each step is independently sufficient for a sub-class of failures.

Solution A — Recompile and Re-transfer

1. Open the WinCC project on the ES.
2. For every picture used by Loop-in-Alarm (@AlarmOneLine.PDL and any user-defined Loop-in-Alarm target pictures), open each picture in the Graphics Designer.
3. Open each C / VBS event handler. Close it without changes.
4. Open the project's Computer » Properties » Graphics Runtime and confirm "Compile all pictures on project download" is enabled.
5. Compile the OS (menu OS » Compile in PCS 7, or Project » Compile » Software (rebuild all) in TIA Portal).
6. Transfer to the target OS using the Project Duplicator again.

Solution B — Move Prefix Assignment to Picture Open Event

1. Open the target picture in the Graphics Designer.
2. On the picture's Open event, add a C action or VBScript that sets the tag prefix based on the alarm's source (or based on a configured tag).
3. Remove the prefix assignment from the navigation button.
4. Recompile and re-transfer.

This ensures the prefix is always set regardless of how the picture is opened.

Solution C — Replace Project Duplicator Transfer with Download from ES

If the differential behavior persists after Solutions A and B, replace the duplicator workflow with a direct download from the ES to the target OS:

1. Configure the OS as a target in TIA Portal / SIMATIC Manager.
2. Perform a full download (Online » Download to device).
3. Verify that Loop-in-Alarm resolves correctly.

The full download preserves compiled scripts, picture binaries, and prefix bindings as a coherent set; the Duplicator sometimes preserves file structure but loses internal references between these elements.

Alarm Control Configuration Reference

The Alarm Control configuration that drives Loop-in-Alarm behavior is documented in the WinCC Information System under Working with WinCC » Alarm Logging » Configuring the Alarm Control. The relevant properties are summarized below.

Verification

After applying any of the solutions above, verify on the target OS:

1. Generate or trigger an alarm from a known tag (e.g. force a high-high limit on a simulated level tag).
2. Wait for the alarm to appear in the Alarm Control on the target OS.
3. Click the Loop-in-Alarm toolbar button.
4. Confirm that:
• The correct picture opens.
• The plant-hierarchy buttons on the target picture become highlighted.
• Tag values render and update.
• The block icon for the alarming tag is highlighted (yellow border).
5. Repeat for at least one alarm per area in the plant hierarchy.

Troubleshooting Matrix

Preventive Measures

• Always perform a full compile of the OS project on the ES immediately before running the Project Duplicator. Uncompiled script changes are the most common silent failure.
• Standardize tag-prefix assignment on the picture's Open event rather than on navigation buttons. This decouples picture behavior from the navigation logic that invokes it.
• Maintain a single source of truth for the BPC / non-BPC decision. If the project enables BPC, every Alarm Control must use LoopInAlarm as the Function Name.
• After each duplicator-based transfer, run a smoke test on the target OS: generate one alarm per area and confirm Loop-in-Alarm resolution before placing the OS into production.
• For large multi-OS projects, prefer a direct download from the ES to each OS over duplicator-based propagation to avoid divergence between OS stations.

Related Configuration Areas

The Loop-in-Alarm mechanism interacts with several other WinCC subsystems. The following list documents the items that should be checked alongside the Alarm Control configuration when troubleshooting:

• Alarm source mapping: each tag's alarm configuration must specify a source picture (or a source area that maps to one) for Loop-in-Alarm to resolve.
• Picture window properties: the picture window that hosts the Loop-in-Alarm target must allow independent tag prefix scoping.
• User administration: Loop-in-Alarm requires operator authorization in some configurations; verify that the current user has the appropriate level.
• Picture navigation caching: TIA Portal V17 and later include a picture caching option; if enabled, confirm that the cache has been invalidated after the transfer.