EPICS support for 2-D detectors/cameras

["Mark Rivers" <rivers@cars.uchicago.edu>]

Folks,

I have just put together a draft proposal for a new model for EPICS
support for area detectors and cameras.  It is based mostly on my
experience here at the APS.  I would like to get comments on it.  In
particular I would like to know if someone else has already come up with
a similar generalized approach to 2-D detectors, or if there is a better
way to do it.

Thanks,
Mark

                                EPICS support for area detectors
                                          March 6, 2008
                                           Mark Rivers
                                              DRAFT

This  is a proposal for a new EPICS interface to 2-D detectors and
cameras.  The intention is to make an interface that is general enough
to support existing and future detectors.  The types of detectors to be
supported include CCDs for visible light and x-rays, pixel-array
detectors, CMOS cameras, and online image plate detectors.  The goal is
to have EPICS be able to control all detector parameters, and also to
have access to the 2-D detector data.


                                       Existing Software

There are several approaches that have been taken in the past for
cameras.

One is the ccdServer written by Brian Tieman.  This is an application
for control and display of cameras on Microsoft Windows computers.  It
uses the Portable Channel Access server to export its functionality to
EPICS.  This application supports a number of cameras, and hides the
differences between them.  It has been used successfully on a number of
beamlines at the APS.  There are several disadvantages to the ccdServer
approach.
* Requires implementing the user-interface for controlling the camera.
In many cases the vendor has already supplied a sophisticated user
interface which has more features than ccdServer, and which cannot be
used when ccdServer is being used.
* Uses the Portable Channel Access server which may not be supported in
the future.  It has a limit of 16,000 bytes for channel access data,
preventing convenient transmission of image data over channel access.
* Is limited to Windows, so cameras such as the MAR-CCD and MAR-345
cannot be supported.

I have written the "ccd" module
(http://cars9.uchicago.edu/software/epics/ccd.html) in synApps that
attempts to be device independent with a common database for all
cameras.  This database consists entirely of soft device support.  There
are separate SNL programs for each camera type that implement the logic
for the database.  The ccd module contains SNL support for cameras from
Roper Scientific and the MAR-CCD.  The Roper Scientific support uses a
TCP/IP socket server that is part of the ccd module.  It calls the
Microsfot OLE/COM interface to control WinView, the vendor supplied
user-interface program.  The MAR-CCD support uses the
marccd_server_socket that the vendor provides for remote control of
their marCCD program.

The problems with the ccd module include:
* EPICS does not have access to the image data, it just controls the
acquisition.  This is largely historical, since ccd was written in the
days of EPICS R3.13, when large arrays were not supported in Channel
Access.
* Using soft device support and SNL lacks features compared to real
EPICS device support, including things like putting records into alarm
state, etc.
* It does not currently implement features like software regions of
interest (ROIs), because the SNL code does not have access to the image
data.

I have also written a separate synApps module called pilatusROI
(http://cars9.uchicago.edu/software/epics/pilatusROI.html) to control
the new Pilatus pixel-array detector from Dectris.  Because this
detector has many features that the ccd module did not support, I used a
different database, and added many features, like multiple ROIs that the
ccd module does not support.  The pilatusROI software does make the
image data available to EPICS, and this has proven to be very useful,
since it can be displayed on any computer on the network.


                                  Proposed New Approach

Because of the limitations on the existing approaches I would like to
propose a new model.  This model follows the one that has recently been
adopted for the EPICS motor record with asyn device and driver support.
It is also similar to the approach that has been used for a number of
years for 1-D detectors in the synApps "mca" module, except that mca
used a custom mca record, while I propose to use only standard EPICS
records for area detectors.

The proposed architecture from the bottom layer up is the following

1. Vendor supplied library or interface to application.  This includes
the Prosilica API for their Gigabit Ethernet cameras, the OLE/COM
interface to WinView for Roper Scientific cameras, and the socket
interfaces to the MAR-CCD, MAR-345, and Pilatus detectors.

2. A device-dependent C API on top of the vendor library that implements
methods like setIntegerProperty, setDoubleProperty, getImageData, etc.
If the image data can be accessed via the API then that will be done,
otherwise the image data will be accessed by reading the disk files that
the vendor software creates.  The functions in this API are all that
need to be written when supporting a new camera.

3. An asyn driver that implements the standard asyn interfaces
(asynInt32, asynFloat64, etc.) and that calls the API at level 2.  This
layer will be device-independent.

4. asyn device support for standard EPICS records.

5. EPICS database that is common to all detectors.  There will be
records in this database that are not used by detectors that don't
implement all features.

6. Optional EPICS database that implements features unique to a specific
detector.

7. EPICS SNL programs for coordinating complex tasks like synchronizing
shutters.

I propose to implement this new model for the following detectors:
* Roper Scientific cameras using the OLE/COM interface to WinView
* MAR-CCD detectors using the socket server (or perhaps another server I
would write)
* MAR-345 using the socket server provided in the MAR-DTB program
* Pilatus detector using the socket server provided by camserver
* Prosilica Gigabit Ethernet cameras using their API.  Note that when
the GenICam (http://www.genicam.org/) vendor-independent library for
GigE, Firewire, USB and CameraLink cameras becomes available later this
year I will probably try to use that instead.