Siemens SFC 17, 18, 19, 107, 108: S7-300 Alarm Functions Compared

When generating process alarms on a SIMATIC S7-300 CPU such as the CPU 315-2DP, the choice between SFC 17, SFC 18, SFC 19, SFC 107, and SFC 108 determines three things: whether the alarm is acknowledgeable at the HMI, how many process values ride with the event, and which message class (state-related "S" or block-related "D") carries the text. This reference distinguishes all five system function calls, documents their input parameters, and shows the configuration path in STEP 7 V5.5 + SP1 and WinCC 7.0 + SP3 required to surface them on the operator screen.

Overview: Two Families, Five SFCs

The five SFCs split into two families. The S message family (SFC 17 / 18 / 19) reports the live state of a boolean signal and carries a single associated value. The D message family (SFC 107 / 108) reports an event emitted by a function block and carries up to ten associated values. Within each family, one SFC requires operator acknowledgment and one does not; SFC 19 is the lone "acknowledgment trigger" used to confirm SFC 17 events back to the PLC.

Refer to the SIMATIC S7-300 System and Standard Functions reference manual (Siemens entry ID 1214574) for the full call interface and error code table: S7-300 / S7-400 System and Standard Functions. The SFC 17 / 18 / 19 / 107 / 108 message-generation SFCs are covered in the "Message SFCs" chapter of the same manual.

Message Class Architecture: S vs D Messages

The "S" prefix in ALARM_S and ALARM_SQ stands for "state-related" — the message status at the HMI mirrors the live state of the SIG input. When SIG transitions from 0 to 1 the message enters the incoming state; when SIG drops back to 0 the message leaves (for SFC 18) or waits for acknowledgment (for SFC 17). The "D" prefix stands for "diagnostic / data" — D messages are event-driven from a block, and their state at the HMI is independent of any single boolean signal.

Configuration differs accordingly:

• S message configuration: STEP 7 → HW Config → CPU Properties → "Messages" tab → "S7 Messages". Allocate message numbers and assign an EV_ID per message. The same EV_ID is passed to SFC 17 / 18 from the user program.
• D message configuration: Open the FB or instance DB in STEP 7 → right-click the block header → "Object Properties" → "Messages" tab. STEP 7 auto-generates an EV_ID and ties the message to that specific block instance.

Both message classes ride the same transport — the S7-300 uses "Alarm_8" (SFC 17 / 18 / 19) and "Alarm_8P" (SFC 107 / 108) protocol PDUs to the WinCC Alarm Logging component over the configured S7 connection. See the WinCC Information System for Alarm Logging configuration: WinCC V7.0 Alarm Logging — Configuration Manual.

SFC 17 ALARM_SQ — Acknowledgeable State-Related Message

SFC 17 generates an S message that remains in the "incoming, not acknowledged" state on the operator screen until the operator acknowledges it. The message is bound to the SIG input: when SIG = 1 the message is active; when SIG returns to 0 the message remains visible (still unacknowledged) until the operator presses the ACK button.

Call interface (STL):

CALL  SFC  17
      SIG    :=  I 0.0          // Trigger signal (BOOL)
      ID     :=  B#16#0A        // Channel ID, S messages on S7-300
      EV_ID  :=  DW#16#0A000001 // Event ID from message configuration
      SD     :=  P#M 100.0 INT 1// Associated value (ANY pointer)
      ?State :=  M 50.0         // TRUE for 1 scan when ACK received
      RET_VAL:=  MW 200         // Return value (INT)

RET_VAL output is a 16-bit word. The most common error codes for SFC 17 are:

The complete error code table is in the S7-300 System and Standard Functions manual linked above.

SFC 18 ALARM_S — Non-Acknowledgeable State-Related Message

SFC 18 has the identical input interface as SFC 17, but the resulting message at the HMI is not acknowledgeable. When SIG = 1 the message becomes "incoming"; when SIG drops to 0 the message leaves the active list immediately. The operator cannot ACK the message because there is nothing to ACK — its lifetime equals the SIG state.

Use SFC 18 for events the operator should see but does not need to confirm: "Valve V101 opened", "Pump P205 running", "Heater on", and similar status messages. The RET_VAL error codes for SFC 18 are identical to SFC 17.

SFC 19 ALARM_SC — Status Acknowledgment

SFC 19 sends a "natural" or "status" acknowledgment from the PLC for an SFC 17 message. It is distinct from the HMI-driven acknowledgment. A typical sequence:

1. Operator sees the alarm on the HMI (from SFC 17).
2. Operator presses the ACK button on the HMI — WinCC sends an acknowledgment frame to the CPU; the CPU clears its "ACK pending" bit for that EV_ID, and the SFC 17 ?State output pulses TRUE for one scan.
3. The fault condition is repaired in the field — the SIG input to SFC 17 drops to 0.
4. The user program calls SFC 19 with the same EV_ID to tell the CPU "this event is fully cleared and acknowledged in process terms."

SFC 19 has only two parameters:

CALL  SFC  19
      EV_ID  :=  DW#16#0A000001  // Same EV_ID as the SFC 17 call
      ?State :=  M 50.1          // TRUE if acknowledgment was registered
      RET_VAL:=  MW 202

The ?State output goes TRUE for one scan when the HMI acknowledgment has been received for this EV_ID. The SFC 19 RET_VAL error table is identical to SFC 17 (same error codes apply).

SFC 107 ALARM_DQ — Acknowledgeable ALARM_D Message

SFC 107 generates a D message tied to a specific FB or instance DB. The message remains in the active list at the HMI until the operator acknowledges it. Unlike SFC 17, SFC 107 carries up to 10 associated values (SD_1 ... SD_10), each an ANY pointer to a process value that will be displayed in the message text.

Call interface (SCL):

// SCL — acknowledgeable D-message with four associated values
"Alarm_FB".ALARM_DQ_Call(
    SIG      :=  #bFaultActive,
    EV_ID    :=  DW#16#0A000010,
    SD_1     :=  "ProcessData".rActualTemp,
    SD_2     :=  "ProcessData".rSetpoint,
    SD_3     :=  "ProcessData".iErrorCode,
    SD_4     :=  "ProcessData".sOperatorID,
    SD_5     :=  FALSE,
    SD_6     :=  FALSE,
    SD_7     :=  FALSE,
    SD_8     :=  FALSE,
    SD_9     :=  FALSE,
    SD_10    :=  FALSE,
    ?State   :=  #bAckReceived,
    RET_VAL  :=  #iStatus
);

EV_ID for D messages is auto-assigned by STEP 7 when the message is configured in the FB / DB object properties. Do not hard-code it; copy the value from the message editor or use the symbolic tag STEP 7 generates. The RET_VAL error codes for SFC 107 are the same as SFC 17 (the message subsystem reports the same faults regardless of message class).

SFC 108 ALARM_D — Non-Acknowledgeable ALARM_D Message

SFC 108 is the non-acknowledgeable counterpart of SFC 107. Identical parameter list, identical 10-value payload, but the message leaves the active list the moment the call is no longer active (i.e. when SIG transitions back to 0 or the calling block is no longer raising the event). SFC 108 is appropriate for informational D-messages such as "Recipe loaded", "Batch completed", or "Operator logged in".

SD (Associated Value) Parameter Explained

The SD input on SFC 17 / 18 and the SD_1 ... SD_10 inputs on SFC 107 / 108 are the "associated values" (German: Zusatzdaten, sometimes translated "process values"). They carry a snapshot of the process state at the moment the message is triggered, and the HMI renders them inside the configured message text at the position of a format specifier.

Example: configure a message text in STEP 7 as

Motor %d current exceeded (limit %d A)

and assign SD_1 to MW100 (actual current as INT) and SD_2 to MW102 (limit as INT). When the message fires, the HMI renders:

Motor 247 current exceeded (limit 230 A)

Supported data types and their format specifiers:

Each SD pointer is declared as ANY and must point to a valid memory area. Common mistakes are misaligned offsets for BYTE / INT pairs, pointing into an unloaded DB, or a length mismatch (e.g. passing 1 byte when the format specifier expects a 4-byte REAL). The CPU returns W#16#80A1 (alignment) or W#16#80A2 (length) when these occur.

Parameter Reference

STEP 7 V5.5 + SP1 Configuration Procedure

For an S message tied to a CPU 315-2DP:

1. Open SIMATIC Manager and load the S7-300 station.
2. Open HW Config and double-click the CPU 315-2DP.
3. Select the "Messages" tab. Click "S7 Messages".
4. Click "New" to add a message row. STEP 7 assigns the next free message number and an EV_ID (DW#16#xxxx).
5. Type the message text, e.g. Motor %d overload.
6. Compile and download HW Config to the CPU.
7. Open the program editor and add the SFC 17 or SFC 18 call in OB1 (or in a dedicated FB) with the EV_ID from step 4.
8. Compile and download the software to the CPU.

For a D message tied to an FB:

1. Open the FB in the program editor (LAD / FBD / STL / SCL).
2. Right-click the FB header → "Object Properties" → "Messages" tab.
3. Choose "Acknowledgeable" (SFC 107) or "Not acknowledgeable" (SFC 108).
4. Type the message text with up to 10 associated value placeholders.
5. STEP 7 auto-generates the EV_ID. Note the value (or use the symbolic name STEP 7 creates).
6. In the FB body, add the SFC 107 or SFC 108 call. Pass the FB's input parameters to the SD_1 ... SD_10 inputs.
7. Compile and download.

For WinCC 7.0 + SP3 to receive the messages:

1. In WinCC Explorer, open "Alarm Logging".
2. The "S7 Protocol Suite" connection must point to the same CPU and use the configured connection name from STEP 7's NetPro.
3. WinCC will auto-import the message texts from STEP 7 if you select "AS messages" in the "Message Configuration" dialog. The EV_IDs from STEP 7 become the WinCC message numbers.
4. Open Graphics Designer and insert an "Alarm Control" or "AlarmView" on the process screen. Wire it to the Alarm Logging component.
5. Compile the OS and start runtime — the message will appear in the AlarmView when the SFC fires.

WinCC 7.0 + SP3 Integration Details

WinCC Alarm Logging distinguishes operator acknowledgments from status acknowledgments. When the operator presses the ACK button on a message generated by SFC 17 or SFC 107, WinCC sends a "Message Acknowledgment" protocol frame back to the CPU; the CPU's SFC 17 / 107 ?State output goes TRUE for one cycle. This is separate from the message going "out" — the message leaves the active list only when SIG drops AND the operator has acknowledged.

If WinCC is configured for "Single acknowledgment" (the default), one operator ACK clears the message regardless of how many operator stations display it. "Multiple acknowledgment" requires an ACK at every station. See the WinCC Information System, Alarm Logging → Configuration → Acknowledgment Concept: WinCC V7.0 Alarm Logging manual.

CPU 315-2DP Compatibility and Limits

The CPU 315-2DP is one of the most widely deployed S7-300 CPUs. The relevant message-system limits for any S7-300 CPU running STEP 7 V5.5 + SP1 are:

Check the exact limits in the CPU's technical data sheet (right-click the CPU in HW Config → "Object Properties" → "Memory" tab and "Diagnostics / Clock" tab). Exceeding the message limit returns RET_VAL W#16#8083 from the SFC. Firmware revisions can also raise the message limit — for example, newer 6ES7315-2EH14-0AB0 builds support more S messages than earlier 6ES7315-2AG10-0AB0 builds.

Code Example — STL and SCL

STL example — SFC 17 with one associated value and SFC 19 status acknowledgment:

// OB1 — segment 1: trigger acknowledgeable S-message
      A     "Motor_OL".Fault
      =     "TempSIG"

      CALL  SFC  17
      SIG    :=  "TempSIG"
      ID     :=  B#16#0A
      EV_ID  :=  DW#16#0A000001
      SD     :=  P#M 100.0 INT 1
      ?State :=  "Motor_OL".AckReceived
      RET_VAL:=  "Motor_OL".Sfc17Status

// OB1 — segment 2: send SFC 19 status ACK when SIG clears
      AN    "Motor_OL".Fault
      A     "Motor_OL".AckReceived
      =     "TempSC"

      CALL  SFC  19
      EV_ID  :=  DW#16#0A000001
      ?State :=  "Motor_OL".SCState
      RET_VAL:=  "Motor_OL".Sfc19Status

SCL example — SFC 107 in an FB:

// FB 101 "MotorMonitor" — acknowledgeable D-message
FUNCTION_BLOCK "MotorMonitor"
VAR
    bFault : BOOL;
    rCurrent : REAL;
    rLimit : REAL;
    iErrorCode : INT;
    bAck : BOOL;
    iStatus : INT;
END_VAR

BEGIN
    bFault := (rCurrent > rLimit);

    "MotorMonitor_Inst".ALARM_DQ(
        SIG      :=  bFault,
        EV_ID    :=  DW#16#0A000010,
        SD_1     :=  rCurrent,
        SD_2     :=  rLimit,
        SD_3     :=  iErrorCode,
        SD_4     :=  FALSE,
        SD_5     :=  FALSE,
        SD_6     :=  FALSE,
        SD_7     :=  FALSE,
        SD_8     :=  FALSE,
        SD_9     :=  FALSE,
        SD_10    :=  FALSE,
        ?State   :=  bAck,
        RET_VAL  :=  iStatus
    );
END_FUNCTION_BLOCK

Configure the message text in the FB's "Object Properties" → "Messages" tab as:

Motor overload: current = %f A, limit = %f A, code = %d

When the fault fires, WinCC displays the three process values at runtime. The two unused SD inputs are tied to FALSE, which is interpreted as "no value" by the message subsystem — the format specifiers for SD_4 ... SD_10 are simply not used in the message text.

Message State Machine

The following diagram shows the lifecycle of an SFC 17 / SFC 107 message at the HMI. The state of the message (incoming / acknowledged / outgoing) is independent of the SIG input — once acknowledged, the message remains visible until SIG drops to 0.

For SFC 18 / SFC 108 the right-hand "Acknowledged" branch is absent — the message leaves the active list the moment SIG drops. The state machine reduces to: Idle → Incoming (SIG=1) → Idle (SIG=0), with no operator intervention required.

Troubleshooting Matrix

Frequently Asked Questions