Experimental Physics and
Industrial Control System

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

I have already merged the changes in asyn to add this new class, since this is completely backwards compatible.

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.

This is also a goal of PVI. The baseclasses (asynNDArrayDriver, ADDriver) should define GUI Groups (Setup, Collect, Attributes, Shutter, etc.) that asynParameters are associated with, and subclasses (ADDriver, ADPilatus) can add their own Groups, as well as adding asynParameters to existing Groups. We have not currently considered hiding or moving asynParameters between Groups, but the YAML file format should be flexible enough to add this in the future if needed.

We are aiming to make usable low-level screens that are guaranteed to contain every asynParameter that a detector driver or plugin exposes. We imagine that there will still be manually generated OPIs that draw together a collection of driver and plugins into a single detector screen, as well as summary screens that layout a smaller selection of widgets in a more intuitive way. These are more site specific, and PVI will not generate these.

I have a question about template files as well. Derived class template files often override record values from the base class. How would this be done with the YAML scheme?

On the C++ side, we have moved the parameter generation from pilatusDetector.cpp to pilatusDetectorParamSet.h, but retained the code in pilatusDetector.cpp. In a similar way, we have moved the parameter generation from pilatus.template into pilatus_parameters.template, replacing it with an include statement, but retained baseclass overridden records and database logic in pilatus.template. We could also consider a YAML file format to do these overrides if necessary.

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!

I would definitely agree with the above for anyone writing their second areaDetector driver, but for first time contributors adding a single feature to a driver there are a lot of small changes that need to be made (add record, add drvInfo string, create parameter variable, call createParam, each with the correct string) before writing the actual logic. Each of these changes then needs to be reviewed upstream, and certain bits that are not required to test (adding to screens and documentation) are easy to forget. We're hoping that this YAML scheme will save effort both for developers and reviewers, but I agree we need to show it works well before we can consider adopting it.

Thanks,

Tom

-- 

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