1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 <2020> 2021 2022 2023 2024 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 <2020> 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: PVI Prototype - a framework for specifying the interface to an EPICS driver in a single YAML file |
From: | "Cobb, Tom \(DLSLtd,RAL,LSCI\) via Tech-talk" <tech-talk at aps.anl.gov> |
To: | Mark Rivers <rivers at cars.uchicago.edu>, "Yendell, Gary (DLSLtd,RAL,LSCI)" <gary.yendell at diamond.ac.uk>, "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov> |
Date: | Thu, 18 Jun 2020 13:09:17 +0000 |
Hi Mark,
No problem, we all get busy!
Thanks, this will let us prototype the generation stage more
One of the goals of PVI is to maintain the external record interface unchanged. The YAML file format must be flexible
to be able to create the scheme you mention, even when certain records don't match the conventions. We will make sure that this is the case.
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.
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.
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 From: Mark Rivers <rivers at cars.uchicago.edu>
Sent: 17 June 2020 19:38 To: Yendell, Gary (DLSLtd,RAL,LSCI) <gary.yendell at diamond.ac.uk>; tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>; Cobb, Tom (DLSLtd,RAL,LSCI) <tom.cobb at diamond.ac.uk> Subject: Re: PVI Prototype - a framework for specifying the interface to an EPICS driver in a single YAML file 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>
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.
-- 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. |