Experimental Physics and
Industrial Control System

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