[Alarms]: Define customized alarms configurations - GUI

[Chsudeepta]

Requirement Description

As an instrument scientist or IBEX user, I want to have greater control over alarms. Today alarms are pre-configured, always enabled, and there is no possibility to configure or customize.

Discussed 10/07/2025 32:58

Explanation

Scientists have often complained about the efficacy of the current alarms mechanism. Scientist from several groups were interviewed and their feedback was collected, Ref. Following issues can be seen for reference:

Parent issues

8422

Child issues

8642
8643
8644
8645
8647
8649
8650
8651
8652

How, Where & What?

Technical feasibility was analysed and it seems that most of the demands from the scientists can be met with the current implementation of the Alarms Server with relevant tweaks from IBEX side (also discussed with @FreddieAkeroyd ). A follow-up with the team was done after some analysis.
We can imagine a GUI like the one shown below:

A new section is introduced in the "Add Blocks" screen that is available from "Edit Current Configuration", "New Configuration" and "Edit Configuration". Same screen is also shown and is modifiable from the "Edit Block" option.

After data has been filled in, the alarms level data must be persisted against the configuration. This can be either in the DB or XMl/JSON/YAML data in the file system for the instrument. "Low Limit" and "High Limit" are editable, numeric and has the same checks as those on default Run Control settings. "Delay" is numeric, "Guidance" is string and "Enabled" and "Latch" are check-boxes. Following defaults are expected:
Low Limit, High Limit and Delay are 0.0; Guidance is blank; Enabled is unchecked; Latch is unchecked.
The Low Limit and High Limit should show the value set on the underlying PV and these should be view-only field.

If Alarms aren't configured using the GUI, alarms defined in the old way should continue to work

Additional Changes

The motivation of the change is to provide users the ability to customize alarms and alter the current alarms behaviour in alignment to the customization. The alarms definition is driven by the file Instrument.xml generated by the code in \Instrument\Apps\EPICS\CSS\master\AlarmServer\make_alarm_config.py. This code is eventually triggered by the block server. Right now it has logic to set some defaults, we need to alter the logic here to read back the newly persisted values and produce the Instrument.xml accordingly. Below is the prescribed structure (we keep the description field blank for the time being):

The changes needed for this are tracked separately.
_{See our Git Workflow.}

Acceptance Criteria

_{What is the acceptance criteria of this ticket? What should the reviewer expect to be complete?}

• New section is introduced in the Add/Edit Blocks screen of the Configurations definition GUI.
• Values provided in the section is persisted, and shown again when the Edit Blocks screen is opened.
• Instrument.xml is changed/regenerated with the new changes matching the schema already shown above.
• GUI Code changes should satisfy the GUI coding standards
• Python code changes should pass the linters defined.

How to Review

_{Before making a PR...}

• GUI should build from the build.bat, passing all the checkstyle clauses
• The following effects should be seen from alarms perspective (these features already exist in the Alarms screen):
• If an alarm is not enabled, the alarm appears with a grey round button in the alarm tree.
• If an alarm is not enabled, it remains inactive as described above even if all other conditions for alarms become true
• If an enabled alarm is configured with a non-zero delay, it becomes active only after the delay period (in seconds) passes once the alarm conditions become true and still remains true.
• If an enabled and active alarm is configured with latch as true, it will require an acknowledgement by the users.
• If an enabled and active alarm is configured with latch as false, it becomes inactive as soon as the alarm conditions are not true anymore. That is, it won't require an acknowledgement by the users.
• If any guidance is defined for the alarm, it will be shown in the GUI as shown below

• If Configure Item option is enabled for a user, then the corresponding values should be shown if the user clicks on this menu item (available with a right click on the alarm item). However, the changes done here will be respected as long as the current session of the Epics server is running. Restarting the Epics will ensure that the user defined values in the "Add Block" will take over. This is so because the values shown in the Alarm tree is managed by CSS code using Alarms Server

_{To the reviewer: Make sure to update submodules!}

[Tom-Willemsen]

@Chsudeepta please split into client-side and server-side