areaDetector: EPICS Area Detector Support

R1-2

May 16, 2008

Mark Rivers

University of Chicago

 

Contents

 

Overview

The areaDetector module provides a general-purpose interface for area (2-D) detectors in EPICS. It is intended to be used with a wide variety of detectors and cameras, ranging from high frame rate CCD and CMOS cameras, pixel-array detectors such as the Pilatus, and large format detectors like the MAR-345 online imaging plate.

The goals of this module are:

 

Architecture

The architecture of the areaDetector module is shown in Figure 1.

Figure 1. Architecture of areaDetector module.

From the bottom to the top this architecture consists of the following:

The code in Layers 1-3 is essentially independent of EPICS. There are only 2 EPICS dependencies in this code.
  1. libCom. libCom from EPICS base provides operating-system independent functions for threads, mutexes, etc.
  2. asyn. asyn is a module that provides interthread messaging services, including queueing and callbacks.
In particular it is possible to eliminate layers 4-6 in the architecture shown in Figure 1, providing there is a programs such as the high-performance GUI shown in Layer 3. This means that it is not necessary to run an EPICS IOC or to use EPICS Channel Access when using the drivers and plugins at Layers 2 and 3.

The plugin architecture is very powerful, because plugins can be reconfigured at run-time. For example the NDPluginStdArrays can switch from getting its array data from a detector driver to an NDPluginROI plugin. That way it will switch from displaying the entire detector to whatever sub-region the ROI driver has selected. Any Channel Access clients connected to the NDPluginStdArrays driver will automatically switch to displaying this subregion. Similarly, the NDPluginFile plugin can be switched at run-time from saving the entire image to saving a selected ROI, just by changing its input source.

The use of plugins is optional, and it is only plugins that require the driver to make the image data available. If there are no plugins being used then EPICS can be used simply to control the detector, without accessing the data itself. This is most useful when the vendor API has the ability to save the data to a file.

What follows is a detailed description of the software, working from the bottom up. Most of the code is object oriented, and written in C++. The parts of the code that depend on anything from EPICS except libCom and asyn have been kept in in separate C files, so that it should be easy to build applications that do not run as part of an EPICS IOC.

 

asynPortDriver

The areaDetector module depends heavily on asyn. It is the software that is used for interthread communication, using the standard asyn interfaces (e.g. asynInt32, asynOctet, etc.), and callbacks. Detector drivers and plugins are asyn port drivers, meaning that they implement one or more of the standard asyn interfaces. They register themselves as interrupt sources, so that they do callbacks to registered asyn clients when values change. asynPortDriver handles all of the details of registering the port driver, registering the supported interfaces, and registering the required interrupt sources.

Drivers and plugins each need to support a number of parameters that control their operation and provide status information. Most of these can be treated as 32-bit integers, 64-bit floats, or strings. When the new value of a parameter is sent to a driver, (e.g. detector binning in the X direction) from an asyn client (e.g. an EPICS record), then the driver will need to take some action. It may change some other parameters in response to this new value (e.g. image size in the X direction). The sequence of operations in the driver can be summarized as

  1. New parameter value arrives, or new data arrives from detector.
  2. Change values of one or more parameters.
  3. For each parameter whose value changes set a flag noting that it changed.
  4. When operation is complete, call the registered callbacks for each changed parameter.
asynPortDriver provides methods to simplify the above sequence, which must be implemented for each of the many parameters that the driver supports. Each parameter is assigned a number, which is the value in the pasynUser-> reason field that asyn clients pass to the driver when reading or writing that parameter. asynPortDriver maintains a table of parameter values, associating each parameter number with a data type (integer, double, or string), caching the current value, and maintaining a flag indicating if a value has changed. Drivers use asynPortDriver methods to read the current value from the table, and to set new values in the table. There is a method to call all registered callbacks for values that have changed since callbacks were last done.

The following are the public definitions in the asynPortDriver class: 

#define asynCommonMask          0x00000001
#define asynDrvUserMask         0x00000002
#define asynOptionMask          0x00000004
#define asynInt32Mask           0x00000008
#define asyUInt32DigitalMask    0x00000010
#define asynFloat64Mask         0x00000020
#define asynOctetMask           0x00000040
#define asynInt8ArrayMask       0x00000080
#define asynInt16ArrayMask      0x00000100
#define asynInt32ArrayMask      0x00000200
#define asynFloat32ArrayMask    0x00000400
#define asynFloat64ArrayMask    0x00000800
#define asynGenericPointerMask  0x00001000

class asynPortDriver {
public:
    asynPortDriver(const char *portName, int maxAddr, int paramTableSize, int interfaceMask, int interruptMask);
    virtual asynStatus getAddress(asynUser *pasynUser, const char *functionName, int *address); 
    virtual asynStatus findParam(asynParamString_t *paramTable, int numParams, const char *paramName, int *param);
    virtual asynStatus readInt32(asynUser *pasynUser, epicsInt32 *value);
    virtual asynStatus writeInt32(asynUser *pasynUser, epicsInt32 value);
    virtual asynStatus getBounds(asynUser *pasynUser, epicsInt32 *low, epicsInt32 *high);
    virtual asynStatus readFloat64(asynUser *pasynUser, epicsFloat64 *value);
    virtual asynStatus writeFloat64(asynUser *pasynUser, epicsFloat64 value);
    virtual asynStatus readOctet(asynUser *pasynUser, char *value, size_t maxChars,
                         size_t *nActual, int *eomReason);
    virtual asynStatus writeOctet(asynUser *pasynUser, const char *value, size_t maxChars,
                          size_t *nActual);
    virtual asynStatus readInt8Array(asynUser *pasynUser, epicsInt8 *value, 
                                        size_t nElements, size_t *nIn);
    virtual asynStatus writeInt8Array(asynUser *pasynUser, epicsInt8 *value,
                                        size_t nElements);
    virtual asynStatus doCallbacksInt8Array(epicsInt8 *value,
                                        size_t nElements, int reason, int addr);
    virtual asynStatus readInt16Array(asynUser *pasynUser, epicsInt16 *value,
                                        size_t nElements, size_t *nIn);
    virtual asynStatus writeInt16Array(asynUser *pasynUser, epicsInt16 *value,
                                        size_t nElements);
    virtual asynStatus doCallbacksInt16Array(epicsInt16 *value,
                                        size_t nElements, int reason, int addr);
    virtual asynStatus readInt32Array(asynUser *pasynUser, epicsInt32 *value,
                                        size_t nElements, size_t *nIn);
    virtual asynStatus writeInt32Array(asynUser *pasynUser, epicsInt32 *value,
                                        size_t nElements);
    virtual asynStatus doCallbacksInt32Array(epicsInt32 *value,
                                        size_t nElements, int reason, int addr);
    virtual asynStatus readFloat32Array(asynUser *pasynUser, epicsFloat32 *value,
                                        size_t nElements, size_t *nIn);
    virtual asynStatus writeFloat32Array(asynUser *pasynUser, epicsFloat32 *value,
                                        size_t nElements);
    virtual asynStatus doCallbacksFloat32Array(epicsFloat32 *value,
                                        size_t nElements, int reason, int addr);
    virtual asynStatus readFloat64Array(asynUser *pasynUser, epicsFloat64 *value,
                                        size_t nElements, size_t *nIn);
    virtual asynStatus writeFloat64Array(asynUser *pasynUser, epicsFloat64 *value,
                                        size_t nElements);
    virtual asynStatus doCallbacksFloat64Array(epicsFloat64 *value,
                                        size_t nElements, int reason, int addr);
    virtual asynStatus readGenericPointer(asynUser *pasynUser, void *pointer);
    virtual asynStatus writeGenericPointer(asynUser *pasynUser, void *pointer);
    virtual asynStatus doCallbacksGenericPointer(void *pointer, int reason, int addr);
    virtual asynStatus drvUserCreate(asynUser *pasynUser, const char *drvInfo, 
                                     const char **pptypeName, size_t *psize);
    virtual asynStatus drvUserGetType(asynUser *pasynUser,
                                        const char **pptypeName, size_t *psize);
    virtual asynStatus drvUserDestroy(asynUser *pasynUser);
    virtual void report(FILE *fp, int details);
    virtual asynStatus connect(asynUser *pasynUser);
    virtual asynStatus disconnect(asynUser *pasynUser);
   
    virtual asynStatus setIntegerParam(int index, int value);
    virtual asynStatus setIntegerParam(int list, int index, int value);
    virtual asynStatus setDoubleParam(int index, double value);
    virtual asynStatus setDoubleParam(int list, int index, double value);
    virtual asynStatus setStringParam(int index, const char *value);
    virtual asynStatus setStringParam(int list, int index, const char *value);
    virtual asynStatus getIntegerParam(int index, int * value);
    virtual asynStatus getIntegerParam(int list, int index, int * value);
    virtual asynStatus getDoubleParam(int index, double * value);
    virtual asynStatus getDoubleParam(int list, int index, double * value);
    virtual asynStatus getStringParam(int index, int maxChars, char *value);
    virtual asynStatus getStringParam(int list, int index, int maxChars, char *value);
    virtual asynStatus callParamCallbacks();
    virtual asynStatus callParamCallbacks(int list, int addr);
    virtual void reportParams();

    /* asynUser connected to ourselves for asynTrace */
    asynUser *pasynUser;
};
A brief explanation of the methods and data in this class is provided here. Users should look at the example driver (simDetector) and plugins provided with areaDetector for examples of how this class is used. 
    asynPortDriver(const char *portName, int maxAddr, int paramTableSize, int interfaceMask, int interruptMask);
This is the constructor for the class. 
    virtual asynStatus getAddress(asynUser *pasynUser, const char *functionName, int *address);
Returns the value from pasynManager-> getAddr(pasynUser,...). Returns an error if the address is not valid, e.g. >= this-> maxAddr. 
    virtual asynStatus readInt32(asynUser *pasynUser, epicsInt32 *value);
    virtual asynStatus readFloat64(asynUser *pasynUser, epicsFloat64 *value);
    virtual asynStatus readOctet(asynUser *pasynUser, char *value, size_t maxChars,
                             size_t *nActual, int *eomReason);
These methods are called by asyn clients to return the current cached value for the parameter indexed by pasynUser-> reason in the parameter table defined by getAddress(). Derived classed typically do not need to implement these methods. 
    virtual asynStatus writeInt32(asynUser *pasynUser, epicsInt32 value);
    virtual asynStatus writeFloat64(asynUser *pasynUser, epicsFloat64 value);
    virtual asynStatus writeOctet(asynUser *pasynUser, const char *value, size_t maxChars,
                          size_t *nActual);
These methods are called by asynClients to set the new value of a parameter. The implementation of these methods in asynPortDriver copies the parameter into a cached location for use by the asynRead(Int32, Float64, and Octet) methods. Most drivers will provide their own implementations of these methods to do driver-dependent operations when there is a new value of the parameter. 
     
    virtual asynStatus readXXXArray(asynUser *pasynUser, epicsInt8 *value, 
                                        size_t nElements, size_t *nIn);
    virtual asynStatus writeXXXArray(asynUser *pasynUser, epicsInt8 *value,
                                        size_t nElements);
    virtual asynStatus doCallbacksXXXArray(epicsInt8 *value,
                                        size_t nElements, int reason, int addr);
    virtual asynStatus readGenericPointer(asynUser *pasynUser, void *handle);
    virtual asynStatus writeGenericPointer(asynUser *pasynUser, void *handle);
    virtual asynStatus doCallbacksGenericPointer(void *handle, int reason, int addr);
where XXX=(Int8, Int16, Int32, Float32, or Float64). The readXXX and writeXXX methods only have stub methods that return an error in asynPortDriver, so they must be implemented in the derived classes if the corresponding interface is used. They are not pure virtual functions so that the derived class need not implement the interface if it is not used. The doCallbacksXXX methods in asynPortDriver call any registered asyn clients on the corresponding interface if the reason and addr values match. It typically does not need to be implemented in derived classes. 
     
    virtual asynStatus findParam(asynParamString_t *paramTable, int numParams, const char *paramName, int *param);
    virtual asynStatus drvUserCreate(asynUser *pasynUser, const char *drvInfo, 
                                     const char **pptypeName, size_t *psize);
    virtual asynStatus drvUserGetType(asynUser *pasynUser,
                                        const char **pptypeName, size_t *psize);
    virtual asynStatus drvUserDestroy(asynUser *pasynUser);
drvUserCreate must be implemented in derived classes that use the parameter facilities of asynPortDriver. The findParam method is a convenience function that searches an array of {enum, string} structures and returns the enum (parameter number) matching the string. This is typically used in the implementation of drvUserCreate in derived classes. drvUserGetType and drvUserDestroy typically do not need to be implemented in derived classes. 
     
    virtual void report(FILE *fp, int details);
    virtual asynStatus connect(asynUser *pasynUser);
    virtual asynStatus disconnect(asynUser *pasynUser);
The report function prints information on registered interrupt clients if details > 0, and prints parameter table information if details > 5. It is typically called by the implementation of report in derived classes before or after they print specific information about themselves. connect and disconnect call pasynManager-> exceptionConnect and pasynManager-> exceptionDisconnect respectively. Derived classes may or may not need to implement these functions. 
     
    virtual asynStatus setIntegerParam(int index, int value);
    virtual asynStatus setIntegerParam(int list, int index, int value);
    virtual asynStatus setDoubleParam(int index, double value);
    virtual asynStatus setDoubleParam(int list, int index, double value);
    virtual asynStatus setStringParam(int index, const char *value);
    virtual asynStatus setStringParam(int list, int index, const char *value);
    virtual asynStatus getIntegerParam(int index, int * value);
    virtual asynStatus getIntegerParam(int list, int index, int * value);
    virtual asynStatus getDoubleParam(int index, double * value);
    virtual asynStatus getDoubleParam(int list, int index, double * value);
    virtual asynStatus getStringParam(int index, int maxChars, char *value);
    virtual asynStatus getStringParam(int list, int index, int maxChars, char *value);
    virtual asynStatus callParamCallbacks();
    virtual asynStatus callParamCallbacks(int list, int addr);
The setXXXParam methods set the value of a parameter in the parameter table in the object. If the value is different from the previous value of the parameter they also set the flag indicating that the value has changed. The getXXXParam methods return the current value of the parameter. There are two versions of the setXXXParam and getXXXParam methods, one with a list argument, and one without. The one without uses list=0, since there is often only a single parameter list (i.e. if maxAddr=1). The callParamCallbacks methods call back any registered clients for parameters that have changed since the last time callParamCallbacks was called. The version of callParamCallbacks with no arguments uses the first parameter list and matches asyn address=0. There is a second version of callParamCallbacks that takes an argument specifying the parameter list number, and the asyn address to match.

NDArray

The NDArray (N-Dimensional array) is the class that is used for passing detector data from drivers to plugins. The NDArray class is defined as follows: 
#define ND_ARRAY_MAX_DIMS 10

/* Enumeration of array data types */
typedef enum
{
    NDInt8,
    NDUInt8,
    NDInt16,
    NDUInt16,
    NDInt32,
    NDUInt32,
    NDFloat32,
    NDFloat64
} NDDataType_t;


typedef struct NDDimension {
    int size;
    int offset;
    int binning;
    int reverse;
} NDDimension_t;

typedef struct NDArrayInfo {
    int nElements;
    int bytesPerElement;
    int totalBytes;
} NDArrayInfo_t;

class NDArray {
public:
    /* Data: NOTE this must come first because ELLNODE must be first, i.e. same address as object */
    /* The first 2 fields are used for the freelist */
    ELLNODE node;
    int referenceCount;
    /* The NDArrayPool object that created this array */
    void *owner;

    int uniqueId;
    double timeStamp;
    int ndims;
    NDDimension_t dims[ND_ARRAY_MAX_DIMS];
    NDDataType_t dataType;
    int dataSize;
    void *pData;

    /* Methods */
    NDArray();
    int          initDimension   (NDDimension_t *pDimension, int size);
    int          getInfo         (NDArrayInfo_t *pInfo);
    int          copy            (NDArray *pOut);
    int          reserve(); 
    int          release();
};
An NDArray is a general purpose class for handling array data. An NDArray object is self-describing, meaning it contains enough information to describe the data itself. It is not intended to contain meta-data describing how the data was collected, etc.

An NDArray can have up to ND_ARRAY_MAX_DIMS dimensions, currently 10. A fixed maximum number of dimensions is used to significantly simplify the code compared to unlimited number of dimensions. Each dimension of the array is described by an NDDimension_t structure. The fields in NDDimension_t are as follows:

The first 3 data fields in the NDArray class, (node, referenceCount, owner) are used by the NDArrayPool class discussed below. The remaining data fields are as follows: The methods of the NDArray class are:

NDArrayPool

The NDArrayPool class manages a free list (pool) of NDArray objects (described above). Drivers allocate NDArray objects from the pool, and pass these objects to plugins. Plugins increase the reference count on the object when they place the object on their queue, and decrease the reference count when they are done processing the array. When the reference count reaches 0 again the NDArray object is placed back on the free list. This mechanism minimizes the copying of array data in plugins. The public interface of the NDArrayPool class is defined as follows: 
class NDArrayPool {
public:
                 NDArrayPool   (int maxBuffers, size_t maxMemory);
    NDArray*     alloc         (int ndims, int *dims, NDDataType_t dataType, int dataSize, void *pData);
    int          reserve       (NDArray *pArray); 
    int          release       (NDArray *pArray);
    int          convert       (NDArray *pIn, 
                                NDArray **ppOut,
                                NDDataType_t dataTypeOut,
                                NDDimension_t *outDims);
    int          report        (int details);
The methods of the NDArrayPool class are:

asynNDArrayDriver

asynNDArrayDriver inherits from asynPortDriver. It implements the asynGenericPointer functions, assuming that these reference NDArray objects. This is the class from which both plugins and area detector drivers are indirectly derived. Its public interface is defined as follows: 
class asynNDArrayDriver : public asynPortDriver {
public:
    asynNDArrayDriver(const char *portName, int maxAddr, int paramTableSize, int maxBuffers, size_t maxMemory,
                      int interfaceMask, int interruptMask);
    virtual asynStatus readGenericPointer(asynUser *pasynUser, void *genericPointer);
    virtual asynStatus writeGenericPointer(asynUser *pasynUser, void *genericPointer);
    virtual void report(FILE *fp, int details);

};
The methods of the asynNDArrayDriver class are:

ADDriver

ADDriver inherits from asynNDArrayDriver. This is the class from which area detector drivers are directly derived. Its public interface is defined as follows: 
class ADDriver : public asynNDArrayDriver {
public:
    ADDriver(const char *portName, int maxAddr, int paramTableSize, int maxBuffers, size_t maxMemory,
             int interfaceMask, int interruptMask);
                 
    /* These are the methods that we override from asynPortDriver */
     virtual asynStatus drvUserCreate(asynUser *pasynUser, const char *drvInfo, 
                                     const char **pptypeName, size_t *psize);
                                     
    /* These are the methods that are new to this class */
    int createFileName(int maxChars, char *fullFileName);
The methods of the ADDriver class are:

simDetector

simDetector is a driver for a simulated area detector. It inherits from ADDriver. The simulation detector implements nearly all of the parameters defined in ADStdDriverParams.h. It also implements a few parameters that are specific to the simulation detector. The simulation detector is useful as a model for writing real detector drivers. It is also very useful for testing plugins and channel access clients. This is part of the definition of the simDetector class: 
class simDetector : public ADDriver {
public:
    simDetector(const char *portName, int maxSizeX, int maxSizeY, NDDataType_t dataType,
                int maxBuffers, size_t maxMemory);
                 
    /* These are the methods that we override from ADDriver */
    virtual asynStatus writeInt32(asynUser *pasynUser, epicsInt32 value);
    virtual asynStatus writeFloat64(asynUser *pasynUser, epicsFloat64 value);
    virtual asynStatus drvUserCreate(asynUser *pasynUser, const char *drvInfo, 
                                     const char **pptypeName, size_t *psize);
    void report(FILE *fp, int details);
The portName, maxBuffers, and maxMemory arguments are passed to the base class constructors. The maxSizeX, maxSizeY, and dataType arguments are specific to the simulation driver, controlling the maximum image size and initial data type of the computed images. The writeInt32 and writeFloat64 methods override those in the base class. The driver takes action when new parameters are passed via those interfaces. For example, the ADAcquire parameter (on the asynInt32 interface) is used to turn acquisition (i.e. computing new images) on and off.

The simulation driver initially sets the image[i, j] = i*gainX + j*gainY * gain * exposureTime * 1000. Thus the image is a linear ramp in the X and Y directions, with the gains in each direction being detector-specific parameters. Each subsquent acquisition increments each pixel value by gain*exposureTime*1000. Thus if gain=1 and exposureTime=.001 second then the pixels are incremented by 1. If the array is an unsigned 8 or 16 bit integer then the pixels will overflow and wrap around to 0 after some period of time. This gives the appearance of bands that appear to move with time. The slope of the bands and their periodicity can be adjusted by changing the gains and exposure times.

The driver creates a thread that waits for a signal to start acquisition. When acquisition is started that thread computes new images and then calls back any registered plugins as follows: 

        /* Put the frame number and time stamp into the buffer */
        pImage->uniqueId = imageCounter;
        pImage->timeStamp = startTime.secPastEpoch + startTime.nsec / 1.e9;
        
        /* Call the NDArray callback */
        /* Must release the lock here, or we can get into a deadlock, because we can
         * block on the plugin lock, and the plugin can be calling us */
        epicsMutexUnlock(this->mutexId);
        asynPrint(this->pasynUser, ASYN_TRACE_FLOW, 
             "%s:%s: calling imageData callback\n", driverName, functionName);
        doCallbacksGenericPointer(pImage, NDArrayData, addr);
        epicsMutexLock(this->mutexId);
The 3 driver-specific parameters are defined in the driver as follows: 
/* If we have any private driver parameters they begin with ADFirstDriverParam and should end
   with ADLastDriverParam, which is used for setting the size of the parameter library table */
typedef enum {
    SimGainX 
        = ADFirstDriverParam,
    SimGainY,
    SimResetImage,
    ADLastDriverParam
} SimDetParam_t;

static asynParamString_t SimDetParamString[] = {
    {SimGainX,          "SIM_GAINX"},  
    {SimGainY,          "SIM_GAINY"},  
    {SimResetImage,     "RESET_IMAGE"},  
};

#define NUM_SIM_DET_PARAMS (sizeof(SimDetParamString)/sizeof(SimDetParamString[0]))
The drvUserCreate function first checks to see if the parameter is one of these 3 parameters that are unique to the simulation driver. If not it checks to see if it is a standard parameter by calling the ADDriver base class method. 
asynStatus simDetector::drvUserCreate(asynUser *pasynUser,
                                      const char *drvInfo, 
                                      const char **pptypeName, size_t *psize)
{
    asynStatus status;
    int param;
    const char *functionName = "drvUserCreate";

    /* See if this is one of our standard parameters */
    status = findParam(SimDetParamString, NUM_SIM_DET_PARAMS, 
                       drvInfo, ¶m);
                                
    if (status == asynSuccess) {
        pasynUser->reason = param;
        if (pptypeName) {
            *pptypeName = epicsStrDup(drvInfo);
        }
        if (psize) {
            *psize = sizeof(param);
        }
        asynPrint(pasynUser, ASYN_TRACE_FLOW,
                  "%s:%s: drvInfo=%s, param=%d\n", 
                  driverName, functionName, drvInfo, param);
        return(asynSuccess);
    }
    
    /* If not, then see if it is a base class parameter */
    status = ADDriver::drvUserCreate(pasynUser, drvInfo, pptypeName, psize);
    return(status);  
}

Prosilica Driver

This is a driver for Gigabit Ethernet and Firewire cameras from Prosilica. It inherits from ADDriver. It also implements a number of parameters that are specific to the Prosilica cameras. The vendor library provided by Prosilica does callbacks to a user-supplied function each time there is a new frame. Thus, it is not necessary to create a thread for callbacks in this driver.

EPICS records

The following EPICS records are used by pilatusROI. All records are prefixed by the macro $(DET) which must be passed to the template file when the records are loaded.

Acquisition related records

Detector related records

File name related records

The FilePath, Filename, FileNumber, and FileFormat PVs are all used to create the final FullFilename.

ROI related records

The SNL code supports up to 32 rectangular ROIs. Fewer ROIs can be used by loading the pilatusROI_N.template file fewer than 32 times, and passing NROIS<32 to the SNL program when it is started. In the following record names $(N) is a number from 1 to 32. ROIs can be any size from a single pixel to the entire chip. An ROI is considered invalid and ignorred by the SNL program if any of Xmin, Xmax, YMin, YMax is less than 0 or greater than the size of the chip in that direction. The ROI is also invalid if Xmin>XMax or YMin>YMax. The ROI$(N)TotalCounts and ROI$(N)NetCounts are computed as each TIFF file is read, regardless of the value of NImages. The ROI$(N)WFTotalCounts and ROI$(N)WFNetCounts arrays are computed and posted to EPICS when acquiring data with NImages>1. The first element in each array is the for the first image in the series, etc.

Image related records

Bad pixel map related records

Flat field correction related records

Communication related records

Scan related records