Making formula pvs in xml file out of certain spreadsheet pvs

[KaushikMalapati]

A replacement for #61, movivation from https://jira.slac.stanford.edu/browse/ECS-6818

Phoebus has support for different pv protocols, with channel acces being the the default.
https://control-system-studio.readthedocs.io/en/latest/core/pv/doc/#formulas

One of these protocols is for "formulas" which are very analogous to calc pvs in edm or the pydm calc plugin. It supports basic arithmetic, and also has a function that returns an alarm severity (major or minor) if a boolean condition evaluates to true - this boolean condition can contain other pvs.
https://control-system-studio.readthedocs.io/en/latest/core/formula/doc/#alarm

This needs changes to how we generate xmls to support - the code in this branch will interpret a pv formatted like minor://{expression} or major://{expression} as an attempt to create a formula based alarm, where the formula pv will go into either a minor or major alarm state based on whether the first five characters are minor or major respectively. It will then format the expression for what phoebus expects which generally looks like (I learned the backticks were not necessary while testing). I tried to make the spreadsheet syntax that nalms users use to make their formula alarms straightforward but I am open to any suggestions

This pull request has a demonstrative formula alarm added to the tmo configuration which I copied into the TST xml config on the dev branch

This is using a branch of slam which is being reviewed from slaclab/slac-alarm-manager#70 to make formula based pvs work with the salami tree.

[pcds-bot]

--- a/Spreadsheet/KFE/TMO-alarms.csv
+++ b/Spreadsheet/KFE/TMO-alarms.csv

@@	#Indent	Branch	PV	Description	Latch	Delay	Filter	Guidance
+++			major://(abs(SL1K0:POWER:ACTUAL_YWIDTH_RBV) * 1000) > AT1K0:GAS_MA_Y:MMS:1	slits too wide

[tangkong]

I think this looks pretty solid, thanks for doing all the legwork here and in Phoebus!

I assume this doesn't work until the SLAM PR is merged? To get this working for us we'll have to roll out an updated conda environment as well.

[tangkong]

Perhaps in a future effort we should update the README here with more complete information on how to use these commands and what exactly the columns mean. The existing confluence pages are a bit more technical than we'd want for people simply contributing the the repository

In particular I'm curious as to what operators are available for these formula pvs

[KaushikMalapati]

In particular I'm curious as to what operators are available for these formula pvs

This page has all the operators
https://control-system-studio.readthedocs.io/en/latest/core/formula/doc/#alarm

[KaushikMalapati]

I assume this doesn't work until the SLAM PR is merged? To get this working for us we'll have to roll out an updated conda environment as well.

We could always make the slam scripts that the lucid screens use source dev_conda instead of pcds_conda? I should also mention that there's a slam bug that should be fixed before making a new version slaclab/slac-alarm-manager#71

[pcds-bot]

--- a/Spreadsheet/KFE/TMO-alarms.csv
+++ b/Spreadsheet/KFE/TMO-alarms.csv

@@	#Indent	Branch	PV	Description	Latch	Delay	Filter	Guidance
+++			major://(abs(SL1K0:POWER:ACTUAL_YWIDTH_RBV) * 1000) > AT1K0:GAS_MA_Y:MMS:1	slits too wide

[tangkong]

I won't rush this through until we see SLAM updated properly. I think having a dev slam is reasonable, once we can grab a stable one. We'll have to go around and change a bunch of scripts in various places though.

[KaushikMalapati]

I won't rush this through until we see SLAM updated properly. I think having a dev slam is reasonable, once we can grab a stable one. We'll have to go around and change a bunch of scripts in various places though.

Sounds good. My branch has been merged, so I think we can release a new version after slaclab/slac-alarm-manager#71 is fixed.

[tangkong]

Thanks for fielding my questions. I think we can merge this without much problem, and make sure to get an updated slam version into dev_conda

[tangkong]

Your last comment does raise the question about the PVA pvs in TMO's config, since they actually don't have any status/severity information. We should look into either removing them or making sure the daq people get those record fields implemented

$ caget PLC:TMO:MOTION:FFO:01:FaultHWO_RBV.SEVR
PLC:TMO:MOTION:FFO:01:FaultHWO_RBV.SEVR NO_ALARM
$ pvget DAQ:NEH:tmo:0:DeadFrac
DAQ:NEH:tmo:0:DeadFrac 2025-02-27 15:30:14.197  0 
$ pvget DAQ:NEH:tmo:0:DeadFrac.STAT
Timeout
DAQ:NEH:tmo:0:DeadFrac.STAT 

[KaushikMalapati]

Your last comment does raise the question about the PVA pvs in TMO's config, since they actually don't have any status/severity information. We should look into either removing them or making sure the daq people get those record fields implemented

$ caget PLC:TMO:MOTION:FFO:01:FaultHWO_RBV.SEVR
PLC:TMO:MOTION:FFO:01:FaultHWO_RBV.SEVR NO_ALARM
$ pvget DAQ:NEH:tmo:0:DeadFrac
DAQ:NEH:tmo:0:DeadFrac 2025-02-27 15:30:14.197  0 
$ pvget DAQ:NEH:tmo:0:DeadFrac.STAT
Timeout
DAQ:NEH:tmo:0:DeadFrac.STAT 

Where do these even come from? I thought all record types had alarm fields like stat and sevr.

[tangkong]

I assume they're some custom record type the daq group stood up? I'm really not sure myself.