Re: PVI Prototype - a framework for specifying the interface to an EPICS driver in a single YAML file

[Mark Rivers via Tech-talk <tech-talk at aps.anl.gov>]

Hi Gary and Tom,

 

First I need to apologize for taking so long to respond to this.

 

It seems like there are several aspects to this approach. 

 

The first is the addition of the new asynParamSet class.  I think this makes sense.  It encapsulates the parameters separately from the rest of the driver variables.  It makes it easier to improve the asynPortDriver code.  I have already merged the changes in asyn to add this new class, since this is completely backwards compatible.

 

The second aspect is the automated generation C++ headers and code, databases and OPI screens from YAML files.  This seems attractive of course, but we need to think about the costs and benefits.

 

In your list of caveats I see this:

 

Ø  Any readback parameters will have an _RBV suffix added. Some existing readbacks do not have this, e.g. Armed in pilatusDetector.

 

The use of _RBV has not been consistent as you say.  Recently I have been using _RBV only for parameters that are both writeable and readable.  The _RBV is used for the readback in that case.  If a parameter is intrinsically read-only (MaxX, MaxY, Armed, TemperatureActual, etc.) the record would not have _RBV.   I worry about changing these PV names.  Lots of clients have been written with those names, including Ophyd used at NSLS-II, etc.

 

I am also somewhat skeptical that YAML will be avble to generate OPI screens that are actually used.  Most real detector screens organize the PVs by function, not by the class which produces them.  Thus a given group may  have PVs from asynNDArrayDriver, ADDriver, and ADPilatus.  It seems to me that this will be difficult to do with autogenerated screens.

 

I have a question about template files as well.  Derived class template files often override record values from the base class.  For example, pilatus.template does not define the TriggerMode record, but it replaces the enum choices:

 

# We redefine the states for the TriggerMode records defined in ADBase.template

record(mbbo,"$(P)$(R)TriggerMode") {

    field(DESC,"Acquire mode")

    field(ZRVL,"0")

    field(ZRST,"Internal")

    field(ONVL,"1")

    field(ONST,"Ext. Enable")

    field(TWVL,"2")

    field(TWST,"Ext. Trigger")

    field(THVL,"3")

    field(THST,"Mult. Trigger")

    field(FRVL,"4")

    field(FRST,"Alignment")

}

 

How would this be done with the YAML scheme?

 

In general I think that the fraction of the time and fraction of the code that would be automated with this process are both a small fraction of the time and code required to write an asynPortDriver driver.  Most of the time required to write a driver is spent learning how the device and the vendor SDK work, and not in the code for the device-specific parameters.  But I could certainly be persuaded of the benefits of the YAML scheme if it can be shown to work well and save effort!

 

Mark

 

 

 

 

---

From: Yendell, Gary (DLSLtd,RAL,LSCI) <gary.yendell at diamond.ac.uk>
Sent: Tuesday, May 19, 2020 12:03 PM
To: tech-talk at aps.anl.gov
Subject: PVI Prototype - a framework for specifying the interface to an EPICS driver in a single YAML file

 

Hi!

 

At DLS we have been working on an idea of Tom Cobb's making: PVI (PV Interface).

 

There is an outline hosted on readthedocs: https://pvi.readthedocs.io/en/latest/contents.html

 

As a brief summary, the goal of PVI is to consolidate the duplicated boiler plate of an EPICS driver (templates, low-level screens and the parameter creation in the c++ code) into one place, allowing these pieces to be generated instead.

 

 

The main purpose of this particular message is to point out the WIP branches of some key modules that have been updated for this framework:

·  asyn - https://github.com/dls-controls/asyn/tree/pvi

·  ADCore - https://github.com/dls-controls/ADCore/tree/pvi

·  ADSimDetector - https://github.com/dls-controls/ADSimDetector/tree/pvi

·  ADPilatus - https://github.com/dls-controls/ADPilatus/tree/pvi

·  motor - https://github.com/dls-controls/motor/tree/pvi

·  pmac - https://github.com/dls-controls/pmac/tree/pvi

 

Other modules that we would like to extend this to are include further areaDetector drivers as well as streamDevice, but this has not been pursued as yet.

 

We are hoping for people to take an interest in this idea so that it can be adopted more widely than just at DLS, so any thoughts and comments would be appreciated, especially from those who have an interest in these modules and can comment on the new structure.

 

Cheers,

Gary

 

-- 

This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom