areaDetector LightField driver

Table of Contents

• Introduction
• Implementation of standard driver parameters
• LightField specific parameters
• Configuration
• MEDM screens
• Restrictions

Introduction

This is an EPICS areaDetector driver for recent Princeton Instruments detectors including the ProEM, PIXIS, PI-MAX3, PI-MAX4, PyLoN, and Quad-RO. It also supports the Acton Series spectrographs.

The interface to the detector is via the Microsoft Common Language Runtime (CLR) interface to the LightField program that Princeton Instruments sells. The areaDetector driver effectively "drives" LightField through the CLR interface, performing most of the same operations that can be performed using the LightField GUI. The advantage of this communication mechanism is that the user can continue to use LightField for viewing images and for configuration operations. LightField is automatically started when the areaDetector software is started.

Because EPICS and the LightField 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. The LightField widget will display the current value of a parameter no matter how it was last changed. EPICS will correctly display the current value of the parameter in the "readback" record, which typically ends in "_RBV", no matter how the value was last changed. However the EPICS output record does not currently update if the value is changed in LightField. This may change in a future version of asyn device support.

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 LightField application.The LightField class documentation describes this class in detail.

Implementation of standard driver parameters

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

1. LFNumAccumulations ($(P)$(R)NumAccumularions). This controls the number of accumulations per image. Accumulations are acquired in hardware on the detector before it is read out.
2. ADNumExposures ($(P)$(R)NumExposures). This controls the number of images that are summed together by LightField into a single image.
3. ADNumImages ($(P)$(R)NumImages). This controls the number of images per acquisition. This is also called AcquisitionFramesToStore in LightField's terminology. These images will all be acquired into a single 3-D array, and saved to a single SPE file in LightField.
4. LFNumAcquisitions ($(P)$(R)NumAcquisitions). This controls the number of times that the driver will repeat an acquisition sequence. This is has no equivalent in LightField, 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. NOTE: NumAcquisitions is not yet implemented, but is planned in a future release.

LightField specific parameters

The LightField driver implements the following parameters in addition to those in asynNDArrayDriver.h and ADDriver.h.

Configuration

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

int LightFieldConfig(const char *portName, const char *experimentName,
                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 LightFieldConfig function in the LightField.cpp documentation and in the documentation for the constructor for the LightField class.

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

MEDM screens

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

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

LightField.adl

LightFieldFile.adl is the screen used to control LighField file I/O.

LightFieldFile.adl

LighField is program that the LightField driver is controlling via Microsoft Common Language Runtime.

LighField program from Priceton Instruments

Restrictions

The following are some current restrictions of the LightField driver:

• The driver has only been successfully built with the commercial version of Visual Studio. It does not seem to be possible to build with the free Express version of Visual Studio because it lacks support for the Microsoft Foundation Classes (MFC).
• If LightField encounters an error it will crash the IOC. The driver establishes an exception handler, but this does not seem to work correctly with the LightField CLR interface.