Alarms: Refinements for use

[KathrynBaker]

As an instrument scientist using the north side muon front end systems I've noticed a few things that would help make things clearer in relation to the alarms, my use cases and behaviours are as follows:

• The vacuum gauges (TPG300) show a minor alarm when a sensor goes over-range or under-range. Some of these are entirely harmless such as the high pressure range Pirani sensors going under-range when the vacuum is good. But all of them appear in the list in the Alarms perspective. Can IBEX be more selective?
• Meanwhile I can set the magnet power supplies (mostly Danfysik) so they show red major errors if they are not close enough to the right current, or have gone off completely. But none of these appear in the Alarms perspective. It would be good if they did.
• A number of IOCs have built in alarm levels that I can’t change by writing a .LO or .LSV field for example. For example the Danfysik supplies show a major alarm if the output is negative, which can happen if the supply is (intentionally) off and there is readout noise, also briefly while a supply to a high inductance magnet is ramping down. The usual .LO level does work if a supply is on and it’s set to a positive value a bit less than the expected voltage. The current readback of the Danfysiks doesn’t have this negative=error feature.
• Similarly the kicker on/off status PVs provided by the SCHNDR_01 IOC are hard coded to give On=No Alarm and Off=Minor alarm. When we’re running in double pulse mode with the kickers intentionally off, it would be good to change these but it seems impossible.

Acceptance Criteria

• [ ] There are comments in this issue relating to each point, whether it is possible, whether it is beyond our control, whether or not it is a bug that needs fixing, etc.
• [ ] Things that require fixing or need work doing have tickets created
• [ ] An email is sent to the appropriate IS detailing what can be fixed, and what can't be fixed

Extra Information

• This was highlighted in a direct email to @KathrynBaker and @FreddieAkeroyd from a specific instrument scientist
• This ticket is not to fix the issues, but to identify them (although if there is a 1-line fix, feel free to put it in as a flash review)

How to Test

verbose instructions for reviewer to test changes (Add before making a PR)

Time in planning

20:25 4/4/24

[FreddieAkeroyd]

The following is from an email I sent:

When a configuration is changed this xml file is re-created from alarm records loaded from epics .db files, the xml file is then loaded into the mysql database on the instrument via the “alarmconfigtool” and then the alarm server and gui look at, and change, mysql directly (e.g. to record alarm acknowledge). So any changes to this xml file will not be preserved. Currently the only way to permanently control what PVs are in the alarm view would be to edit the .db files loaded by IOCs and add/remove the “info(alarm, …) ” entries in PV records, but any such db changes would be lost on an ibex update. To make the system more flexible we would need to change how we implement the alarm configuration. We could for example have very little, if anything, added by default, and then it would be up to a scientist to specify alarm setup for each PV/item on an OPI for components/configurations. But we would need to do some requirements gathering across instruments to determine what everybody needs and hence the best way to make the system behave for everybody. A simpler and quicker to implement solution, but which may not be flexible enough, is to just make whether an IOC (and some pre-defined sets of pvs) were present in the alarm view via an IOC macro (like specifying the COM port when adding an ioc). So this would let you chose if an IOC was there at all, but which PVs would be included would have been pre-determined by ibex. How much flexibility on choice of PVs to include verses just having an IOC included at all do you need? If a PV is added for everybody to the alarm view, unless high/low etc are also specified it would usually just sit there as saying it was OK (but may go into alarm if the device is disconnected)

[isaachilly]

Comments on issues

1. TPG - Make a different PV (e.g., TPG300:PressureAlarm) that fans out to the limits of the pressure PVs a normal range or a very large range based on if the vacuum is good so as to not raise an alarm when vacuum is fine. What does a vacuum being good mean?
2. Red major alarms not showing because current PV doesnt have info(alarm, "<name of IOC (not including _0X)>") in db records. Re limits the scientist is most likely setting a the wrong PV for the error to propagate. I.E, setting VOLT:LOLO when they should set VRAW:LOLO.
3. SCHNNDR_01 - Similarly to the TPG. Make a different PV that sets the alarm config of the status PVs so that when the kicker is running double pulse mode (find appropriate PV)

[KathrynBaker]

Tickets seem appropriate and I have confirmed an email has been sent