WinCC Flexible Alarm Display from SIMOTION SCOUT Configuration

1. Overview

SIMOTION controllers configured in SCOUT (or the TIA Portal engineering environment for newer firmware) define alarms in the project tree under Alarms. These alarms are stored in the controller's runtime data structure and can be raised at runtime by the application program. The companion HMI engineering tool WinCC flexible 2008 SP5 / WinCC (TIA Portal) is responsible for displaying those alarms on panels such as the MP 277, TP 177B, Comfort Panel, or the runtime simulator.

The most common reason a configured alarm does not appear in the HMI Alarm View is a missing HMI-side subscription: WinCC flexible must be told which alarm number range or alarm class to poll, and the project must be compiled, downloaded, and connected to the SIMOTION controller over PROFINET, PROFIBUS, or MPI/Industrial Ethernet. This article explains the SCOUT-side configuration, the Structured Text (ST) function-block code required to raise and clear alarms using the _alarmscid and _alarmsid system functions, the WinCC flexible Alarm View wiring, and the diagnostics path when the alarm still does not show up.

2. Architecture and Alarm Flow

Alarms flow from the controller to the HMI through the following layers:

1. SCOUT project tree → Alarms configuration with alarm numbers, classes, message texts, and structAlarmId handles.
2. ST application → calls _alarmscid(id) to query state and _alarmsid(sig, ev_id) to raise/clear the alarm.
3. Controller runtime → writes the alarm status into the SIMOTION alarm buffer and broadcasts it on the configured HMI connection.
4. WinCC flexible / WinCC TIA → subscribes to the alarm class, updates the Alarm View, and shows the text plus state color.

A functional end-to-end chain requires all four layers. If any link is missing, the HMI will show no entry, even when the alarm is correctly raised in SCOUT.

3. Prerequisites

4. Configuring Alarms in SCOUT

1. Open the SIMOTION project in SCOUT, right-click Alarms in the project tree under the controller, and choose Insert new alarm.
2. Define the alarm number (1…65 535). The number is the handle the application code will use.
3. Select the alarm class (e.g., FAULT, WARNING, INFO) and the associated display class on the HMI side.
4. Enter the message text and any acknowledgement model (none, coming, going, coming & going, status, status & ack).
5. Compile the SCOUT project (Project → Compile and check objects). The compiler generates the structAlarmId symbol used by ST.

The alarm configuration is the static side. Dynamic raising/clearing is handled in the application program.

5. ST Application Code: Raising and Clearing Alarms

The system functions _alarmscid and _alarmsid are the canonical way to drive SIMOTION alarms from ST. The functions are declared in the SIMOTION system library and operate on a structAlarmId argument that the compiler generates from the alarm configuration. The _alarmscid call returns the current state of the alarm as a DWORD; the constant MESSAGE_STATE_INACTIVE = 16#0010 means the alarm is not currently active.

5.1 Complete INTERFACE and IMPLEMENTATION Block

INTERFACE
TYPE
  actuator_status_enum : (STATUS_OFF, STATUS_ON, STATUS_DISABLED, STATUS_FAULT);
END_TYPE

FUNCTION event_handler;
FUNCTION alarm_handler;
FUNCTION get_actuator_status;
END_INTERFACE

IMPLEMENTATION
VAR_GLOBAL CONSTANT
  MESSAGE_STATE_INACTIVE : DWORD := 16#0010;
END_VAR

FUNCTION event_handler : VOID
VAR_INPUT
  raise    : BOOL;
  event_id : structAlarmId;
END_VAR
VAR
  event_state   : DWORD;
  return_dword  : DWORD;
END_VAR
event_state := _alarmscid(event_id);

IF raise AND event_state = MESSAGE_STATE_INACTIVE THEN
  return_dword := _alarmsid(sig := TRUE,  ev_id := event_id);
END_IF;

IF NOT raise AND event_state <> MESSAGE_STATE_INACTIVE THEN
  return_dword := _alarmsid(sig := FALSE, ev_id := event_id);
END_IF;
END_FUNCTION

FUNCTION alarm_handler : VOID
VAR_INPUT
  raise    : BOOL;
  alarm_id : structAlarmId;
END_VAR
VAR
  alarm_state   : DWORD;
  return_dword  : DWORD;
END_VAR
alarm_state := _alarmscid(alarm_id);

IF raise AND alarm_state = MESSAGE_STATE_INACTIVE THEN
  return_dword := _alarmsid(sig := TRUE,  ev_id := alarm_id);
END_IF;

IF NOT raise AND alarm_state <> MESSAGE_STATE_INACTIVE THEN
  return_dword := _alarmsid(sig := FALSE, ev_id := alarm_id);
END_IF;
END_FUNCTION

FUNCTION get_actuator_status : actuator_status_enum
VAR_INPUT
  enabled : BOOL;
  on      : BOOL;
  fault   : BOOL;
END_VAR
IF fault THEN
  get_actuator_status := STATUS_FAULT;
ELSIF NOT enabled THEN
  get_actuator_status := STATUS_DISABLED;
ELSIF on THEN
  get_actuator_status := STATUS_ON;
ELSE
  get_actuator_status := STATUS_OFF;
END_IF;
END_FUNCTION
END_IMPLEMENTATION

5.2 Calling Pattern

1. Insert a new ST source file in the SCOUT project under the SIMOTION controller → Programs → ST sources.
2. Paste the interface and implementation above. The order in the file (INTERFACE before IMPLEMENTATION) is required by the ST compiler.
3. In the call site, use Symbol input help… on the alarm_id input. The symbol browser will list the configured alarms; selecting one auto-fills the structAlarmId.
4. Compile the ST source. Any mismatch between the configured alarm numbers and the call site will produce a Type mismatch or Undefined symbol error.

5.3 State Word Reference

6. WinCC Flexible HMI Configuration

Once SCOUT can raise the alarm, the HMI project must be configured to receive and render it.

6.1 Add a Connection to the SIMOTION Controller

1. In the WinCC flexible project tree, right-click Connections and choose Add Connection.
2. Set the Communication driver to SIMOTION (or PROFINET in TIA Portal). The driver is part of the SIMOTION HMI option.
3. Enter the IP address of the SIMOTION interface (X150, X160, or PN/IE) and the rack/slot (for PROFIBUS) or station number (for PROFINET).
4. Confirm the connection is online using Tools → Status of Connections — the icon must turn green.

6.2 Configure the Alarm Classes

Alarm classes determine color and acknowledgement behavior on the HMI. In WinCC flexible:

1. Open Project → Alarm Logging (or in TIA Portal, HMI alarms → Alarm classes).
2. Verify the default classes Errors, Warnings, System, Diagnostic Events, and Motion exist.
3. Under Settings → Controller alarms, enable SIMOTION alarms. Without this flag the HMI will not poll the controller alarm buffer.

6.3 Place an Alarm View on a Screen

1. Open the desired screen in the HMI screen editor.
2. From the Tools palette, expand Enhanced Objects and drag Alarm View onto the screen.
3. In the Alarm View properties, set the Alarm class filter to All (or to the specific class such as Errors).
4. Enable the columns: Number, Time, Date, State, and Text. These map to the alarm record fields in the SIMOTION buffer.
5. Resize the view to display at least 8–10 rows so a triggering alarm is visible without scrolling.

6.4 Compile and Download

1. Compile the HMI project (Project → Compiler → All). The compile must finish without errors. Common issues: missing PLC tag, broken connection, or a tag assigned to a controller that is not in the project.
2. Download the project to the HMI (Target system → Download). The transfer requires a working PG/PC interface, typically Ethernet for Comfort Panels and USB/PROFINET for older panels.
3. Restart the HMI Runtime if the alarm class configuration was changed while online.

7. Parameter Mapping Reference

8. Verification

After completing the SCOUT and WinCC flexible configuration, validate the chain end-to-end:

1. Online in SCOUT: open the Alarm buffer on the controller. Trigger the alarm from the ST program (e.g., force raise := TRUE on a test call). The buffer must show the alarm with state Present.
2. Online in WinCC flexible: switch to Runtime on the HMI. The Alarm View must show a new row within one polling cycle (typically 250–1000 ms depending on the connection type).
3. Acknowledge path: if the alarm requires acknowledgement, the Ack button must clear the corresponding bit in the controller alarm state.
4. Clear path: setting raise := FALSE in the application code must transition the alarm to Going and then remove it from the active list, leaving an entry in the history log.

9. Troubleshooting Matrix

10. Field-Commissioning Checklist

• SCOUT alarm list contains the expected numbers and classes.
• ST source compiled without warnings; structAlarmId symbols resolved.
• Controller is in RUN with the program active and the alarm task scheduled.
• WinCC flexible connection is online (green icon in the status bar).
• Alarm class filter on the HMI includes the active class.
• Alarm View object is placed on a screen that is the active screen in Runtime.
• Manual trigger from SCOUT (right-click → Acknowledge/Trigger alarm) produces a row in the HMI Alarm View within 2 seconds.
• Acknowledge button removes the active state on the controller.

11. Frequently Asked Questions