Speaker
Description
At Diamond Light Source there are currently many different ways to write device support and as a result the drivers are often bespoke, don’t follow a common convention and are only understood by the engineer that wrote them. We wanted to better standardise and lower the barrier of entry to writing device drivers and to promote greater collaboration across different software groups, such as with the teams that implement the bluesky/ophyd scanning layer. Strict silos of responsibilities for different layers of the software stack leads to roadblocks, unclear APIs and difficulty solve problems that fall between the gap. By making the driver code more accessible - removing the need for specialist EPICS knowledge - a wider group of developers across software groups and beamlines can understand and contribute to the device drivers. Driver development will become more collaborative and open, with robust software engineering standards applied at the code review stage and ownership by teams rather than individuals.
With this goal in mind, we have developed a simple and flexible framework for creating device drivers in modern, idiomatic python. The driver can be tested independently of a control system and then loaded into an application with one or more transports to expose an external API, such as EPICS, Tango or GraphQL. The EPICS transport builds on the pythonSoftIOC package, hiding some of the EPICS internals and sharp corners in the API behind a simpler interface. FastCS makes it easy to dynamically define the API at runtime by introspecting a device. For example, Dectris Eiger detectors provide a REST API to query what parameters the detector has, including their datatype and limits. This means a FastCS driver for Eiger can query this API during initialisation and create (for example) EPICS PVs for all of the parameters in the API, without having to statically define them in the code - unless they are used for internal logic. Additionally, in the EPICS transport a GUI (Phoebus .bob file) is generated with all of the PVs in the IOC. The combined effect of this is if the firmware is updated on the hardware and adds a new parameter, adding the corresponding PV to the GUI just requires rebooting the IOC.
This talk will provide an overview of the FastCS architecture, demonstrate examples of static and dynamically drivers and the walk through the process of creating device support using the framework.
