Events

Declare an event when a condition needs a stable identity, operator-visible details, and reusable automation hooks. The declaration key is its identity; changing the title does not create a new key.

React to a limit

The following example assumes docs_demo_pressure and docs_demo_pressure_limit already exist. Its output is a demonstration abort-request channel, which your controller must handle explicitly.

event docs_demo_pressure_abort:
    title: "Pressure limit exceeded"
    type: abort
    description: "Measured pressure is above the configured limit."
    resolution: "Inspect the cause and verify the system before restarting."
    system: "DEMO"
    subsystem: "PRESSURE"
    channels: |docs_demo_pressure|, |docs_demo_pressure_limit|

    trigger:
        if |docs_demo_pressure| > |docs_demo_pressure_limit|:
            return 1

    on_firing:
        if value == 1:
            override |docs_demo_fuel_valve| = 0
        if value == 0:
            free |docs_demo_fuel_valve|

The populated trigger: runs once at activation, then synchronously when an input dependency changes. It is never polled. An exact numeric 1 asserts the condition; a rising edge fires the event. Staying at 1 does not repeatedly fire it. Zero, another result, no return, or an execution error deasserts it.

The firing reaction runs inline in that channel-update chain. on_firing: runs for both transitions, so the example explicitly frees its automatic override when the trigger clears. on_event: runs when the event enters or leaves the board; use it for an additional cleanup path when appropriate. Overrides are never released implicitly.

An ARGUS event of type abort does not stop every task or command hardware by itself. Connect the reaction to your application’s control logic and follow the channel’s write authority. Device response still depends on the driver, transport, and hardware. See Execution and Timing.

Generated channels

For the example above:

Use on_firing: for a firing reaction and on_event: for board-presence reactions. Both receive value/new_value and the previous current_value. Do not add an explicit return; the engine preserves the generated diagnostic value. Static channel reads in these sections also register calculation dependencies, so keep the reaction’s inputs intentional.

Acknowledging an event does not clear its condition. Resolution is allowed after firing stops. An event triggered again later reopens or refreshes the same keyed event. ARGUS Events explains the operator controls.

Trigger a one-shot event

Leave trigger: empty when the event should accept external pulses without a maintained sensor condition:

event docs_demo_checkpoint:
    title: "Checkpoint reached"
    type: message
    trigger:

task_sequence docs_demo_checkpoint_run:
    trigger docs_demo_checkpoint

A statement-form trigger or external pulse uses a five-second firing heartbeat. Repeated triggers refresh that heartbeat. This differs from the maintained condition above, whose firing state clears as soon as its condition deasserts.

Event details and graphs

title is required. Types are message, warning, error, abort, hold, and prompt. Optional metadata includes description, resolution, system, subsystem, channels, and auto_acknowledge; prompts also support prompt_type and options.

In a channels: line, commas separate series and semicolons start another graph. Add @1 through @5 to select a Y axis. For example, |temperature|@1, >100@1; |pressure|@1, =50@2 draws two graphs with a temperature threshold and a pressure reference line.

Functions such as message(...), warning(...), and error(...) create independent ad hoc events, even if their title matches a declaration. Use declarations for stable identity and reactions; use the functions for standalone notifications. Both Lua and Native C++ execution modes support declarations.