WinCC Flexible PC Runtime: Audible Alarm on New SFC108 ALARM_D

Problem Statement

WinCC Flexible PC Runtime receives CPU-generated diagnostic and process alarms via SFC108 ALARM_D on SIMATIC S7-300/S7-400 controllers. Unlike bit-mapped HMI alarms configured in the WinCC Flexible project, ALARM_D messages are stateful at the PLC: they are sent, arrive at the HMI, and must be individually acknowledged. The default alarm view displays these events but emits no acoustic signal, so operators only see new alarms when they happen to be looking at the screen. A typical customer requirement is:

• Play a WAV file (continuous, looped, or repeated pulse) from the PC speaker every time a new, unacknowledged ALARM_D enters the message list.
• Stop the sound automatically when the operator presses an Acknowledge/Mute button on the screen.
• Resume the sound if a different, additional alarm arrives after the mute was pressed (a reset must not silence subsequent new alarms).

WinCC Flexible 2008 SP5 and later (the last shipping release of the WinCC Flexible line before the transition to TIA Portal WinCC) does not provide a built-in "play sound on new alarm" property. A working solution always combines a PLC-side or HMI-side new-alarm detector with a Windows audio command launched through an event or VBScript.

Architecture: SFC108 ALARM_D and the WinCC Flexible Message Subsystem

SFC108 ALARM_D is the SIMATIC S7 system function that submits a message to the station configured in the STEP 7 hardware configuration (either an HMI or a central PG/PC). It carries a message number (EV_ID), up to ten associated values, and an acknowledgment state defined in the message text configuration. The message is delivered to all subscribers that have registered for the corresponding EV_ID, which in a WinCC Flexible Runtime is the HMI tag list compiled from the project.

For the audible-warning task, three things must be true before any sound can be triggered:

1. The CPU must be able to submit messages. This requires a configured connection of type "S7-Connection" with the "Active" connection establishment flag, and a message configuration downloaded to the CPU (or generated by the HMI station).
2. The WinCC Flexible project must contain the matching message number and text in Project > Messages > Alarm Settings, mapped to a class (e.g. "Errors, alarms with single acknowledgment").
3. The PC Runtime must be running with a valid authorization on a Windows host with an active sound device. WinCC Flexible PC Runtime runs on Windows XP SP3 / Windows 7 / Windows Server 2003/2008 depending on the installed build.

Reference for SFC108 input/output behavior is the STEP 7 System and Standard Functions manual, available from the Siemens Industry Online Support portal. Search index "SFC108" returns the parameter table (SIG, ID, EV_ID, SEVERITY, ACK_STATE) that must match the message configuration on both sides.

Alarm State Model: New, Active, Acknowledged, Gone

An ALARM_D event has four observable states on the HMI side:

The crucial property is that a new alarm is detected as a positive edge of the ALARM_D active state at the PLC, or equivalently as the appearance of a new entry in the WinCC Flexible message list. A reset / Mute button must not latch the alarm in a "no sound" state if a different alarm arrives later. The implementation must compare the current set of incoming alarm IDs against the set that was present when Mute was pressed, and re-arm the trigger when the two sets differ.

Detection Method 1: PLC-Side Edge Detection (Bit Latching)

The most robust and CPU-independent approach is to create one or more bits in the PLC that go true on a new alarm and remain true until acknowledged. The HMI then only needs to play/stop the WAV on these bits.

Build a 16-bit "incoming alarms word" in a marker area (e.g. MW 200) where each bit represents the active state of one ALARM_D message (or one group of messages aggregated by class). Compare the word to a stored "previous alarms word". Any bit that is 1 in the current word and was 0 in the previous word is a new alarm. The simplified STL is shown below; the same logic can be coded in LAD or FBD.

// STEP 7 STL (S7-300/400)
NETWORK 1  // Build the incoming alarms word
  L     MW 200                  // current incoming word
  T     MW 202                  // snapshot for next cycle

NETWORK 2  // Detect new alarm (edge)
  L     MW 200                  // current
  L     MW 202                  // previous
  XOW                          // XOR: bit set only on change
  L     MW 200                  // current
  AND                          // only bits that are 1 NOW and just changed
  T     MW 204                  // "new alarm" latches per cycle

NETWORK 3  // Latch until Mute/ACK from HMI
  U     M 50.0                  // acknowledge pushbutton from HMI
  UN    M 51.0                  // new-alarm latched
  O     M 51.0
  S     M 51.0                  // set latch
  U     M 50.0
  R     M 51.0                  // reset on acknowledge
  NOP   0

Make M 51.0 the bit the HMI watches for "sound on". The HMI acknowledge button sets M 50.0 for one cycle (configured in the button event), which resets the latch. If, while the operator is muted, a second bit in MW 200 rises, network 2 will produce a new edge in MW 204, re-setting M 51.0 and re-triggering the sound without operator action.

This approach does not require WinCC Flexible to expose the alarm list to the script. It only needs a single Boolean tag.

Detection Method 2: WinCC Flexible System Events

If PLC code is locked or you cannot add markers, WinCC Flexible Runtime fires system events on alarm state changes. They are listed under Project > Messages > System Events in the WinCC Flexible configuration, and the most useful are:

Wire ~AlarmOn to a function in WinCC Flexible that runs a VBScript. The script calls an external sound tool. Wire ~AlarmAck to a function that calls the stop command of the same tool. This is cleaner than the PLC-side approach for projects that already expose ALARM_D to the HMI and is the recommended path on WinCC Flexible 2008 SP3 and later.

Note: System event names differ slightly between WinCC Flexible and TIA Portal WinCC. For TIA Portal documentation, refer to the SIMATIC WinCC (TIA Portal) engineering manual on the Siemens Industry Online Support portal.

Audio Playback Tool Comparison

If the deployment is locked down and third-party tools are not permitted, the PowerShell method is the most reliable. If the WinCC Flexible target is a PC Panel (a Windows CE image running on a Panel PC 477/577/677), only ceplayer.exe is available and the sound must be pulsed from the PLC every 5 seconds until acknowledged.

Step-by-Step Implementation on PC Runtime

Prerequisites

• WinCC Flexible 2008 SP5 (or compatible SP) with PC Runtime authorization.
• STEP 7 V5.5 project with one or more ALARM_D messages, compiled and downloaded.
• One HMI tag (Boolean) that signals "sound on" (PLC-side) or two system events (~AlarmOn, ~AlarmAck).
• WAV file placed on the Runtime PC at a known path, e.g. C:\Audio\alarm.wav.

Procedure

1. Create the alarm-detection marker in the PLC as described in the edge-detection section. Reserve DBW 0 for the current alarms word, DBW 2 for the previous snapshot, and a Boolean Sound_On at DBX 4.0.
2. In WinCC Flexible, add the tag Sound_On with the matching address, polling cycle 250 ms.
3. Add a function PlaySound with a single line of VBScript: CreateObject("WScript.Shell").Run "powershell -NoProfile -Command \"(New-Object Media.SoundPlayer 'C:\Audio\alarm.wav').PlayLooping()\"", 0, False
4. Add a function StopSound with: CreateObject("WScript.Shell").Run "powershell -NoProfile -Command \"(Get-Process powershell | Where-Object {$_.MainWindowTitle -eq ''} | ForEach-Object { $_.CloseMainWindow() })\"", 0, False — or, more reliably, store the PowerShell PID in a tag on the first call and Stop-Process -Id <pid> on stop.
5. On the Sound_On tag, configure Event > Change Value > On change to 1 → PlaySound. On change to 0 → StopSound.
6. Place an Acknowledge/Mute button on the alarm screen. Configure Press event to set the HMI tag Ack_Trigger for one PLC cycle, which the PLC uses to reset the Sound_On latch and to copy the current alarms word into the previous-word buffer.
7. Compile and start Runtime. Trigger any ALARM_D from the PLC; verify the WAV loops. Press Mute; verify it stops. Trigger a second, different ALARM_D; verify the sound resumes without operator action.

VBScript Reference (PC Runtime)

' PlaySound - call from "Change Value = 1" event
Sub PlaySound()
    Dim wsh, cmd
    Set wsh = CreateObject("WScript.Shell")
    cmd = "powershell -NoProfile -Command """ & _
          "$p = New-Object System.Media.SoundPlayer 'C:\Audio\alarm.wav'; " & _
          "$p.PlayLooping()"""
    wsh.Run cmd, 0, False
    Set wsh = Nothing
End Sub

' StopSound - call from "Change Value = 0" or Ack button
Sub StopSound()
    Dim wsh, cmd
    Set wsh = CreateObject("WScript.Shell")
    wsh.Run "taskkill /IM powershell.exe /F", 0, True
    Set wsh = Nothing
End Sub

Panel PC (Windows CE) Variant

On a Windows CE Panel PC, the same function call works with ceplayer.exe:

'\Storage Card CF\audio\alarm.wav
CreateObject("WScript.Shell").Run """\windows\ceplayer.exe"" ""\Storage Card CF\audio\alarm.wav""", 0, False

Because ceplayer closes itself after a single play, the PLC must pulse a bit every 5 seconds while the alarm is active and unacknowledged. Use a self-resetting timer in the PLC, gated by the alarm-active state. ceplayer must be configured to run Minimized and Wait for program to end = No, otherwise the HMI script blocks until the WAV ends.

Acknowledge and Mute Logic

The Acknowledge button must do three things in sequence:

1. Stop the WAV immediately (HMI function StopSound).
2. Reset the Sound_On latch in the PLC so it can re-arm.
3. Acknowledge the visible alarm in the WinCC Flexible message view. This is done either by a separate button bound to the alarm control's built-in Acknowledge function, or by a single combined button that calls Acknowledge on the alarm control first and then triggers the HMI function above.

Do not bind Acknowledge to the alarm control's Reset action. Reset clears the row from the message view; with ALARM_D, that is acceptable, but it also hides whether the underlying PLC condition is still true, which is undesirable for safety-relevant messages.

Verification and Commissioning

Run the following test sequence on the installed Runtime, not on the engineering station:

1. Set the audio output device on the Runtime PC to a known speaker or headphones. Confirm Windows can play the WAV from Explorer.
2. Trigger ALARM_D #1 from the PLC test table. Confirm the WAV starts within 250 ms (one polling cycle of the sound tag).
3. Press the Acknowledge/Mute button. Confirm the WAV stops within 1 second.
4. While muted, trigger ALARM_D #2. Confirm the WAV resumes without operator action.
5. Acknowledge both alarms. Confirm silence.
6. Disconnect the S7 connection from the Runtime side and trigger an ALARM_D from STEP 7. Confirm no sound (the alarm does not arrive).
7. Cycle power on the Runtime PC. Confirm that on restart, no sound is played for stale, already-acknowledged alarms retained in the HMI log buffer.

Troubleshooting Matrix

Edge Cases and Field Notes

Multiple simultaneous alarms. A single Sound_On latch is sufficient; the operator still needs to acknowledge each row individually. Do not attempt to play distinct WAVs per alarm; it does not scale and increases script complexity without operator benefit.

Alarm flooding. If the PLC can produce more than one ALARM_D per second, the edge detection word will overflow the 16-bit marker. Use a DB array indexed by EV_ID and keep a running CRC or hash to detect set-difference; alternatively, latch a single any-new-alarm flag and clear it on the Acknowledge event, accepting that the operator cannot distinguish which alarm is new while the previous is still unacknowledged.

Hot-standby / redundant Runtime. If the project runs on a redundant pair of PCs, the sound script must bind to the same tag in both projects. The tag must come from the PLC, not the local Runtime, so the state survives a switchover.

Migration to TIA Portal WinCC. The same architecture applies, but the system events are now under HMI Tags > System Events in the HMI device configuration. TIA Portal WinCC also supports a built-in Horn object (audio output) on Comfort Panels, which obsoletes ceplayer for that hardware class. See the SIMATIC HMI Comfort Panels manual on the Siemens Industry Online Support for the Horn configuration steps.

Security / Windows UAC. On Windows 7 and later, launching powershell.exe from a WinCC Flexible Runtime that runs as a service account may be blocked by UAC. Either run the Runtime as an interactive user with the UAC slider at the default position, or replace PowerShell with a signed helper executable that does not trigger the UAC consent dialog.

Locale-specific path separators. The WinCC Flexible script engine on some builds treats backslashes in VBScript string literals as escape characters. To avoid that, use forward slashes (which Windows accepts) or double the backslashes in the WAV path string.

FAQ