1. EPICS Server structure
Status
Current
Context
This module aims to deliver “DAE Diagnostics”, in the forms of:
Spectra plots
Information about vetoes
Event-rate information
“Detector diagnostics”
Of these, the most demanding case is serving spectra plots; there can be large numbers of spectra corresponding to different detectors and periods, and each spectrum has the potential to update at a high rate as new neutron events are histogrammed into the spectrum.
Use cases for DAE spectra include:
A user visually monitoring a spectrum from a GUI. This means it must be possible for a client to monitor a spectrum that it is interested in.
Scripted clients, which will retrieve spectra programmatically, for example:
Several approaches to serving spectra were considered:
Static PVs (fastcs)
In this approach, this service would statically create PVs for each spectrum/period combination, and
update them as new neutron events arrive. fastcs can serve arrays over both CA and PVA
simultaneously.
This approach is simple, but very wasteful performance-wise: all spectra would be being updated constantly, even if no client was interested. The performance of this approach is not viable, even for modest numbers of spectra.
CA Server (pcaspy)
PCAS & pcaspy are deprecated, and there is not presently a route to “bridge” a PCAS/pcaspy server to PVA. Support for PVA is considered a requirement, so this option is discarded.
PVA server (p4p)
This approach uses the p4p.server.DynamicProvider to dynamically serve PVA PVs to subscribed
clients. It is conceptually similar to the pcaspy approach above, but would only support PVA.
Decision
Spectra will be served via p4p using p4p.server.DynamicProvider.
Consequences
Spectra will only be available over PVA. No CA support will be available.
The existing Eclipse-based IBEX client can support PVA in OPIs.
ibex_bluesky_coreandgenieclients already have support for PVA but will need updates to use it to acquire spectra.
Spectra will be served by a
p4pserver.