S5f1

S5F1/S5F2 is the SECS-II message pair equipment uses to report an alarm condition to the host — spontaneous, equipment-initiated notification carrying an Alarm Identifier (ALID), an alarm code indicating set or clear, and descriptive alarm text, following the same unsolicited pattern as S6F11's collection-event reporting rather than a host-requested query. S5F1 (Alarm Report Send) is sent the moment equipment detects an alarm condition transitioning — either newly set or newly cleared — and S5F2 (Alarm Report Send Acknowledge) is the host's simple confirmation of receipt; unlike collection events, which require the define/link/enable setup chain before they flow, alarm reporting in GEM is typically always active rather than needing to be separately configured per alarm.

Equipment detects an alarm condition
e.g. overtemperature, vacuum loss, door interlock fault
S5F1/S5F2 alarm reportEquipment-initiated, generally always active
S5F1 sent: ALID + set/clear code + alarm text
Alarm Report Send
S5F2 returned: simple acknowledgment
Alarm Report Send Acknowledge
Host logs/escalates the alarm
Operator notification, automated response, or both

The set/clear distinction carried in S5F1 is what lets a host track an alarm's full lifecycle rather than just knowing it happened once — equipment reports the alarm both when the condition first becomes true (set) and again when it resolves (clear), which means a host that only reacts to the "set" report and ignores "clear" reports will keep treating a long-resolved alarm as still active, exactly the kind of state-tracking bug that produces false alarm backlogs and operator alert fatigue over time. Because alarm reporting bypasses the collection-event define/link/enable chain, it is also one of the few GEM mechanisms that a host can generally rely on working immediately on any compliant tool without prior configuration, which is a deliberate design choice — safety-relevant notifications should not depend on a host having correctly completed an optional setup sequence first.

S5F1/S5F2 — Alarm Lifecycle: Set and Clear both transitions are reported — tracking only "set" causes stale alarms time S5F1: ALID set S5F1: ALID clear alarm condition active Host must act on BOTH reports ignoring the clear report leaves the alarm shown as active indefinitely

S5F1/S5F2 is deliberately independent of the collection-event setup chain (S2F33 through S2F38) that governs ordinary process data reporting, since alarm notification is treated as a baseline safety mechanism rather than an optional, host-configured feature — this is also why alarm identifiers are typically documented in a tool's Common Equipment Model (SEMI E120) alongside status variables and equipment constants, so a host integration knows what every ALID it might receive actually means.

Take S5F1 further

Ask the copilot about this term, or have our engineers assess it against your process.