From fe8e0336193d9b0249dead66438dd8e7302466e9 Mon Sep 17 00:00:00 2001 From: rivers Date: Wed, 19 Aug 2009 13:46:19 +0000 Subject: [PATCH] Updated for R1-5 git-svn-id: https://subversion.xor.aps.anl.gov/synApps/areaDetector/trunk@9337 dc6c5ff5-0b8b-c028-a01f-ffb33f00fc8b --- documentation/FirewireWinDoc.html | 2314 ++++++++++++----------- documentation/Mar345Doc.html | 1262 ++++++------ documentation/MarCCDDoc.html | 1739 ++++++++--------- documentation/NDPluginColorConvert.html | 107 +- documentation/NDPluginFile.html | 55 +- documentation/NDPluginROI.html | 158 +- documentation/NDPluginStdArrays.html | 2 +- documentation/PerkinElmerDoc.html | 22 +- documentation/RoperDoc.html | 150 +- documentation/pilatusDoc.html | 192 +- documentation/prosilicaDoc.html | 79 +- documentation/pvcamDoc.html | 378 ++-- documentation/simDetectorDoc.html | 294 +-- 13 files changed, 3235 insertions(+), 3517 deletions(-) diff --git a/documentation/FirewireWinDoc.html b/documentation/FirewireWinDoc.html index 6231339..7e83a42 100755 --- a/documentation/FirewireWinDoc.html +++ b/documentation/FirewireWinDoc.html @@ -1,1160 +1,1162 @@ - - - Firewire IIDC (CDAM) Windows driver - - - -
-

- Firewire IIDC (CDAM) Windows driver

-

- August 17, 2009

-

- Mark Rivers

-

- University of Chicago

-
-

- Table of Contents

- -

- Introduction

-

- This is a driver for Firewire (IEEE 1394) cameras that follow the - IIDC/DCAM specification. This industry standard allows a single driver to - control cameras from any manufacturer, using any of the supported video formats - and features. It inherits from ADDriver and implements many of the parameters in - asynNDArrayDriver.h and ADDriver.h. It also implements a number of parameters that - are specific to the Firewire cameras.

-

- This driver runs only on Windows. It uses the - Carnegie Mellon 1394 camera driver and library. There is also an areaDetector - Firewire driver for Linux available from the - Diamond Light Source. -

-

- This driver inherits from ADDriver. The - firewireWinDCAM class documentation describes this class in detail.

-

- The IIDC/DCAM specification defines standard ways that manufacturers must implement - features like shutter time, white balance, frame sizes, frame rates, etc. There - is a standard way to determine whether or not a particular camera supports a particular - feature. If it does then there is a standard way of querying the allowed range of - values for that feature. This makes it quite easy to write a driver that can support - cameras with any capabilities from any manufacturer.

-

- Video formats, modes, and frame rates

-

- The DCAM specification defines standard video frame sizes, color modes and frames - rates. The following tables lists these standard formats and mode. Video format - 7 is special. It allows defining an ROI on the camera to read out. The pixel resolution - with which the size and position of this ROI can be defined can be queried, and - is not necessarily a single pixel. In Format 7 the frame rate settings do not apply, - and the frame rate is determined by the size of the Fireware data packets.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Standard IIDC/DCAM Video Formats and Video Modes
- Format Number - Format Description - Mode Number - Mode Description
- 0 - VGA
- 0 - 160x120 YUV444
- 1 - 320x240 YUV422
- 2 - 640x480 YUV411
- 3 - 640X480 YUV422
- 4 - 640x480 RGB
- 5 - 640x480 Mono8
- 6 - 640x480 Mono16
- 7 - Reserved
- 1 - Super-VGA1
- 0 - 800x600 YUV422
- 1 - 800x600 RGB
- 2 - 800x600 Mono8
- 3 - 1024x768 YUV422
- 4 - 1024x768 RGB
- 5 - 1024x768 Mono8
- 6 - 800x600 Mono16
- 7 - 1024x768 Mono16
- 2 - Super-VGA2
- 0 - 1280x960 YUV422
- 1 - 1280x960 RGB
- 2 - 1280x960 Mono8
- 3 - 1600x1200 YUV422
- 4 - 1600x1200 RGB
- 5 - 1600x1200 Mono8
- 6 - 1280x960 Mono16
- 7 - 1600x1200 Mono16
- 3-5 - Reserved
- 0-7 - Reserved
- 6 - Still image
- 0 - Exif
- 1-7 - Reserved
- 7 - Partial Image (user-defineable ROI)
- 0-7 - Vendor-defined
-

- The following tables lists the standard frame rates for formats 0, 1 and 2. Note - that not all frame rates are supported by the IIDC standard for every format and - mode, and even when a frame rate is supported by the standard it may not be implemented - for a particular camera. In Format 7 the frame rate settings do not apply, and the - frame rate is determined by the size of the Fireware data packets. The areaDetector - driver currently sets the Format 7 packet size to the vendor recommended size, which - typically results in the maximum possible frame rate.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Standard IIDC/DCAM Video Frame Rates
- Frame Rate Number - Frame Rate (Frames/second)
- 0 - 1.875
- 1 - 3.75
- 2 - 7.5
- 3 - 15
- 4 - 30
- 5 - 60
- 6 - 120
- 7 - 240
-

- The DCAM specification defines 22 standard features, which control things such as - the brightness, white balance, shutter time, etc.. For each feature the standard - defines control in both device units (12-bit integers) and absolute units (floating - point). For example shutter time may support absolute seconds, as well as device - units. A feature may or may not be supported on a particular camera. If it is supported - it may or may not permit control in absolute units. Each feature may support both - manual control and automatic control (e.g. automatic gain control). The following - tables lists these standard features.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Standard IIDC/DCAM Features
- Feature Number - Feature Description - EPICS record string for firewireFeature.template
- 0 - Brightness - BRIGHTNESS
- 1 - Auto exposure - EXPOSURE
- 2 - Sharpness - SHARPNESS
- 3 - White balance (color tint) - WHITEB
- 4 - Hue (color tint) - HUE
- 5 - Saturation (color saturation) - SATURATION
- 6 - Gamma (response curve) - GAMMA
- 7 - Shutter (exposure time) - SHUTTER
- 8 - Gain (amplification) - GAIN
- 9 - Iris - IRIS
- 10 - Focus - FOCUS
- 11 - Temperature - TEMP
- 12 - Trigger mode - TRIGGER
- 13 - Trigger delay - TRIGDLY
- 14 - White shading - WHITES
- 15 - Frame rate - FRAMERATE
- 16 - Zoom - ZOOM
- 17 - Pan - PAN
- 18 - Tilt - TILT
- 19 - Optical filter - FILTER
- 20 - Capture size - CAPTSIZE
- 21 - Capture quality - QUALITY
-

- Firewire specific parameters

-

- The firewireWinDCAM driver implements the following parameters in addition to those - in asynNDArrayDriver.h and ADDriver.hh. Note that to reduce the width of this table - the enum names have been split into 2 lines, but these are just a single name, for - example mar345ScanSize. -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Parameter Definitions in firewireWinDCAM.cpp and EPICS Record Definitions
- Enum name - asyn interface - Access - Description - drvUser string - EPICS record name - EPICS record type
- Video format parameters. In firewireDCAM.template and firewireVideoModes.template.
- FDC_
- format
- asynInt32 - r/w - The video format. The allowed choices are 0="VGA", 1="Super VGA 1", 2="Super VGA - 2", 6="Still image", 7="User-defined". The FDC_has_format and FDC_valid_format parameters - described below indicate whether a particular format is actually supported by the - camera. - FDC_FORMAT - $(P)$(R)FORMAT
- $(P)$(R)FORMAT_RBV
- mbbo -
- mbbi -
- FDC_
- has_format
- asynInt32 - r/o - A flag indicating whether a particular format (0-7) is supported by the camera. - FDC_HAS_FORMAT - $(P)$(R)HAS_FORMAT_$(N) (N=0-7) - bi -
- FDC_
- valid_format
- asynOctet - r/o - A string describing each of the formats (0-7) supported by the camera. The string - is "N.A." if the format is not supported. - FDC_VALID_FORMAT - $(P)$(R)VALID_FORMAT_$(N) (N=0-7) - stringin -
- FDC_
- current_format
- asynOctet - r/o - A string describing the currently selected video format. - FDC_CURRENT_FORMAT - $(P)$(R)CURRENT_FORMAT - stringin -
- Video mode parameters. In firewireDCAM.template and firewireVideoModes.template.
- FDC_
- mode
- asynInt32 - r/w - The video mode. The allowed choices are 0-7. The FDC_has_mode and FDC_valid_mode - parameters described below indicate whether a particular mode is actually supported - by the camera in the currently selected video format. - FDC_MODE - $(P)$(R)MODE
- $(P)$(R)MODE_RBV
- mbbo -
- mbbi -
- FDC_
- has_mode
- asynInt32 - r/o - A flag indicating whether a particular mode (0-7) is supported by the camera in - the currently selected format. - FDC_HAS_MODE - $(P)$(R)HAS_MODE_$(N) (N=0-7) - bi -
- FDC_
- valid_mode
- asynOctet - r/o - A string describing each of the modes (0-7) supported by the camera in the currently - selected video format. The string is "N.A." if the mode is not supported in this - format. - FDC_VALID_MODE - $(P)$(R)VALID_MODE_$(N) (N=0-7) - stringin -
- FDC_
- current_mode
- asynOctet - r/o - A string describing the currently selected video mode. - FDC_CURRENT_MODE - $(P)$(R)CURRENT_MODE - stringin -
- Video frame rate parameters. These parameters do not apply when the video format=7. - In firewireDCAM.template and firewireVideoModes.template.
- FDC_
- framerate
- asynInt32 - r/w - The frame rate in frames/second. The allowed choices are 0="1.875", 1="3.75", 2="7.5", - 3="15", 4="30", 5="60", 6="120", 7="240". FDC_has_framerate and FDC_valid_framerate - parameters described below indicate whether a particular frame rate is actually - supported by the camera in the currently selected video format and mode. - FDC_FRAMERATE - $(P)$(R)FR
- $(P)$(R)FR_RBV
- mbbo -
- mbbi -
- FDC_
- has_framerate
- asynInt32 - r/o - A flag indicating whether a particular frame rate (0-7) is supported by the camera - in the currently selected video format and mode. - FDC_HAS_FRAMERATE - $(P)$(R)HAS_RATE_$(N) (N=0-7) - bi -
- FDC_
- valid_framerate
- asynOctet - r/o - A string describing each of the frame rates (0-7) supported by the camera in the - currently selected video format and mode. The string is "N.A." if the frame rate - is not supported in this format and mode. - FDC_VALID_FRAMERATE - $(P)$(R)VALID_RATE_$(N) (N=0-7) - stringin -
- FDC_
- current_framerate
- asynOctet - r/o - A string describing the currently selected video frame rate. - FDC_CURRENT_FRAMERATE - $(P)$(R)CURRENT_RATE - stringin -
- Video color code parameters. These parameters only apply when the video format=7. - In firewireDCAM.template and firewireColorCodes.template.
- FDC_
- colorcode
- asynInt32 - r/w - The color code. The allowed choices are 0-10. FDC_has_colorcode and FDC_valid_colorcode - parameters described below indicate whether a particular color code is actually - supported by the camera in the currently selected video format (7) and mode. - FDC_COLORCODE - $(P)$(R)COLORCODE
- $(P)$(R)COLORCODE_RBV
- mbbo -
- mbbi -
- FDC_
- has_colorcode
- asynInt32 - r/o - A flag indicating whether a particular color code (0-10) is supported by the camera - in the currently selected video format (7) and mode. - FDC_HAS_COLORCODE - $(P)$(R)HAS_COLORCODE_$(N) (N=0-10) - bi -
- FDC_
- valid_colorcode
- asynOctet - r/o - A string describing each of the color codes (0-10) supported by the camera in the - currently selected video format (7) and mode. The string is "N.A." if the color - code is not supported in this format and mode. - FDC_VALID_COLORCODE - $(P)$(R)VALID_COLORCODE_$(N) (N=0-10) - stringin -
- FDC_
- current_colorcode
- asynOctet - r/o - A string describing the currently selected color code. - FDC_CURRENT_COLORCODE - $(P)$(R)CURRENT_COLORCODE - stringin -
- Video feature parameters. These parameters apply to each of the 22 DCAM features - listed above. In firewireFeature.template.
- FDC_
- feat_val
- asynInt32 - r/w - The feature value in device units. - FDC_FEAT_VAL - $(P)$(R)$(FEATURE)
- $(P)$(R)$(FEATURE)_RBV
- ao -
- ai -
- FDC_
- feat_val_abs
- asynFloat64 - r/w - The feature value in absolute units. - FDC_FEAT_VAL_ABS - $(P)$(R)$(FEATURE)_ABS
- $(P)$(R)$(FEATURE)_ABS_RBV
- ao -
- ai -
- FDC_
- feat_available
- asynInt32 - r/o - A flag indicating if the feature is available. - FDC_FEAT_AVL - $(P)$(R)$(FEATURE)_AVL - bi -
- FDC_
- feat_absolute
- asynInt32 - r/o - A flag indicating if absolute control of the feature is available. - FDC_FEAT_ABSOLUTE - $(P)$(R)$(FEATURE)_ABS_AVL - bi -
- FDC_
- feat_mode
- asynInt32 - r/o - Selects manual (0) or automatic (1) control of the feature. - FDC_FEAT_MODE - $(P)$(R)$(FEATURE)_CTRL
- $(P)$(R)$(FEATURE)_CTRL_RBV
- bo -
- bi -
- FDC_
- feat_val_min
- asynInt32 - r/o - The minimum allowed value of the feature in device units. The database copies this - value to the LOPR and DRVL fields of the $(P)$(R)$(FEATURE) record. - FDC_FEAT_VAL_MIN - $(P)$(R)$(FEATURE)_MIN - ai -
- FDC_
- feat_val_max
- asynInt32 - r/o - The maximum allowed value of the feature in device units. The database copies this - value to the HOPR and DRVH fields of the $(P)$(R)$(FEATURE) record. - FDC_FEAT_VAL_MAX - $(P)$(R)$(FEATURE)_MAX - ai -
- FDC_
- feat_val_abs_min
- asynInt32 - r/o - The minimum allowed value of the feature in absolute units. The database copies - this value to the LOPR and DRVL fields of the $(P)$(R)$(FEATURE)_ABS record. - FDC_FEAT_VAL_ABS_MIN - $(P)$(R)$(FEATURE)_ABS_MIN - ai -
- FDC_
- feat_val_abs_max
- asynFloat64 - r/o - The maximum allowed value of the feature in absolute units. The database copies - this value to the HOPR and DRVH fields of the $(P)$(R)$(FEATURE)_ABS record. - FDC_FEAT_VAL_ABS_MAX - $(P)$(R)$(FEATURE)_ABS_MAX - ai -
-

- Configuration

-

- The firewireWinDCAM driver is created with the WinFDC_Config command, either from - C/C++ or from the EPICS IOC shell.

+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> + + + Firewire IIDC (CDAM) Windows driver + + + +
+

+ Firewire IIDC (DCAM) Windows driver

+

+ August 17, 2009

+

+ Mark Rivers

+

+ University of Chicago

+
+

+ Table of Contents

+ +

+ Introduction

+

+ This is a driver for Firewire (IEEE 1394) cameras that follow the + IIDC/DCAM specification. This industry standard allows a single driver to + control cameras from any manufacturer, using any of the supported video formats + and features.

+

+ This driver runs only on Windows. It uses the + Carnegie Mellon 1394 camera driver and library. There is also an areaDetector + Firewire driver for Linux available from the + Diamond Light Source. +

+

+ This driver inherits from ADDriver. + It implements many of the parameters in NDStdDriverParam_t (see + asynNDArryDriver.h) and in ADStdDriverParam_t (see + ADArrayDriver.h). It also implements a number of parameters that are specific + to the Firewire cameras. The + firewireWinDCAM class documentation describes this class in detail.

+

+ The IIDC/DCAM specification defines standard ways that manufacturers must implement + features like shutter time, white balance, frame sizes, frame rates, etc. There + is a standard way to determine whether or not a particular camera supports a particular + feature. If it does then there is a standard way of querying the allowed range of + values for that feature. This makes it quite easy to write a driver that can support + cameras with any capabilities from any manufacturer.

+

+ Video formats, modes, and frame rates

+

+ The DCAM specification defines standard video frame sizes, color modes and frames + rates. The following tables lists these standard formats and mode. Video format + 7 is special. It allows defining an ROI on the camera to read out. The pixel resolution + with which the size and position of this ROI can be defined can be queried, and + is not necessarily a single pixel. In Format 7 the frame rate settings do not apply, + and the frame rate is determined by the size of the Fireware data packets.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Standard IIDC/DCAM Video Formats and Video Modes
+ Format Number + Format Description + Mode Number + Mode Description
+ 0 + VGA
+ 0 + 160x120 YUV444
+ 1 + 320x240 YUV422
+ 2 + 640x480 YUV411
+ 3 + 640X480 YUV422
+ 4 + 640x480 RGB
+ 5 + 640x480 Mono8
+ 6 + 640x480 Mono16
+ 7 + Reserved
+ 1 + Super-VGA1
+ 0 + 800x600 YUV422
+ 1 + 800x600 RGB
+ 2 + 800x600 Mono8
+ 3 + 1024x768 YUV422
+ 4 + 1024x768 RGB
+ 5 + 1024x768 Mono8
+ 6 + 800x600 Mono16
+ 7 + 1024x768 Mono16
+ 2 + Super-VGA2
+ 0 + 1280x960 YUV422
+ 1 + 1280x960 RGB
+ 2 + 1280x960 Mono8
+ 3 + 1600x1200 YUV422
+ 4 + 1600x1200 RGB
+ 5 + 1600x1200 Mono8
+ 6 + 1280x960 Mono16
+ 7 + 1600x1200 Mono16
+ 3-5 + Reserved
+ 0-7 + Reserved
+ 6 + Still image
+ 0 + Exif
+ 1-7 + Reserved
+ 7 + Partial Image (user-defineable ROI)
+ 0-7 + Vendor-defined
+

+ The following tables lists the standard frame rates for formats 0, 1 and 2. Note + that not all frame rates are supported by the IIDC standard for every format and + mode, and even when a frame rate is supported by the standard it may not be implemented + for a particular camera. In Format 7 the frame rate settings do not apply, and the + frame rate is determined by the size of the Fireware data packets. The areaDetector + driver currently sets the Format 7 packet size to the vendor recommended size, which + typically results in the maximum possible frame rate.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Standard IIDC/DCAM Video Frame Rates
+ Frame Rate Number + Frame Rate (Frames/second)
+ 0 + 1.875
+ 1 + 3.75
+ 2 + 7.5
+ 3 + 15
+ 4 + 30
+ 5 + 60
+ 6 + 120
+ 7 + 240
+

+ The DCAM specification defines 22 standard features, which control things such as + the brightness, white balance, shutter time, etc.. For each feature the standard + defines control in both device units (12-bit integers) and absolute units (floating + point). For example shutter time may support absolute seconds, as well as device + units. A feature may or may not be supported on a particular camera. If it is supported + it may or may not permit control in absolute units. Each feature may support both + manual control and automatic control (e.g. automatic gain control). The following + tables lists these standard features.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Standard IIDC/DCAM Features
+ Feature Number + Feature Description + EPICS record string for firewireFeature.template
+ 0 + Brightness + BRIGHTNESS
+ 1 + Auto exposure + EXPOSURE
+ 2 + Sharpness + SHARPNESS
+ 3 + White balance (color tint) + WHITEB
+ 4 + Hue (color tint) + HUE
+ 5 + Saturation (color saturation) + SATURATION
+ 6 + Gamma (response curve) + GAMMA
+ 7 + Shutter (exposure time) + SHUTTER
+ 8 + Gain (amplification) + GAIN
+ 9 + Iris + IRIS
+ 10 + Focus + FOCUS
+ 11 + Temperature + TEMP
+ 12 + Trigger mode + TRIGGER
+ 13 + Trigger delay + TRIGDLY
+ 14 + White shading + WHITES
+ 15 + Frame rate + FRAMERATE
+ 16 + Zoom + ZOOM
+ 17 + Pan + PAN
+ 18 + Tilt + TILT
+ 19 + Optical filter + FILTER
+ 20 + Capture size + CAPTSIZE
+ 21 + Capture quality + QUALITY
+

+ Firewire specific parameters

+

+ The firewireWinDCAM driver implements the following parameters in addition to those + in asynNDArrayDriver.h and ADDriver.hh. Note that to reduce the width of this table + the enum names have been split into 2 lines, but these are just a single name, for + example mar345ScanSize. +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Parameter Definitions in firewireWinDCAM.cpp and EPICS Record Definitions
+ Enum name + asyn interface + Access + Description + drvUser string + EPICS record name + EPICS record type
+ Video format parameters. In firewireDCAM.template and firewireVideoModes.template.
+ FDC_
+ format
+ asynInt32 + r/w + The video format. The allowed choices are 0="VGA", 1="Super VGA 1", 2="Super VGA + 2", 6="Still image", 7="User-defined". The FDC_has_format and FDC_valid_format parameters + described below indicate whether a particular format is actually supported by the + camera. + FDC_FORMAT + $(P)$(R)FORMAT
+ $(P)$(R)FORMAT_RBV
+ mbbo +
+ mbbi +
+ FDC_
+ has_format
+ asynInt32 + r/o + A flag indicating whether a particular format (0-7) is supported by the camera. + FDC_HAS_FORMAT + $(P)$(R)HAS_FORMAT_$(N) (N=0-7) + bi +
+ FDC_
+ valid_format
+ asynOctet + r/o + A string describing each of the formats (0-7) supported by the camera. The string + is "N.A." if the format is not supported. + FDC_VALID_FORMAT + $(P)$(R)VALID_FORMAT_$(N) (N=0-7) + stringin +
+ FDC_
+ current_format
+ asynOctet + r/o + A string describing the currently selected video format. + FDC_CURRENT_FORMAT + $(P)$(R)CURRENT_FORMAT + stringin +
+ Video mode parameters. In firewireDCAM.template and firewireVideoModes.template.
+ FDC_
+ mode
+ asynInt32 + r/w + The video mode. The allowed choices are 0-7. The FDC_has_mode and FDC_valid_mode + parameters described below indicate whether a particular mode is actually supported + by the camera in the currently selected video format. + FDC_MODE + $(P)$(R)MODE
+ $(P)$(R)MODE_RBV
+ mbbo +
+ mbbi +
+ FDC_
+ has_mode
+ asynInt32 + r/o + A flag indicating whether a particular mode (0-7) is supported by the camera in + the currently selected format. + FDC_HAS_MODE + $(P)$(R)HAS_MODE_$(N) (N=0-7) + bi +
+ FDC_
+ valid_mode
+ asynOctet + r/o + A string describing each of the modes (0-7) supported by the camera in the currently + selected video format. The string is "N.A." if the mode is not supported in this + format. + FDC_VALID_MODE + $(P)$(R)VALID_MODE_$(N) (N=0-7) + stringin +
+ FDC_
+ current_mode
+ asynOctet + r/o + A string describing the currently selected video mode. + FDC_CURRENT_MODE + $(P)$(R)CURRENT_MODE + stringin +
+ Video frame rate parameters. These parameters do not apply when the video format=7. + In firewireDCAM.template and firewireVideoModes.template.
+ FDC_
+ framerate
+ asynInt32 + r/w + The frame rate in frames/second. The allowed choices are 0="1.875", 1="3.75", 2="7.5", + 3="15", 4="30", 5="60", 6="120", 7="240". FDC_has_framerate and FDC_valid_framerate + parameters described below indicate whether a particular frame rate is actually + supported by the camera in the currently selected video format and mode. + FDC_FRAMERATE + $(P)$(R)FR
+ $(P)$(R)FR_RBV
+ mbbo +
+ mbbi +
+ FDC_
+ has_framerate
+ asynInt32 + r/o + A flag indicating whether a particular frame rate (0-7) is supported by the camera + in the currently selected video format and mode. + FDC_HAS_FRAMERATE + $(P)$(R)HAS_RATE_$(N) (N=0-7) + bi +
+ FDC_
+ valid_framerate
+ asynOctet + r/o + A string describing each of the frame rates (0-7) supported by the camera in the + currently selected video format and mode. The string is "N.A." if the frame rate + is not supported in this format and mode. + FDC_VALID_FRAMERATE + $(P)$(R)VALID_RATE_$(N) (N=0-7) + stringin +
+ FDC_
+ current_framerate
+ asynOctet + r/o + A string describing the currently selected video frame rate. + FDC_CURRENT_FRAMERATE + $(P)$(R)CURRENT_RATE + stringin +
+ Video color code parameters. These parameters only apply when the video format=7. + In firewireDCAM.template and firewireColorCodes.template.
+ FDC_
+ colorcode
+ asynInt32 + r/w + The color code. The allowed choices are 0-10. FDC_has_colorcode and FDC_valid_colorcode + parameters described below indicate whether a particular color code is actually + supported by the camera in the currently selected video format (7) and mode. + FDC_COLORCODE + $(P)$(R)COLORCODE
+ $(P)$(R)COLORCODE_RBV
+ mbbo +
+ mbbi +
+ FDC_
+ has_colorcode
+ asynInt32 + r/o + A flag indicating whether a particular color code (0-10) is supported by the camera + in the currently selected video format (7) and mode. + FDC_HAS_COLORCODE + $(P)$(R)HAS_COLORCODE_$(N) (N=0-10) + bi +
+ FDC_
+ valid_colorcode
+ asynOctet + r/o + A string describing each of the color codes (0-10) supported by the camera in the + currently selected video format (7) and mode. The string is "N.A." if the color + code is not supported in this format and mode. + FDC_VALID_COLORCODE + $(P)$(R)VALID_COLORCODE_$(N) (N=0-10) + stringin +
+ FDC_
+ current_colorcode
+ asynOctet + r/o + A string describing the currently selected color code. + FDC_CURRENT_COLORCODE + $(P)$(R)CURRENT_COLORCODE + stringin +
+ Video feature parameters. These parameters apply to each of the 22 DCAM features + listed above. In firewireFeature.template.
+ FDC_
+ feat_val
+ asynInt32 + r/w + The feature value in device units. + FDC_FEAT_VAL + $(P)$(R)$(FEATURE)
+ $(P)$(R)$(FEATURE)_RBV
+ ao +
+ ai +
+ FDC_
+ feat_val_abs
+ asynFloat64 + r/w + The feature value in absolute units. + FDC_FEAT_VAL_ABS + $(P)$(R)$(FEATURE)_ABS
+ $(P)$(R)$(FEATURE)_ABS_RBV
+ ao +
+ ai +
+ FDC_
+ feat_available
+ asynInt32 + r/o + A flag indicating if the feature is available. + FDC_FEAT_AVL + $(P)$(R)$(FEATURE)_AVL + bi +
+ FDC_
+ feat_absolute
+ asynInt32 + r/o + A flag indicating if absolute control of the feature is available. + FDC_FEAT_ABSOLUTE + $(P)$(R)$(FEATURE)_ABS_AVL + bi +
+ FDC_
+ feat_mode
+ asynInt32 + r/o + Selects manual (0) or automatic (1) control of the feature. + FDC_FEAT_MODE + $(P)$(R)$(FEATURE)_CTRL
+ $(P)$(R)$(FEATURE)_CTRL_RBV
+ bo +
+ bi +
+ FDC_
+ feat_val_min
+ asynInt32 + r/o + The minimum allowed value of the feature in device units. The database copies this + value to the LOPR and DRVL fields of the $(P)$(R)$(FEATURE) record. + FDC_FEAT_VAL_MIN + $(P)$(R)$(FEATURE)_MIN + ai +
+ FDC_
+ feat_val_max
+ asynInt32 + r/o + The maximum allowed value of the feature in device units. The database copies this + value to the HOPR and DRVH fields of the $(P)$(R)$(FEATURE) record. + FDC_FEAT_VAL_MAX + $(P)$(R)$(FEATURE)_MAX + ai +
+ FDC_
+ feat_val_abs_min
+ asynInt32 + r/o + The minimum allowed value of the feature in absolute units. The database copies + this value to the LOPR and DRVL fields of the $(P)$(R)$(FEATURE)_ABS record. + FDC_FEAT_VAL_ABS_MIN + $(P)$(R)$(FEATURE)_ABS_MIN + ai +
+ FDC_
+ feat_val_abs_max
+ asynFloat64 + r/o + The maximum allowed value of the feature in absolute units. The database copies + this value to the HOPR and DRVH fields of the $(P)$(R)$(FEATURE)_ABS record. + FDC_FEAT_VAL_ABS_MAX + $(P)$(R)$(FEATURE)_ABS_MAX + ai +
+

+ Configuration

+

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

WinFDC_Config(const char *portName, const char* camid, 
               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 WinFDC_Config function in the - firewireWinDCAM.cpp documentation and in the documentation for the constructor - for the FirewireWinDCAM - class. -

-

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

-

- MEDM screens

-

- The following show the MEDM screens that are used to control the Firewire detectors. - Note that the general purpose screen ADBase.adl must be used to control many features, - but it exposes some controls that are not applicable to Firewire cameras, and lacks - many fields that are important for such cameras. A new Firewire-specific top-level - control screen will be added in a future release.

-

- firewireFeatures.adl is the screen used to control the features of - Firewire cameras. -

-
-

- firewireFeatures.adl

- firewireFeatures.png
-

- firewireVideoFormats.adl is the screen used to control the video formats - and modes of Firewire cameras. This is a screen shot when the camera is not in Format - 7. -

-
-

- firewireVideoFormats.adl

- firewireVideoFormats.png
-

- firewireVideoFormats.adl is the screen used to control the video formats - and modes of Firewire cameras. This is a screen shot when the camera is in Format - 7, in which case the video rate menu is not displayed. -

-
-

- firewireVideoFormats.adl

- firewireVideoFormatsFormat7.png
- - + +

+ For details on the meaning of the parameters to this function refer to the detailed + documentation on the WinFDC_Config function in the + firewireWinDCAM.cpp documentation and in the documentation for the constructor + for the FirewireWinDCAM + class. +

+

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

+

+ MEDM screens

+

+ The following show the MEDM screens that are used to control the Firewire detectors. + Note that the general purpose screen ADBase.adl must be used to control many features, + but it exposes some controls that are not applicable to Firewire cameras, and lacks + many fields that are important for such cameras. A new Firewire-specific top-level + control screen will be added in a future release.

+

+ firewireFeatures.adl is the screen used to control the features of + Firewire cameras. +

+
+

+ firewireFeatures.adl

+ firewireFeatures.png
+

+ firewireVideoFormats.adl is the screen used to control the video formats + and modes of Firewire cameras. This is a screen shot when the camera is not in Format + 7. +

+
+

+ firewireVideoFormats.adl

+ firewireVideoFormats.png
+

+ firewireVideoFormats.adl is the screen used to control the video formats + and modes of Firewire cameras. This is a screen shot when the camera is in Format + 7, in which case the video rate menu is not displayed. +

+
+

+ firewireVideoFormats.adl

+ firewireVideoFormatsFormat7.png
+ + diff --git a/documentation/Mar345Doc.html b/documentation/Mar345Doc.html index a1d9aab..5917044 100755 --- a/documentation/Mar345Doc.html +++ b/documentation/Mar345Doc.html @@ -1,635 +1,637 @@ - - - areaDetector mar345 driver - - - -
-

- areaDetector mar345 driver

-

- August 17, 2009

-

- Mark Rivers

-

- University of Chicago

-
-

- Table of Contents

- -

- Introduction

-

- This is a driver for the mar345 detector from - Marresearch GmbH. It implements many of the parameters in asynNDArrayDriver.h - and ADDriver.h. It also implements a number of parameters that are specific to the - mar345 detector.

-

- The interface to the detector is via a TCP/IP socket interface to the mar345dtb - program that Marresearch provides. The mar345dtb program must be started before - the areaDetector software is started. -

-

- mar345dtb must be configured to accepts commands on a TCP/IP socket port. This is - done by editing the file /home/mar345/tables/config.xxx (where xxx is the serial - number of that detector) and editing the COMMAND line to the following format:

+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> + + + areaDetector mar345 driver + + + +
+

+ areaDetector mar345 driver

+

+ August 17, 2009

+

+ Mark Rivers

+

+ University of Chicago

+
+

+ Table of Contents

+ +

+ Introduction

+

+ This is a driver for the mar345 detector from + Marresearch GmbH.

+

+ The interface to the detector is via a TCP/IP socket interface to the mar345dtb + program that Marresearch provides. The mar345dtb program must be started before + the areaDetector software is started. +

+

+ mar345dtb must be configured to accepts commands on a TCP/IP socket port. This is + done by editing the file /home/mar345/tables/config.xxx (where xxx is the serial + number of that detector) and editing the COMMAND line to the following format:

COMMAND PORT 5001
-    
-

- where 5001 is the TCP/IP port to use. Any high port number can be used, but it must - agree with the one specified in the areaDetector mar345Config command described - below.

-

- The mar345dtb program saves the data to disk as compressed binary files. The areaDetector - software reads these disk files in order to read the data, because mar345dtb does - not provide another mechanism to access the data. -

-

- This driver inherits from ADDriver. The - mar345 class documentation describes this class in detail.

-

- Implementation of standard driver parameters

-

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

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Implementation of Parameters in asynNDArrayDriver.h and ADDriver.h, and EPICS Record - Definitions in ADBase.template and NDFile.template
- Enum name - EPICS record name - Description
- ADAcquire - $(P$(R)Acquire - Setting this to 1 starts an acquisition sequence. If ADNumImages is greater than - 1 then it acquires multiple frames. For each frame it does the following: -
    -
  1. Erases the detector if mar345EraseMode is "Before expose".
  2. -
  3. Opens the shutter if either the mar345 shutter or EPICS shutter controls are enabled.
  4. -
  5. Waits for the desired exposure time.
  6. -
  7. Closes the shutter if either the mar345 shutter or EPICS shutter controls are - enabled.
  8. -
  9. Scans the detector and saves the file.
  10. -
  11. Erases the detector if mar345EraseMode is "After scan".
  12. -
- If ADAcquire is set to 0 during exposure (step 3 above) then it proceeds immediately - to step 4, finishes collecting the current frame and stops the acquisition sequence - if ADNumImages is greater than 1. If mar345Abort is set to 0 then the acquisition - is terminated as soon as possible without saving the data. Note however that commands - to the mar345 server to erase, change mode, or scan cannot be aborted, so the driver - must wait for these commands to complete. -
- ADNumImages - $(P$(R)NumImages - Controls the number of images to acquire when ADImageMode is ADImageMultiple.
- ADAcquirePeriod - $(P$(R)AcquirePeriod - Controls the period between images when ADImageMode is ADImageMultiple or ADImageContinuous. - If this is greater than the acquisition time plus readout overhead then the driver - will wait until the period has elapsed before starting the next acquisition.
- NDFilePath - $(P$(R)FilePath - Controls the path for saving images. It must be a valid path for mar345dtb and - for the areaDetector driver, which is normally running in an EPICS IOC. If mar345dtb - and the EPICS IOC are not running on the same machine then soft links will typically - be used to make the paths look identical.
- NDFileFormat - $(P)$(R)FileFormat - mar345 only supports mar345 format binary files. -
- NDStatus - $(P)$(R)DetectorState_RBV - mar345 replaces the state strings with the following: Exposing, Scanning, Erasing, - Changing Mode, Aborting, Error, and Waiting. -
-

- It is useful to use NDPluginROI to define an ROI containing the entire mar345 detector. - The MaxValue_RBV PV in this ROI can be monitored to make sure that the 16-bit limit - of 65,535 is not being approached in any pixel. -

-

- mar345 specific parameters

-

- The mar345 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 enum names have - been split into 2 lines, but these are just a single name, for example mar345ScanSize. -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Parameter Definitions in mar345.cpp and EPICS Record Definitions in mar345.template
- Enum name - asyn interface - Access - Description - drvUser string - EPICS record name - EPICS record type
- Readout parameters
- mar345
- ScanSize
- asynInt32 - r/w - The detector diameter to read out. Choices are 180mm, 240mm, 300mm, and 345mm. - MAR_SIZE - $(P)$(R)ScanSize
- $(P)$(R)ScanSize_RBV
- mbbo -
- mbbi -
- mar345
- ScanResolution
- asynInt32 - r/w - The pixel size to use when reading the detector out. Choices are 0.10 and 0.15mm. - MAR_RESOLUTION - $(P)$(R)ScanResolution
- $(P)$(R)ScanResolution_RBV
- mbbo -
- mbbi -
- mar345
- ChangeMode
- asynInt32 - r/w - Writing 1 to this parameter causes the ScanSize and ScanResolution values to be - sent to the server, changing the scan mode. This is not strictly necessary, because - the size and resolution is also encoded in the file extension used in the scan command. - However, changing the mode before doing a scan reduces the time for the scan, because - the detector is already configured for the correct mode. - MAR_CHANGE_MODE - $(P)$(R)ChangeMode
- $(P)$(R)ChangedMode_RBV
- busy -
- bi -
- Erase parameters
- mar345
- EraseMode
- asynInt32 - r/w - Controls whether an erase cycle should be automatically performed during acquisition. - Choices are None, Before expose, and After scan. - MAR_ERASE_MODE - $(P)$(R)EraseMode
- $(P)$(R)EraseMode_RBV
- mbbo -
- mbbi -
- mar345
- NumErase
- asynInt32 - r/w - The number of erase cycles to perform each time the detector is erased, either because - the mar345Erase parameter is set to 1, or because of an automatic erase as part - of an acquisition. - MAR_NUM_ERASE - $(P)$(R)NumErase
- $(P)$(R)NumErase_RBV
- longout -
- longin -
- mar345
- Erase
- asynInt32 - r/w - Write 1 to this parameter to initiate erasing the detector. The detector will be - erased multiple times if mar345NumErase is greater than 1. - MAR_ERASE - $(P)$(R)Erase
- $(P)$(R)Erase_RBV
- busy -
- bi -
- Abort parameters
- mar345
- Abort
- asynInt32 - r/w - Writing 1 to this parameter aborts the current operation as soon as possible and - returns the driver to the idle state. Note however that commands to the mar345 server - cannot be aborted, so the driver must wait for the current command to complete. - MAR_ABORT - $(P)$(R)Abort
- $(P)$(R)Abort_RBV
- bo -
- bi -
- Debugging
- N/A - N/A - N/A - asyn record to control debugging communication with mar345dtb program - N/A - $(P)$(R)marSserverAsyn - asyn
-

- Unsupported standard driver parameters

-

- The mar345 driver does not support the following standard driver parameters because - they are not supported in the mar345dtb program:

- -

- Configuration

-

- The mar345 driver is created with the mar345Config command, either from C/C++ or - from the EPICS IOC shell.

+ +

+ where 5001 is the TCP/IP port to use. Any high port number can be used, but it must + agree with the one specified in the areaDetector mar345Config command described + below.

+

+ The mar345dtb program saves the data to disk as compressed binary files. The areaDetector + software reads these disk files in order to read the data, because mar345dtb does + not provide another mechanism to access the data. +

+

+ This driver inherits from ADDriver. + It implements many of the parameters in NDStdDriverParam_t (see + asynNDArryDriver.h) and in ADStdDriverParam_t (see + ADArrayDriver.h). It also implements a number of parameters that are specific + to the mar345 detector. The mar345 + class documentation describes this class in detail.

+

+ Implementation of standard driver parameters

+

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

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Implementation of Parameters in asynNDArrayDriver.h and ADDriver.h, and EPICS Record + Definitions in ADBase.template and NDFile.template
+ Enum name + EPICS record name + Description
+ ADAcquire + $(P$(R)Acquire + Setting this to 1 starts an acquisition sequence. If ADNumImages is greater than + 1 then it acquires multiple frames. For each frame it does the following: +
    +
  1. Erases the detector if mar345EraseMode is "Before expose".
  2. +
  3. Opens the shutter if either the mar345 shutter or EPICS shutter controls are enabled.
  4. +
  5. Waits for the desired exposure time.
  6. +
  7. Closes the shutter if either the mar345 shutter or EPICS shutter controls are + enabled.
  8. +
  9. Scans the detector and saves the file.
  10. +
  11. Erases the detector if mar345EraseMode is "After scan".
  12. +
+ If ADAcquire is set to 0 during exposure (step 3 above) then it proceeds immediately + to step 4, finishes collecting the current frame and stops the acquisition sequence + if ADNumImages is greater than 1. If mar345Abort is set to 0 then the acquisition + is terminated as soon as possible without saving the data. Note however that commands + to the mar345 server to erase, change mode, or scan cannot be aborted, so the driver + must wait for these commands to complete. +
+ ADNumImages + $(P$(R)NumImages + Controls the number of images to acquire when ADImageMode is ADImageMultiple.
+ ADAcquirePeriod + $(P$(R)AcquirePeriod + Controls the period between images when ADImageMode is ADImageMultiple or ADImageContinuous. + If this is greater than the acquisition time plus readout overhead then the driver + will wait until the period has elapsed before starting the next acquisition.
+ NDFilePath + $(P$(R)FilePath + Controls the path for saving images. It must be a valid path for mar345dtb and + for the areaDetector driver, which is normally running in an EPICS IOC. If mar345dtb + and the EPICS IOC are not running on the same machine then soft links will typically + be used to make the paths look identical.
+ NDFileFormat + $(P)$(R)FileFormat + mar345 only supports mar345 format binary files. +
+ NDStatus + $(P)$(R)DetectorState_RBV + mar345 replaces the state strings with the following: Exposing, Scanning, Erasing, + Changing Mode, Aborting, Error, and Waiting. +
+

+ It is useful to use NDPluginROI to define an ROI containing the entire mar345 detector. + The MaxValue_RBV PV in this ROI can be monitored to make sure that the 16-bit limit + of 65,535 is not being approached in any pixel. +

+

+ mar345 specific parameters

+

+ The mar345 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 enum names have + been split into 2 lines, but these are just a single name, for example mar345ScanSize. +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Parameter Definitions in mar345.cpp and EPICS Record Definitions in mar345.template
+ Enum name + asyn interface + Access + Description + drvUser string + EPICS record name + EPICS record type
+ Readout parameters
+ mar345
+ ScanSize
+ asynInt32 + r/w + The detector diameter to read out. Choices are 180mm, 240mm, 300mm, and 345mm. + MAR_SIZE + $(P)$(R)ScanSize
+ $(P)$(R)ScanSize_RBV
+ mbbo +
+ mbbi +
+ mar345
+ ScanResolution
+ asynInt32 + r/w + The pixel size to use when reading the detector out. Choices are 0.10 and 0.15mm. + MAR_RESOLUTION + $(P)$(R)ScanResolution
+ $(P)$(R)ScanResolution_RBV
+ mbbo +
+ mbbi +
+ mar345
+ ChangeMode
+ asynInt32 + r/w + Writing 1 to this parameter causes the ScanSize and ScanResolution values to be + sent to the server, changing the scan mode. This is not strictly necessary, because + the size and resolution is also encoded in the file extension used in the scan command. + However, changing the mode before doing a scan reduces the time for the scan, because + the detector is already configured for the correct mode. + MAR_CHANGE_MODE + $(P)$(R)ChangeMode
+ $(P)$(R)ChangedMode_RBV
+ busy +
+ bi +
+ Erase parameters
+ mar345
+ EraseMode
+ asynInt32 + r/w + Controls whether an erase cycle should be automatically performed during acquisition. + Choices are None, Before expose, and After scan. + MAR_ERASE_MODE + $(P)$(R)EraseMode
+ $(P)$(R)EraseMode_RBV
+ mbbo +
+ mbbi +
+ mar345
+ NumErase
+ asynInt32 + r/w + The number of erase cycles to perform each time the detector is erased, either because + the mar345Erase parameter is set to 1, or because of an automatic erase as part + of an acquisition. + MAR_NUM_ERASE + $(P)$(R)NumErase
+ $(P)$(R)NumErase_RBV
+ longout +
+ longin +
+ mar345
+ Erase
+ asynInt32 + r/w + Write 1 to this parameter to initiate erasing the detector. The detector will be + erased multiple times if mar345NumErase is greater than 1. + MAR_ERASE + $(P)$(R)Erase
+ $(P)$(R)Erase_RBV
+ busy +
+ bi +
+ Abort parameters
+ mar345
+ Abort
+ asynInt32 + r/w + Writing 1 to this parameter aborts the current operation as soon as possible and + returns the driver to the idle state. Note however that commands to the mar345 server + cannot be aborted, so the driver must wait for the current command to complete. + MAR_ABORT + $(P)$(R)Abort
+ $(P)$(R)Abort_RBV
+ bo +
+ bi +
+ Debugging
+ N/A + N/A + N/A + asyn record to control debugging communication with mar345dtb program + N/A + $(P)$(R)marSserverAsyn + asyn
+

+ Unsupported standard driver parameters

+

+ The mar345 driver does not support the following standard driver parameters because + they are not supported in the mar345dtb program:

+ +

+ Configuration

+

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

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

-

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

-

- MEDM screens

-

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

-

- mar345.adl is the main screen used to control the mar345 driver. -

-
-

- mar345.adl

- mar345.png
-

- Performance measurements

-

- The mar345 is definitely not a fast detector! The following measurements show the - time to perform various erase and scan operations. Note that because the mar345 - file format is compressed the file sizes are typically much less than the image - sizes listed.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Scan diameter - Pixel size - Image dimensions - Image size (MB) - Time to scan - Time to erase
- 180 mm - - 0.15 mm - - 1200x1200 - - 2.7 - - 38.6 - - 37.8 -
- 240 mm - - 0.15 mm - - 1600x1600 - - 4.9 - - 50.4 - - 50.8 -
- 300 mm - - 0.15 mm - - 2000x2000 - - 7.6 - - 74.7 - - 66.9 -
- 345 mm - - 0.15 mm - - 2300x2300 - - 10.1 - - 88.6 - - 82.7 -
- 180 mm - - 0.10 mm - - 1800x1800 - - 6.2 - - 46.4 - - 45.9 -
- 240 mm - - 0.10 mm - - 2400x2400 - - 11.0 - - 71.9 - - 63.8 -
- 300 mm - - 0.10 mm - - 3000x3000 - - 17.2 - - 89.1 - - 87.0 -
- 345 mm - - 0.10 mm - - 3450x3450 - - 22.7 - - 107.5 - - 107.1 -
-

- Restrictions

-

- The following are some current restrictions of the mar345 driver:

- - - + +

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

+

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

+

+ MEDM screens

+

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

+

+ mar345.adl is the main screen used to control the mar345 driver. +

+
+

+ mar345.adl

+ mar345.png
+

+ Performance measurements

+

+ The mar345 is definitely not a fast detector! The following measurements show the + time to perform various erase and scan operations. Note that because the mar345 + file format is compressed the file sizes are typically much less than the image + sizes listed.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Scan diameter + Pixel size + Image dimensions + Image size (MB) + Time to scan + Time to erase
+ 180 mm + + 0.15 mm + + 1200x1200 + + 2.7 + + 38.6 + + 37.8 +
+ 240 mm + + 0.15 mm + + 1600x1600 + + 4.9 + + 50.4 + + 50.8 +
+ 300 mm + + 0.15 mm + + 2000x2000 + + 7.6 + + 74.7 + + 66.9 +
+ 345 mm + + 0.15 mm + + 2300x2300 + + 10.1 + + 88.6 + + 82.7 +
+ 180 mm + + 0.10 mm + + 1800x1800 + + 6.2 + + 46.4 + + 45.9 +
+ 240 mm + + 0.10 mm + + 2400x2400 + + 11.0 + + 71.9 + + 63.8 +
+ 300 mm + + 0.10 mm + + 3000x3000 + + 17.2 + + 89.1 + + 87.0 +
+ 345 mm + + 0.10 mm + + 3450x3450 + + 22.7 + + 107.5 + + 107.1 +
+

+ Restrictions

+

+ The following are some current restrictions of the mar345 driver:

+ + + diff --git a/documentation/MarCCDDoc.html b/documentation/MarCCDDoc.html index 6144cc7..80688e6 100755 --- a/documentation/MarCCDDoc.html +++ b/documentation/MarCCDDoc.html @@ -1,876 +1,879 @@ - - - areaDetector MarCCD driver - - - -
-

- areaDetector MarCCD driver

-

- August 17, 2009

-

- Mark Rivers

-

- University of Chicago

-
-

- Table of Contents

- -

- Introduction

-

- This is a driver for the MarCCD detectors from Rayonix/MarUSA. - It implements many of the parameters in asynNDArrayDriver.h and ADDriver.h. It also - implements a number of parameters that are specific to the MarCCD detectors.

-

- The interface to the detector is via a TCP/IP socket interface to the marccd_server_socket - server that MarUSA provides. The marccd_server_socket program must be started before - the areaDetector software is started, by running the marccd program and executing - Acquire/Remote Control/Start. -

-

- marccd must be using Version 1 of the remote protocol. This is normally done done - by editing the file marccd/configuration/marccd.conf and replacing the line

+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> + + + areaDetector MarCCD driver + + + +
+

+ areaDetector MarCCD driver

+

+ August 17, 2009

+

+ Mark Rivers

+

+ University of Chicago

+
+

+ Table of Contents

+ +

+ Introduction

+

+ This is a driver for the MarCCD detectors from Rayonix/MarUSA. +

+

+ The interface to the detector is via a TCP/IP socket interface to the marccd_server_socket + server that MarUSA provides. The marccd_server_socket program must be started before + the areaDetector software is started, by running the marccd program and executing + Acquire/Remote Control/Start. +

+

+ marccd must be using Version 1 of the remote protocol. This is normally done done + by editing the file marccd/configuration/marccd.conf and replacing the line

include marccd_server_v0.conf
-    
-

- with

+ +

+ with

include marccd_server_v1.conf
-    
-

- The file marccd_server_v1.conf should contain the lines:

+ +

+ The file marccd_server_v1.conf should contain the lines:

remote_mode_server_command /home/marccd/contrib/marccd_server/marccd_server_socket
 remote_mode_server_arguments 2222
-    
-

- The first line points to the location of the marccd_server_socket program that is - used to implement remote control. In order to work with the areaDetector driver - this must be a version of this program created after November 11, 2008 when support - for the get_frameshift command was added. A recent version of this - program can be downloaded from the - Rayonix FTP site. -

-

- The marccd program saves the data to disk as TIFF files. The areaDetector software - reads these disk files in order to read the data, because marccd does not provide - another mechanism to access the data. -

-

- This driver inherits from ADDriver. The - marCCD class documentation describes this class in detail.

-

- Implementation of standard driver parameters

-

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

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Implementation of Parameters in asynNDArrayDriver.h and ADDriver.h, and EPICS Record - Definitions in ADBase.template and NDFile.template
- Enum name - EPICS record name - Description
- ADFrameType - $(P$(R)FrameType - The driver redefines the choices for the ADFrameType parameter (record $(P)$(R)FrameType) - from ADDriver.h. The choices for the MarCCD are: -
    -
  • Normal (corrected data frame without double correlation)
  • -
  • Background (background frame with 0 exposure time, done with double correlation - to remove zingers)
  • -
  • Raw (data frame without correction for background or spatial distortion)
  • -
  • DblCorrelation (two images each collected for half the nominal acquisition time, - zingers removed by double correlation)
  • -
-
- ADNumImages - $(P$(R)NumImages - Controls the number of images to acquire when ADImageMode is ADImageMultiple.
- ADAcquirePeriod - $(P$(R)AcquirePeriod - Controls the period between images when ADImageMode is ADImageMultiple or ADImageContinuous. - If this is greater than the acquisition time plus readout overhead then the driver - will wait until the period has elapsed before starting the next acquisition.
- ADReadStatus - $(P)$(R)ReadStatus - Writing 1 to this parameter causes the status to be read from the marccd server. - By processing or periodically scanning this record the status information can be - refreshed. This is normally not necessary, but if ADArrayCallbacks is 0 and marCCDOverlap - is 1 then the status will not indicate that the system is idle when acquisition - is complete, because the driver polling stops before the file is written. This record - can be used to eliminate the confusion that might cause.
- NDFilePath - $(P$(R)FilePath - Controls the path for saving images. It must be a valid path for marccd and - for the areaDetector driver, which is normally running in an EPICS IOC. If marccd - and the EPICS IOC are not running on the same machine then soft links will typically - be used to make the paths look identical.
- NDFileFormat - $(P)$(R)FileFormat - marccd only supports TIFF files. -
-

- It is useful to use NDPluginROI to define an ROI containing the entire marccd detector. - The MaxValue_RBV PV in this ROI can be monitored to make sure that the 16-bit limit - of 65,535 is not being approached in any pixel. -

-

- MarCCD specific parameters

-

- The MarCCD 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 enum names have - been split into 2 lines, but these are just a single name, for example marCCDState. -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Parameter Definitions in marccd.cpp and EPICS Record Definitions in marccd.template
- Enum name - asyn interface - Access - Description - drvUser string - EPICS record name - EPICS record type
- Status parameters
- marCCD
- State
- asynInt32 - r/o - State word returned by marccd server. The low-order 4-bits of this word are the - state of the marccd server, and will be Idle (0x0), Error (0x7), or Busy (0x8). - The next 20 bits encode the state of the 5 server tasks (Acquire, Readout, Correct, - Save, Dezinger) with 4-bits per task. Each task can be in the state Idle (0x0), - Queued (0x1), Executing (0x2), Error (0x4), or Reserved (0x8). - MAR_STATE - $(P)$(R)MarState_RBV - longin
- marCCD
- Status
- asynInt32 - r/o - Status of the marccd server task (Idle, Error, or Busy) - MAR_STATUS - $(P)$(R)MarStatus_RBV - mbbi
- marCCDTask
- AcquireStatus
- asynInt32 - r/o - Status of the marccd server acquire task (Idle, Queued, Executing, Error, or Reserved) - MAR_ACQUIRE_STATUS - $(P)$(R)MarAcquireStatus_RBV - mbbi
- marCCDTask
- ReadoutStatus
- asynInt32 - r/o - Status of the marccd server readout task (Idle, Queued, Executing, Error, or Reserved) - MAR_READOUT_STATUS - $(P)$(R)MarReadoutStatus_RBV - mbbi
- marCCDTask
- CorrectStatus
- asynInt32 - r/o - Status of the marccd server correct task (Idle, Queued, Executing, Error, or Reserved) - MAR_CORRECT_STATUS - $(P)$(R)MarCorrectStatus_RBV - mbbi
- marCCDTask
- WritingStatus
- asynInt32 - r/o - Status of the marccd server file writing task (Idle, Queued, Executing, Error, or - Reserved) - MAR_WRITING_STATUS - $(P)$(R)MarWritingStatus_RBV - mbbi
- marCCDTask
- DezingerStatus
- asynInt32 - r/o - Status of the marccd server dezinger task (Idle, Queued, Executing, Error, or Reserved) - MAR_DEZINGER_STATUS - $(P)$(R)MarDezingerStatus_RBV - mbbi
- Optimization parameters
- marCCD
- Overlap
- asynInt32 - r/w - The marccd server has 5 tasks (Acquire, Readout, Correct, Write, Dezinger) that - can overlap their operation. The areaDetector driver can exploit this to improve - performance in some circumstances. If this parameter is set to 1 (Overlap) then - the ADAcquire parameter will go to 0 (Done) when the Readout task is done executing, - but before the Correct and Write tasks have finished correcting and saving the file - to disk. This improves performance because the next image can begin as soon as ADAcquire - goes to done, and hence before the previous image is written to disk. Note, however - that this parameter must be set to 0 (Sequential) if callbacks are being used to - compute ROIs that are being used in data collection, e.g. in a scan. If this is - not done then the ROI information will be grabbed before it is updated and incorrect - scan data will result. - MAR_OVERLAP - $(P)$(R)OverlapMode -
- $(P)$(R)OverlapMode_RBV
- bo -
- bi
- Frameshift parameters
- marCCD
- Frameshift
- asynInt32 - r/w - marccd can be used for time-resolved studies by collecting multiple data sets before - reading out the detector. This is done by placing a mask in front of the detector - that restricts the x-rays to horizontal stripe. An exposure is made, and then an - external signal causes the detector to shift the image by the number of lines given - by this parameter. A number of images separated by times of a few milliseconds can - be collected, and then the detector is read out. Set this parameter to 0 to disable - frameshift mode. - MAR_FRAME_SHIFT - $(P)$(R)FrameShift -
- $(P)$(R)FrameShift_RBV
- longout -
- longin
- Timeout parameters
- marCCD
- TiffTimeout
- asynFloat64 - r/w - Timeout in seconds when reading a TIFF file. It should be set to several seconds, - because there it can take some time for the marccd server to write the file. - MAR_TIFF_TIMEOUT - $(P)$(R)ReadTiffTimeout - ao
- Ancillary parameters. These parameters are written to the header of the marccd - TIFF file.
- marCCD
- DetectorDistance
- asynFloat64 - r/w - Distance from the sample to the detector (mm) - MAR_DETECTOR_DISTANCE - $(P)$(R)DetectorDistance - ao
- marCCD
- BeamX
- asynFloat64 - r/w - X position of the direct beam on the detector (mm) - MAR_BEAM_X - $(P)$(R)BeamX - ao
- marCCD
- BeamY
- asynFloat64 - r/w - Y position of the direct beam on the detector (mm) - MAR_BEAM_Y - $(P)$(R)BeamY - ao
- marCCD
- StartPhi
- asynFloat64 - r/w - Starting value of phi rotation (deg) - MAR_START_PHI - $(P)$(R)StartPhi - ao
- marCCD
- RotationAxis
- asynOctet - r/w - Rotation axis being used (phi, omega, etc.) - MAR_ROTATION_AXIS - $(P)$(R)RotationAxis - stringout
- marCCD
- RotationRange
- asynFloat64 - r/w - Rotation range of the rotation axis. - MAR_ROTATION_RANGE - $(P)$(R)RotationRange - ao
- marCCD
- TwoTheta
- asynOctet - r/w - Detector two-theta angle (deg); ignored if empty string; requires theta axis definition - with display name "TwoTheta" in marccd configuration file (e.g. "theta_display_name - TwoTheta") - MAR_TWO_THETA - $(P)$(R)TwoTheta - stringout
- marCCD
- Wavelength
- asynFloat64 - r/w - Wavelength in Angstroms. - MAR_WAVELENGTH - $(P)$(R)Wavelength - ao
- marCCD
- FileComments
- asynOctet - r/w - Comments for this file. - MAR_FILE_COMMENTS - $(P)$(R)FileComments - waveform
- marCCD
- DatasetComments
- asynOctet - r/w - Comments for this dataset. - MAR_DATASET_COMMENTS - $(P)$(R)DatasetComments - waveform
- Debugging
- N/A - N/A - N/A - asyn record to control debugging communication with marccd_server_socket program - N/A - $(P)$(R)marSserverAsyn - asyn
-

- Unsupported standard driver parameters

-

- The MarCCD driver does not support the following standard driver parameters because - they are not supported in the marccd program:

- -

- Configuration

-

- The marCCD driver is created with the marCCDConfig command, either from C/C++ or - from the EPICS IOC shell.

+ +

+ The first line points to the location of the marccd_server_socket program that is + used to implement remote control. In order to work with the areaDetector driver + this must be a version of this program created after November 11, 2008 when support + for the get_frameshift command was added. A recent version of this + program can be downloaded from the + Rayonix FTP site. +

+

+ The marccd program saves the data to disk as TIFF files. The areaDetector software + reads these disk files in order to read the data, because marccd does not provide + another mechanism to access the data. +

+

+ This driver inherits from ADDriver. + It implements many of the parameters in NDStdDriverParam_t (see + asynNDArryDriver.h) and in ADStdDriverParam_t (see + ADArrayDriver.h). It also implements a number of parameters that are specific + to the MarCCD detectors. The + marCCD class documentation describes this class in detail.

+

+ Implementation of standard driver parameters

+

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

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Implementation of Parameters in asynNDArrayDriver.h and ADDriver.h, and EPICS Record + Definitions in ADBase.template and NDFile.template
+ Enum name + EPICS record name + Description
+ ADFrameType + $(P$(R)FrameType + The driver redefines the choices for the ADFrameType parameter (record $(P)$(R)FrameType) + from ADDriver.h. The choices for the MarCCD are: +
    +
  • Normal (corrected data frame without double correlation)
  • +
  • Background (background frame with 0 exposure time, done with double correlation + to remove zingers)
  • +
  • Raw (data frame without correction for background or spatial distortion)
  • +
  • DblCorrelation (two images each collected for half the nominal acquisition time, + zingers removed by double correlation)
  • +
+
+ ADNumImages + $(P$(R)NumImages + Controls the number of images to acquire when ADImageMode is ADImageMultiple.
+ ADAcquirePeriod + $(P$(R)AcquirePeriod + Controls the period between images when ADImageMode is ADImageMultiple or ADImageContinuous. + If this is greater than the acquisition time plus readout overhead then the driver + will wait until the period has elapsed before starting the next acquisition.
+ ADReadStatus + $(P)$(R)ReadStatus + Writing 1 to this parameter causes the status to be read from the marccd server. + By processing or periodically scanning this record the status information can be + refreshed. This is normally not necessary, but if ADArrayCallbacks is 0 and marCCDOverlap + is 1 then the status will not indicate that the system is idle when acquisition + is complete, because the driver polling stops before the file is written. This record + can be used to eliminate the confusion that might cause.
+ NDFilePath + $(P$(R)FilePath + Controls the path for saving images. It must be a valid path for marccd and + for the areaDetector driver, which is normally running in an EPICS IOC. If marccd + and the EPICS IOC are not running on the same machine then soft links will typically + be used to make the paths look identical.
+ NDFileFormat + $(P)$(R)FileFormat + marccd only supports TIFF files. +
+

+ It is useful to use NDPluginROI to define an ROI containing the entire marccd detector. + The MaxValue_RBV PV in this ROI can be monitored to make sure that the 16-bit limit + of 65,535 is not being approached in any pixel. +

+

+ MarCCD specific parameters

+

+ The MarCCD 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 enum names have + been split into 2 lines, but these are just a single name, for example marCCDState. +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Parameter Definitions in marccd.cpp and EPICS Record Definitions in marccd.template
+ Enum name + asyn interface + Access + Description + drvUser string + EPICS record name + EPICS record type
+ Status parameters
+ marCCD
+ State
+ asynInt32 + r/o + State word returned by marccd server. The low-order 4-bits of this word are the + state of the marccd server, and will be Idle (0x0), Error (0x7), or Busy (0x8). + The next 20 bits encode the state of the 5 server tasks (Acquire, Readout, Correct, + Save, Dezinger) with 4-bits per task. Each task can be in the state Idle (0x0), + Queued (0x1), Executing (0x2), Error (0x4), or Reserved (0x8). + MAR_STATE + $(P)$(R)MarState_RBV + longin
+ marCCD
+ Status
+ asynInt32 + r/o + Status of the marccd server task (Idle, Error, or Busy) + MAR_STATUS + $(P)$(R)MarStatus_RBV + mbbi
+ marCCDTask
+ AcquireStatus
+ asynInt32 + r/o + Status of the marccd server acquire task (Idle, Queued, Executing, Error, or Reserved) + MAR_ACQUIRE_STATUS + $(P)$(R)MarAcquireStatus_RBV + mbbi
+ marCCDTask
+ ReadoutStatus
+ asynInt32 + r/o + Status of the marccd server readout task (Idle, Queued, Executing, Error, or Reserved) + MAR_READOUT_STATUS + $(P)$(R)MarReadoutStatus_RBV + mbbi
+ marCCDTask
+ CorrectStatus
+ asynInt32 + r/o + Status of the marccd server correct task (Idle, Queued, Executing, Error, or Reserved) + MAR_CORRECT_STATUS + $(P)$(R)MarCorrectStatus_RBV + mbbi
+ marCCDTask
+ WritingStatus
+ asynInt32 + r/o + Status of the marccd server file writing task (Idle, Queued, Executing, Error, or + Reserved) + MAR_WRITING_STATUS + $(P)$(R)MarWritingStatus_RBV + mbbi
+ marCCDTask
+ DezingerStatus
+ asynInt32 + r/o + Status of the marccd server dezinger task (Idle, Queued, Executing, Error, or Reserved) + MAR_DEZINGER_STATUS + $(P)$(R)MarDezingerStatus_RBV + mbbi
+ Optimization parameters
+ marCCD
+ Overlap
+ asynInt32 + r/w + The marccd server has 5 tasks (Acquire, Readout, Correct, Write, Dezinger) that + can overlap their operation. The areaDetector driver can exploit this to improve + performance in some circumstances. If this parameter is set to 1 (Overlap) then + the ADAcquire parameter will go to 0 (Done) when the Readout task is done executing, + but before the Correct and Write tasks have finished correcting and saving the file + to disk. This improves performance because the next image can begin as soon as ADAcquire + goes to done, and hence before the previous image is written to disk. Note, however + that this parameter must be set to 0 (Sequential) if callbacks are being used to + compute ROIs that are being used in data collection, e.g. in a scan. If this is + not done then the ROI information will be grabbed before it is updated and incorrect + scan data will result. + MAR_OVERLAP + $(P)$(R)OverlapMode +
+ $(P)$(R)OverlapMode_RBV
+ bo +
+ bi
+ Frameshift parameters
+ marCCD
+ Frameshift
+ asynInt32 + r/w + marccd can be used for time-resolved studies by collecting multiple data sets before + reading out the detector. This is done by placing a mask in front of the detector + that restricts the x-rays to horizontal stripe. An exposure is made, and then an + external signal causes the detector to shift the image by the number of lines given + by this parameter. A number of images separated by times of a few milliseconds can + be collected, and then the detector is read out. Set this parameter to 0 to disable + frameshift mode. + MAR_FRAME_SHIFT + $(P)$(R)FrameShift +
+ $(P)$(R)FrameShift_RBV
+ longout +
+ longin
+ Timeout parameters
+ marCCD
+ TiffTimeout
+ asynFloat64 + r/w + Timeout in seconds when reading a TIFF file. It should be set to several seconds, + because there it can take some time for the marccd server to write the file. + MAR_TIFF_TIMEOUT + $(P)$(R)ReadTiffTimeout + ao
+ Ancillary parameters. These parameters are written to the header of the marccd + TIFF file.
+ marCCD
+ DetectorDistance
+ asynFloat64 + r/w + Distance from the sample to the detector (mm) + MAR_DETECTOR_DISTANCE + $(P)$(R)DetectorDistance + ao
+ marCCD
+ BeamX
+ asynFloat64 + r/w + X position of the direct beam on the detector (mm) + MAR_BEAM_X + $(P)$(R)BeamX + ao
+ marCCD
+ BeamY
+ asynFloat64 + r/w + Y position of the direct beam on the detector (mm) + MAR_BEAM_Y + $(P)$(R)BeamY + ao
+ marCCD
+ StartPhi
+ asynFloat64 + r/w + Starting value of phi rotation (deg) + MAR_START_PHI + $(P)$(R)StartPhi + ao
+ marCCD
+ RotationAxis
+ asynOctet + r/w + Rotation axis being used (phi, omega, etc.) + MAR_ROTATION_AXIS + $(P)$(R)RotationAxis + stringout
+ marCCD
+ RotationRange
+ asynFloat64 + r/w + Rotation range of the rotation axis. + MAR_ROTATION_RANGE + $(P)$(R)RotationRange + ao
+ marCCD
+ TwoTheta
+ asynOctet + r/w + Detector two-theta angle (deg); ignored if empty string; requires theta axis definition + with display name "TwoTheta" in marccd configuration file (e.g. "theta_display_name + TwoTheta") + MAR_TWO_THETA + $(P)$(R)TwoTheta + stringout
+ marCCD
+ Wavelength
+ asynFloat64 + r/w + Wavelength in Angstroms. + MAR_WAVELENGTH + $(P)$(R)Wavelength + ao
+ marCCD
+ FileComments
+ asynOctet + r/w + Comments for this file. + MAR_FILE_COMMENTS + $(P)$(R)FileComments + waveform
+ marCCD
+ DatasetComments
+ asynOctet + r/w + Comments for this dataset. + MAR_DATASET_COMMENTS + $(P)$(R)DatasetComments + waveform
+ Debugging
+ N/A + N/A + N/A + asyn record to control debugging communication with marccd_server_socket program + N/A + $(P)$(R)marSserverAsyn + asyn
+

+ Unsupported standard driver parameters

+

+ The MarCCD driver does not support the following standard driver parameters because + they are not supported in the marccd program:

+ +

+ Configuration

+

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

int marCCDConfig(const char *portName, const char *serverPort,
                  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 mar345Config function in the - marCCD.cpp documentation and in the documentation for the constructor for - the marCCD class. -

-

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

-

- MEDM screens

-

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

-

- marccd.adl is the main screen used to control the MarCCD driver. -

-
-

- marccd.adl

- marCCD.png
-

- marccdAncillary.adl is the screen used to input ancillary information - that is written to the MarCCD TIFF files. -

-
-

- marccdAncillary.adl

- MarCCDAncillary.png
-

- asynRecord.adl is used to control the debugging information printed - by the asyn TCP/IP driver (asynTraceIODriver) and the EPICS device support (asynTraceIODevice).

-
-

- asynRecord.adl

- MarCCDAsynRecord.png
-

- asynOctet.adl can be used to send any command to the marccd remote - server and display the response. It can be loaded from the More menu in asynRecord.adl - above.

-
-

- asynOctet.adl

- MarCCDAsynOctet.png
-

- Performance measurements

-

- The following measurements were done to demonstrate the performance that can be - obtained with the areaDetector MarCCD driver. These measurements were made with - a MAR-165 CCD. The EPICS IOC was running on the same Linux machine as the marccd - program. The acquisition time was 1 second.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Binning - Image size - marCCDOverlap - Time for 10 images - Overhead per image - Time per task
- 2x2 - - 2048x2048 - - Sequential - - 50.0 - - 4.00 - - Readout: 3.02 -
- Correct: 0.56 -
- Save: 0.20 -
- 2x2 - - 2048x2048 - - Overlap - - 46.2 - - 3.62 - - Same -
- 4x4 - - 1024x1024 - - Sequential - - 29.0 - - 1.90 - - Readout: 1.30 -
- Correct: 0.28 -
- Save: 0.06 -
- 4x4 - - 1024x1024 - - Overlap - - 28.7 - - 1.87 - - Same -
- 8x8 - - 512x512 - - Sequential - - 24.0 - - 1.40 - - Readout: 0.78 -
- Correct: 0.29 -
- Save: 0.06 -
- 8x8 - - 512x512 - - Overlap - - 23.6 - - 1.36 - - Same -
-

- Restrictions

-

- The following are some current restrictions of the MarCCD driver:

- - - + +

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

+

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

+

+ MEDM screens

+

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

+

+ marccd.adl is the main screen used to control the MarCCD driver. +

+
+

+ marccd.adl

+ marCCD.png
+

+ marccdAncillary.adl is the screen used to input ancillary information + that is written to the MarCCD TIFF files. +

+
+

+ marccdAncillary.adl

+ MarCCDAncillary.png
+

+ asynRecord.adl is used to control the debugging information printed + by the asyn TCP/IP driver (asynTraceIODriver) and the EPICS device support (asynTraceIODevice).

+
+

+ asynRecord.adl

+ MarCCDAsynRecord.png
+

+ asynOctet.adl can be used to send any command to the marccd remote + server and display the response. It can be loaded from the More menu in asynRecord.adl + above.

+
+

+ asynOctet.adl

+ MarCCDAsynOctet.png
+

+ Performance measurements

+

+ The following measurements were done to demonstrate the performance that can be + obtained with the areaDetector MarCCD driver. These measurements were made with + a MAR-165 CCD. The EPICS IOC was running on the same Linux machine as the marccd + program. The acquisition time was 1 second.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Binning + Image size + marCCDOverlap + Time for 10 images + Overhead per image + Time per task
+ 2x2 + + 2048x2048 + + Sequential + + 50.0 + + 4.00 + + Readout: 3.02 +
+ Correct: 0.56 +
+ Save: 0.20 +
+ 2x2 + + 2048x2048 + + Overlap + + 46.2 + + 3.62 + + Same +
+ 4x4 + + 1024x1024 + + Sequential + + 29.0 + + 1.90 + + Readout: 1.30 +
+ Correct: 0.28 +
+ Save: 0.06 +
+ 4x4 + + 1024x1024 + + Overlap + + 28.7 + + 1.87 + + Same +
+ 8x8 + + 512x512 + + Sequential + + 24.0 + + 1.40 + + Readout: 0.78 +
+ Correct: 0.29 +
+ Save: 0.06 +
+ 8x8 + + 512x512 + + Overlap + + 23.6 + + 1.36 + + Same +
+

+ Restrictions

+

+ The following are some current restrictions of the MarCCD driver:

+ + + diff --git a/documentation/NDPluginColorConvert.html b/documentation/NDPluginColorConvert.html index c13cad0..2c2dee8 100755 --- a/documentation/NDPluginColorConvert.html +++ b/documentation/NDPluginColorConvert.html @@ -10,7 +10,7 @@

areaDetector Plugin NDPluginColorConvert

- January 30, 2009

+ August 17, 2009

Mark Rivers

@@ -28,30 +28,13 @@ Overview

- This plugin is a tool for converting the color mode of NDArray data. -

+ NDPluginColorConvert is a tool for converting the color mode of NDArray data. It + receives an input NDArray with one color mode and outputs another NDArray with a + (potentially) different color mode. All other attributes of the array are preserved.

- NDPluginColorConvert inherits from NDPluginDriver. NDPluginColorConvert receives - an input NDArray with one color mode and outputs another NDArray with a (potentially) - different color mode. All other attributes of the array are preserved. The NDPluginColorConvert - public interface is defined in NDPluginColorConvert.h as follows:

-
class NDPluginColorConvert : public NDPluginDriver {
-public:
-    NDPluginColorConvert(const char *portName, int queueSize, int blockingCallbacks,
-                         const char *NDArrayPort, int NDArrayAddr,
-                         size_t maxMemory);
-
-    /* These methods override the virtual methods in the base class */
-    void processCallbacks(NDArray *pArray);
-    asynStatus drvUserCreate(asynUser *pasynUser, const char *drvInfo,
-                             const char **pptypeName, size_t *psize);
-
-    /* These methods are just for this class */
-    template <typename epicstype> void convertColor(NDArray *pArray);
-};
-...
-}
-
+ NDPluginColorConvert inherits from NDPluginDriver. The + NDPluginColorConvert class documentation describes this class in detail. +

NDPluginColorConvert defines the following parameters. It also implements all of the standard plugin parameters from NDPluginDriver @@ -123,72 +106,18 @@ public: The NDPluginColorConvert plugin is created with the following command, either from C/C++ or from the EPICS IOC shell.

-
int drvNDColorConvertConfigure(const char *portName, int queueSize, int blockingCallbacks, 
-                               const char *NDArrayPort, int NDArrayAddr, 
-                               int maxBuffers, size_t maxMemory);
+  
 int NDColorConvertConfigure(const char *portName, int queueSize, int blockingCallbacks, 
+                             const char *NDArrayPort, int NDArrayAddr, 
+                             int maxBuffers, size_t maxMemory,
+                             int priority, int stackSize)
   
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Argument - Description
- portName - The name of the asyn port for this plugin. -
- queueSize - The maximum number of NDArray objects that can be queued for processing. Passed - to the NDPluginDriver base class constructor. -
- blockingCallbacks - Flag controlling whether callbacks block. Passed to the NDPluginDriver base class - constructor. -
- NDArrayPort - The name of the asyn port of the driver that will provide the NDArray data. Passed - to the NDPluginDriver base class constructor. -
- NDArrayAddr - The asyn addr of the asyn port of the driver that will provide the NDArray data. - Passed to the NDPluginDriver base class constructor. -
- maxBuffers - Maximum number of NDArray buffers to be created for plugin callbacks, i.e. for plugins - that will be getting called from this plugin. Passed to the constructor for the - NDPluginDriver base class.
- maxMemory - Maximum number of bytes of memory to be allocated from the NDArrayPool. Passed to - the constructor for the NDPluginDriver base class.
+

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

Screen shots

diff --git a/documentation/NDPluginFile.html b/documentation/NDPluginFile.html index be7f11d..aa1ba18 100755 --- a/documentation/NDPluginFile.html +++ b/documentation/NDPluginFile.html @@ -53,13 +53,14 @@ they all must fit in a memory buffer. It is the fastest mode, with the least probability of dropping arrays, because no disk I/O is required while capture is in progress.

  • Stream mode. In this mode the data are written to a single disk file for those - file formats that support multiple arrays per file (currently only netCDF; NeXus/HDF support for - multiple arrays per file is planned for a future release). Each - frame is appended to the file without closing it. It is intermediate in speed between + file formats that support multiple arrays per file (currently only netCDF; NeXus/HDF + support for multiple arrays per file is planned for a future release). Each frame + is appended to the file without closing it. It is intermediate in speed between single mode and capture mode, but unlike capture mode it is not limited by available memory in the number of arrays that can be saved. For file formats that do not support - multiple arrays per file (e.g. JPEG, TIFF and currently NeXus/HDF) this mode is really the same as Single - mode, except that one can specify a total number of files to save before stopping.
  • + multiple arrays per file (e.g. JPEG, TIFF and currently NeXus/HDF) this mode is + really the same as Single mode, except that one can specify a total number of files + to save before stopping.

    At least one array with the same datatype, array size, and attributes must have @@ -87,8 +88,8 @@ mode are supported by writing multiple JPEG files.

    - The JPEG plugin supports the Int32 parameter NDFileJPEGQuality to control the amount of - compression in the file. This parameter varies from 0 (maximum compression, lowest + The JPEG plugin supports the Int32 parameter NDFileJPEGQuality to control the amount + of compression in the file. This parameter varies from 0 (maximum compression, lowest quality) to 100 (least compression, best quality). NDFileJPEG.template defines 2 records to support this: $(P)$(R)JPEGQuality (longout) and $(P)$(R)JPEGQuality_RBV (longin). @@ -313,17 +314,17 @@ variables: NeXus (HDF) file plugin

    - A plugin to write NeXus files was - written by John Hammonds from the APS. NeXus is a standard format for x-ray and - neutron data based on HDF. This is a very general - file format, capable of storing any type of array data and meta-data. + A plugin to write NeXus files + was written by John Hammonds from the APS. NeXus is a standard format for x-ray + and neutron data based on HDF. This is a very + general file format, capable of storing any type of array data and meta-data.

    The NDFileNexus class documentation describes this class in detail.

    - The NDFileNexus plugin is created with the NDFileNexusConfigure command, either from - C/C++ or from the EPICS IOC shell.

    + The NDFileNexus plugin is created with the NDFileNexusConfigure command, either + from C/C++ or from the EPICS IOC shell.

    NDFileNexusConfigure (const char *portName, int queueSize, int blockingCallbacks, 
                           const char *NDArrayPort, int NDArrayAddr, size_t maxMemory, 
                           int priority, int stackSize)
    @@ -333,8 +334,10 @@ variables:
         documentation on the NDFileNexusConfigure function in the 
           NDFileNexus.cpp documentation and in the documentation for the constructor
         for the NDFileNexus class.

    -

    NDFileNeXus uses 2 additional parameters to define the location of an XML file that is read to determine - the contents of the NeXus files written by this plugin. These are described in the following table.

    +

    + NDFileNeXus uses 2 additional parameters to define the location of an XML file that + is read to determine the contents of the NeXus files written by this plugin. These + are described in the following table.

    @@ -373,10 +376,10 @@ variables: @@ -391,28 +394,30 @@ variables:
    TEMPLATE_FILE_PATH - $(P)$(R)TemplateFilePath
    + $(P)$(R)TemplateFilePath
    $(P)$(R)TemplateFilePath_RBV
    - waveform
    + waveform
    waveform
    TEMPLATE_FILE_NAME - $(P)$(R)TemplateFileName
    + $(P)$(R)TemplateFileName
    $(P)$(R)TemplateFileName_RBV
    - waveform
    + waveform
    waveform
    -

    There is currently no documentation on the contents of the XML template file. However, there are example - XML template files in the iocSimDetector and iocPerkinElmer directories. Documentation on the XML file - contents will be written ASAP.

    +

    + There is currently no documentation on the contents of the XML template file. However, + there are example XML template files in the iocSimDetector and iocPerkinElmer directories. + Documentation on the XML file contents will be written ASAP.

    Screen shots

    The following is the MEDM screen that provides access to the parameters in NDPluginDriver.h - and NDPluginFile.h through records in NDPluginBase.template and NDFile.template. - This is the MEDM screen that is used to control the saving of images to disk in netCDF format.

    + and NDPluginFile.h through records in NDPluginBase.template and NDFileNetCDF.template. + This is the MEDM screen that is used to control the saving of images to disk in + netCDF format.

    NDPluginFileNetCDF.adl

    - NDPluginFileNetCDF.png

    + NDFileNetCDF.png

    diff --git a/documentation/NDPluginROI.html b/documentation/NDPluginROI.html index e835565..7fef536 100755 --- a/documentation/NDPluginROI.html +++ b/documentation/NDPluginROI.html @@ -10,7 +10,7 @@

    areaDetector Plugin NDPluginROI

    - January 30, 2009

    + August 17, 2009

    Mark Rivers

    @@ -20,6 +20,7 @@ Contents

    @@ -44,42 +45,26 @@ rather than the full detector driver data.

    - Each NDPluginROI can handle any number of ROIs. The maximum number of ROIs that - the plugin can support is defined when the plugin is created. Several ROI plugins - could be created for a single detector driver to increase the number of threads - running in parallel, maximizing the use of multiple CPU cores. Individual ROIs are - addressed through the asyn interfaces by the asyn "addr" field in the asynUser structure. - Note that while the NDPluginROI should be N-dimensional, the EPICS interface to - the definition of the ROI is currently limited to a maximum of 3-D. This limitation - will be removed in a future release. + Each of these operations can be enabled or disabled independently.

    - NDPluginROI inherits from NDPluginDriver. The NDPluginROI public interface is defined - in NDPluginROI.h as follows: + Each NDPluginROI can handle any number of ROIs. Several ROI plugins could be created + for a single detector driver to increase the number of threads running in parallel, + maximizing the use of multiple CPU cores. Individual ROIs are addressed through + the asyn interfaces by the asyn "addr" field in the asynUser structure. Note that + while the NDPluginROI should be N-dimensional, the EPICS interface to the definition + of the ROI is currently limited to a maximum of 3-D. This limitation will be removed + in a future release.

    -
    class NDPluginROI : public NDPluginDriver {
    -public:
    -    NDPluginROI(const char *portName, int queueSize, int blockingCallbacks, 
    -                 const char *NDArrayPort, int NDArrayAddr, int maxROIs, size_t maxMemory);
    -    /* These methods override the virtual methods in the base class */
    -    void processCallbacks(NDArray *pArray);
    -    asynStatus writeInt32(asynUser *pasynUser, epicsInt32 value);
    -    asynStatus drvUserCreate(asynUser *pasynUser, const char *drvInfo, 
    -                             const char **pptypeName, size_t *psize);
    -
    -    /* These methods are unique to this class */
    -    asynStatus readFloat64Array(asynUser *pasynUser, epicsFloat64 *value, 
    -                                size_t nelements, size_t *nIn);
    -                                
    -

    - The readFloat64Array method is used to read the histogram data for the ROI. + NDPluginROI inherits from NDPluginDriver. The + NDPluginROI class documentation describes this class in detail.

    NDPluginROI.h defines the following parameters that are global to all ROIs for a - plugin. It also implements all of the standard plugin parameters from NDPlugDriver. - The EPICS database NDROI.template provide access to these parameters, listed in - the following table. + plugin. It also implements all of the standard plugin parameters from + NDPluginDriver. The EPICS database NDROI.template provide access to these + parameters, listed in the following table.

    @@ -498,7 +483,7 @@ public: Data type of the ROI (NDDataType_t). This can be different from the data type of the NDArray callback data. + ROI_DATA_TYPE @@ -528,7 +513,7 @@ public: + NDArraySizeX + ARRAY_SIZE_X + $(P)$(R)ArraySizeX_RBV + NDArraySizeY + ARRAY_SIZE_Y + $(P)$(R)ArraySizeY_RBV + NDArraySizeZ + ARRAY_SIZE_Z + $(P)$(R)ArraySizeZ_RBV @@ -819,86 +804,21 @@ public:

    Configuration

    - The NDPluginROI plugin is created with the following command, either from C/C++ - or from the EPICS IOC shell. -

    -
    int drvNDROIConfigure(const char *portName, int queueSize, int blockingCallbacks, 
    -                      const char *NDArrayPort, int NDArrayAddr, int maxROIs,
    -                      int maxBuffers, size_t maxMemory);
    -
    -
    +    The NDPluginROI plugin is created with the NDROIConfigure command, either from C/C++
    +    or from the EPICS IOC shell.

    +
    +NDROIConfigure(const char *portName, int queueSize, int blockingCallbacks,
    +               const char *NDArrayPort, int NDArrayAddr, int maxROIs,
    +               int maxBuffers, size_t maxMemory,
    +               int priority, int stackSize)
       
    -
    - DATA_TYPE $(P)$(R)DataType
    $(P)$(R)DataType_RBV
    - ADImageSizeX asynInt32 @@ -536,15 +521,15 @@ public: Size of the ROI data in the X direction - IMAGE_SIZE_X - $(P)$(R)ImageSizeX_RBV longin
    - ADImageSizeY asynInt32 @@ -552,15 +537,15 @@ public: Size of the ROI data in the Y direction - IMAGE_SIZE_Y - $(P)$(R)ImageSizeY_RBV longin
    - ADImageSizeZ asynInt32 @@ -568,9 +553,9 @@ public: Size of the ROI data in the Z direction - IMAGE_SIZE_Z - $(P)$(R)ImageSizeZ_RBV longin
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    - Argument - Description
    - portName - The name of the asyn port for this plugin. -
    - queueSize - The maximum number of NDArray objects that can be queued for processing. Passed - to the NDPluginDriver base class constructor. -
    - blockingCallbacks - Flag controlling whether callbacks block. Passed to the NDPluginDriver base class - constructor. -
    - NDArrayPort - The name of the asyn port of the driver that will provide the NDArray data. Passed - to the NDPluginDriver base class constructor. -
    - NDArrayAddr - The asyn addr of the asyn port of the driver that will provide the NDArray data. - Passed to the NDPluginDriver base class constructor. -
    - maxROIs - Maximum number of ROIs that this plugin will support. -
    - maxBuffers - Maximum number of NDArray buffers to be created for plugin callbacks, i.e. for plugins - that will be getting called from this plugin. Passed to the constructor for the - NDPluginDriver base class.
    - maxMemory - Maximum number of bytes of memory to be allocated from the NDArrayPool. Passed to - the constructor for the NDPluginDriver base class. The NDPluginROI plugin allocates - one NDArray object for each ROI, so this should be at least maxROIs times the size - of the largest NDArray to be used.
    +

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

    Screen shots

    diff --git a/documentation/NDPluginStdArrays.html b/documentation/NDPluginStdArrays.html index a7086a9..95f8bad 100755 --- a/documentation/NDPluginStdArrays.html +++ b/documentation/NDPluginStdArrays.html @@ -97,7 +97,7 @@

    The NDPluginStdArrays plugin is created with the NDStdArraysConfigure command, either from C/C++ or from the EPICS IOC shell.

    -
    NDStdArraysConfigure (const char *portName, int queueSize, int blockingCallbacks, 
    +  
    NDStdArraysConfigure (const char *portName, int queueSize, int blockingCallbacks, 
                           const char *NDArrayPort, int NDArrayAddr, size_t maxMemory, 
                           int priority, int stackSize)
       
    diff --git a/documentation/PerkinElmerDoc.html b/documentation/PerkinElmerDoc.html index 58d1545..e580b95 100644 --- a/documentation/PerkinElmerDoc.html +++ b/documentation/PerkinElmerDoc.html @@ -32,9 +32,7 @@ Introduction

    This is a driver for the flat-panel amorphous silicon detectors from - PerkinElmer. It implements many of the parameters in asynNDArrayDriver.h and - ADDriver.h. It also implements a number of parameters that are specific to the PerkinElmer - detectors.

    + PerkinElmer.

    The driver is based upon the library provided by PerkinElmer. It only runs on Microsoft Windows computers. @@ -42,7 +40,11 @@

    ADD ADDTIONAL INTRODUCTORY TEXT HERE.

    - This driver inherits from ADDriver. The + This driver inherits from ADDriver. + It implements many of the parameters in NDStdDriverParam_t (see + asynNDArryDriver.h) and in ADStdDriverParam_t (see + ADArrayDriver.h). It also implements a number of parameters that are specific + to the PerkinElmer detectors. The PerkinElmer class documentation describes this class in detail.

    Implementation of standard driver parameters

    @@ -78,9 +80,9 @@

    - It is useful to use NDPluginROI to define an ROI containing the entire PerkinElmer detector. - The MaxValue_RBV PV in this ROI can be monitored to make sure that the 16-bit limit - of 65,535 is not being approached in any pixel. + It is useful to use NDPluginROI to define an ROI containing the entire PerkinElmer + detector. The MaxValue_RBV PV in this ROI can be monitored to make sure that the + 16-bit limit of 65,535 is not being approached in any pixel.

    PerkinElmer specific parameters

    @@ -124,10 +126,10 @@ PE_NUM_FRAME_BUFFERS - $(P)$(R)PENumFrameBuffers
    + $(P)$(R)PENumFrameBuffers
    $(P)$(R)PENumFrameBuffers_RBV - longout
    + longout
    longin @@ -151,7 +153,7 @@

    For details on the meaning of the parameters to this function refer to the detailed - documentation on the mar345Config function in the + documentation on the PerkinElmerConfig function in the PerkinElmer.cpp documentation and in the documentation for the constructor for the PerkinElmer class.

    diff --git a/documentation/RoperDoc.html b/documentation/RoperDoc.html index f66c787..258b21d 100755 --- a/documentation/RoperDoc.html +++ b/documentation/RoperDoc.html @@ -10,7 +10,7 @@

    areaDetector Roper driver

    - December 6, 2008

    + August 18, 2009

    Mark Rivers

    @@ -34,8 +34,7 @@ This is a driver for the Roper Scientific detectors, which includes those from Princeton Instruments and Photometrics. - It inherits from ADDriver and implements most of the parameters in ADStdDriverParams.h. - It also implements a number of parameters that are specific to the Roper detectors.

    +

    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 @@ -59,6 +58,13 @@ 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 in NDStdDriverParam_t (see + asynNDArryDriver.h) and in ADStdDriverParam_t (see + 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

    @@ -80,8 +86,8 @@ - Implementation of Parameters in ADStdDriverParams.h and EPICS Record Definitions - in ADBase.template and NDFile.template + Implementation of Parameters in asynNDArrayDriver.h and ADDriver.h, and EPICS Record + Definitions in ADBase.template and NDFile.template @@ -98,7 +104,7 @@ $(P$(R)ImageMode The driver redefines the choices for the ADImageMode parameter (record $(P)$(R)ImageMode) - from ADStdDriverParams.h. The choices for the Roper are: + from ADDriver.h. The choices for the Roper are:

    • Normal: This is the same as pressing the Acquire button in WinView. It may collect more than 1 exposure per image if NumExposures>1, more than 1 image per acquisition @@ -145,7 +151,7 @@ $(P$(R)TriggerMode The driver redefines the choices for the ADTriggerMode parameter (record $(P)$(R)TriggerMode) - from ADStdDriverParams.h. The choices for the Roper are: + from ADDriver.h. The choices for the Roper are:
      • Free run: This acquires images as quickly as possible given the exposure and readout times.
      • @@ -159,12 +165,12 @@ - ADFileFormat + NDFileFormat $(P)$(R)FileFormat - The driver redefines the choices for the ADFileFormat parameter (record $(P)$(R)FileFormat) - from ADStdDriverParams.h. The choices for the Roper are: + The driver redefines the choices for the NDFileFormat parameter (record $(P)$(R)FileFormat) + from asynNDArrayDriver.h. The choices for the Roper are:
        • SPE: This is the default file format for WinView. It is a binary format with a header containing all of the acquisition and setup information.
        • @@ -193,9 +199,9 @@

          Roper specific parameters

          - The Roper driver implements the following parameters in addition to those in ADStdDriverParams.h. - Note that to reduce the width of this table the enum names have been split into - 2 lines, but these are just a single name, for example marCCDState. + 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 enum names have + been split into 2 lines, but these are just a single name, for example marCCDState.

          @@ -342,105 +348,28 @@
          • Frame type (ADFrameType). This may be supported in a future release to control acquisition of flat field and dark current frames.
          • -
          • Reading previous files (ADReadFile). This may be supported in a future release.
          • -
          • Capture or stream file saving (ADFileWriteMode, ADFileCapture, ADNumCapture, ADNumCaptured)
          • +
          • 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 following command, either from C/C++ or from - the EPICS IOC shell. -

          -
             
          -roperConfig(const char *portName, int maxBuffers, size_t maxMemory);
          +    The Roper driver is created with the prosilicaConfig 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)
             
          -
          - - - - - - - - - - - - - - - - - - -
          - Argument - Description
          - portName - The name of the asyn port for this detector. -
          - maxBuffers - Maximum number of buffers to be created for plugin callbacks. Passed to the constructor - for the ADDriver base class.
          - maxMemory - Maximum number of bytes of memory to be allocated for plugin callbacks. Passed to - the constructor for the ADDriver base class.

          - The following is an example st.cmd startup script: + 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.

          -
          < envPaths
          -errlogInit(20000)
          -
          -dbLoadDatabase("$(AREA_DETECTOR)/dbd/roperApp.dbd")
          -
          -roperApp_registerRecordDeviceDriver(pdbbase) 
          -
          -roperConfig("ROPER1", 50, 200000000)
          -asynSetTraceIOMask("ROPER1",0,2)
          -#asynSetTraceMask("ROPER1",0,9)
          -dbLoadRecords("$(AREA_DETECTOR)/ADApp/Db/ADBase.template",   "P=13ROPER1:,R=cam1:,PORT=ROPER1,ADDR=0,TIMEOUT=1")
          -dbLoadRecords("$(AREA_DETECTOR)/ADApp/Db/NDFile.template",   "P=13ROPER1:,R=cam1:,PORT=ROPER1,ADDR=0,TIMEOUT=1")
          -dbLoadRecords("$(AREA_DETECTOR)/ADApp/Db/roper.template",    "P=13ROPER1:,R=cam1:,PORT=ROPER1,ADDR=0,TIMEOUT=1")
          -
          -# Create a standard arrays plugin, set it to get data from the Roper driver.
          -drvNDStdArraysConfigure("ROPER1Image", 5, 0, "ROPER1", 0, -1)
          -dbLoadRecords("$(AREA_DETECTOR)/ADApp/Db/NDPluginBase.template","P=13ROPER1:,R=image1:,PORT=ROPER1Image,ADDR=0,TIMEOUT=1,NDARRAY_PORT=ROPER1,NDARRAY_ADDR=0")
          -dbLoadRecords("$(AREA_DETECTOR)/ADApp/Db/NDStdArrays.template", "P=13ROPER1:,R=image1:,PORT=ROPER1Image,ADDR=0,TIMEOUT=1,SIZE=16,FTVL=SHORT,NELEMENTS=1500000")
          -# Load the database to use with Stephen Mudie's IDL code
          -dbLoadRecords("$(AREA_DETECTOR)/ADApp/Db/EPICS_AD_Viewer.template", "P=13ROPER1:, R=image1:")
          -
          -# Create a file saving plugin
          -drvNDFileConfigure("ROPER1File", 5, 0, "ROPER1", 0)
          -dbLoadRecords("$(AREA_DETECTOR)/ADApp/Db/NDPluginBase.template","P=13ROPER1:,R=file1:,PORT=ROPER1File,ADDR=0,TIMEOUT=1,NDARRAY_PORT=ROPER1,NDARRAY_ADDR=0")
          -dbLoadRecords("$(AREA_DETECTOR)/ADApp/Db/NDFile.template",      "P=13ROPER1:,R=file1:,PORT=ROPER1File,ADDR=0,TIMEOUT=1")
          -
          -# Create an ROI plugin
          -drvNDROIConfigure("ROPER1ROI", 5, 0, "ROPER1", 0, 10, -1)
          -dbLoadRecords("$(AREA_DETECTOR)/ADApp/Db/NDPluginBase.template","P=13ROPER1:,R=ROI1:,  PORT=ROPER1ROI,ADDR=0,TIMEOUT=1,NDARRAY_PORT=ROPER1,NDARRAY_ADDR=0")
          -dbLoadRecords("$(AREA_DETECTOR)/ADApp/Db/NDROI.template",       "P=13ROPER1:,R=ROI1:,  PORT=ROPER1ROI,ADDR=0,TIMEOUT=1")
          -dbLoadRecords("$(AREA_DETECTOR)/ADApp/Db/NDROIN.template",      "P=13ROPER1:,R=ROI1:0:,PORT=ROPER1ROI,ADDR=0,TIMEOUT=1,HIST_SIZE=256")
          -dbLoadRecords("$(AREA_DETECTOR)/ADApp/Db/NDROIN.template",      "P=13ROPER1:,R=ROI1:1:,PORT=ROPER1ROI,ADDR=1,TIMEOUT=1,HIST_SIZE=256")
          -dbLoadRecords("$(AREA_DETECTOR)/ADApp/Db/NDROIN.template",      "P=13ROPER1:,R=ROI1:2:,PORT=ROPER1ROI,ADDR=2,TIMEOUT=1,HIST_SIZE=256")
          -dbLoadRecords("$(AREA_DETECTOR)/ADApp/Db/NDROIN.template",      "P=13ROPER1:,R=ROI1:3:,PORT=ROPER1ROI,ADDR=3,TIMEOUT=1,HIST_SIZE=256")
          -
          -# Load scan records
          -dbLoadRecords("$(SSCAN)/sscanApp/Db/scan.db", "P=13ROPER1:,MAXPTS1=2000,MAXPTS2=200,MAXPTS3=20,MAXPTS4=10,MAXPTSH=10")
          -
          -set_requestfile_path("./")
          -set_savefile_path("./autosave")
          -set_requestfile_path("$(SSCAN)/sscanApp/Db")
          -set_requestfile_path("$(AREA_DETECTOR)/ADApp/Db")
          -set_pass0_restoreFile("auto_settings.sav")
          -set_pass1_restoreFile("auto_settings.sav")
          -save_restoreSet_status_prefix("13ROPER1:")
          -dbLoadRecords("$(AUTOSAVE)/asApp/Db/save_restoreStatus.db", "P=13ROPER1:")
          -
          -iocInit()
          -
          -# save things every thirty seconds
          -create_monitor_set("auto_settings.req", 30,"P=13ROPER1:,D=cam1:")
          -
          -

          MEDM screens

          @@ -672,10 +601,11 @@ create_monitor_set("auto_settings.req", 30,"P=13ROPER1:,D=cam1:") 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 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.
            diff --git a/documentation/pilatusDoc.html b/documentation/pilatusDoc.html index 394b337..70c45b5 100755 --- a/documentation/pilatusDoc.html +++ b/documentation/pilatusDoc.html @@ -10,7 +10,7 @@

            areaDetector Pilatus driver

            - December 11, 2008

            + August 18, 2009

            Mark Rivers

            @@ -22,8 +22,8 @@
          • Introduction
          • Implementation of standard driver parameters
          • Pilatus specific parameters
          • -
          • MEDM screens
          • Configuration
          • +
          • MEDM screens
          • Performance measurements
          • Hardware notes
          • Restrictions
          • @@ -32,9 +32,8 @@ Introduction

            This is a driver for the Pilatus pixel array detectors - Dectris. It inherits from ADDriver and implements many of the parameters in - ADStdDriverParams.h. It also implements a number of parameters that are specific - to the Pilatus detectors.

            + Dectris. +

            The interface to the detector is via a TCP/IP socket interface to the camserver server that Dectris provides. The camserver program must be started before the areaDetector @@ -46,6 +45,13 @@ reads these disk files in order to read the data, because camserver does not provide another mechanism to access the data.

            +

            + This driver inherits from ADDriver. + It implements many of the parameters in NDStdDriverParam_t (see + asynNDArryDriver.h) and in ADStdDriverParam_t (see + ADArrayDriver.h). It also implements a number of parameters that are specific + to the Pilatus detectors.The + pilatusDetector class documentation describes this class in detail.

            Implementation of standard driver parameters

            @@ -73,7 +79,7 @@ $(P$(R)TriggerMode The driver redefines the choices for the ADTriggerMode parameter (record $(P)$(R)TriggerMode) - from ADStdDriverParams.h. The choices for the Pilatus are: + from ADDriver.h. The choices for the Pilatus are:

            • Internal (external signal not used)
            • External Enable (count while external trigger line is high, readout on high to @@ -142,7 +148,7 @@ - ADFilePath + NDFilePath $(P$(R)FilePath @@ -153,7 +159,7 @@ - ADFileFormat + NDFileFormat $(P)$(R)FileFormat @@ -161,9 +167,9 @@ The areaDetector Pilatus driver only supports TIFF files, so the extension should be .tif. When saving multiple images (NImages>1) camserver has its own rules for creating the names of the individual files. The rules are as follows. The name constructed - using the algorithm described for ADFileTemplate under - File Saving Parameters in ADStdDriverParams is used as a basename. The following - examples show the interpretation of the basename. + using the algorithm described for NDFileTemplate under + File Saving Parameters is used as a basename. The following examples show + the interpretation of the basename.
              Basename            Files produced
                    
               test6.tif           test6_00000.tif,  test6_00001.tif, ...
              @@ -187,9 +193,9 @@ test6_2_0035.tif    test6_2_0035.tif, test6_2_0036.tif, ...
                 

              Pilatus specific parameters

              - The Pilatus driver implements the following parameters in addition to those in ADStdDriverParams.h:. - Note that to reduce the width of this table the enum names have been split into - 2 lines, but these are just a single name, for example PilatusDelayTime. + The Pilatus 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 enum names have + been split into 2 lines, but these are just a single name, for example PilatusDelayTime.

              @@ -463,153 +469,27 @@ badX2,badY2 replacementX2,replacementY2
              -

              +

              Configuration

              - The Pilatus driver is created with the following command, either from C/C++ or from - the EPICS IOC shell. -

              -
                 
              -pilatusDetectorConfig(const char *portName, const char *camserverPort, 
              -                      int maxSizeX, int maxSizeY, int maxBuffers, size_t maxMemory);
              +    The pilatusDetector driver is created with the pilatusDetectorConfig command, either
              +    from C/C++ or from the EPICS IOC shell.

              +
              int pilatusDetectorConfig(const char *portName, const char *camserverPort, 
              +                          int maxSizeX, int maxSizeY,
              +                          int maxBuffers, size_t maxMemory,
              +                          int priority, int stackSize)
                 
              - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
              - Argument - Description
              - portName - The name of the asyn port for this detector. -
              - camserverPort - The name of the asyn TCP/IP port to communicate with camserver. This must have been - previously created with drvAsynIPPortConfig(), -
              - maxSizeX - The number of pixels in the X direction on the detector. This is 487 for the Pilatus - 100K.
              - maxSizeY - The number of pixels in the Y direction on the detector. This is 195 for the Pilatus - 100K.
              - maxBuffers - Maximum number of buffers to be created for plugin callbacks. Passed to the constructor - for the ADDriver base class.
              - maxMemory - Maximum number of bytes of memory to be allocated for plugin callbacks. Passed to - the constructor for the ADDriver base class.

              - The following is an example st.cmd startup script: + For details on the meaning of the parameters to this function refer to the detailed + documentation on the pilatusDetectorConfig function in the + pilatusDetector.cpp documentation and in the documentation for the constructor + for the pilatusDetector + class. +

              +

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

              -
              < envPaths
              -errlogInit(20000)
              -
              -dbLoadDatabase("$(AREA_DETECTOR)/dbd/pilatusDetectorApp.dbd")
              -pilatusDetectorApp_registerRecordDeviceDriver(pdbbase) 
              -
              -###
              -# Create the asyn port to talk to the Pilatus on port 41234.
              -drvAsynIPPortConfigure("camserver","gse-pilatus2:41234")
              -# Set the input and output terminators.
              -asynOctetSetInputEos("camserver", 0, "\030")
              -asynOctetSetOutputEos("camserver", 0, "\n")
              -
              -pilatusDetectorConfig("Pil", "camserver", 487, 195, 50, 200000000)
              -dbLoadRecords("$(AREA_DETECTOR)/ADApp/Db/ADBase.template",   "P=13PIL1:,R=cam1:,PORT=Pil,ADDR=0,TIMEOUT=1")
              -dbLoadRecords("$(AREA_DETECTOR)/ADApp/Db/pilatus.template","P=13PIL1:,R=cam1:,PORT=Pil,ADDR=0,TIMEOUT=1,CAMSERVER_PORT=camserver")
              -
              -# Create a standard arrays plugin
              -drvNDStdArraysConfigure("PilImage", 5, 0, "Pil", 0, -1)
              -dbLoadRecords("$(AREA_DETECTOR)/ADApp/Db/NDPluginBase.template","P=13PIL1:,R=image1:,PORT=PilImage,ADDR=0,TIMEOUT=1,NDARRAY_PORT=Pil,NDARRAY_ADDR=0")
              -dbLoadRecords("$(AREA_DETECTOR)/ADApp/Db/NDStdArrays.template", "P=13PIL1:,R=image1:,PORT=PilImage,ADDR=0,TIMEOUT=1,SIZE=32,FTVL=LONG,NELEMENTS=94965")
              -
              -# Create an ROI plugin with 8 ROIs
              -drvNDROIConfigure("PilROI", 5, 0, "Pil", 0, 8, -1)
              -dbLoadRecords("$(AREA_DETECTOR)/ADApp/Db/NDPluginBase.template","P=13PIL1:,R=ROI1:,  PORT=PilROI,ADDR=0,TIMEOUT=1,NDARRAY_PORT=Pil,NDARRAY_ADDR=0")
              -dbLoadRecords("$(AREA_DETECTOR)/ADApp/Db/NDROI.template",       "P=13PIL1:,R=ROI1:,  PORT=PilROI,ADDR=0,TIMEOUT=1")
              -dbLoadRecords("$(AREA_DETECTOR)/ADApp/Db/NDROIN.template",      "P=13PIL1:,R=ROI1:0:,PORT=PilROI,ADDR=0,TIMEOUT=1,HIST_SIZE=256")
              -dbLoadRecords("$(AREA_DETECTOR)/ADApp/Db/NDROIN.template",      "P=13PIL1:,R=ROI1:1:,PORT=PilROI,ADDR=1,TIMEOUT=1,HIST_SIZE=256")
              -dbLoadRecords("$(AREA_DETECTOR)/ADApp/Db/NDROIN.template",      "P=13PIL1:,R=ROI1:2:,PORT=PilROI,ADDR=2,TIMEOUT=1,HIST_SIZE=256")
              -dbLoadRecords("$(AREA_DETECTOR)/ADApp/Db/NDROIN.template",      "P=13PIL1:,R=ROI1:3:,PORT=PilROI,ADDR=3,TIMEOUT=1,HIST_SIZE=256")
              -dbLoadRecords("$(AREA_DETECTOR)/ADApp/Db/NDROIN.template",      "P=13PIL1:,R=ROI1:4:,PORT=PilROI,ADDR=3,TIMEOUT=1,HIST_SIZE=256")
              -dbLoadRecords("$(AREA_DETECTOR)/ADApp/Db/NDROIN.template",      "P=13PIL1:,R=ROI1:5:,PORT=PilROI,ADDR=3,TIMEOUT=1,HIST_SIZE=256")
              -dbLoadRecords("$(AREA_DETECTOR)/ADApp/Db/NDROIN.template",      "P=13PIL1:,R=ROI1:6:,PORT=PilROI,ADDR=3,TIMEOUT=1,HIST_SIZE=256")
              -dbLoadRecords("$(AREA_DETECTOR)/ADApp/Db/NDROIN.template",      "P=13PIL1:,R=ROI1:7:,PORT=PilROI,ADDR=3,TIMEOUT=1,HIST_SIZE=256")
              -
              -# Create "fastSweep" drivers for the MCA record to do on-the-fly scanning of ROI data
              -initFastSweep("PilSweepTotal", "PilROI", 8, 2048, "TOTAL_ARRAY", "CALLBACK_PERIOD")
              -initFastSweep("PilSweepNet", "PilROI", 8, 2048, "NET_ARRAY", "CALLBACK_PERIOD")
              -
              -# Load MCA records for the fast sweep drivers
              -dbLoadRecords("$(MCA)/mcaApp/Db/mca.db", "P=13PIL1:,M=ROI1:0:TotalArray,DTYP=asynMCA,NCHAN=2048,INP=@asyn(PilSweepTotal 0)")
              -dbLoadRecords("$(MCA)/mcaApp/Db/mca.db", "P=13PIL1:,M=ROI1:1:TotalArray,DTYP=asynMCA,NCHAN=2048,INP=@asyn(PilSweepTotal 1)")
              -dbLoadRecords("$(MCA)/mcaApp/Db/mca.db", "P=13PIL1:,M=ROI1:2:TotalArray,DTYP=asynMCA,NCHAN=2048,INP=@asyn(PilSweepTotal 2)")
              -dbLoadRecords("$(MCA)/mcaApp/Db/mca.db", "P=13PIL1:,M=ROI1:3:TotalArray,DTYP=asynMCA,NCHAN=2048,INP=@asyn(PilSweepTotal 3)")
              -dbLoadRecords("$(MCA)/mcaApp/Db/mca.db", "P=13PIL1:,M=ROI1:4:TotalArray,DTYP=asynMCA,NCHAN=2048,INP=@asyn(PilSweepTotal 4)")
              -dbLoadRecords("$(MCA)/mcaApp/Db/mca.db", "P=13PIL1:,M=ROI1:5:TotalArray,DTYP=asynMCA,NCHAN=2048,INP=@asyn(PilSweepTotal 5)")
              -dbLoadRecords("$(MCA)/mcaApp/Db/mca.db", "P=13PIL1:,M=ROI1:6:TotalArray,DTYP=asynMCA,NCHAN=2048,INP=@asyn(PilSweepTotal 6)")
              -dbLoadRecords("$(MCA)/mcaApp/Db/mca.db", "P=13PIL1:,M=ROI1:7:TotalArray,DTYP=asynMCA,NCHAN=2048,INP=@asyn(PilSweepTotal 7)")
              -
              -dbLoadRecords("$(MCA)/mcaApp/Db/mca.db", "P=13PIL1:,M=ROI1:0:NetArray,DTYP=asynMCA,NCHAN=2048,INP=@asyn(PilSweepNet 0)")
              -dbLoadRecords("$(MCA)/mcaApp/Db/mca.db", "P=13PIL1:,M=ROI1:1:NetArray,DTYP=asynMCA,NCHAN=2048,INP=@asyn(PilSweepNet 1)")
              -dbLoadRecords("$(MCA)/mcaApp/Db/mca.db", "P=13PIL1:,M=ROI1:2:NetArray,DTYP=asynMCA,NCHAN=2048,INP=@asyn(PilSweepNet 2)")
              -dbLoadRecords("$(MCA)/mcaApp/Db/mca.db", "P=13PIL1:,M=ROI1:3:NetArray,DTYP=asynMCA,NCHAN=2048,INP=@asyn(PilSweepNet 3)")
              -dbLoadRecords("$(MCA)/mcaApp/Db/mca.db", "P=13PIL1:,M=ROI1:4:NetArray,DTYP=asynMCA,NCHAN=2048,INP=@asyn(PilSweepNet 4)")
              -dbLoadRecords("$(MCA)/mcaApp/Db/mca.db", "P=13PIL1:,M=ROI1:5:NetArray,DTYP=asynMCA,NCHAN=2048,INP=@asyn(PilSweepNet 5)")
              -dbLoadRecords("$(MCA)/mcaApp/Db/mca.db", "P=13PIL1:,M=ROI1:6:NetArray,DTYP=asynMCA,NCHAN=2048,INP=@asyn(PilSweepNet 6)")
              -dbLoadRecords("$(MCA)/mcaApp/Db/mca.db", "P=13PIL1:,M=ROI1:7:NetArray,DTYP=asynMCA,NCHAN=2048,INP=@asyn(PilSweepNet 7)")
              -
              -
              -#asynSetTraceMask("Pil",0,255)
              -#asynSetTraceMask("PilROI",0,3)
              -#asynSetTraceIOMask("PilROI",0,4)
              -
              -# Load scan records for scanning energy threshold
              -dbLoadRecords("$(SSCAN)/sscanApp/Db/scan.db", "P=13PIL1:cam1:,MAXPTS1=2000,MAXPTS2=200,MAXPTS3=20,MAXPTS4=10,MAXPTSH=10")
              -
              -set_requestfile_path("./")
              -set_savefile_path("./autosave")
              -set_requestfile_path("$(AREA_DETECTOR)/ADApp/Db")
              -set_requestfile_path("$(SSCAN)/sscanApp/Db")
              -set_pass0_restoreFile("auto_settings.sav")
              -set_pass1_restoreFile("auto_settings.sav")
              -save_restoreSet_status_prefix("13PIL1:")
              -dbLoadRecords("$(AUTOSAVE)/asApp/Db/save_restoreStatus.db", "P=13PIL1:")
              -
              -iocInit()
              -
              -# save things every thirty seconds
              -create_monitor_set("auto_settings.req", 30,"P=13PIL1:,D=cam1:")
              -
              -

              MEDM screens

              diff --git a/documentation/prosilicaDoc.html b/documentation/prosilicaDoc.html index 1dcd987..5116ef0 100755 --- a/documentation/prosilicaDoc.html +++ b/documentation/prosilicaDoc.html @@ -10,7 +10,7 @@

              areaDetector Prosilica driver

              - January 30, 2009

              + August 18, 2009

              Mark Rivers

              @@ -20,27 +20,39 @@ Contents

              Overview

              This is a driver for Gigabit Ethernet and Firewire cameras from - Prosilica. It inherits from ADDriver and implements nearly all of the parameters - in ADStdDriverParams.h. It also implements a number of parameters that are specific - to the Prosilica cameras. The driver is only supported under Windows (EPICS win32-x86 - architecture) and Linux because the vendor library is only provided as a pre-built - binary for those operating systems. The vendor library provided by Prosilica does - callbacks to a user-supplied function each time there is a new frame. Thus, the - driver does not need to create a thread itself for callbacks. + Prosilica. The driver is only supported under Windows (EPICS win32-x86 architecture) + and Linux because the vendor library is only provided as a pre-built binary for + those operating systems. The vendor library provided by Prosilica does callbacks + to a user-supplied function each time there is a new frame. Thus, the driver does + not need to create a thread itself for callbacks."

              The vendor library supports saving individual frames as TIFF files, and this is - implemented in the driver. The NDPluginFile plugin can be used to capture or stream - images much more rapidly in the netCDF file format. + implemented in the driver. The NDFileNetCDF + plugin can be used to capture or stream images much more rapidly in the netCDF file + format.

              - The driver redefines the choices for 2 of the parameters defined in ADStdDriverParams.h. + This driver inherits from ADDriver. + It implements nearly all of the parameters in NDStdDriverParam_t (see + asynNDArryDriver.h) and in ADStdDriverParam_t (see + ADArrayDriver.h). It also implements a number of parameters that are specific + to the Prosilica cameras. The + prosilica class documentation describes this class in detail.

              +

              + Implementation of standard driver parameters

              +

              + The driver redefines the choices for several of the parameters defined in ADDriver.h. The ADTriggerMode choices for the Prosilica are:

                @@ -58,7 +70,7 @@ in the driver.

                - The ADFileFormat choices for the Prosilica are: + The NDFileFormat choices for the Prosilica are:

                • TIFF (this is the only format supported)
                • @@ -66,14 +78,14 @@ with only 1 choice)

                - The ADDataType choices for the Prosilica are: + The NDDataType choices for the Prosilica are:

                • NDUInt8 (8-bit data)
                • NDUInt16 (12 or 16 bit data)

                - The ADColorMode choices for the Prosilica are: + The NDColorMode choices for the Prosilica are:

                • NDColorModeMono (monochromatic data)
                • @@ -84,9 +96,11 @@ The color Prosilica cameras are also capable of various YUV color formats but these are not supported in the driver. They may be added in a future release.

                  +

                  + Pilatus specific parameters

                  The Prosilica driver implements the following parameters in addition to those in - ADStdDriverParams.h: + asynNDArrayDriver.h and ADDriver.h:

                  @@ -655,6 +669,37 @@
                  +

                  + Configuration

                  +

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

                  +
                  int prosilicaConfig(char *portName,
                  +                    int uniqueId,
                  +                    int maxBuffers, size_t maxMemory,
                  +                    int priority, int stackSize)
                  +  
                  +

                  + The uniqueId parameter is a unique number assigned to each Prosilica camera. + areaDetector uses this number, rather than the TCP/IP address, to find the camera + and connect to it. This is done so that the cameras can be configured to use DHCP, + and hence have non-predictable TCP/IP addresses. This does mean that areaDetector + IOC must be on the same subnet as the camera, since cameras cannot be found by UniqueID + through routers. The simplest way to determine the uniqueId of a camera is to run + the Prosilica GigEViewer application, select the camera, and press the "i" icon + on the bottom of the main window to show the camera information for this camera. + The Unique ID will be displayed on the first line in the information window. For + details on the meaning of the other parameters to this function refer to the detailed + documentation on the prosilicaConfig function in the + prosilica.cpp documentation and in the documentation for the constructor for + the prosilica class. +

                  +

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

                  +

                  + MEDM screens

                  The following is the MEDM screen ADBase.adl connected to a Prosilica camera.

                  @@ -685,8 +730,8 @@ when the areaDetector driver is running it does not gracefully recover.

                  - The Linux driver currently requires some modifications to EPICS base. This should - be resolved either by modifying base or with changes from Prosilica for their driver. + The Linux driver requires a patch for EPICS base R3.14.10 because EPICS does not + correctly pass on SIGALARM signals. This will be fixed in R3.14.11.

                  diff --git a/documentation/pvcamDoc.html b/documentation/pvcamDoc.html index f3e3c3e..8a393e3 100644 --- a/documentation/pvcamDoc.html +++ b/documentation/pvcamDoc.html @@ -1,193 +1,193 @@ - - - areaDetector PVCAM driver - - - -
                  -

                  - areaDetector PVCAM driver

                  -

                  - August 18, 2009

                  -

                  - Brian Tieman, John Hammonds, Mark Rivers

                  -

                  - Argonne National Laboratory and University of Chicago

                  -
                  -

                  - Table of Contents

                  - -

                  - Introduction

                  -

                  - This is a driver for the Roper Scientific - detectors, which includes those from - Princeton Instruments and Photometrics.

                  -

                  - The driver is based upon the PVCAM library from Roper, and only runs on Microsoft - Windows computers. This driver is complementary to the areaDetector - Roper driver. That driver uses the Microsoft COM interface to control the - Roper WinView program. This driver works at a lower level, communicating instead - with the PVCAM library layer. PVCAM supports all Photometrics cameras, and many, - but not all, Princeton Instruments cameras. -

                  -

                  - ADD ADDTIONAL INTRODUCTORY TEXT HERE.

                  -

                  - This driver inherits from ADDriver. - It implements many of the parameters in NDStdDriverParam_t (see - asynNDArryDriver.h) and in ADStdDriverParam_t (see - ADArrayDriver.h). It also implements a number of parameters that are specific - to the Roper detectors. The pvCam - class documentation describes this class in detail.

                  -

                  - Implementation of standard driver parameters

                  -

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

                  -

                  - DOCUMENT IMPLEMENTATION OF STANDARD DRIVER PARAMETERS IN THIS TABLE

                  - - - - - - - - - - - - - - - - -
                  - Implementation of Parameters in asynNDArrayDriver.h and ADDriver.h, and EPICS Record - Definitions in ADBase.template and NDFile.template
                  - Enum name - EPICS record name - Description
                  - ADNumImages - $(P$(R)NumImages - Controls the number of images to acquire when ADImageMode is ADImageMultiple.
                  -

                  - PVCAM specific parameters

                  -

                  - The PVCAM 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 enum names have - been split into 2 lines, but these are just a single name, for example PVCamInitDetector. -

                  - - - - - - - - - - - - - - - - - - - - - - - - -
                  - Parameter Definitions in pvcamSrc.h and EPICS Record Definitions in pvCam.template
                  - Enum name - asyn interface - Access - Description - drvUser string - EPICS record name - EPICS record type
                  - PVCam
                  - InitDetector
                  - asynInt32 - r/w - Initializes the detector - PVCAM_INITIALIZE_DETECTOR - $(P)$(R)Initialize
                  - $(P)$(R)Initialize_RBV
                  - longout
                  - longin
                  -

                  - Unsupported standard driver parameters

                  -

                  - The PVCAM driver does not support the following standard driver parameters because - they are not supported in the PVCAM library:

                  -
                    -
                  • List any unsupported parameters here (WORK NEEDED)
                  • -
                  -

                  - Configuration

                  -

                  - The PVCAM driver is created with the pvCamConfig command, either from C/C++ or from - the EPICS IOC shell.

                  + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> + + + areaDetector PVCAM driver + + + +
                  +

                  + areaDetector PVCAM driver

                  +

                  + August 18, 2009

                  +

                  + Brian Tieman, John Hammonds, Mark Rivers

                  +

                  + Argonne National Laboratory and University of Chicago

                  +
                  +

                  + Table of Contents

                  + +

                  + Introduction

                  +

                  + This is a driver for the Roper Scientific + detectors, which includes those from + Princeton Instruments and Photometrics.

                  +

                  + The driver is based upon the PVCAM library from Roper, and only runs on Microsoft + Windows computers. This driver is complementary to the areaDetector + Roper driver. That driver uses the Microsoft COM interface to control the + Roper WinView program. This driver works at a lower level, communicating instead + with the PVCAM library layer. PVCAM supports all Photometrics cameras, and many, + but not all, Princeton Instruments cameras. +

                  +

                  + ADD ADDTIONAL INTRODUCTORY TEXT HERE.

                  +

                  + This driver inherits from ADDriver. + It implements many of the parameters in NDStdDriverParam_t (see + asynNDArryDriver.h) and in ADStdDriverParam_t (see + ADArrayDriver.h). It also implements a number of parameters that are specific + to the Roper detectors. The pvCam + class documentation describes this class in detail.

                  +

                  + Implementation of standard driver parameters

                  +

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

                  +

                  + DOCUMENT IMPLEMENTATION OF STANDARD DRIVER PARAMETERS IN THIS TABLE

                  + + + + + + + + + + + + + + + + +
                  + Implementation of Parameters in asynNDArrayDriver.h and ADDriver.h, and EPICS Record + Definitions in ADBase.template and NDFile.template
                  + Enum name + EPICS record name + Description
                  + ADNumImages + $(P$(R)NumImages + Controls the number of images to acquire when ADImageMode is ADImageMultiple.
                  +

                  + PVCAM specific parameters

                  +

                  + The PVCAM 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 enum names have + been split into 2 lines, but these are just a single name, for example PVCamInitDetector. +

                  + + + + + + + + + + + + + + + + + + + + + + + + +
                  + Parameter Definitions in pvcamSrc.h and EPICS Record Definitions in pvCam.template
                  + Enum name + asyn interface + Access + Description + drvUser string + EPICS record name + EPICS record type
                  + PVCam
                  + InitDetector
                  + asynInt32 + r/w + Initializes the detector + PVCAM_INITIALIZE_DETECTOR + $(P)$(R)Initialize
                  + $(P)$(R)Initialize_RBV
                  + longout
                  + longin
                  +

                  + Unsupported standard driver parameters

                  +

                  + The PVCAM driver does not support the following standard driver parameters because + they are not supported in the PVCAM library:

                  +
                    +
                  • List any unsupported parameters here (WORK NEEDED)
                  • +
                  +

                  + Configuration

                  +

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

                  int pvCamConfig(const char *portName, int maxSizeX, int maxSizeY, int dataType, 
                                   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 pvCamConfig function in the - pvCam.cpp documentation and in the documentation for the constructor for the - pvCam class. -

                  -

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

                  -

                  - MEDM screens

                  -

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

                  -

                  - pvCam.adl is the main screen used to control the PVCAM driver. -

                  -
                  -

                  - pvCam.adl

                  - pvCam.png
                  -

                  - Performance measurements

                  -

                  - The following measurements were done to demonstrate the performance that can be - obtained with the areaDetector PVCAM driver.

                  -

                  - PUT A TABLE OF PERFORMANCE MEASUREMENTS HERE

                  -

                  - Restrictions

                  -

                  - The following are some current restrictions of the PVCAM driver:

                  -
                    -
                  • DOCUMENT ANY IMPORTANT RESTRICTIONS OF THE PVCAM DRIVER HERE
                  • -
                  - - +
              +

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

              +

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

              +

              + MEDM screens

              +

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

              +

              + pvCam.adl is the main screen used to control the PVCAM driver. +

              +
              +

              + pvCam.adl

              + pvCam.png
              +

              + Performance measurements

              +

              + The following measurements were done to demonstrate the performance that can be + obtained with the areaDetector PVCAM driver.

              +

              + PUT A TABLE OF PERFORMANCE MEASUREMENTS HERE

              +

              + Restrictions

              +

              + The following are some current restrictions of the PVCAM driver:

              +
                +
              • DOCUMENT ANY IMPORTANT RESTRICTIONS OF THE PVCAM DRIVER HERE
              • +
              + + diff --git a/documentation/simDetectorDoc.html b/documentation/simDetectorDoc.html index 65cb46e..087e8dd 100755 --- a/documentation/simDetectorDoc.html +++ b/documentation/simDetectorDoc.html @@ -10,7 +10,7 @@

              areaDetector Simulation driver

              - January 30, 2009

              + August 18, 2009

              Mark Rivers

              @@ -24,70 +24,31 @@
            • Introduction
            • Simulation driver specific parameters
            • Unsupported standard driver parameters
            • -
            • Screenshots
            • Configuration
            • +
            • MEDM screens
            • +
            • Image viewers

            Introduction

            - 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, - with the exception of the file saving parameters, which it does not implement. 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);
            -
            -

            - In the constructor simDetector the portName, maxBuffers, and maxMemory - arguments are passed to the ADDriver base class constructor. 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. + simDetector is a driver for a simulated area 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.

            - 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. -

            + This driver inherits from ADDriver. + It implements nearly all of the parameters in NDStdDriverParam_t (see + asynNDArryDriver.h) and in ADStdDriverParam_t (see + ADArrayDriver.h), with the exception of the file saving parameters, which + it does not implement. It also implements a few parameters that are specific to + the simulation detector. The + simDetector class documentation describes this class in detail.

            - 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: + 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.

            -
                    /* 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);
            -

            Simulation driver specific parameters

            @@ -151,6 +112,60 @@ public: ao
            ai + + + SimGainRed + + asynFloat64 + + r/w + + Gain of the red channel + + SIM_GAIN_RED + + $(P)$(R)GainRed
            + $(P)$(R)GainRed_RBV + + ao
            + ai + + + + SimGainGreen + + asynFloat64 + + r/w + + Gain of the green channel + + SIM_GAIN_GREEN + + $(P)$(R)GainGreen
            + $(P)$(R)GainGreen_RBV + + ao
            + ai + + + + SimGainBlue + + asynFloat64 + + r/w + + Gain of the blue channel + + SIM_GAIN_BLUE + + $(P)$(R)GainBlue
            + $(P)$(R)GainBlue_RBV + + ao
            + ai + SimResetImage @@ -159,7 +174,7 @@ public: r/w - Reset image back to initial conditions when 1. + Set to 1 to reset image back to initial conditions RESET_IMAGE @@ -171,6 +186,26 @@ public: +

            + For monochrome images (NDColorMode=NDColorModeMono) the simulation driver initially + sets the image[i, j] = i*SimGainX + j*SimGainY * ADGain * ADAcquireTime * 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 ADgain*ADAcquireTime*1000. Thus if ADGain=1 and ADAcquireTime=.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 acquire + times. +

            +

            + For color images (NDColorMode=NDColorModeRGB1, RGB2 or RGB3) there are 3 images + computed, one each for the red, green and blue channels. Each image is computed + with the same algorithm as for the monochrome case, except each is multiplied by + its appropriate gain factor (SimGainRed, SimGainGreen, SimGainBlue). Thus if each + of these color gains is 1.0 the color image will be identical to the monochrome + image, but if the color gains are different from each other then image will have + color bands.

            Unsupported standard driver parameters

              @@ -178,8 +213,49 @@ public:
            • Collect: Trigger mode (ADTriggerMode)
            • File control: No file I/O is supported
            -

            - Screenshots

            +

            + Configuration

            +

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

            +
            int simDetectorConfig(const char *portName, 
            +                      int maxSizeX, int maxSizeY, int dataType,
            +                      int maxBuffers, size_t maxMemory, 
            +                      int priority, int stackSize)
            +  
            +

            + The simDetector-specific fields in this command are:

            +
              +
            • maxSizeX Maximum number of pixels in the X direction for the simulated + detector.
            • +
            • maxSizeY Maximum number of pixels in the Y direction for the simulated + detector.
            • +
            • dataType Initial data type of the detector data. These are the enum + values for NDDataType_t, i.e. +
                +
              • 0=NDInt8
              • +
              • 1=NDUInt8
              • +
              • 2=NDInt16
              • +
              • 3=NDUInt16
              • +
              • 4=NDInt32
              • +
              • 5=NDUInt32
              • +
              • 6=NDFloat32
              • +
              • 7=NDFloat64
              • +
              +
            • +
            +

            + For details on the meaning of the other parameters to this function refer to the + detailed documentation on the simDetectorConfig function in the + simDetector.cpp documentation and in the documentation for the constructor + for the simDetector class. +

            +

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

            +

            + MEDM screens

            The following is the MEDM screen ADBase.adl connected to a simulation detector.

            @@ -197,102 +273,26 @@ public: simDetector.adl simDetector.png +

            + Image viewers

            - The following is an IDL - epics_ad_display screen using - image_display to display the simulation detector images. + The following is an IDL epics_ad_display + screen using + image_display to display the simulation detector images.

            epics_ad_display.pro

            simDetector_image_display.png
            -

            - Configuration

            - This driver is configured via the simDetectorConfig() function. If this - is to be used in an IOC, it must be called before iocInit(). It has the - following syntax: -

            -
            simDetectorConfig(const char *portName, int maxSizeX, int maxSizeY, 
            -                  int dataType, int maxBuffers, size_t maxMemory)
            -  
            - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
            - Argument - Description
            - portName - The name of the asyn port for this detector. -
            - maxSizeX - Maximum number of pixels in the X direction for the simulated detector. -
            - maxSizeY - Maximum number of pixels in the Y direction for the simulated detector. -
            - dataType - Initial data type of the detector data. These are the enum values for NDDataType_t, - i.e. -
              -
            • 0=NDInt8
            • -
            • 1=NDUInt8
            • -
            • 2=NDInt16
            • -
            • 3=NDUInt16
            • -
            • 4=NDInt32
            • -
            • 5=NDUInt32
            • -
            • 6=NDFloat32
            • -
            • 7=NDFloat64
            • -
            -
            - maxBuffers - Maxiumum number of NDArray objects (image buffers) this driver is allowed to allocate. - The driver itself requires 2 buffers, and each queue element in a plugin can require - one buffer. So, for example, if 3 plugins are connected to this driver, and each - has a queue size of 10, then maxBuffers should be at least 32. -
            - maxMemory - Maxiumum number of bytes of memory for all NDArray objects (image buffers) allocated - by this driver. If maxSizeX=maxSizeY=1024, and maxBuffers=32, then maxMemory should - be at least 33554432 (32MB). -
            -

            - If being used in an IOC, and an EPICS PV interface with the driver is desired, the - ADBase.template and simDetector.template databases should also - be loaded for the driver instance. -

            -

            - The areaDetector software comes with an example IOC for the simulation driver, - iocBoot/iocSimDetector. + The following is an ImageJ plugin + EPICS_AD_Viewer screen displaying color simulation detector images.

            +
            +

            + ImageJ plugin EPICS_AD_Viewer

            + simDetector_ImageJ_display.png +