80 likes | 242 Views
areaDetector: Recent Additions and Future Plans. Mark Rivers GeoSoilEnviroCARS, Advanced Photon Source University of Chicago. Recent Additions (R1-10) Improved timestamp support.
E N D
areaDetector: Recent Additions and Future Plans Mark Rivers GeoSoilEnviroCARS, Advanced Photon Source University of Chicago
Recent Additions (R1-10)Improved timestamp support • New timestamp functions added to asynManager in response to need from LCLS. These are used to set a user-defined timestamp source, to attach that timestamp to pasynUser. Standard asyn device support sets prec->time with this value, which will be used if prec->TSE=-2. asynStatus (*registerTimeStampSource)(asynUser *pasynUser, void *userPvt, timeStampCallback callback); asynStatus (*unregisterTimeStampSource)(asynUser *pasynUser); asynStatus (*updateTimeStamp)(asynUser *pasynUser); asynStatus (*getTimeStamp)(asynUser *pasynUser, epicsTimeStamp *pTimeStamp); asynStatus (*setTimeStamp)(asynUser *pasynUser, const epicsTimeStamp *pTimeStamp); • Added new virtual methods to asynPortDriver for timestamp support. These are updateTimeStamp(), setTimeStamp(), getTimeStamp().
Recent Additions (R1-10)Improved timestamp support • Added new epicsTimeStamp field to NDArray. The previous timeStamp field was a double. Useful for plotting and math, but only microsecond precision and not useful for record timestamps. • All drivers now call the following as soon as an image is collected: updateTimeStamp(&pImage->epicsTS); • NDPluginDriver::processCallbacks now calls the following when an NDArray is received: setTimeStamp(&pArray->epicsTS); • This means that all EPICS records, including plugin records, associated with a specific NDArray will have the timestamp when that array was collected if the record has TSE=-2
Recent Additions (R1-10)Other • New driver for new Princeton Instruments detectors using their LightField control program. Uses Microsoft Common Language Runtime to control their application, which is written in C#. • Added new attribute type, NDAttrSourceFunct. This type of attribute gets its value from a user-defined C++ function. It can thus be use to get any type of metadata. Previously only EPICS PVs and driver/plugin parameters were available as metadata.
Near Term Plans (R1-11?)Improved support for file plugins • New HDF5 plugin in progress at DLS with input from APS • Features of existing areaDetector HDF5 plugin from DLS (chunking, compression) • Adds XML configuration file to control layout of data and attributes in XML file • Hopefully can replace existing AD HDF5, Nexus, and Tim Madden’s HDF5 plugins with a single plugin. • Enhanced support for controlling the file destination (path, name, number) via NDAttributes attached to the NDArray. • Driver sets attributes to determine the values when array is collected, the plugin saves files with different names for flat fields, etc.
Future Plans R2-0 • areaDetector is getting too big. • New releases are held up waiting for testing on one detector types, etc. • The next major release (R2-0) will split up areaDetector • areaDetector will include only the core components and most plugins • Unbundle detector drivers into their own modules • ADPilatus, ADProsilica, etc.. • These can be released on a timely basis, independent of other detectors. • Some plugins may be unbundled as well • e.g. NDPluginMagick to simplify build for those who don’t need them • How to do this without multiplying my work by 15 with release notes for each module, etc.
Future Plans R2-0 • Hard to collaborate • Need write permission to APS SVN repository • Move areaDetector to git and github?
Future Plans R3-0 • asynPortDriver2 • Will need to be a new base class for backwards compatibility • Will improve to better C++ code. • Use exceptions! • I want suggestions and input on this • ADDriver2 base class • Put more functionality in ADDriver base class so driver writers don’t worry about getting attributes, etc. • Non-trivial because different detector APIs are so different