areaDetector Pixirad driver

Table of Contents

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

Introduction

This is an EPICS areaDetector driver for the Pixirad detectors from Pixirad.

The Pixirad detector is a pixel array detector with a cadmium teluride (CdTe) sensor, so it has high efficiency at high energy. There are 2 versions of the ASIC, the older PII, and the newer PIII. The PII base module is 476 x 512 pixels, while the PIII is 402 x 512 pixels. The detector is available with a single module (Pixirad-1), 2 modules (Pixirad-2), and 8 modules (Pixirad-8).

The detector does photon counting of all photons above a programmable energy threshold. The detector hardware has 2 energy thresholds and two counters per pixel, so it can collect 2 energy images simultaneously. The PII firmware supports 4 thresholds, by first collecting 2 energies, and then collecting another image with 2 additional energies. The detector can be operated in 1, 2, or 4 color mode. In addition it supports deadtime-free (DTF) counting modes where one image is being collected while the other is being read out. Both 1 and 2 color DTF modes are supported. The NDArrays produced by this driver are unsigned 16-bit integers. They have dimensions [XSIZE, YSIZE] for 1 color images, [XSIZE, YSIZE, 2] for 2 color images, and [XSIZE, YSIZE, 4] for 4 color images. XSIZE=476 for PII and 402 for PIII. YSIZE=NumModules*512 for both the PII and PIII.

The command interface to the detector is via a TCP/IP socket interface to the detector on port 2222.

The driver receives status information from the detector via UDP broadcast messages on port 2224. The status includes temperatures, humidity and high voltage.

The driver receives image data from the detector via UDP broadcast messages on port 2223 for the Pixirad-1, and port 9999 for the Pixirad-2 and Pixirad-8. This data is received by a "UDP listener thread" in the driver, which passes the UDP buffers as they are received via a pointer on an epicsMessageQueue to a "data unpacking thread". This second thread unscrambles the UDP buffers, converts them to areaDetector NDArrays, and does the callbacks to registered plugins. The size of the epicsMessageQueue is controlled by a parameter passed to the driver constructor, and is set to 1500 in the example IOC. This provides a buffer in case the UDP listener thread is receiving images faster than the data unpacking thread can process them.

The detector can in principle be on a public network where it will receive its IP address from a DHCP server. In practice the current detector firmware does not work correctly in this configuration, because the UDP messages do not use the correct network addresses. This means that the detector must be placed on a private network with no DHCP server. It will always have the network address 192.168.0.1. This also means that the computer running the areaDetector driver must have 2 network cards, with the one connected to the detector having a host address on the 192.168.0 subnet.

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

Implementation of standard driver parameters

The following table describes how the Pixirad driver implements some of the standard driver parameters.

When collecting 2 or 4 color images it is useful to use NDPluginROI to select a single color. This can be done by defining an ROI with X and Y set to the full detector size (AutoSizeX=Yes, AutoSizeY=Yes) and Z set to AutoSizeX=No and SizeZ=1. MinZ can then be used to select a single color (0=color 1, 1=color2, etc.). If the NDStdArrays plugin is set to get its data from this ROI plugin then the ImageJ display client will display the selected color image.

Pixirad specific parameters

The Pixirad 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 AutoCalibrate.

Unsupported standard driver parameters

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

• Number of exposures per image (ADNumExposures)
• Gain (ADGain)
• Region to read out or binning (ADMinX, ADMinY, ADSizeX, ADSizeY, ADBinX, ADBinY, ADReverseX, ADReverseY)
• Data type (NDDataType)

Configuration

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

int pixiradConfig(const char *portName, const char *commandPortName,
                 int dataPortNumber, int statusPortNumber, int maxDataPortBuffers,
                 int maxSizeX, int maxSizeY,
                 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 pixiradConfig function in the pixirad.cpp documentation and in the documentation for the constructor for the pixirad class.

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

MEDM screens

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

pixirad.adl is the main screen used to control the Pixirad driver.

pixirad.adl

Performance measurements

The following measurements were done to demonstrate the performance that can be obtained with the areaDetector Pixirad driver. The timings were done by measuring the frequency of the Sync Out signal on an oscilloscope. The SyncOutFunction was "Shutter" and 1000 frames were collected.

The measurements above were made with TriggerMode=Internal. Additional measurements made using TriggerMode=External showed that the maximum frame rate was the same as that shown in the table, i.e. as soon as the external trigger frequency exceeded this value the detector ignored every second external trigger pulse.

The data above show that the detector overhead is about 7.5 ms in "1 color low"; mode. In "1 color DTF"; mode the overhead is about 0.7 ms, but with a minimum frame period of 7 ms. In "2 color" mode the overhead is 15 ms, or 7.5 ms per image, the same as in "1 color low". In "4 color" mode two exposures are required. The total time is equal to AcquireTime*2 + 0.0075*4, so again the overhead is about 7.5 ms per image.

Restrictions

The following are some current restrictions of the Pixirad driver due to bugs in the Pixirad firmware:

• The detector does not accept a high-voltage value unless 2 different values are sent to it after power-cycle or system reset. The areaDetector driver works around this problem by sending the requested voltage minus 1.0 and then the requested voltage when the IOC starts up, and also after a system reset. However, it appears that even this is sometimes not sufficient. To see if this is a problem set the HVState to On and see if the HVActual is close to the requested value. If it is not, for example if it is only 12V or so, then change the HVValue to something else and then back to the requested value. This should fix the problem.
• At high frame rates there can be occasional loss of UDP packets. This will result in an error message on the IOC console, UDPBuffersRead will be fewer than NumImages, and the Acquire PV will not go back to 0. If this happens then press the Stop button (setting Acquire to 0). If a DTF sequence was being acquired then sometimes all subsequent images will be corrupted, and it will be necessary to restart the EPICS IOC.
• If a long acquisition sequence is started it is not currently possible to make the detector abort it. There is a command that can be sent to the detector to abort an acquisition, but unfortunately this causes the detector to malfunction for subsequent acquisitions.
• The detector does not send UDP status packets during acquisition. If the HVMode=Auto and HVState=Off, which is a normal way to operate, then the HVActual readback will be 0 during acquisition, because no status update happens after the high voltage is automatically turned on at the start of acquisition. Immediately upon completion of acquisition the status updates begin, and a few non-zero values will be observed as the high voltage ramps down. This is normal, but it may cause confusion, since it appears that the high voltage has not been turned on during acquisition, when actually it was.