1. EPICS Server structure

Status

Current

Context

This module’s responsibility is to:

Communicate with the streaming control boards in the data streaming pipeline
Send run starts and stops to a Kafka topic for downstream consumers to know that a run has started or stopped.
Serve an EPICS IOC to allow doing the above via EPICS with a similar interface to ISISDAE currently used to communicate to the previous detector acquisition electronics.

All of this could be achieved with an EPICS StreamDevice IOC along with state notation language or similar for the run state. This is one option.

The IOC part of this can be achieved with several options:

Channel Access

caproto is an option to use Channel Access as a server, however it is not currently maintained

pcaspy is another option, but it uses the PCAS library which is also deprecated - it’s no longer bundled in EPICS releases.

Channel Access is now generally a legacy protocol which is not recommended for new development.

PV Access

p4p is the industry-standard library to use for PV access in python, and is actively maintained.

Both

FastCS can provide a way of writing EPICS device support with a PV Access and Channel Access server simultaneously.

This project is still fairly early in development, and documentation is somewhat sparse. It would also need UDP support (and the streaming control board’s protocol) for this particular use case.

Decision

The IOC will be written in Python as it is much easier for rapid prototyping and can more easily be separated from the rest of the EPICS build as it doesn’t require a compiled state-notation language support module or asyn/stream device.

The IOC will use p4p’s server API and will serve PV Access only.

Consequences

PVs will only be available via PV Access. The GUI and any other clients like genie-python will need to cater for this.
- Clients like genie-python will need to cater for certain pieces of logic being different anyway.
The IOC will serve PVs using the p4p.server.Server API.