PV Comparison in NALMS #61
Conversation
|
--- a/Spreadsheet/KFE/TMO-alarms.csv
|
Spreadsheet/KFE/TMO-alarms.csv
Outdated
| @@ -90,6 +91,7 @@ | |||
| ,,ST1K4:TEST:MMS:STATE:ERR_RBV,ST1K4 error state,,,, | |||
| ,,ST1K4:TEST:MMS:STATE:GET_RBV,ST1K4 state,,,PPS:NEH1:1:ST3K4INSUM!=0, | |||
| ,,ST1K4:TEST:MMS:STATE:ST3K4_AUTO_RBV,ST1K4 follow ST3K4 status,,,, | |||
| ,,CMP:ST1K4:TEST:MMS:STATE:GET_RBV,ST1K4 and ST3K4 state,,,,,PPS:NEH1:1:ST3K4INSUM!=0&ST1K4:TEST:MMS:STATE:GET_RBV=2 | |||
There was a problem hiding this comment.
| ,,CMP:ST1K4:TEST:MMS:STATE:GET_RBV,ST1K4 and ST3K4 state,,,,,PPS:NEH1:1:ST3K4INSUM!=0&ST1K4:TEST:MMS:STATE:GET_RBV=2 | |
| ,,CMP:ST1K4:TEST:MMS:STATE:GET_RBV,ST1K4 and ST3K4 state,,,,PPS:NEH1:1:ST3K4INSUM!=0&ST1K4:TEST:MMS:STATE:GET_RBV=2, | |
I think you've misplaced the expression here, we should have a trailing comma
There was a problem hiding this comment.
Looks like I messed up some stuff when I was resolving the merge conflict. I think I've fixed it in my latest commits
|
An interesting take on the problem. While I'm in favor of keeping all of the nalms config in one place, this does toe the line as something that might be outside of the scope of Interestingly the example expression you provided in this PR is not a comparison between two PVs, but rather two independent expressions that you want to both be true? (or at least that's how it reads to me) On that note, it's interesting to consider the order of operations for these comparison operators. Python evaluates logical (and/or/not) operators after relational (>, <, ==) operators, but does your IOC? Have you built one of these IOCS yet? |
| def get_field(match): | ||
| nonlocal index | ||
| index = index + 1 | ||
| return ascii_uppercase[index] |
There was a problem hiding this comment.
This could also just be a generator of ascii_uppercase
There was a problem hiding this comment.
That's what I initially tried, but re.sub wouldn't accept a generator only a function.
There was a problem hiding this comment.
I was thinking something like this:
In [8]: gen_upper = (letter for letter in ascii_uppercase)
In [9]: gen_upper
Out[9]: <generator object <genexpr> at 0x7f63b21d6c80>
In [10]: def get_field(match):
...: return next(gen_upper)
...:
In [11]: get_field('s')
Out[11]: 'A'
In [12]: get_field('s')
Out[12]: 'B'
In [13]: get_field('s')
Out[13]: 'C'There was a problem hiding this comment.
or even making that function a lambda
| @@ -41,6 +44,8 @@ def csvtoxml(infile, outfile, cname): | |||
| if 'Guidance' in row and row['Guidance']: | |||
| guidance = ET.SubElement(pv, 'guidance') | |||
| guidance.text = row['Guidance'] | |||
| if 'Expression' in row and row['Expression']: | |||
There was a problem hiding this comment.
So are we adding an additional column here? I don't see this column in the CSV you modified
There was a problem hiding this comment.
Added to header now,
|
--- a/Spreadsheet/KFE/TMO-alarms.csv
|
I originally wanted to make this part of the repo to piggyback off of the existing scripts that parse the csvs and because I thought it'd be nice if the ioc building process was done by a workflow so the "comparison" pvs nalms looks for are made at around the same time that the iocs that host them are built, but I would be fine splitting this off.
Calling it a comparison is not a great name. I just used it because it was the name of the ticket.
I don't think the order that python would evaluate operators matters here, since Python is only extracting PV strings out of the expression field and replacing them with alphabetical variable names that a calc record would expect. epics does have operator precedence which I assume matches how c does it. https://github.com/slac-epics/epics-base/blob/308e234c41f59b9103b6d309f3256262a3175da2/modules/libcom/src/calc/postfix.c#L133. Parentheses have the highest priority so you can also right an expression and evaluates in the expected order, and I think it makes sense that you would write this expression the same way you would the calc field of a calc record (which is what this is used for). I have built an ioc for this. The parent is /cds/group/pcds/epics-dev/kaushikm/ioc/common/nalms, the ioc is ioc-nalms-TMO-alarms in the tst iocmanager with the one alarm that I added in this pr. |
|
Now that you've added the columns to the csv, I see more clearly what you're trying to accomplish here. I think I'm leaning even more toward the camp of having these IOCs be defined by config files separate from the nalms config. There is already confusion as to where the alarm thresholds come from, and I don't want to suggest that the user can set them through the NALMS csv. I do think that this can reasonably live in the Does this properly handle the comparison between two PVs? That was brought up in the ticket and was what I understood to be the missing feature here. |
|
I'm just seeing first seeing this now (looking at this repo for something else, I'll add myself as a watcher as well), but if I'm understanding the request right I think this could potentially be handled by the PyDM data plugin for NALMS? https://slaclab.github.io/slac-alarm-manager/pydm/ Basically you can put in The main restriction is the |
From the page you linked, it looks like the data plugin only lets you make channels to pvs in nalms or components which have the highest severity out of all of their subcomponents. Based on what I read in the ticket, they wanted a system where you could make a nalms alarm based on a certain condition or a comparison between pvs. The example James gave is an alarm that goes off when the photon energy is below 400eV and the a mirror is using the B4C stripe. Can the plugin do something like that? What would happen if you put a new name that didn't match any pvs or components? |
|
The example of highest severity was used in the documentation as it is specific to an accelerator use case, but more generally the data plugin will just match the alarm state of NALMS rather than EPICS. So for that example, you'd have the PV with its normal EPICS alarm that will go off when the energy drops below 400eV, and then the enabling filter from NALMS that looks at the mirror and prevents the alarm from being raised unless that condition is hit too. The enabling filter is just exactly what Phoebus uses, no changes in NALMS. https://control-system-studio.readthedocs.io/en/latest/core/formula/doc/index.html So you should be able to use multiple combinations of PVs in expressions supported by that The name does have to match either a PV or component though. It will just be ignored if it doesn't. |
|
Is this I think part of the issue on the photon side though is that the native EPICS alarms aren't necessarily what people want to be warned on, e.g. different users disagree on what counts as an issue for their different instruments. For example, a steering mirror may have many valid states and therefore be NO_ALARM in many positions, but this mirror actually picks between TMO and RIX as destinations, so either instrument may want to see an alarm when the beam is sent to the other. To this end the standard approach would be to create new PVs with unique alarm states to then ingest into NALMS, and this PR is a step in one option to automate this process. |
Yep, that is exactly correct. Not used in slam, for PyDM only.
Yes, that makes sense! Just wanted to double check since NALMS does provide some flexibility in setting up additional conditions on alarms with enabling filters. But new PVs will work just fine and also be able to be queried outside of NALMS/PyDM if needed. |
|
@jbellister-slac according to If I made an entry in one of our configs where the value for pv is would nalms deploy it as an alarm that has major severity when the formula evaluates to true that shows up in slam just like a normal pv alarm without any other work? |
|
Hmm.. at a minimum I'd need to update slam to work with However, I'm not actually sure what happens if you use a non |
Where would slam need to be updated at? Doesn't it get all its information from kafka? Testing this first is agood idea. |
|
I just need to fix how I parse the key returned from kafka. It was originally done in a channel-access-only world where I didn't have any consideration for any other protocol's prefix and the |
This pr will allow users to add pv comparison expressions to nalms configuration files which will automatically be parsed and used to generate ioc configuration files, which alongside a new nalms ioc (analogous to ads-ioc) will host calc records to perform those calculations and provide pvs with user specified alarm states based on the calculated value that nalms can use to create alarms. The motivation comes from https://jira.slac.stanford.edu/browse/ECS-6818.
I have written some of the non boilerplate-part of the nalms ioc
comparison.db
st.cmd
The spreadsheets, with the use of nine new columns allows users to specify
Ideally, whenever pcds-nalms is pushed to these iocs cfgs would not only be generated but also automatically deployed just like the phoebus alarm servers are. Alternatively, the cfgs could be used by users to make deployment as simple as possible. I think there is a lot of flexibility in how to do this, so I am open to suggestions/questions.