FastCS: Framework for Building Device Support in Python for EPICS, Tango, and More
"FastCS is a versatile framework designed to create device support in Python for control systems like EPICS and Tango. It enables dynamic PV creation, isolating testing, and collaborative driver development. Supports modern Python features and multiple transport options."
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
FastCS A framework for building device support in Python for EPICS, Tango and more Gary Yendell
Motivation Introspect device to create PVs dynamically at IOC boot Allow IOC to be introspected by ophyd via PVA structure Define device logic independently from control system oEnable isolated testing and pluggable APIs Create a more accessible way of writing device support
FastCS Design Core logic built on asyncio Support modern python versions and leverage new features oFollowing numpy deprecation timeline (3.11+) Robust static type checking currently pyright standard mode Collaborative device driver development
Controller Interface Inherit Controller class Add Attributes and Methods to define API Optionally implement initialise method
Attributes AttrR(Int(min=0, max=10)) AttrRW(Float(prec=3, units="s")) AttrR(String(), description="State")) Access Modes o AttrR, AttrW, AttrRW Datatypes o Bool, Int, Float, String, Enum, Waveform, Table Metadata o description, min, max, precision, units, allowed values
Methods Command methods create an API for requests that take no parameters Scan methods create periodic tasks on the asyncio event loop Define statically with @command / @scan decorator on Controller method Define dynamically with Command() / Scan() by passing a callable
Transport Multiple options for the transport layer built into FastCS oEPICS CA (pythonSoftIOC) oEPICS PVA (p4p) oTango (pytango) oHTTP (fastapi) oGraphQL (strawberry) Can load multiple transports into the application to serve the controller API simultaneously
Connection Handler Define update and put methods to communicate with device Pass to Attributes to add callbacks to send values to the device and read values back
Testing Our usual way of testing oRun IOC on the beamline against real device and poke things manually or with a test script Modular architecture allows testing different layers in isolation oConnection handler against device oController against device, without transport layer oController with transport layer against simulator or mocked connection oTransport layer with dummy controller
Dynamic Controller Definition The initialise method provides a hook to query the device before the transport layer is created Introspect device to see the API it provides and create Attributes and Methods dynamically during start up Removes need to statically define all parameters, or implement a subset and need to manually add more in the future
Controller Dynamic Controller Definition Eiger has an introspectable API Get list of parameters in each subsystem Get metadata for each parameter
UIs EPICS transports generate a technical UI containing all the PVs in the IOC using pvi library Comprehensive view of the IOC for a controls engineer and a palette to copy widgets into pixel-placed UIs Consistent UIs with FastCS and epics-containers
Current State Still exploring the scope and refining the API Happy with how simple the driver API is, but need to expose some more complexity to provide more optional flexibility Keen to see if others find this to be a useful way of building device support and would like to collaborate
Questions? Resources FastCS: github.com/DiamondLightSource/FastCS o Tutorials: diamondlightsource.github.io/FastCS/demo/tutorials (in main soon!) pvi: github.com/DiamondLightSource/pvi epics-containers: epics-containers.github.io Eiger: github.com/DiamondLightSource/fastcs-eiger PandA: github.com/PandABlocks/fastcs-PandABlocks TwinCAT: github.com/DiamondLightSource/catio
