Support EPICS alarms

[cnlklink]

Right now only ACNET alarms are supported. Extend this support to EPICS alarms.

[beauremus]

I'm not sure what the data path looks like for PIP-II.
The ACORN vision is one where the application doesn't need to know what front-end they are talking to.
Is this something to involve others in, or is the path forward clear?

[cnlklink]

Path forward is mostly clear and this is just a reminder to do the work. There are some details to resolve though. For example, EPICS has "hi" and "hi hi" and "lo" and "lo lo" thresholds but ACNET only has min/max. Do we need to communicate those details to the user? If yes, then the data path needs to carry the details of the Alarm threshold from the IOC or Frontend all the way up to the presentation in the parameter page.

[beauremus]

Right. The current data path using the foreign mapping requires that data conform to our power supply model. So the concept of "hi hi" and "lo lo" don't exist. I'd imagine we map one of the alarm limits to our concept of alarms.
I'm not sure if DPM supports EPICS alarms yet.

[rneswold]

It's hard not exposing the low-level details because it's part of our mental model and vocabulary at the lab. We had the same trouble when we were writing the ACSys/FE framework. I tried to present a more general device model that was a superset of all features of our data acquisition. But people still added crap like is_gets32 in the code (I cleaned up the code so it no longer does.) But I gave up sanitizing the alarms and FTP support because those were essentially C-to-Erlang ports. 🙄

I don't think we should be trying to match the old param page feature-for-feature. But it's a tough line to follow because it can't look too alien, either.

We should come up with a superset of alarm features and then map both controls systems' info into it. We'll have other tools that let users see a low-level, gory-detail view of the device's alarms (for troubleshooting.)