WinCC Flexible Discrete Alarm VBScript Access: Methods & Limits

Overview

WinCC Flexible provides a VBScript runtime environment on Comfort Panels, Mobile Panels, Multi Panels, and on the PC-based WinCC Flexible Runtime. Engineers frequently ask whether a discrete alarm can be referenced as an object — for example DiscreteAlarm_1.Text or DiscreteAlarm_1.Number — and whether those properties can be read, modified, or passed into a subroutine when the alarm is raised, cleared, or acknowledged. The short answer, as confirmed in the WinCC Flexible online help and replicated in numerous field cases, is no: WinCC Flexible does not expose discrete alarm instances as Automation objects to VBScript. Discrete alarms are configured in the alarm editor and rendered by the alarm view / alarm window control, but they are not addressable from generic screen scripts.

This reference documents the actual limits, the recommended indirect patterns, the ShowSystemAlarm system function, the alarm event handlers that exist on Comfort Panels and Runtime Advanced, and how the picture changes in the successor product, WinCC Unified. It includes runnable VBScript fragments, parameter tables, and a troubleshooting matrix for the most common error conditions encountered during commissioning.

Discrete Alarm Model in WinCC Flexible

WinCC Flexible classifies messages into discrete alarms, analog alarms, and system alarms. Each discrete alarm binds to a single trigger bit inside an HMI tag (typically a Bool, Word, Int, or DWord) and renders a configurable message text when the trigger bit transitions from 0 to 1. The discrete alarm has a fixed set of design-time attributes; runtime properties are not addressable as a script object.

Because the discrete alarm record itself is not addressable, VBScript cannot subscribe to "alarm activated", "alarm cleared", or "acknowledged" callbacks directly. The runtime only exposes a global alarm API plus the trigger tags that fire the alarms.

Direct Property Access: Why It Fails

The pattern engineers typically attempt looks like this:

' Hypothetical — does NOT compile in WinCC Flexible
Dim sText
sText = DiscreteAlarm_5.Text       ' Error: object undefined
Call LogMessage(DiscreteAlarm_5.Number, sText)

This fails because DiscreteAlarm_5 is not a registered Automation object in the WinCC Flexible runtime. The documented object model is restricted to:

• HMIRuntime — top-level runtime object
• Screen / ScreenItems — current screen and its items
• Tags — HMI tag collection (read / write by name)
• SmartTags — convenience accessor for configured tag names
• AlarmEvents — available on WinCC Runtime Advanced ≥ V14 SP1

None of these collections contain discrete alarm instances. The WinCC Flexible Help entries "How do you dynamize objects in WinCC flexible via scripts?" and "Which VBS information and programming aids are there in WinCC Flexible?" confirm that the available object model is restricted to screens, tags, and a fixed set of system functions.

Workaround 1: ShowSystemAlarm for Synthetic Messages

When the requirement is to generate a runtime message from script (for example, an operator prompt derived from a calculation), use the documented system function ShowSystemAlarm. It pushes an entry into the active alarm window without requiring a preconfigured discrete alarm:

' Runtime-evaluated message
ShowSystemAlarm "Compressor " & SmartTags("UnitName") & _
               " exceeded " & CStr(SmartTags("TempLimit")) & " °C"

Syntax (WinCC Flexible / WinCC Comfort, VBS):

Behavior on a Comfort Panel:

• Appears as an "Operator information" class message in the alarm window.
• Severity is fixed at the "Operator Information" class — it is not a process alarm and is not logged unless the operator class is configured for logging in the alarm buffer.
• No acknowledgement is required; the entry clears when the operator presses the configured button or after the configured display duration.
• Maximum length is 512 characters on PC Runtime; Comfort Panels cap at 255 characters; older 170 / 270 panels cap at 80.

ShowSystemAlarm is useful for surfacing derived conditions that do not correspond to a single trigger bit. It does not provide a hook to inspect or mutate a configured discrete alarm record.

Workaround 2: Tag-Based Mirror Pattern

To pass alarm properties into a subroutine, mirror the data in a separate internal tag or string variable that is updated by a parallel mechanism. Two variants are common in the field.

2a. Tag-Change Event Drives the Subroutine

Bind the discrete alarm's trigger bit to a configured tag, then attach a VBScript subroutine to the tag's "Change value" event. The trigger tag value is fully readable; from it you can infer state.

' Configuration:
'   Tag "Alarm1Trigger" : Bool, internal
'   Discrete alarm "Alarm1" bound to bit 0 of Alarm1Trigger
'   VBS on "Change value" of Alarm1Trigger:

Sub OnAlarm1TriggerChange(ByVal Item)
    If Item.Value = True Then
        LogOperatorAction "Alarm1 activated on unit " & SmartTags("CurrentUnit")
    Else
        LogOperatorAction "Alarm1 cleared"
    End If
End Sub

Because the script receives Item as a HMITag object, you have access to the trigger tag's value, name, and quality code — but you still cannot query the discrete alarm record itself.

2b. Auxiliary String Tag Holds the Alarm Text

If the goal is to display the message text on a non-alarm-view object (a label, tooltip, popup), populate an internal string tag from the same script that processes the trigger:

' Internal tags:
'   sAlarmText   : WString[254]
'   bAlarmActive : Bool

Sub UpdateAlarmDisplay(ByVal Item)
    Dim sText
    Select Case SmartTags("AlarmCode")
        Case 1: sText = "Motor overload — check current"
        Case 2: sText = "Bearing temp limit exceeded"
        Case Else: sText = "Unknown alarm: " & SmartTags("AlarmCode")
    End Select
    SmartTags("sAlarmText")   = sText
    SmartTags("bAlarmActive") = Item.Value
End Sub

Bind the discrete alarm to AlarmCode as the trigger source, but treat AlarmCode as the canonical state carrier. The discrete alarm then becomes purely a presentation layer.

Workaround 3: Alarm Event Functions on the Panel

Comfort Panels and WinCC Runtime Advanced expose a small set of event functions specifically for alarms. Configure these in the alarm editor under Properties → Events rather than via generic screen scripts:

Each handler receives the alarm number as an implicit parameter when invoked from a function list; in VBS the number is available through the alarm context on supported firmware. This is the closest WinCC Flexible comes to "alarm as an object". Engineers who need true alarm-property callbacks should treat these events as the official entry points and avoid trying to address alarms by symbolic name from generic script bodies.

VBScript Code Examples

Example 1: Aggregating Multiple Discrete Alarms

' Purpose: combine the state of five discrete alarms into a single
'          summary bit and a comma-separated text string.
'
' Tags:
'   AlarmSummary : Bool
'   AlarmText    : WString[254]

Sub AggregateAlarms()
    Dim sList, bAny, i
    sList = ""
    bAny  = False
    For i = 1 To 5
        If SmartTags("Alarm" & i & "_Active") Then
            bAny = True
            If Len(sList) > 0 Then sList = sList & ", "
            sList = sList & SmartTags("Alarm" & i & "_Text")
        End If
    Next
    SmartTags("AlarmSummary") = bAny
    SmartTags("AlarmText")    = sList
    If bAny Then
        ShowSystemAlarm "Aggregated: " & sList
    End If
End Sub

Example 2: Conditional Re-arming Using the Trigger Tag

' Purpose: clear the alarm only if the underlying process condition
'          has actually returned to normal.
'
' Bind to event "Change value" of tag "PressureHigh".

Sub OnPressureHighChange(ByVal Item)
    If Item.Value = False Then
        If SmartTags("PressureActual") < SmartTags("PressureSP") Then
            SmartTags("AlarmArmed") = True
        End If
    End If
End Sub

Example 3: Acknowledgement Logger

' Purpose: when an alarm is acknowledged, append a line to a CSV file
'          on the panel's storage card.
'
' Bind to event "OnAcknowledge" of any discrete alarm that requires
' the audit trail.

Sub LogAck(ByVal AlarmID)
    Dim f, sLine
    Set f = CreateObject("FileCtl.File")
    f.Open "\Storage Card SD\ack_log.csv", 8, True  ' 8 = modeAppend
    sLine = Now & "," & SmartTags("CurrentUser") & "," & AlarmID
    f.LinePrint sLine
    f.Close
End Sub

Pattern Comparison

Acknowledgement Models and Alarm Classes

Discrete alarms in WinCC Flexible belong to one of several alarm classes. The class drives how the alarm is presented and whether acknowledgement is required:

Confirmation of acknowledgement happens at the panel level, not at the alarm object level. The standard acknowledgement workflow uses the alarm view's acknowledge button, which fires the OnAcknowledge event handler. There is no script API to acknowledge an alarm programmatically by number — the typical workaround is to write the alarm code to a marker tag and process it in a downstream PLC block.

PLC to HMI Tag Coupling

Most discrete alarms are triggered by bits inside a process tag read from a SIMATIC S7-300 / S7-400 / S7-1200 / S7-1500 PLC over MPI, PROFIBUS, or PROFINET. Verify the tag connection is healthy before debugging alarm scripts:

1. In WinCC Flexible, open HMI tags and select the trigger tag.
2. Confirm the address (e.g., DB100.DBX0.0) matches the PLC symbol.
3. Right-click the connection and select Check consistency.
4. On the panel, open the alarm view and verify the discrete alarm fires when the bit is forced in the PLC.
5. Add a temporary internal Bool tag and bind a script to it to confirm the VBScript runtime itself is responsive.

A misconfigured trigger bit produces a script that never executes, and engineers commonly mistake that for a VBScript defect. The fix is at the tag-connection layer, not the script layer.

Multilingual Text Considerations

Alarm text is normally edited through text lists to support multiple runtime languages. WinCC Flexible evaluates the active language at message-render time, not at script-execution time. Because the alarm object is not addressable from script, VBScript cannot pick the correct text list entry — it can only mirror the bit state. If you need a label that shows the same translated text as the alarm, bind the label to the same text-list reference rather than to a script-populated string tag. Text-list bindings honour the active language automatically.

Migration to WinCC Unified

For new projects or hardware refreshes, migrating to WinCC Unified removes most of the limitations above. In Unified (TIA Portal V16 and later), discrete alarms are first-class objects accessible through the JavaScript API on the Unified Panel and Unified PC Runtime. Trigger tags, alarm text, state, and acknowledgement are all addressable from script.

Discrete Alarm Configuration in TIA Portal

The configuration path for discrete alarms in TIA Portal / WinCC Unified is documented at Configuring discrete alarms (WinCC Unified):

1. Open the project in TIA Portal and select the HMI device.
2. In the project tree, open HMI tags → Show all tags.
3. Create the trigger tag (e.g., HMI_Tag_1) as Bool, Int, Word, or DWord depending on the alarm density.
4. Open the HMI alarms editor and switch to the Discrete alarms tab.
5. Click Add to create a new discrete alarm row.
6. Bind the alarm's trigger to the desired tag and bit (e.g., bit 0 of HMI_Tag_1).
7. Configure the alarm class (Errors, Warnings, Information), the message text (multilingual via text lists), and any associated logging.
8. Compile the HMI and download to the target.

Once configured, the alarm is addressable from a Unified screen's JavaScript via the alarm API — for example HMIRuntime.Alarms and the associated event interface.

Troubleshooting Matrix

Field Commissioning Checklist

1. Verify the discrete alarm fires in the alarm view before binding any VBScript handlers. A misconfigured trigger bit silently produces a script that never executes.
2. Confirm the trigger tag connection in the HMI tags editor (right-click → Check consistency).
3. For each tag that drives a script, verify the tag's quality code by displaying it on a screen during commissioning.
4. Test acknowledgement by simulating operator ACK; verify the OnAcknowledge handler runs and the marker tag updates.
5. Validate multilingual text by switching the panel language; verify the alarm text updates as expected.
6. For audit logs, test the storage card path and file permissions during commissioning — not after the line is in production.
7. Document the alarm number, trigger tag, and handler functions in the project documentation so future engineers do not waste hours trying to read alarm properties from script.

Best Practices

• Treat the discrete alarm as a presentation primitive, not an application object. Put process logic on the trigger tag, not on the alarm.
• Configure OnAlarm / OnClear / OnAcknowledge events for any audit logging — do not rely on polling from a screen event.
• Keep ShowSystemAlarm messages short. Comfort Panel string limit is 255 characters.
• Use a dedicated internal tag (Bool or Word) as the "alarm code" carrier so that downstream logic does not need to enumerate alarm numbers.
• For new projects, default to WinCC Unified unless the panel hardware is locked by inventory or by an existing spare-parts policy.
• Avoid mixing trigger sources across discrete and analog alarms in the same event handler — the implicit alarm context differs.

Frequently Asked Questions