Resolving Duplicate ALARM_SQ Tags in STEP 7 V5.4 with WinCC V7.0

Overview

The ALARM_SQ (and ALARM_DQ) standard block family in SIMATIC STEP 7 V5.4 SP4 generates message-capable alarms on S7-300/S7-400 CPUs and, when combined with the AS-OS Engineering tool, automatically publishes them to a paired WinCC V7.0 SP1 station. A common field complaint is that the OS compile step creates three ancillary tags for every alarm:

• <MSG_ID>.EventState
• <MSG_ID>.EventRaw#1
• <MSG_ID>.EventTrans#1

These tags are visible in WinCC Tag Management and inflate the runtime tag count by a factor of three per active message. On large plants with thousands of alarms this is a serious licensing and memory problem because WinCC tags are sold in 128/256/512/... licensed increments. This reference documents the root cause, the field-proven workaround, the verification procedure, and the migration path to the TIA Portal Program_Alarm instruction that does not exhibit the same behavior.

Background: The ALARM_SQ Block Architecture

ALARM_SQ is one of the four standard message-procedure blocks delivered with the STEP 7 Standard Library under Standard Library > Miscellaneous Blocks:

Each call to ALARM_SQ opens a message slot in the CPU's local message buffer. The block returns a 24-byte Message Instance data record containing the slot number (MSG_ID), the event state, the raw event ID, and the transition ID. When the OS is compiled by the AS-OS wizard, STEP 7 reads these records from the S7 program and creates a mirror of three WinCC tags per slot:

The first tag (EventState) is mandatory because the WinCC Alarm Control reads it to color the message line. The remaining two (EventRaw#1 and EventTrans#1) are conditional: they are emitted only when the corresponding Instance DB has the attribute Operator Control and Monitoring = S7_m_c / true set on its Special Object Properties.

Problem: Duplicate Tag Generation in WinCC

A user running STEP 7 V5.4 SP4 with WinCC V7.0 SP1 reports the following after running AS-OS Engineering → Compile OS:

"When I compile the OS, tags are created by the STEP 7 but for each alarm it is created 2 tags named xx.EventRaw#1 and xx.EventTrans#1... this is increasing the tags. How can I prevent this case?"

The same symptom is reproduced in a second independent project that uses ALARM_DQ in combination with the S7_server = alarm_archiv attribute. The user explicitly needs the Operator Control and Monitoring attribute for unrelated reasons (locking inputs, password handling, operator authorization), and therefore cannot disable it globally on the block.

Symptom Summary

• Every ALARM_SQ / ALARM_DQ call yields exactly three tags in WinCC Tag Management instead of one.
• Tags are read-only and cannot be deleted manually from the WinCC project tree because they are regenerated on the next OS compile.
• Tag licensing charges increase 3×; on a 4 000-message plant this means 8 000 power-tags instead of 4 000.
• OS compile time grows roughly linearly with the number of message instances because the AS-OS wizard re-reads every Instance DB.

Root Cause: Operator Control and Monitoring Attribute

The two extra tags are produced by the Operator Control and Monitoring (German: Bedien- und Beobachtbarkeit, abbreviated B&B) interface. When this attribute is enabled on a block's Special Object Properties, STEP 7 instruments the following capabilities into the Instance DB:

1. Input disabling (operator lock per signal) — the EventTrans#1 tag carries the transition between locked and unlocked states.
2. Output acknowledgment — the EventRaw#1 tag carries the raw raised edge so WinCC can display the message even after the CPU restart.
3. Authentication / authorization — the slot can be tied to a user-class check on the HMI side.

Each of these capabilities requires its own tag because WinCC's Channel "SIMATIC S7 Protocol Suite" maps them to discrete DB bits. The PLC firmware writes the raw state into EventRaw#1, the user-side transition into EventTrans#1, and the consolidated state into EventState. When the B&B attribute is off, only EventState is published because the operator-level semantics do not exist.

Solution: Disable Operator Control and Monitoring on the Instance DB

The field-proven workaround, confirmed on STEP 7 V5.4 SP4 / V5.5 with WinCC V7.0 SP1 / V7.2, is to clear the Operator Control and Monitoring flag for the Instance DB of the user FB that contains the ALARM_SQ call.

Prerequisites

• STEP 7 V5.4 SP4 (or V5.5) installed and licensed, including the Standard Library.
• WinCC V7.0 SP1 (or V7.2) installed with the SIMATIC S7 Protocol Suite channel.
• The S7 program and the WinCC project must reside in a STEP 7 multi-project and be linked through the AS-OS Engineering wizard.
• The user FB containing the ALARM_SQ / ALARM_DQ call must have been compiled at least once so that the Instance DB exists.

Step-by-Step Procedure

1. Open the S7 program in SIMATIC Manager.
2. In the project tree, navigate to S7 Program → Blocks and locate the multi-instance DB of the user FB that wraps ALARM_SQ (for example DB120 "Alarm_FB_IDB").
3. Double-click the Instance DB to open the LAD/FBD/ST editor.
4. Right-click the block title bar and choose Object Properties (or use menu Edit → Object Properties).
5. Switch to the Special Object Properties tab.
6. Locate the checkbox Operator Control and Monitoring (German: Bedien- und Beobachtbarkeit).
7. Uncheck the box. Click OK.
8. Save and close the Instance DB.
9. Recompile the S7 program: PLC → Compile and Download Objects or simply Save and Compile.
10. Open the WinCC project (it can stay in the same multi-project) and run the AS-OS Engineering → Compile OS wizard again.
11. After the OS compile completes, open WinCC Explorer → Tag Management → SIMATIC S7 PROTOCOL SUITE → [connection] → [tags] and verify that EventRaw#1 and EventTrans#1 are no longer present.

Code Snippet: Typical ALARM_SQ Call

The following ST snippet shows a representative instance that triggers the duplicate-tag behavior when the IDB has B&B enabled. The block call itself does not need to change.

// FB120 "Alarm_Handler" - representative call
FUNCTION_BLOCK FB120
VAR
    iAlarmID : INT;        // Message slot from ALARM_SQ
    bSignal  : BOOL;       // Process condition to monitor
    bAck     : BOOL;       // Operator acknowledgement
    bLock    : BOOL;       // Operator lock request
END_VAR
BEGIN
    // Standard library call
    iAlarmID := ALARM_SQ(
        EN     := TRUE,
        SIG    := bSignal,           // Event signal
        ID     := DW#16#EEEE0001,    // Message number (any free number)
        EV_ID  := DW#16#EEEE0001,    // Event ID (must match)
        SE     := bLock,             // 1 = lock / unlock
        ACK    := bAck,              // Acknowledgement
        LADDR  := W#16#0FFE          // Diagnostic address (or 0)
    );
END_FUNCTION_BLOCK

The SE and ACK inputs are the underlying mechanism for the B&B attribute. When B&B is unchecked, WinCC still receives the alarm but cannot display lock-state transitions.

Verification

1. Open the WinCC project and select Tools → Cross References for the alarm tag prefix.
2. Confirm that EventRaw#1 and EventTrans#1 no longer appear in the tag list.
3. Trigger a test alarm in PLCSIM (or on the real CPU) and confirm that the WinCC Alarm Control still receives the message and shows the correct state color (red = active, green = acknowledged).
4. Check the WinCC license usage: Project → Properties → Licenses. The "Power Tags" count should drop by 2 per message.
5. Open the OS Project Editor → Message Configuration and confirm that the alarm is still listed with correct text and associated values.

Alternative Approaches

Parameter Reference: ALARM_SQ Inputs

Memory and Licensing Impact

The economic impact of the duplicate tags is best understood with the WinCC V7 power-tag licensing model. A 4 000-alarm plant experiences the following delta:

The 3× multiplier also has a WinCC runtime effect: each tag is updated cyclically by the S7 channel driver. Disabling B&B halves the cyclic S7 communication load per message, which can be a relief on slow MPI/Profibus links.

Migration Path: TIA Portal Program_Alarm

For new projects or for plants undergoing a STEP 7 V5.4 → TIA Portal V16/V17/V20 migration, the equivalent of ALARM_SQ is the Program_Alarm instruction. According to the official TIA Portal help for V20, the workflow is:

1. Create a global data block (for example DB_Alarms) and declare a tag of type BOOL for every signal to be monitored.
2. Inside a function block, call the Program_Alarm instruction and wire the signal tag, the alarm text, and the associated values.
3. The instruction returns an alarm instance and a single alarm-state tag; no EventRaw / EventTrans companion tags are produced.
4. When the OS (WinCC Professional / Unified) is compiled, only the configured alarm and its datapoint tag are published, halving or thirding the tag count per alarm.

The full procedure is documented in the TIA Portal V20 help portal under Extended Instructions (S7-1200/S7-1500) → Alarms → Program_Alarm. The new instruction also supports message classes, priorities, and free-form associated values without the "Operator Control and Monitoring" flag of the legacy model.

Edge Cases and Field Notes

1. PCS 7 vs. Stand-alone STEP 7

The B&B flag is a STEP 7 feature, not a PCS 7 feature. In PCS 7 V8/V9 the master data library (APL — Advanced Process Library) configures B&B on every channel block by default to support operator lock. Disabling it on a PCS 7 APL block breaks the standard operator faceplate. Apply the fix only on custom FBs in PCS 7, never on APL channel blocks.

2. AS-OS Re-Compile Resets the Flag

When the OS is re-compiled after a STEP 7 program change, the AS-OS wizard does not overwrite the Instance DB attribute. The flag persists. However, deleting and re-creating the Instance DB (for example by recompiling the FB with a new interface) restores the default value (checked). Always re-apply the unchecked state after any FB re-compile.

3. Read-Only Behavior in WinCC

The duplicate tags are flagged as system-managed in WinCC and cannot be removed manually from Tag Management. Attempting to delete them generates the warning "Tag is generated by STEP 7 and cannot be edited". The only legal way to remove them is the STEP 7-side fix described above followed by an OS re-compile.

4. Interaction with Alarm_Archiv

When the project uses the S7_server = alarm_archiv attribute (typically on a server pair), the alarm archive is unaffected by the B&B flag. Disabling B&B only removes the auxiliary WinCC tags; the archive continues to log the alarm with the configured state, priority, and associated values.

5. PLCSIM and WinCC Runtime

When the fix is verified in PLCSIM, the duplicate tags disappear from the WinCC project on the next compile. They do not need a WinCC runtime restart, but a new Activate of the WinCC project is required to drop the cached tag list at runtime.

Troubleshooting Matrix

Best Practices

1. Decide up-front which alarms require operator lock / unlock. Mark them explicitly in the project standards document.
2. Disable B&B on all non-critical alarms to keep the tag count and licensing predictable.
3. Use a single multi-instance DB per process unit so the B&B flag can be managed at one place.
4. Add a comment in the IDB header that documents the B&B state ("B&B disabled 2024-03-15 j.doe to limit WinCC tags") to prevent accidental re-enabling.
5. For new projects, prefer TIA Portal V16+ and the Program_Alarm instruction; the legacy B&B model is deprecated.
6. Re-validate the tag count after every OS compile using a small WinCC script or the project's Cross Reference report.

FAQ