areaDetector Roper driver

Table of Contents

• Introduction
• Implementation of standard driver parameters
• Roper specific parameters
• Unsupported standard driver parameters
• Configuration
• MEDM screens
• Performance measurements
• Restrictions

Introduction

This is an EPICS areaDetector driver for the Roper Scientific detectors, which includes those from Princeton Instruments and Photometrics.

The interface to the detector is via a the Microsoft COM interface to the WinView or WinSpec programs that Roper provides. The term WinView will be used in this document to refer to either WinView or WinSpec, as they are equivalent in terms of the areaDetector driver. The areaDetector driver effectively "drives" WinView through the COM interface, performing many of the same operations that can be performed using the WinView GUI. The advantage of this communication mechanism is that the user can continue to use WinView for viewing images and for configuration operations. WinView is normally started before the areaDetector software is started. However, if the areaDetector software is started without WinView running, then WinView will be started in the background, and will not be visible. This may be desirable in some applications.

Because EPICS and the WinView GUI can control many of the same parameters the user must be aware of the interactions between the two control systems. The basic rule is that the value of a parameter will be determined by whichever control system last wrote to that parameter. Both EPICS and WinView will correctly display the current value of a parameter no matter how it was last changed. However, in WinView this requires closing and re-opening the window that controls that parameter, such as the Experiment Setup tabbed windows, to see any changes made by EPICS since the window was opened.

This driver inherits from ADDriver. It implements many of the parameters asynNDArrayDriver.h and in ADArrayDriver.h. It also implements a number of parameters that are specific to the Roper detectors.The roper class documentation describes this class in detail.

Implementation of standard driver parameters

The following table describes how the Roper driver implements some of the standard driver parameters. Note that there are 3 possible levels of nested acquisition looping when using the Roper driver. From the innermost to outermost loop these are as follows:

1. ADNumExposures ($(P)$(R)NumExposures). This controls the number of exposures per image. This is called "accumulations" in Roper's terminology.
2. ADNumImages ($(P)$(R)NumImages). This controls the number of images per acquisition. This is also called "number of images" in Roper's terminology. These images will all be acquired into a single 3-D array, and saved to a single SPE file in WinView.
3. RoperNumAcquisitions ($(P)$(R)NumNumAcquisitions). This controls the number of times that the driver will repeat an acquisition sequence. This is has no equivalent in WinView, it is handled entirely by the areaDetector driver. It can be used to acquire multiple data sets, where each is controlled by the above parameters.

Roper specific parameters

The Roper driver implements the following parameters in addition to those in asynNDArrayDriver.h and ADDriver.h. Note that to reduce the width of this table the parameter index variable names have been split into 2 lines, but these are just a single name, for example marCCDState.

Unsupported standard driver parameters

The Roper driver does not support the following standard driver parameters:

• Frame type (ADFrameType). This may be supported in a future release to control acquisition of flat field and dark current frames.
• Reading previous files (NDReadFile). This may be supported in a future release.
• Capture or stream file saving (NDFileWriteMode, NDFileCapture, NDNumCapture, NDNumCaptured)

Configuration

The Roper driver is created with the roperConfig command, either from C/C++ or from the EPICS IOC shell.

int roperConfig(const char *portName,
                int maxBuffers, size_t maxMemory,
                int priority, int stackSize)
  

For details on the meaning of the parameters to this function refer to the detailed documentation on the roperConfig function in the roper.cpp documentation and in the documentation for the constructor for the roper class.

There an example IOC boot directory and startup script (iocBoot/iocRoper/st.cmd) provided with areaDetector.

MEDM screens

The following show the MEDM screens that are used to control the Roper detector. Note that the general purpose screen ADBase.adl can be used, but it exposes a few controls that are not applicable to the Roper, and lacks some fields that are important for the Roper.

Roper.adl is the main screen used to control the Roper driver.

roper.adl

RoperFile.adl is the screen used to control WinView file I/O.

RoperFile.adl

WinView is program that the Roper driver is controlling via Microsoft COM.

WinView program from Roper Scientific

Performance measurements

The following measurements were done to demonstrate the performance that can be obtained with the areaDetector Roper driver. These measurements were made with a CoolSnap-HQ2 detector which has 1392x1040 pixels. The acquisition time was 0.01 second. The overhead per image in the table below is the total time to acquire the data set minus 1.00 seconds (the acquisition time) divided by 100. Acquisitions were done in 2 modes:

1. In the first mode NumImages=100 and NumAcquisitions=1, i.e. the data were all collected into a single SPE file. In this mode the time per image is really controlled by the acquisition time and readout time. At the end of the acquisition there is then a delay, perhaps in copying the data from one buffer to another. The acquisition time in this mode is the time from when acquire was started until WinView reported acquisition was complete and the write to disk began. The additional time to write the file to disk is also listed.
2. In the second mode NumImages=1 and NumAcquisitions=100, i.e. the data were collected into 100 SPE files. This is equivalent to pressing the Acquire button in WinView 100 times. There is additional overhead per image that arises from downloading parameters to the camera and in creating a new display window in WinView. In this mode the test was done both with the EPICS AutoSave PV set to 1 (which effectively does a WinView "Save As" operation for each file), and with AutoSave set to 0, which does not write disk files at all. The acquisition time listed is with AutoSave on, i.e. saving 100 disk files. Interestingly it was generally faster to collect the data with AutoSave on than with it off! The time to save the 100 disk files is thus actually negative, i.e. it took that much longer to collect the data sets without saving the disk files. The reason for this is unclear, but it seems to be something internal to WinView.

Restrictions

The following are some current restrictions of the Roper driver:

• The are hundreds of parameters that can be controlled in WinView via the COM interface for acquiring, processing and displaying images. This driver does not attempt to support all of them, just the ones that are most commonly needed for EPICS data acquisition and control software. Additional features of WinView are very easy to add to the EPICS interface if needed in the future. Settings that EPICS does not control and which do not need to be frequently changed can simply be set via the WinView GUI.
• When NumImages is greater than one WinView collects a 3-D stack of images. The areaDetector driver can save that data to a file using WinView. However, the driver callbacks to plugins currently only passes the first image in that stack. It is not practical to pass all the images in the stack at once as a 3-d array, because this would require allocating a second 3-D array of the same size as the one in the WinView buffer. What would be possible is to pass each of the images in the stack on after the other. This will be implemented in a future release.
• Reading data files back into WinView is not currently supported. This may be added in a future release.
• The values of ADNumImagesCounter ($(P)$(R)NumImagesCounter_RBV) and ADNumExposuresCounter ($(P)$(R)NumExposuresCounter_RBV) are not updated during acquisition. This is because WinView does not appear to be correctly returning the values of the EXP_CSEQUENTS and EXP_CACCUMS parameters. The reason for this is under investigation and hopefully will be fixed in a future release.
• The driver does not pass callbacks for images in WinView focus mode. I don't currently have the required information on how to know when new data is available in focus mode and how to read it. Hopefully this will be added in a future release.
• WinView/WinSpec must be version 2.5.22 or later, because the class names changed in that release.
• The following items are hardcoded in the driver. They can be changed by recompiling if necessary.
  • ERROR_MESSAGE_SIZE=256 The maximum size of error messages that can be retrieved from WinView.
  • ROPER_POLL_TIME=0.01 seconds. The time between polling WinView status to see when acquisition is complete.
• There is a bug in Windows XP SP2 that causes WinView to hang after about 1600 acquisitions have been performed in a single WinView session. Acquisition means the equivalent of pressing the Acquire button, regardless of how many images were collected in a single acquisition. This would typically mean that 1600 SPE files had been saved. After 1600 acquisitions it is necessary to exit WinView and restart it. This problem is fixed in SP3 for Windows XP, and in Microsoft Vista.