WinCC Alarm Lock: Resolving CameIn WentOut Re-trigger on Restart

Problem Definition: CameIn/WentOut Re-trigger After Runtime Restart

WinCC Runtime (WinCC V7.x and TIA Portal WinCC Professional V16–V19) records alarm events as discrete state transitions on each monitored tag, bit selection, or AS message. The Alarm Logging service maintains the current status of every active message number in an internal message frame buffer that is written to the message archive and persisted across Runtime restarts.

When the Runtime is deactivated (project stopped) while one or more messages are in the CameIn state (status flag = 1, not yet acknowledged), those open states remain in the buffer. On the next Runtime start, the message frames are reloaded. Any tag that is still at the high level is reported as a new CameIn event with a fresh time stamp equal to the moment of project activation. Operators therefore see what appear to be duplicate alarm entries after every restart, even though the underlying PLC condition never actually cleared between the two timestamps.

Siemens classifies this as a feature rather than a defect: it allows the archive to reconstruct continuous process state across a planned or unplanned Runtime stop, and lets the operator know that the Runtime was inactive during the gap. When the duplicate entry is not desired (for example, a long-term OS shutdown or PC reboot with a continuous process behind it), the WinCC Alarm Control offers a Lock mechanism that suppresses re-triggered messages while still recording legitimate state transitions. The same mechanism is documented in Siemens Support entry 15186316.

Alarm State Model and CameIn/WentOut Semantics

WinCC distinguishes the following alarm statuses per message number and instance, controlled by bits stored in the message frame and updated by the Alarm Logging service:

For bit-mapped alarms the message status is evaluated continuously by the Alarm Logging service on the WinCC server. For AS (PLC) alarms the status is communicated via the S7 connection and the ALARM_S / ALARM_D / ALARM_8P protocols, depending on the PLC family (S7-300/400 with ALARM_S, S7-1200/1500 with ALARM_8P and program_Alarm, or ALARM_D for S7-400 with acknowledge).

The CameIn / WentOut pair is logged with separate time stamps and a single message number. If a tag is high when the Runtime starts, only a CameIn event is logged; the matching WentOut will be logged later when the tag finally falls, regardless of when the Runtime started.

Root Cause of Re-trigger on Runtime Deactivation

Three distinct code paths can produce the observed re-trigger:

1. Normal Persistence Path (intended behavior): The message frame buffer keeps CameIn state for any active message number. On project activation, Alarm Logging detects that the tag bit is still high and logs a fresh CameIn entry. This is the most common cause and is what the user sees in the alarm screen.
2. Auto-Start of WinCC Runtime after PC reboot: When WinCC Runtime is configured with AutoStart > Runtime start on system startup and the OS boots faster than the alarm archive replay completes, pending CameIn frames are replayed against the current tag value, producing the same re-trigger pattern as a manual deactivate/reactivate cycle.
3. Re-docking of PLC connection: If the PLC tag is a non-buffered bit that briefly reads as 0 during reconnect, the CameIn state may be lost and the next rising edge is logged again. This is rare but appears identical to the symptom the user reported.

The correct remedy for path 1 and path 2 is the lock mechanism described in the next section. Path 3 requires either setting the tag's Update property in WinCC to "On Change" with operator-controlled reconnect, or using a retentive tag in the PLC.

Lock/Unlock Mechanism in the WinCC Alarm Control

The Alarm Control (WinCC Alarm Control Classic for WinCC V7, WinCC Alarm Control for WinCC Professional) exposes two operator actions that affect visibility without affecting the archive:

• Lock selected messages: hides the alarm row in the Alarm Control view; the underlying message number remains in the alarm buffer.
• Unlock selected messages: re-enables display of previously locked messages.

The lock is implemented by setting a per-instance lock bit in the Alarm Logging service. The lock survives a Runtime restart but is cleared when the message number is removed from the configuration or when the alarm archive is reset from WinCC Explorer (Alarm Logging > Archive > Reset). For typical operational use, a lock created in one Runtime session is honored in the next.

Locking differs from Acknowledgment: an acknowledged CameIn still displays in the Alarm Control (typically in a different color and without the bell icon) until the tag returns to 0. A locked CameIn does not display at all. Locking also differs from Hide (WinCC V7) and Invisible (WinCC Professional) configuration properties, which are design-time settings applied to all instances of a message number.

Configuring the Lock Dialog in the Alarm Control Toolbar

To enable the lock dialog buttons on a WinCC Alarm Control:

1. Open the WinCC Explorer or TIA Portal WinCC configuration in which the Alarm Control screen is configured.
2. Select the Alarm Control on the screen. In WinCC V7, right-click and choose Configure. In TIA Portal, open the Properties > Toolbar tab of the HMI Alarm Control.
3. In WinCC V7, switch to the Toolbar tab and enable the buttons Lock, Unlock, and Lock Dialog. In TIA Portal, enable Lock selection, Lock list, Unlock, and Selection for lock dialog.
4. In the Alarm Control General tab (WinCC V7) or General > Operation (TIA Portal), ensure Selection is set to Line or Block rather than None; without selection the lock buttons cannot operate.
5. Compile and download or activate the project. In Runtime, click the Lock Dialog button to open a dialog listing all message numbers by class and state. Tick the message numbers to lock, then OK.

The lock dialog is the preferred operator interface when more than a few alarms must be handled. It is the same control referenced in Siemens Support entry 15186316.

Group-Based Alarm Locking for Bulk Operations

When the project contains several hundred message numbers (the user's case mentions ~200), clicking each alarm line is impractical. The Alarm Control lock dialog supports filtering and multi-selection. The recommended sequence is:

1. Open the Lock Dialog in Runtime.
2. Use the Class filter to display only the message class containing the persistent alarms (for example, "Process - High Priority").
3. Use the State filter to display only CameIn (active, not acknowledged).
4. Use Ctrl+A or the Select all visible toolbar button to mark every visible row.
5. Click Lock. The dialog confirms the number of messages locked.

In WinCC V7, additional filtering criteria are available in the lock dialog: Area, Source, Priority, and Time. In TIA Portal WinCC Professional, the lock dialog exposes Message class, Priority, and State. Use these to lock only the relevant subset.

For an automated group lock at Runtime startup, a VBScript can be scheduled in the project startup tasks. The script must run after the Alarm Logging service is fully initialized. A minimum delay of 10 s is recommended.

Automating Lock/Unlock for PC Shutdown and Restart Cycles

For unattended OS shutdown and restart (the user's specific scenario), the lock and unlock operations can be scripted. Two common patterns are shown below.

WinCC V7 (Classic) VBScript on Alarm Logging

' Place in Global Script > Actions > Project Startup
' Execute once after Runtime start, after 10 s delay
Sub OnLocksAfterStart()
    Dim objAL, sResult
    Set objAL = HMIRuntime.AlarmLogging
    ' Lock by message class - all "Process-High" alarms currently CameIn
    sResult = objAL.Lock "Class:Process-High"
    HMIRuntime.Trace "Lock result: " & sResult & vbCrLf
    Set objAL = Nothing
End Sub

The HMIRuntime.AlarmLogging object's Lock method accepts a selection string of the form Class:<name>, Number:<n1>,<n2>,…, or Priority:<n>. The Unlock method uses the same syntax.

TIA Portal WinCC Professional - Scheduled VBScript

' Place in Scheduled Tasks > Run once at Runtime start (with 10 s delay)
Sub LockAtStart()
    Dim sResult
    sResult = SmartTags("HMIRuntime").AlarmLogging.Lock("Class:Process-High")
    ShowSystemAlarm "Auto-lock executed: " & sResult
End Sub

Shutdown Sequence Hook

Windows shutdown cannot reliably trigger a WinCC script because the Runtime is terminated before any user-mode shutdown handler runs. The reliable approach is the startup lock combined with an unlock-on-runtime-stop handler:

1. Configure WinCC Runtime to start automatically when the OS boots (TIA Portal: Runtime settings > AutoStart; WinCC V7: Computer > Startup).
2. Schedule a startup task that locks all message numbers in the relevant classes 10 s after Runtime start.
3. Schedule a shutdown task in Computer > Shutdown (WinCC V7) or Runtime settings > Tasks (TIA Portal) that unlocks the same classes before Runtime closes.

This avoids the re-trigger after the next boot while preserving lock/unlock visibility in the archive.

TIA Portal WinCC Professional vs WinCC V7 Differences

Both products share the same WinCC Alarm Control OCX and the same lock semantics; the differences are in the configuration surface and the API namespace.

State Machine Reference

Verification Procedures

1. Trigger a known alarm from the PLC (or set the trigger tag in WinCC Tag Simulator to 1).
2. Acknowledge the alarm in Runtime.
3. Open the Alarm Control and confirm the message is visible.
4. Open the Lock Dialog and lock the message.
5. Confirm the alarm row disappears from the Alarm Control within one refresh cycle (default 1 s).
6. Open WinCC Explorer > Alarm Logging > Archive > View, confirm the Lock event is recorded with operator name and time stamp.
7. Deactivate and reactivate Runtime. Confirm no new CameIn is logged for the still-high tag.
8. Unlock the message. Confirm it reappears immediately.

For the automated case, perform steps 1-3, then reboot the OS. After the Runtime auto-start and the 10 s startup task, confirm in the alarm archive that a Lock event from the script user (default: SYSTEM) is recorded and that no fresh CameIn appears for the high tag.

Troubleshooting Matrix

Field-Proven Caveats

• Locking only affects operator display. The message is still archived and still drives the horn, the collective acknowledgment, and any computed tag defined on the alarm status.
• In redundant WinCC V7 server pairs, locks are replicated to the standby server through the redundancy sync of the alarm database. Verify both servers are in sync after a failover by inspecting the Alarm Control on the now-active server.
• In WinCC Professional RT with Softnet-based S7 connection, the connection will briefly drop on PC reboot. Configure Reconnect automatically on the connection to avoid spurious WentOut/CameIn during the boot window.
• The lock does not survive a Complete reset of the alarm archive from WinCC Explorer. If you reset the archive, all locks are cleared and all CameIn messages will re-trigger on the next Runtime start until the operator or script locks them again.

FAQ