Convert to Linux terminators

git-svn-id: https://subversion.xor.aps.anl.gov/synApps/areaDetector/trunk@7708 dc6c5ff5-0b8b-c028-a01f-ffb33f00fc8b
This commit is contained in:
rivers
2008-10-20 16:26:28 +00:00
parent d067316459
commit 96e6b24271
4 changed files with 1109 additions and 1109 deletions
+228 -228
View File
@@ -1,228 +1,228 @@
a<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>areaDetector Plugin NDPluginFile</title>
</head>
<body>
<div style="text-align: center">
<h1>
areaDetector Plugin NDPluginFile</h1>
<h2>
September 19, 2008</h2>
<h2>
Mark Rivers</h2>
<h2>
University of Chicago</h2>
</div>
<h2>
Contents</h2>
<ul>
<li><a href="#Overview">Overview</a></li>
<li><a href="#Configuration">Configuration</a></li>
<li><a href="#Screens">Screen shots</a></li>
<li><a href="#netCDF">netCDF file contents</a></li>
<li><a href="#IDL">IDL file reading function</a></li>
<li><a href="#Future">Future plans</a></li>
</ul>
<h2 id="Overview">
Overview
</h2>
<p>
NDPluginFile saves the NDArray data from a callback to a disk file.
</p>
<p>
NDPluginFile inherits from NDPluginDriver. This plugin currently saves data in the
<a href="http://www.unidata.ucar.edu/software/netcdf">netCDF</a> file format, which
is a portable self-describing binary file format supported by <a href="http://www.unidata.ucar.edu/">
UniData</a> at <a href="http://www.ucar.edu/">UCAR (University Corporation for Atmospheric
Research).</a>
</p>
<p>
The NDArray callback data can be written to disk in 1 of 3 modes:
</p>
<ol>
<li>Single mode. In this mode each NDArray callback results in a separate disk file.</li>
<li>Capture mode. In this mode a memory buffer is allocated before saving begins.
Callback arrays are placed into this buffer, and when capture stops the file is
written to disk. This mode limits the number of frames that can be saved, because
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.</li>
<li>Stream mode. In this mode the data are written to a single disk file, with each
frame being 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.</li>
</ol>
<p>
The NDPluginFile public interface is defined in NDPluginFile.h as follows:
</p>
<pre>/* Note that the file format enum must agree with the mbbo/mbbi records in the NDFile.template file */
typedef enum {
NDFileFormatNetCDF,
} NDPluginFileFormat_t;
typedef enum {
NDPluginFileModeSingle,
NDPluginFileModeCapture,
NDPluginFileModeStream
} NDPluginFileMode_t;
...
class NDPluginFile : public NDPluginDriver {
public:
NDPluginFile(const char *portName, int queueSize, int blockingCallbacks,
const char *NDArrayPort, int NDArrayAddr);
/* These methods override those in the base class */
void processCallbacks(NDArray *pArray);
asynStatus writeInt32(asynUser *pasynUser, epicsInt32 value);
asynStatus writeNDArray(asynUser *pasynUser, void *genericPointer);
asynStatus drvUserCreate(asynUser *pasynUser, const char *drvInfo,
const char **pptypeName, size_t *psize);
...
}
</pre>
<p>
NDPluginFile supports all of the file saving parameters defined in <a href="areaDetectorDoc.html#ADStdDriverParams">
ADStdDriverParams.h</a>, e.g. ADFilePath, ADFileName, etc. Thus, the same interface
that is used for saving files directly in a driver is used for this plugin.
</p>
<h2 id="Configuration">
Configuration</h2>
<p>
The NDPluginFile plugin is created with the following command, either from C/C++
or from the EPICS IOC shell.
</p>
<pre>drvNDFileConfigure(const char *portName, int queueSize, int blockingCallbacks,
const char *NDArrayPort, int NDArrayAddr)
</pre>
<table border="1" cellpadding="2" cellspacing="2" style="text-align: left">
<tr>
<th>
Argument</th>
<th>
Description</th>
</tr>
<tr>
<td>
<code>portName</code></td>
<td>
The name of the asyn port for this plugin.
</td>
</tr>
<tr>
<td>
<code>queueSize</code></td>
<td>
The maximum number of NDArray objects that can be queued for processing. Passed
to the NDPluginDriver base class constructor.
</td>
</tr>
<tr>
<td>
<code>blockingCallbacks</code></td>
<td>
Flag controlling whether callbacks block. Passed to the NDPluginDriver base class
constructor.
</td>
</tr>
<tr>
<td>
<code>NDArrayPort</code></td>
<td>
The name of the asyn port of the driver that will provide the NDArray data. Passed
to the NDPluginDriver base class constructor.
</td>
</tr>
<tr>
<td>
<code>NDArrayAddr</code></td>
<td>
The asyn addr of the asyn port of the driver that will provide the NDArray data.
Passed to the NDPluginDriver base class constructor.
</td>
</tr>
</table>
<h2 id="Screens">
Screen shots</h2>
<p>
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 for
drivers that do not support saving files to disk themselves.
</p>
<div style="text-align: center">
<h3>
NDFile.adl</h3>
<p>
<img alt="NDFile.png" src="NDFile.png" /></p>
</div>
<h2 id="netCDF">
netCDF file contents</h2>
<p>
The following is the header contents of a netCDF file produced by this plugin. This
information was produced with the following command:</p>
<pre>
ncdump -h test_A_2.nc
netcdf test_A_2 {
dimensions:
numArrays = 200 ;
dim0 = 480 ;
dim1 = 640 ;
variables:
int uniqueId(numArrays) ;
double timeStamp(numArrays) ;
byte array_data(numArrays, dim0, dim1) ;
// global attributes:
:dataType = 0 ;
:numArrayDims = 2 ;
:dimSize = 640, 480 ;
:dimOffset = 0, 0 ;
:dimBinning = 1, 1 ;
:dimReverse = 0, 0 ;
}
</pre>
<p>
This is an explanation of this output:
</p>
<ul>
<li>dimensions: numArrays is the number of arrays in the file. It will be 1 for files
collected in Single mode, and is normally &gt 1 for files collected in Capture or
Stream mode. For each array dim0 is the slowest varying dimension, dim1 the next
slowest, etc.</li>
<li>variables: There are 3 variables in the netCDF file. uniqueId is the unique ID
number of each array. timeStamp is the timestamp in seconds for each array. array_data
is the array data. Its data type depends on the data type of the NDArray data passed
in the callbacks. It dimensions are [numArrays, dim0, dim1, ...dimN]. This notation
is in the Fortran syntax where the slowest varying dimension comes first in the
list.</li>
<li>global attributes. dataType is the NDDataType_t enum value for the array data
type. numArrayDims is the number of dimensions in each array. array_data has 1 more
dimension than this, numArrays, because it contains all of the array callback data.
dimSize is an array[numArrayDims] containing the size of each dimension, with the
fastest varying dimension first. dimOffset, dimBinning, and dimReverse are the values
of the offset, binning and reverse fields in the NDDimension_t structure for each
dimension.</li>
</ul>
<h2 id="IDL">
IDL file reading function</h2>
<p>
There is an IDL function, <a href="http://cars.uchicago.edu/software/idl/detector_routines.html#read_nd_netcdf">
read_nd_netcdf</a> that can be used to read the netCDF files created by this plugin.
This routine is contained in the <a href="http://cars.uchicago.edu/software/idl/detectors.html#read_nd_netcdf">
CARS IDL detector package</a>. This function is currently limited to reading the
entire file at once, so it may fail for very large files on machines with insufficient
virtual memory. This will be fixed in a future release.
</p>
<h2 id="Future">
Future plans</h2>
<p>
Additional file formats, such as TIFF and HDF may be supported in the future.
</p>
<p>
The IDL function described above will be enhanced to allow reading only a subset
of the file at a time.
</p>
</body>
</html>
a<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>areaDetector Plugin NDPluginFile</title>
</head>
<body>
<div style="text-align: center">
<h1>
areaDetector Plugin NDPluginFile</h1>
<h2>
September 19, 2008</h2>
<h2>
Mark Rivers</h2>
<h2>
University of Chicago</h2>
</div>
<h2>
Contents</h2>
<ul>
<li><a href="#Overview">Overview</a></li>
<li><a href="#Configuration">Configuration</a></li>
<li><a href="#Screens">Screen shots</a></li>
<li><a href="#netCDF">netCDF file contents</a></li>
<li><a href="#IDL">IDL file reading function</a></li>
<li><a href="#Future">Future plans</a></li>
</ul>
<h2 id="Overview">
Overview
</h2>
<p>
NDPluginFile saves the NDArray data from a callback to a disk file.
</p>
<p>
NDPluginFile inherits from NDPluginDriver. This plugin currently saves data in the
<a href="http://www.unidata.ucar.edu/software/netcdf">netCDF</a> file format, which
is a portable self-describing binary file format supported by <a href="http://www.unidata.ucar.edu/">
UniData</a> at <a href="http://www.ucar.edu/">UCAR (University Corporation for Atmospheric
Research).</a>
</p>
<p>
The NDArray callback data can be written to disk in 1 of 3 modes:
</p>
<ol>
<li>Single mode. In this mode each NDArray callback results in a separate disk file.</li>
<li>Capture mode. In this mode a memory buffer is allocated before saving begins.
Callback arrays are placed into this buffer, and when capture stops the file is
written to disk. This mode limits the number of frames that can be saved, because
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.</li>
<li>Stream mode. In this mode the data are written to a single disk file, with each
frame being 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.</li>
</ol>
<p>
The NDPluginFile public interface is defined in NDPluginFile.h as follows:
</p>
<pre>/* Note that the file format enum must agree with the mbbo/mbbi records in the NDFile.template file */
typedef enum {
NDFileFormatNetCDF,
} NDPluginFileFormat_t;
typedef enum {
NDPluginFileModeSingle,
NDPluginFileModeCapture,
NDPluginFileModeStream
} NDPluginFileMode_t;
...
class NDPluginFile : public NDPluginDriver {
public:
NDPluginFile(const char *portName, int queueSize, int blockingCallbacks,
const char *NDArrayPort, int NDArrayAddr);
/* These methods override those in the base class */
void processCallbacks(NDArray *pArray);
asynStatus writeInt32(asynUser *pasynUser, epicsInt32 value);
asynStatus writeNDArray(asynUser *pasynUser, void *genericPointer);
asynStatus drvUserCreate(asynUser *pasynUser, const char *drvInfo,
const char **pptypeName, size_t *psize);
...
}
</pre>
<p>
NDPluginFile supports all of the file saving parameters defined in <a href="areaDetectorDoc.html#ADStdDriverParams">
ADStdDriverParams.h</a>, e.g. ADFilePath, ADFileName, etc. Thus, the same interface
that is used for saving files directly in a driver is used for this plugin.
</p>
<h2 id="Configuration">
Configuration</h2>
<p>
The NDPluginFile plugin is created with the following command, either from C/C++
or from the EPICS IOC shell.
</p>
<pre>drvNDFileConfigure(const char *portName, int queueSize, int blockingCallbacks,
const char *NDArrayPort, int NDArrayAddr)
</pre>
<table border="1" cellpadding="2" cellspacing="2" style="text-align: left">
<tr>
<th>
Argument</th>
<th>
Description</th>
</tr>
<tr>
<td>
<code>portName</code></td>
<td>
The name of the asyn port for this plugin.
</td>
</tr>
<tr>
<td>
<code>queueSize</code></td>
<td>
The maximum number of NDArray objects that can be queued for processing. Passed
to the NDPluginDriver base class constructor.
</td>
</tr>
<tr>
<td>
<code>blockingCallbacks</code></td>
<td>
Flag controlling whether callbacks block. Passed to the NDPluginDriver base class
constructor.
</td>
</tr>
<tr>
<td>
<code>NDArrayPort</code></td>
<td>
The name of the asyn port of the driver that will provide the NDArray data. Passed
to the NDPluginDriver base class constructor.
</td>
</tr>
<tr>
<td>
<code>NDArrayAddr</code></td>
<td>
The asyn addr of the asyn port of the driver that will provide the NDArray data.
Passed to the NDPluginDriver base class constructor.
</td>
</tr>
</table>
<h2 id="Screens">
Screen shots</h2>
<p>
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 for
drivers that do not support saving files to disk themselves.
</p>
<div style="text-align: center">
<h3>
NDFile.adl</h3>
<p>
<img alt="NDFile.png" src="NDFile.png" /></p>
</div>
<h2 id="netCDF">
netCDF file contents</h2>
<p>
The following is the header contents of a netCDF file produced by this plugin. This
information was produced with the following command:</p>
<pre>
ncdump -h test_A_2.nc
netcdf test_A_2 {
dimensions:
numArrays = 200 ;
dim0 = 480 ;
dim1 = 640 ;
variables:
int uniqueId(numArrays) ;
double timeStamp(numArrays) ;
byte array_data(numArrays, dim0, dim1) ;
// global attributes:
:dataType = 0 ;
:numArrayDims = 2 ;
:dimSize = 640, 480 ;
:dimOffset = 0, 0 ;
:dimBinning = 1, 1 ;
:dimReverse = 0, 0 ;
}
</pre>
<p>
This is an explanation of this output:
</p>
<ul>
<li>dimensions: numArrays is the number of arrays in the file. It will be 1 for files
collected in Single mode, and is normally &gt 1 for files collected in Capture or
Stream mode. For each array dim0 is the slowest varying dimension, dim1 the next
slowest, etc.</li>
<li>variables: There are 3 variables in the netCDF file. uniqueId is the unique ID
number of each array. timeStamp is the timestamp in seconds for each array. array_data
is the array data. Its data type depends on the data type of the NDArray data passed
in the callbacks. It dimensions are [numArrays, dim0, dim1, ...dimN]. This notation
is in the Fortran syntax where the slowest varying dimension comes first in the
list.</li>
<li>global attributes. dataType is the NDDataType_t enum value for the array data
type. numArrayDims is the number of dimensions in each array. array_data has 1 more
dimension than this, numArrays, because it contains all of the array callback data.
dimSize is an array[numArrayDims] containing the size of each dimension, with the
fastest varying dimension first. dimOffset, dimBinning, and dimReverse are the values
of the offset, binning and reverse fields in the NDDimension_t structure for each
dimension.</li>
</ul>
<h2 id="IDL">
IDL file reading function</h2>
<p>
There is an IDL function, <a href="http://cars.uchicago.edu/software/idl/detector_routines.html#read_nd_netcdf">
read_nd_netcdf</a> that can be used to read the netCDF files created by this plugin.
This routine is contained in the <a href="http://cars.uchicago.edu/software/idl/detectors.html#read_nd_netcdf">
CARS IDL detector package</a>. This function is currently limited to reading the
entire file at once, so it may fail for very large files on machines with insufficient
virtual memory. This will be fixed in a future release.
</p>
<h2 id="Future">
Future plans</h2>
<p>
Additional file formats, such as TIFF and HDF may be supported in the future.
</p>
<p>
The IDL function described above will be enhanced to allow reading only a subset
of the file at a time.
</p>
</body>
</html>
+256 -256
View File
@@ -1,256 +1,256 @@
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>areaDetector Plugin NDPluginStdArrays</title>
</head>
<body>
<div style="text-align: center">
<h1>
areaDetector Plugin NDPluginStdArrays</h1>
<h2>
September 19, 2008</h2>
<h2>
Mark Rivers</h2>
<h2>
University of Chicago</h2>
</div>
<h2>
Contents</h2>
<ul>
<li><a href="#Overview">Overview</a></li>
<li><a href="#Configuration">Configuration</a></li>
<li><a href="#Screens">Screen shots</a></li>
<li><a href="#IDLClient">IDL image display client</a></li>
<li><a href="#Future">Future plans</a></li>
</ul>
<h2 id="Overview">
Overview
</h2>
<p>
This plugin is the tool for converting the NDArray data produced by asynNDArrayDriver
drivers into a form that can be accessed by EPICS.
</p>
<p>
NDPluginStdArrays inherits from NDPluginDriver. NDPluginStdArrays converts the NDArray
data from a callback into the 1-dimensional arrays supported by the standard asyn
array interfaces, i.e. asyn[Int8, Int16, Int32, Float32, Float64]Array. These interfaces
are supported by the EPICS waveform record using standard asyn device support. Because
this plugin inherits from <a href="pluginDoc.html#NDPluginDriver">NDPluginDriver</a>
it also provides additional information on the array data (e.g. number of dimensions
and dimension data) that are made available as EPICS PVs so that clients can correctly
interpret the array data. The NDPluginStdArrays public interface is defined in NDPluginStdArrays.h
as follows:</p>
<pre>
class NDPluginStdArrays : public NDPluginDriver {
public:
NDPluginStdArrays(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);
virtual asynStatus readInt8Array(asynUser *pasynUser, epicsInt8 *value,
size_t nElements, size_t *nIn);
virtual asynStatus readInt16Array(asynUser *pasynUser, epicsInt16 *value,
size_t nElements, size_t *nIn);
virtual asynStatus readInt32Array(asynUser *pasynUser, epicsInt32 *value,
size_t nElements, size_t *nIn);
virtual asynStatus readFloat32Array(asynUser *pasynUser, epicsFloat32 *value,
size_t nElements, size_t *nIn);
virtual asynStatus readFloat64Array(asynUser *pasynUser, epicsFloat64 *value,
size_t nElements, size_t *nIn);
asynStatus drvUserCreate(asynUser *pasynUser, const char *drvInfo,
const char **pptypeName, size_t *psize);
...
}
</pre>
<p>
NDPluginStdArrays defines the following parameters. It also implements all of the
standard plugin parameters from <a href="pluginDoc.html#NDPluginDriver">NDPluginDriver</a>
. The EPICS database NDStdArrays.template provides access to these parameters, listed
in the following table.
</p>
<table border="1" cellpadding="2" cellspacing="2" style="text-align: left">
<tbody>
<tr>
<td align="center" colspan="7,">
<b>Parameter Definitions in NDPluginStdArrays.h and EPICS Record Definitions in NDStdArrays.template</b></td>
</tr>
<tr>
<th>
Enum name</th>
<th>
asyn interface</th>
<th>
Access</th>
<th>
Description</th>
<th>
drvUser string</th>
<th>
EPICS record name</th>
<th>
EPICS record type</th>
</tr>
<tr>
<td>
NDPluginStdArraysData</td>
<td>
asyn[Int8, Int16, Int32, Float32, Float64]Array</td>
<td>
r/o</td>
<td>
Array data as a 1-D array, possibly converted in data type from that in the NDArray
object to the specific asyn interface.</td>
<td>
STD_ARRAY_DATA</td>
<td>
$(P)$(R)ArrayData</td>
<td>
waveform</td>
</tr>
</tbody>
</table>
<p>
If the array data contains more than 16,000 bytes then in order for EPICS clients
to receive this data they must be built with EPICS R3.14 (not R3.13), and the environment
variable EPICS_CA_MAX_ARRAY_BYTES on both the EPICS IOC computer and EPICS client
computer must be set to a value at least as large as the array size in bytes.</p>
<h2 id="Configuration">
Configuration</h2>
<p>
The NDPluginStdArrays plugin is created with the following command, either from
C/C++ or from the EPICS IOC shell.
</p>
<pre>drvNDStdArraysConfigure(const char *portName, int queueSize, int blockingCallbacks,
const char *NDArrayPort, int NDArrayAddr, size_t maxMemory)
</pre>
<table border="1" cellpadding="2" cellspacing="2" style="text-align: left">
<tr>
<th>
Argument</th>
<th>
Description</th>
</tr>
<tr>
<td>
<code>portName</code></td>
<td>
The name of the asyn port for this plugin.
</td>
</tr>
<tr>
<td>
<code>queueSize</code></td>
<td>
The maximum number of NDArray objects that can be queued for processing. Passed
to the NDPluginDriver base class constructor.
</td>
</tr>
<tr>
<td>
<code>blockingCallbacks</code></td>
<td>
Flag controlling whether callbacks block. Passed to the NDPluginDriver base class
constructor.
</td>
</tr>
<tr>
<td>
<code>NDArrayPort</code></td>
<td>
The name of the asyn port of the driver that will provide the NDArray data. Passed
to the NDPluginDriver base class constructor.
</td>
</tr>
<tr>
<td>
<code>NDArrayAddr</code></td>
<td>
The asyn addr of the asyn port of the driver that will provide the NDArray data.
Passed to the NDPluginDriver base class constructor.
</td>
</tr>
<tr>
<td>
<code>maxMemory</code></td>
<td>
Maximum number of bytes of memory to be allocated from the NDArrayPool. Passed to
the constructor for the NDPluginDriver base class. The NDStdArrays plugin allocates
2 NDArray objects, so this should be at least twice the size of the largest NDArray
to be used.</td>
</tr>
</table>
<h2 id="Screens">
Screen shots</h2>
<p>
The following is the MEDM screen that provides access to the parameters in NDPluginDriver.h
and NDPluginStdArrays.h through records in NDPluginBase.template and NDStdArrays.template.
This is the MEDM screen that is normally used to control the display of images via
EPICS channel access.
</p>
<div style="text-align: center">
<h3>
NDStdArrays.adl</h3>
<p>
<img alt="NDStdArrays.png" src="NDStdArrays.png" /></p>
</div>
<h2 id="IDLClient">
IDL Image Display Client</h2>
<p>
There is an IDL procedure called <a href="http://cars.uchicago.edu/software/idl/imaging_routines.html#epics_ad_display">
epics_ad_display</a> that can be used to display 2-dimensional array data that
the NDStdArrays plugin sends to EPICS. This IDL client is available as source code
(which requires an IDL license), and also as a pre-built IDL .sav file that can
be run for free under the IDL Virtual Machine. This IDL program can run on any machine
that IDL runs on, and that has the ezcaIDL shareable library built for it. This
includes Windows, Linux, Solaris, and Mac. <code>epics_ad_display</code> is included
in the <a href="http://cars.uchicago.edu/software/IDL/imaging.html">CARS IDL imaging
software.</a>
</p>
<p>
The control window for <code>epics_ad_display</code> is shown below. It has a field
to input the base name of the EPICS PVs with the image data. It also has fields
to enable/display the IDL display update, to change the display mode, to autoscale
the intensity, and to invert the image in the Y direction. If autoscale is set to
No then manual scaling can be entered in the Min and Max fields. The number of frames
per second actually being displayed by IDL is shown. There is a status window that
shows whether the EPICS PVs are connected and the time the last was array received,
updated once per second.
</p>
<div style="text-align: center">
<h3>
Main window for IDL epics_ad_display</h3>
<p>
<img alt="IDL_epics_ad_display.png" src="IDL_epics_ad_display.png" /></p>
</div>
<p>
<code>epics_ad_display</code> can use the simple IDL routine <code>tv</code> to
display the images. This is the fastest mode, and results in a non-scalable unadorned
window.</p>
<div style="text-align: center">
<h3>
IDL epics_ad_display using the IDL <code>tv</code> routine.</h3>
<p>
<img alt="IDL_epics_ad_display_tv.jpg" src="IDL_epics_ad_display_tv.jpg" /></p>
</div>
<p>
<code>epics_ad_display</code> can also use the routine <a href="http://cars.uchicago.edu/software/IDL/imaging_routines.html#IMAGE_DISPLAY">
image_display.pro</a> to display the images. This routine displays row and column
profiles as the cursor is moved. It allows changing the color lookup tables, and
zooming in (right mouse click) and out (left mouse click). The following is an example
of <code>image_display</code> displaying an image from the simulation detector.</p>
<div style="text-align: center">
<h3>
epics_ad_display using the image_display routine</h3>
<p>
<img alt="simDetector_image_display.png" src="simDetector_image_display.png" /></p>
</div>
<h2 id="Future">
Future plans</h2>
<p>
Stephen Mudie at the Australian Synchrotron has written a very nice IDL client to
display the EPICS images from the Flea Firewire cameras. This client should be converted
to display the data from this areaDetector plugin.
</p>
</body>
</html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>areaDetector Plugin NDPluginStdArrays</title>
</head>
<body>
<div style="text-align: center">
<h1>
areaDetector Plugin NDPluginStdArrays</h1>
<h2>
September 19, 2008</h2>
<h2>
Mark Rivers</h2>
<h2>
University of Chicago</h2>
</div>
<h2>
Contents</h2>
<ul>
<li><a href="#Overview">Overview</a></li>
<li><a href="#Configuration">Configuration</a></li>
<li><a href="#Screens">Screen shots</a></li>
<li><a href="#IDLClient">IDL image display client</a></li>
<li><a href="#Future">Future plans</a></li>
</ul>
<h2 id="Overview">
Overview
</h2>
<p>
This plugin is the tool for converting the NDArray data produced by asynNDArrayDriver
drivers into a form that can be accessed by EPICS.
</p>
<p>
NDPluginStdArrays inherits from NDPluginDriver. NDPluginStdArrays converts the NDArray
data from a callback into the 1-dimensional arrays supported by the standard asyn
array interfaces, i.e. asyn[Int8, Int16, Int32, Float32, Float64]Array. These interfaces
are supported by the EPICS waveform record using standard asyn device support. Because
this plugin inherits from <a href="pluginDoc.html#NDPluginDriver">NDPluginDriver</a>
it also provides additional information on the array data (e.g. number of dimensions
and dimension data) that are made available as EPICS PVs so that clients can correctly
interpret the array data. The NDPluginStdArrays public interface is defined in NDPluginStdArrays.h
as follows:</p>
<pre>
class NDPluginStdArrays : public NDPluginDriver {
public:
NDPluginStdArrays(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);
virtual asynStatus readInt8Array(asynUser *pasynUser, epicsInt8 *value,
size_t nElements, size_t *nIn);
virtual asynStatus readInt16Array(asynUser *pasynUser, epicsInt16 *value,
size_t nElements, size_t *nIn);
virtual asynStatus readInt32Array(asynUser *pasynUser, epicsInt32 *value,
size_t nElements, size_t *nIn);
virtual asynStatus readFloat32Array(asynUser *pasynUser, epicsFloat32 *value,
size_t nElements, size_t *nIn);
virtual asynStatus readFloat64Array(asynUser *pasynUser, epicsFloat64 *value,
size_t nElements, size_t *nIn);
asynStatus drvUserCreate(asynUser *pasynUser, const char *drvInfo,
const char **pptypeName, size_t *psize);
...
}
</pre>
<p>
NDPluginStdArrays defines the following parameters. It also implements all of the
standard plugin parameters from <a href="pluginDoc.html#NDPluginDriver">NDPluginDriver</a>
. The EPICS database NDStdArrays.template provides access to these parameters, listed
in the following table.
</p>
<table border="1" cellpadding="2" cellspacing="2" style="text-align: left">
<tbody>
<tr>
<td align="center" colspan="7,">
<b>Parameter Definitions in NDPluginStdArrays.h and EPICS Record Definitions in NDStdArrays.template</b></td>
</tr>
<tr>
<th>
Enum name</th>
<th>
asyn interface</th>
<th>
Access</th>
<th>
Description</th>
<th>
drvUser string</th>
<th>
EPICS record name</th>
<th>
EPICS record type</th>
</tr>
<tr>
<td>
NDPluginStdArraysData</td>
<td>
asyn[Int8, Int16, Int32, Float32, Float64]Array</td>
<td>
r/o</td>
<td>
Array data as a 1-D array, possibly converted in data type from that in the NDArray
object to the specific asyn interface.</td>
<td>
STD_ARRAY_DATA</td>
<td>
$(P)$(R)ArrayData</td>
<td>
waveform</td>
</tr>
</tbody>
</table>
<p>
If the array data contains more than 16,000 bytes then in order for EPICS clients
to receive this data they must be built with EPICS R3.14 (not R3.13), and the environment
variable EPICS_CA_MAX_ARRAY_BYTES on both the EPICS IOC computer and EPICS client
computer must be set to a value at least as large as the array size in bytes.</p>
<h2 id="Configuration">
Configuration</h2>
<p>
The NDPluginStdArrays plugin is created with the following command, either from
C/C++ or from the EPICS IOC shell.
</p>
<pre>drvNDStdArraysConfigure(const char *portName, int queueSize, int blockingCallbacks,
const char *NDArrayPort, int NDArrayAddr, size_t maxMemory)
</pre>
<table border="1" cellpadding="2" cellspacing="2" style="text-align: left">
<tr>
<th>
Argument</th>
<th>
Description</th>
</tr>
<tr>
<td>
<code>portName</code></td>
<td>
The name of the asyn port for this plugin.
</td>
</tr>
<tr>
<td>
<code>queueSize</code></td>
<td>
The maximum number of NDArray objects that can be queued for processing. Passed
to the NDPluginDriver base class constructor.
</td>
</tr>
<tr>
<td>
<code>blockingCallbacks</code></td>
<td>
Flag controlling whether callbacks block. Passed to the NDPluginDriver base class
constructor.
</td>
</tr>
<tr>
<td>
<code>NDArrayPort</code></td>
<td>
The name of the asyn port of the driver that will provide the NDArray data. Passed
to the NDPluginDriver base class constructor.
</td>
</tr>
<tr>
<td>
<code>NDArrayAddr</code></td>
<td>
The asyn addr of the asyn port of the driver that will provide the NDArray data.
Passed to the NDPluginDriver base class constructor.
</td>
</tr>
<tr>
<td>
<code>maxMemory</code></td>
<td>
Maximum number of bytes of memory to be allocated from the NDArrayPool. Passed to
the constructor for the NDPluginDriver base class. The NDStdArrays plugin allocates
2 NDArray objects, so this should be at least twice the size of the largest NDArray
to be used.</td>
</tr>
</table>
<h2 id="Screens">
Screen shots</h2>
<p>
The following is the MEDM screen that provides access to the parameters in NDPluginDriver.h
and NDPluginStdArrays.h through records in NDPluginBase.template and NDStdArrays.template.
This is the MEDM screen that is normally used to control the display of images via
EPICS channel access.
</p>
<div style="text-align: center">
<h3>
NDStdArrays.adl</h3>
<p>
<img alt="NDStdArrays.png" src="NDStdArrays.png" /></p>
</div>
<h2 id="IDLClient">
IDL Image Display Client</h2>
<p>
There is an IDL procedure called <a href="http://cars.uchicago.edu/software/idl/imaging_routines.html#epics_ad_display">
epics_ad_display</a> that can be used to display 2-dimensional array data that
the NDStdArrays plugin sends to EPICS. This IDL client is available as source code
(which requires an IDL license), and also as a pre-built IDL .sav file that can
be run for free under the IDL Virtual Machine. This IDL program can run on any machine
that IDL runs on, and that has the ezcaIDL shareable library built for it. This
includes Windows, Linux, Solaris, and Mac. <code>epics_ad_display</code> is included
in the <a href="http://cars.uchicago.edu/software/IDL/imaging.html">CARS IDL imaging
software.</a>
</p>
<p>
The control window for <code>epics_ad_display</code> is shown below. It has a field
to input the base name of the EPICS PVs with the image data. It also has fields
to enable/display the IDL display update, to change the display mode, to autoscale
the intensity, and to invert the image in the Y direction. If autoscale is set to
No then manual scaling can be entered in the Min and Max fields. The number of frames
per second actually being displayed by IDL is shown. There is a status window that
shows whether the EPICS PVs are connected and the time the last was array received,
updated once per second.
</p>
<div style="text-align: center">
<h3>
Main window for IDL epics_ad_display</h3>
<p>
<img alt="IDL_epics_ad_display.png" src="IDL_epics_ad_display.png" /></p>
</div>
<p>
<code>epics_ad_display</code> can use the simple IDL routine <code>tv</code> to
display the images. This is the fastest mode, and results in a non-scalable unadorned
window.</p>
<div style="text-align: center">
<h3>
IDL epics_ad_display using the IDL <code>tv</code> routine.</h3>
<p>
<img alt="IDL_epics_ad_display_tv.jpg" src="IDL_epics_ad_display_tv.jpg" /></p>
</div>
<p>
<code>epics_ad_display</code> can also use the routine <a href="http://cars.uchicago.edu/software/IDL/imaging_routines.html#IMAGE_DISPLAY">
image_display.pro</a> to display the images. This routine displays row and column
profiles as the cursor is moved. It allows changing the color lookup tables, and
zooming in (right mouse click) and out (left mouse click). The following is an example
of <code>image_display</code> displaying an image from the simulation detector.</p>
<div style="text-align: center">
<h3>
epics_ad_display using the image_display routine</h3>
<p>
<img alt="simDetector_image_display.png" src="simDetector_image_display.png" /></p>
</div>
<h2 id="Future">
Future plans</h2>
<p>
Stephen Mudie at the Australian Synchrotron has written a very nice IDL client to
display the EPICS images from the Flea Firewire cameras. This client should be converted
to display the data from this areaDetector plugin.
</p>
</body>
</html>
+329 -329
View File
@@ -1,329 +1,329 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>areaDetector ADSC driver</title>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type" />
</head>
<body>
<div style="text-align: center">
<h1>
areaDetector ADSC driver</h1>
<h2>
September 17, 2008</h2>
<h2>
Lewis Muir</h2>
<h2>
University of Chicago</h2>
</div>
<h2>
Table of Contents</h2>
<ol>
<li><a href="#Introduction">Introduction</a></li>
<li><a href="#Dependencies">Dependencies</a></li>
<li><a href="#Building">Building</a></li>
<li><a href="#Configuring">Configuring</a></li>
<li><a href="#ImageModes">Image Modes</a></li>
<li><a href="#TriggerModes">Trigger Modes</a></li>
<li><a href="#DarkImages">Dark Images</a></li>
<li><a href="#ValuesAndSettings">Driver Specific Values and Settings</a></li>
<li><a href="#Screenshots">Screenshots</a></li>
<li><a href="#Unsupported">Unsupported <tt>areaDetector</tt> <q>base</q> Features</a></li>
<li><a href="#Limitations">Limitations</a></li>
</ol>
<h2 id="Introduction">
Introduction</h2>
<p>
This is a driver for <a href="http://www.adsc-xray.com/">ADSC</a> detectors. It
has been tested with the ADSC Q210. While not yet tested with other models, it should
work with the ADSC Q4 (with the upgrade to four computers), Q4r, Q210, Q210r, Q270,
Q315, and Q315r.
</p>
<h2 id="Dependencies">
Dependencies</h2>
<p>
This driver controls the detector via the <tt>detcon_lib_th</tt> detector control
library provided by ADSC. The <tt>detcon_lib_th</tt> library must date from 2008-06-30
or newer.
</p>
<h2 id="Building">
Building</h2>
<ol>
<li>Build the ADSC control library</li>
<li>Copy and rename, or create a symlink to, the ADSC <tt>auxlib.a</tt> library so
that it has the name <tt>libauxlib.a</tt> to satisfy the EPICS build facility's
requirement that a library file name start with <q><tt>lib</tt></q></li>
<li>Add <q><tt>DIRS += adscSrc</tt></q> to <tt>ADApp/Makefile</tt></li>
<li>Set <tt>ADSC_HOME</tt> in <tt>ADApp/adscSrc/Makefile</tt></li>
<li>Rebuild the <tt>areaDetector</tt> module</li>
</ol>
<h2 id="Configuring">
Configuring</h2>
<p>
This driver is configured via the <tt>adscConfig()</tt> function. If this is to
be used in an IOC, it must be called before <tt>iocInit()</tt>. It has the following
signature:
</p>
<dl>
<dt><tt>int adscConfig(const char *portName, const char *modelName)</tt></dt>
<dd>
<dl>
<dt><tt>portName</tt></dt>
<dd>
ASYN port name for the driver instance</dd>
<dt><tt>modelName</tt></dt>
<dd>
ADSC detector model name; must be one of <tt>Q4</tt>, <tt>Q4r</tt>, <tt>Q210</tt>,
<tt>Q210r</tt>, <tt>Q270</tt>, <tt>Q315</tt>, <tt>Q315r</tt></dd>
</dl>
</dd>
</dl>
<p>
The underlying ADSC control library obtains its configuration from the environment.
Therefore, the environment must be correctly configured (i.e. ADSC environment variables
set) for the ADSC control library before calling <tt>adscConfig()</tt>.
</p>
<p>
If being used in an IOC, and an EPICS PV interface with the driver is desired, the
<tt>ADBase.template</tt> and <tt>adsc.template</tt> databases should also be loaded
for the driver instance.
</p>
<p>
An example IOC configuration for this driver is at <tt>iocBoot/iocAdsc/st.cmd</tt>.
</p>
<h2 id="ImageModes">
Image Modes</h2>
<h3>
<tt>Single</tt></h3>
<p>
The <tt>Single</tt> mode acquires just one image.
</p>
<h3>
<tt>Multiple</tt></h3>
<p>
The <tt>Multiple</tt> mode acquires the number of images specified in <tt>$(P)$(R)NumImages_RBV</tt>.
</p>
<h3>
<tt>Continuous</tt></h3>
<p>
The <tt>Continuous</tt> mode acquires images indefinitely until <em>last image</em>
is set. In this mode, the last image of the acquisition must be signaled before
exposing the last image by setting <tt>$(P)$(R)ADSCLastImage</tt> to <tt>1</tt>.
This requirement is due to how the underlying ADSC control library works.
</p>
<h2 id="TriggerModes">
Trigger Modes</h2>
<h3>
<tt>Internal</tt></h3>
<p>
The <tt>Internal</tt> mode will make the driver expose images on its own once the
acquisition is started.
</p>
<h3>
<tt>External</tt></h3>
<p>
The <tt>External</tt> mode will make the driver expose images only when told to
once the acquisition is started. A special protocol must be followed to trigger
each image exposure. This would normally be very simple, but because the ADSC control
library can report that an exposure did not work and should be retried after any
exposure, a more complex protocol is required.
</p>
<p>
The protocol is described in terms of the EPICS PV driver interface, but the same
rules apply if controlling the driver directly through ASYN. The protocol is as
follows:
</p>
<ol>
<li>Wait for <tt>$(P)$(R)ADSCOkToExpose</tt> to be <tt>Yes</tt></li>
<li>Set <tt>$(P)$(R)ADSCExTrCtl</tt> to <tt>Start</tt> to start the exposure</li>
<li>Set <tt>$(P)$(R)ADSCExTrCtl</tt> to <tt>Stop</tt> to stop the exposure</li>
<li>Wait for <tt>$(P)$(R)ADSCExTrCtl_RBV</tt> to be <tt>OK</tt> or <tt>Again</tt></li>
<li>If <tt>$(P)$(R)ADSCExTrCtl_RBV</tt> is <tt>Again</tt>, the exposure did not work
and should be tried again</li>
</ol>
<p>
Note that care must be taken when waiting for <tt>$(P)$(R)ADSCExTrCtl_RBV</tt> to
be <tt>OK</tt> or <tt>Again</tt> to ensure the PV value is not stale (i.e. from
the previous exposure). There are at least two methods to ensure this:
</p>
<ul>
<li>Use a CA monitor on <tt>$(P)$(R)ADSCExTrCtl_RBV</tt>; before waiting for the <tt>
OK</tt> or <tt>Again</tt> values, wait for the <tt>Stop</tt> value; a CA monitor
is used to receive the value changes since the PV will have the <tt>Stop</tt> value
for just a short time</li>
<li>After starting the exposure, wait for <tt>$(P)$(R)ADSCExTrCtl_RBV</tt> to be <tt>
Start</tt></li>
</ul>
<h2 id="DarkImages">
Dark Images</h2>
<p>
Dark images are acquired automatically at the beginning of a data acquisition. They
are taken if any of the following conditions are true:
</p>
<ul>
<li><em>Reuse darks</em> is <tt>No</tt></li>
<li><em>Exposure time</em> is different from that of the previous acquisition</li>
<li><em>ADC/binning</em> is different from that of the previous acquisition</li>
<li><em>Binning</em> is different from that of the previous acquisition</li>
<li>The acquisition is the first after <em>stored darks</em> was changed from <tt>
Yes</tt> to <tt>No</tt></li>
</ul>
<h2 id="ValuesAndSettings">
Driver Specific Values and Settings</h2>
<p>
This driver provides status values and settings in addition to what is provided
by <tt>areaDetector</tt> <q>base</q>. They are listed here according to their label
in the driver specific MEDM GUI and their EPICS PV name in the EPICS PV driver interface.
A screenshot of the driver specific MEDM GUI can be seen in the <a href="#Screenshots">
Screenshots</a> section.
</p>
<h3>
Detector Condition</h3>
<dl>
<dt>State, <tt>$(P)$(R)ADSCState</tt></dt>
<dd>
State of the detector reported by the ADSC control library.</dd>
<dt>Status, <tt>$(P)$(R)ADSCStatus</tt></dt>
<dd>
Status message reported by the ADSC control library.</dd>
<dt>Last error, <tt>$(P)$(R)ADSCLastError</tt></dt>
<dd>
Last error message reported by the ADSC control library.</dd>
<dt>Update rate for above properties, <tt>$(P)$(R)ADSCReadConditn.SCAN</tt></dt>
<dd>
How frequently to update the above properties.</dd>
</dl>
<h3>
Detector Error Recovery</h3>
<dl>
<dt>Software Reset, <tt>$(P)$(R)ADSCSoftReset</tt></dt>
<dd>
Performs a software reset. Aborts any current operation, clears status and error
messages, and sets <em>detector state</em> to <tt>Idle</tt>.</dd>
</dl>
<h3>
Detector Continuous Image Mode</h3>
<dl>
<dt>Last Image, <tt>$(P)$(R)ADSCLastImage</tt></dt>
<dd>
Signals that the next exposure is the last image when in <tt>Continuous</tt> image
mode.</dd>
</dl>
<h3>
Detector External Trigger</h3>
<dl>
<dt>OK to expose, <tt>$(P)$(R)ADSCOkToExpose</tt></dt>
<dd>
When in <tt>External</tt> trigger mode, indicates whether it is OK to start an image
exposure.</dd>
<dt>Start, Stop, <tt>$(P)$(R)ADSCExTrCtl</tt></dt>
<dd>
When in <tt>External</tt> trigger mode, set to <tt>1</tt> to start an exposure and
<tt>0</tt> to stop it.</dd>
<dt><tt>$(P)$(R)ADSCExTrCtl_RBV</tt></dt>
<dd>
When in <tt>External</tt> trigger mode, will be <tt>Start</tt>, <tt>Stop</tt>, <tt>
OK</tt>, or <tt>Again</tt>. See <a href="#TriggerModes">Trigger Modes</a> section
for more about how this property will behave.</dd>
</dl>
<h3>
Driver Parameters</h3>
<dl>
<dt>Reuse darks, <tt>$(P)$(R)ADSCReusDrk</tt></dt>
<dd>
Reuse dark images when possible. This is useful to avoid wasting time acquiring
dark images when previously acquired dark images are available and can be reused.</dd>
<dt>Dezinger, <tt>$(P)$(R)ADSCDezingr</tt></dt>
<dd>
Acquire <q>dezingered</q> images.</dd>
</dl>
<h3>
Detector Hardware Parameters</h3>
<dl>
<dt>ADC/Binning, <tt>$(P)$(R)ADSCAdc</tt></dt>
<dd>
For Q4 and Q4r detectors, controls whether to use <tt>Fast</tt> or <tt>Slow</tt>
ADC. For all other detectors, controls whether to use <tt>Hardware</tt> or <tt>Software</tt>
binning.</dd>
<dt>Raw images, <tt>$(P)$(R)ADSCRaw</tt></dt>
<dd>
Write raw images.</dd>
<dt>Image transforms, <tt>$(P)$(R)ADSCImXform</tt></dt>
<dd>
Perform image transformations.</dd>
<dt>Stored darks, <tt>$(P)$(R)ADSCStrDrks</tt></dt>
<dd>
Use stored dark images. If set to <tt>Yes</tt>, stored dark images are assumed to
have been installed by ADSC and should be used.</dd>
</dl>
<h3>
Detector File Parameters</h3>
<dl>
<dt>Beam center X, <tt>$(P)$(R)ADSCBeamX</tt></dt>
<dd>
Beam center in the X dimension.</dd>
<dt>Beam center Y, <tt>$(P)$(R)ADSCBeamY</tt></dt>
<dd>
Beam center in the Y dimension.</dd>
<dt>Distance, <tt>$(P)$(R)ADSCDistnce</tt></dt>
<dd>
Detector distance.</dd>
<dt>Two theta, <tt>$(P)$(R)ADSC2Theta</tt></dt>
<dd>
Detector 2&theta; angle.</dd>
<dt>Axis, <tt>$(P)$(R)ADSCAxis</tt></dt>
<dd>
Crystal rotation axis.</dd>
<dt>Wavelength, <tt>$(P)$(R)ADSCWavelen</tt></dt>
<dd>
X-ray wavelength.</dd>
<dt>Image width, <tt>$(P)$(R)ADSCImWidth</tt></dt>
<dd>
Crystal rotation during exposure.</dd>
<dt>Phi, <tt>$(P)$(R)ADSCPhi</tt></dt>
<dd>
Phi position at start of exposure.</dd>
<dt>Omega, <tt>$(P)$(R)ADSCOmega</tt></dt>
<dd>
Omega position at start of exposure.</dd>
<dt>Kappa, <tt>$(P)$(R)ADSCKappa</tt></dt>
<dd>
Kappa position at start of exposure.</dd>
</dl>
<h2 id="Screenshots">
Screenshots</h2>
<ul>
<li><a href="adsc-screenshot.png">ADSC Specific MEDM GUI</a></li>
</ul>
<h2 id="Unsupported">
Unsupported <tt>areaDetector</tt> <q>base</q> Features</h2>
<ul>
<li>Shutter control</li>
<li>Collect: number of exposures per image</li>
<li>File: save file</li>
<li>File: read file</li>
<li>File: format</li>
<li>File: auto save (always <tt>Yes</tt>)</li>
<li>Readout: image region of interest</li>
<li>Readout: reverse image</li>
<li>Readout: gain</li>
<li>Readout: data type (always <tt>UInt16</tt>)</li>
<li>Image frame callbacks</li>
</ul>
<h2 id="Limitations">
Limitations</h2>
<ul>
<li>Only one ADSC detector may be controlled with this driver per OS process. If this
driver is being used in an IOC, this means only one ADSC detector may be controlled
with this driver per IOC. This is a limitation of the underlying ADSC control library
which does not support more than one detector per OS process.</li>
<li>Acquiring <q>dezingered</q> images is not supported. This is a limitation of the
underlying ADSC control library which has a bug preventing it from working correctly.</li>
<li><em>Software reset</em> does not work. This is a limitation of the underlying
ADSC control library which has a bug preventing it from working correctly. It would
be great if, after an error, performing a software reset would allow a new acquisition
to proceed normally. Currently, the recovery solution often is to restart the control
software.</li>
</ul>
</body>
</html>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>areaDetector ADSC driver</title>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type" />
</head>
<body>
<div style="text-align: center">
<h1>
areaDetector ADSC driver</h1>
<h2>
September 17, 2008</h2>
<h2>
Lewis Muir</h2>
<h2>
University of Chicago</h2>
</div>
<h2>
Table of Contents</h2>
<ol>
<li><a href="#Introduction">Introduction</a></li>
<li><a href="#Dependencies">Dependencies</a></li>
<li><a href="#Building">Building</a></li>
<li><a href="#Configuring">Configuring</a></li>
<li><a href="#ImageModes">Image Modes</a></li>
<li><a href="#TriggerModes">Trigger Modes</a></li>
<li><a href="#DarkImages">Dark Images</a></li>
<li><a href="#ValuesAndSettings">Driver Specific Values and Settings</a></li>
<li><a href="#Screenshots">Screenshots</a></li>
<li><a href="#Unsupported">Unsupported <tt>areaDetector</tt> <q>base</q> Features</a></li>
<li><a href="#Limitations">Limitations</a></li>
</ol>
<h2 id="Introduction">
Introduction</h2>
<p>
This is a driver for <a href="http://www.adsc-xray.com/">ADSC</a> detectors. It
has been tested with the ADSC Q210. While not yet tested with other models, it should
work with the ADSC Q4 (with the upgrade to four computers), Q4r, Q210, Q210r, Q270,
Q315, and Q315r.
</p>
<h2 id="Dependencies">
Dependencies</h2>
<p>
This driver controls the detector via the <tt>detcon_lib_th</tt> detector control
library provided by ADSC. The <tt>detcon_lib_th</tt> library must date from 2008-06-30
or newer.
</p>
<h2 id="Building">
Building</h2>
<ol>
<li>Build the ADSC control library</li>
<li>Copy and rename, or create a symlink to, the ADSC <tt>auxlib.a</tt> library so
that it has the name <tt>libauxlib.a</tt> to satisfy the EPICS build facility's
requirement that a library file name start with <q><tt>lib</tt></q></li>
<li>Add <q><tt>DIRS += adscSrc</tt></q> to <tt>ADApp/Makefile</tt></li>
<li>Set <tt>ADSC_HOME</tt> in <tt>ADApp/adscSrc/Makefile</tt></li>
<li>Rebuild the <tt>areaDetector</tt> module</li>
</ol>
<h2 id="Configuring">
Configuring</h2>
<p>
This driver is configured via the <tt>adscConfig()</tt> function. If this is to
be used in an IOC, it must be called before <tt>iocInit()</tt>. It has the following
signature:
</p>
<dl>
<dt><tt>int adscConfig(const char *portName, const char *modelName)</tt></dt>
<dd>
<dl>
<dt><tt>portName</tt></dt>
<dd>
ASYN port name for the driver instance</dd>
<dt><tt>modelName</tt></dt>
<dd>
ADSC detector model name; must be one of <tt>Q4</tt>, <tt>Q4r</tt>, <tt>Q210</tt>,
<tt>Q210r</tt>, <tt>Q270</tt>, <tt>Q315</tt>, <tt>Q315r</tt></dd>
</dl>
</dd>
</dl>
<p>
The underlying ADSC control library obtains its configuration from the environment.
Therefore, the environment must be correctly configured (i.e. ADSC environment variables
set) for the ADSC control library before calling <tt>adscConfig()</tt>.
</p>
<p>
If being used in an IOC, and an EPICS PV interface with the driver is desired, the
<tt>ADBase.template</tt> and <tt>adsc.template</tt> databases should also be loaded
for the driver instance.
</p>
<p>
An example IOC configuration for this driver is at <tt>iocBoot/iocAdsc/st.cmd</tt>.
</p>
<h2 id="ImageModes">
Image Modes</h2>
<h3>
<tt>Single</tt></h3>
<p>
The <tt>Single</tt> mode acquires just one image.
</p>
<h3>
<tt>Multiple</tt></h3>
<p>
The <tt>Multiple</tt> mode acquires the number of images specified in <tt>$(P)$(R)NumImages_RBV</tt>.
</p>
<h3>
<tt>Continuous</tt></h3>
<p>
The <tt>Continuous</tt> mode acquires images indefinitely until <em>last image</em>
is set. In this mode, the last image of the acquisition must be signaled before
exposing the last image by setting <tt>$(P)$(R)ADSCLastImage</tt> to <tt>1</tt>.
This requirement is due to how the underlying ADSC control library works.
</p>
<h2 id="TriggerModes">
Trigger Modes</h2>
<h3>
<tt>Internal</tt></h3>
<p>
The <tt>Internal</tt> mode will make the driver expose images on its own once the
acquisition is started.
</p>
<h3>
<tt>External</tt></h3>
<p>
The <tt>External</tt> mode will make the driver expose images only when told to
once the acquisition is started. A special protocol must be followed to trigger
each image exposure. This would normally be very simple, but because the ADSC control
library can report that an exposure did not work and should be retried after any
exposure, a more complex protocol is required.
</p>
<p>
The protocol is described in terms of the EPICS PV driver interface, but the same
rules apply if controlling the driver directly through ASYN. The protocol is as
follows:
</p>
<ol>
<li>Wait for <tt>$(P)$(R)ADSCOkToExpose</tt> to be <tt>Yes</tt></li>
<li>Set <tt>$(P)$(R)ADSCExTrCtl</tt> to <tt>Start</tt> to start the exposure</li>
<li>Set <tt>$(P)$(R)ADSCExTrCtl</tt> to <tt>Stop</tt> to stop the exposure</li>
<li>Wait for <tt>$(P)$(R)ADSCExTrCtl_RBV</tt> to be <tt>OK</tt> or <tt>Again</tt></li>
<li>If <tt>$(P)$(R)ADSCExTrCtl_RBV</tt> is <tt>Again</tt>, the exposure did not work
and should be tried again</li>
</ol>
<p>
Note that care must be taken when waiting for <tt>$(P)$(R)ADSCExTrCtl_RBV</tt> to
be <tt>OK</tt> or <tt>Again</tt> to ensure the PV value is not stale (i.e. from
the previous exposure). There are at least two methods to ensure this:
</p>
<ul>
<li>Use a CA monitor on <tt>$(P)$(R)ADSCExTrCtl_RBV</tt>; before waiting for the <tt>
OK</tt> or <tt>Again</tt> values, wait for the <tt>Stop</tt> value; a CA monitor
is used to receive the value changes since the PV will have the <tt>Stop</tt> value
for just a short time</li>
<li>After starting the exposure, wait for <tt>$(P)$(R)ADSCExTrCtl_RBV</tt> to be <tt>
Start</tt></li>
</ul>
<h2 id="DarkImages">
Dark Images</h2>
<p>
Dark images are acquired automatically at the beginning of a data acquisition. They
are taken if any of the following conditions are true:
</p>
<ul>
<li><em>Reuse darks</em> is <tt>No</tt></li>
<li><em>Exposure time</em> is different from that of the previous acquisition</li>
<li><em>ADC/binning</em> is different from that of the previous acquisition</li>
<li><em>Binning</em> is different from that of the previous acquisition</li>
<li>The acquisition is the first after <em>stored darks</em> was changed from <tt>
Yes</tt> to <tt>No</tt></li>
</ul>
<h2 id="ValuesAndSettings">
Driver Specific Values and Settings</h2>
<p>
This driver provides status values and settings in addition to what is provided
by <tt>areaDetector</tt> <q>base</q>. They are listed here according to their label
in the driver specific MEDM GUI and their EPICS PV name in the EPICS PV driver interface.
A screenshot of the driver specific MEDM GUI can be seen in the <a href="#Screenshots">
Screenshots</a> section.
</p>
<h3>
Detector Condition</h3>
<dl>
<dt>State, <tt>$(P)$(R)ADSCState</tt></dt>
<dd>
State of the detector reported by the ADSC control library.</dd>
<dt>Status, <tt>$(P)$(R)ADSCStatus</tt></dt>
<dd>
Status message reported by the ADSC control library.</dd>
<dt>Last error, <tt>$(P)$(R)ADSCLastError</tt></dt>
<dd>
Last error message reported by the ADSC control library.</dd>
<dt>Update rate for above properties, <tt>$(P)$(R)ADSCReadConditn.SCAN</tt></dt>
<dd>
How frequently to update the above properties.</dd>
</dl>
<h3>
Detector Error Recovery</h3>
<dl>
<dt>Software Reset, <tt>$(P)$(R)ADSCSoftReset</tt></dt>
<dd>
Performs a software reset. Aborts any current operation, clears status and error
messages, and sets <em>detector state</em> to <tt>Idle</tt>.</dd>
</dl>
<h3>
Detector Continuous Image Mode</h3>
<dl>
<dt>Last Image, <tt>$(P)$(R)ADSCLastImage</tt></dt>
<dd>
Signals that the next exposure is the last image when in <tt>Continuous</tt> image
mode.</dd>
</dl>
<h3>
Detector External Trigger</h3>
<dl>
<dt>OK to expose, <tt>$(P)$(R)ADSCOkToExpose</tt></dt>
<dd>
When in <tt>External</tt> trigger mode, indicates whether it is OK to start an image
exposure.</dd>
<dt>Start, Stop, <tt>$(P)$(R)ADSCExTrCtl</tt></dt>
<dd>
When in <tt>External</tt> trigger mode, set to <tt>1</tt> to start an exposure and
<tt>0</tt> to stop it.</dd>
<dt><tt>$(P)$(R)ADSCExTrCtl_RBV</tt></dt>
<dd>
When in <tt>External</tt> trigger mode, will be <tt>Start</tt>, <tt>Stop</tt>, <tt>
OK</tt>, or <tt>Again</tt>. See <a href="#TriggerModes">Trigger Modes</a> section
for more about how this property will behave.</dd>
</dl>
<h3>
Driver Parameters</h3>
<dl>
<dt>Reuse darks, <tt>$(P)$(R)ADSCReusDrk</tt></dt>
<dd>
Reuse dark images when possible. This is useful to avoid wasting time acquiring
dark images when previously acquired dark images are available and can be reused.</dd>
<dt>Dezinger, <tt>$(P)$(R)ADSCDezingr</tt></dt>
<dd>
Acquire <q>dezingered</q> images.</dd>
</dl>
<h3>
Detector Hardware Parameters</h3>
<dl>
<dt>ADC/Binning, <tt>$(P)$(R)ADSCAdc</tt></dt>
<dd>
For Q4 and Q4r detectors, controls whether to use <tt>Fast</tt> or <tt>Slow</tt>
ADC. For all other detectors, controls whether to use <tt>Hardware</tt> or <tt>Software</tt>
binning.</dd>
<dt>Raw images, <tt>$(P)$(R)ADSCRaw</tt></dt>
<dd>
Write raw images.</dd>
<dt>Image transforms, <tt>$(P)$(R)ADSCImXform</tt></dt>
<dd>
Perform image transformations.</dd>
<dt>Stored darks, <tt>$(P)$(R)ADSCStrDrks</tt></dt>
<dd>
Use stored dark images. If set to <tt>Yes</tt>, stored dark images are assumed to
have been installed by ADSC and should be used.</dd>
</dl>
<h3>
Detector File Parameters</h3>
<dl>
<dt>Beam center X, <tt>$(P)$(R)ADSCBeamX</tt></dt>
<dd>
Beam center in the X dimension.</dd>
<dt>Beam center Y, <tt>$(P)$(R)ADSCBeamY</tt></dt>
<dd>
Beam center in the Y dimension.</dd>
<dt>Distance, <tt>$(P)$(R)ADSCDistnce</tt></dt>
<dd>
Detector distance.</dd>
<dt>Two theta, <tt>$(P)$(R)ADSC2Theta</tt></dt>
<dd>
Detector 2&theta; angle.</dd>
<dt>Axis, <tt>$(P)$(R)ADSCAxis</tt></dt>
<dd>
Crystal rotation axis.</dd>
<dt>Wavelength, <tt>$(P)$(R)ADSCWavelen</tt></dt>
<dd>
X-ray wavelength.</dd>
<dt>Image width, <tt>$(P)$(R)ADSCImWidth</tt></dt>
<dd>
Crystal rotation during exposure.</dd>
<dt>Phi, <tt>$(P)$(R)ADSCPhi</tt></dt>
<dd>
Phi position at start of exposure.</dd>
<dt>Omega, <tt>$(P)$(R)ADSCOmega</tt></dt>
<dd>
Omega position at start of exposure.</dd>
<dt>Kappa, <tt>$(P)$(R)ADSCKappa</tt></dt>
<dd>
Kappa position at start of exposure.</dd>
</dl>
<h2 id="Screenshots">
Screenshots</h2>
<ul>
<li><a href="adsc-screenshot.png">ADSC Specific MEDM GUI</a></li>
</ul>
<h2 id="Unsupported">
Unsupported <tt>areaDetector</tt> <q>base</q> Features</h2>
<ul>
<li>Shutter control</li>
<li>Collect: number of exposures per image</li>
<li>File: save file</li>
<li>File: read file</li>
<li>File: format</li>
<li>File: auto save (always <tt>Yes</tt>)</li>
<li>Readout: image region of interest</li>
<li>Readout: reverse image</li>
<li>Readout: gain</li>
<li>Readout: data type (always <tt>UInt16</tt>)</li>
<li>Image frame callbacks</li>
</ul>
<h2 id="Limitations">
Limitations</h2>
<ul>
<li>Only one ADSC detector may be controlled with this driver per OS process. If this
driver is being used in an IOC, this means only one ADSC detector may be controlled
with this driver per IOC. This is a limitation of the underlying ADSC control library
which does not support more than one detector per OS process.</li>
<li>Acquiring <q>dezingered</q> images is not supported. This is a limitation of the
underlying ADSC control library which has a bug preventing it from working correctly.</li>
<li><em>Software reset</em> does not work. This is a limitation of the underlying
ADSC control library which has a bug preventing it from working correctly. It would
be great if, after an error, performing a software reset would allow a new acquisition
to proceed normally. Currently, the recovery solution often is to restart the control
software.</li>
</ul>
</body>
</html>
+296 -296
View File
@@ -1,296 +1,296 @@
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>areaDetector: EPICS software for area detectors</title>
</head>
<body>
<h1>
areaDetector: EPICS software for area detectors</h1>
<p>
Module Owner: Mark Rivers: University of Chicago</p>
<p>
This page is the home of <b>areaDetector</b>, an application for controlling area
(2-D) detectors, including CCDs, pixel array detectors, and online imaging plates.
</p>
<p>
<b>NOTE:</b> This module will replace the <a href="http://cars.uchicago.edu/software/epics/ccd.html">
ccd</a> and <a href="http://cars.uchicago.edu/software/epics/epilatusROI.html">pilatusROI</a>
modules. &nbsp;</p>
<p>
Devices supported in <b>areaDetector</b> include:</p>
<p>
From <a href="http://www.dectris.com">Dectris</a>
</p>
<ul>
<li>The <a href="http://www.dectris.com/sites/pilatus100k.html">Pilatus</a> pixel-array
detector.</li>
</ul>
<p>
From <a href="http://www.prosilica.com">Prosilica</a>
</p>
<ul>
<li>High-speed, high-resolution CCD cameras. These use GigE and Firewire interfaces.</li>
</ul>
<p>
From <a href="http://www.mar-usa.com/">MAR</a> (coming soon)</p>
<ul>
<li>MAR-165 CCD camera.</li>
<li>MAR-345 online image plate reader</li>
</ul>
<p>
From <a href="http://www.roperscientific.com/">Roper</a> (coming soon)</p>
<ul>
<li>All CCD cameras supported by the WinView program.&nbsp; This includes the entire
Princeton Instruments line, as well as most of the Photometrics line. </li>
</ul>
<p>
From <a href="http://www.bruker-axs.de/">Bruker</a> (coming soon)</p>
<ul>
<li>The SMART CCD camera line with Photometrics cameras. This requires the PCI interface
card, replacing the old ISA bus card, and requires controlling the detector with
WinView, not the SMART software.</li>
</ul>
<p>
Please email any comments and bug reports to <a href="mailto:%20rivers@cars.uchicago.edu">
Mark Rivers</a> who is responsible for coordinating development and releases.</p>
<h2>
Where to find it</h2>
<p>
The areaDetector module is in the EPICS Applications SVN repository on <a href="http://epics.svn.sourceforge.net/viewvc/epics/applications/trunk/areaDetector/">
SourceForge.</a> Persons wishing to collaborate on this project can contact Mark
Rivers to get write access to this application there.
</p>
<p>
You can download the software from the links in the table below:</p>
<table border="1" summary="Where to find the software">
<tbody>
<tr align="center">
<th>
Module Version</th>
<th>
Release Date</th>
<th>
Filename</th>
<th>
Documentation</th>
<th>
Release Notes</th>
<th>
Known Problems</th>
</tr>
<tr>
<td>
1-2</td>
<td>
19-Sep-2008</td>
<td>
<a href="http://cars.uchicago.edu/software/pub/areaDetectorR1-1.tgz">areaDetectorR1-2.tgz</a></td>
<td>
<a href="areaDetectorDoc.html">areaDetectorDoc</a></td>
<td>
<a href="areaDetectorReleaseNotes.html">Release notes</a></td>
<td>
See release notes</td>
</tr>
<tr>
<td>
1-1</td>
<td>
10-May-2008</td>
<td>
<a href="http://cars.uchicago.edu/software/pub/areaDetectorR1-1.tgz">areaDetectorR1-1.tgz</a></td>
<td>
<a href="areaDetectorDoc.html">areaDetectorDoc</a></td>
<td>
<a href="areaDetectorReleaseNotes.html">Release notes</a></td>
<td>
See release notes</td>
</tr>
<tr>
<td>
1-0</td>
<td>
11-Apr-2008</td>
<td>
<a href="http://cars.uchicago.edu/software/pub/areaDetectorR1-0.tgz">areaDetectorR1-0.tgz</a></td>
<td>
<a href="areaDetectorDoc.html">areaDetectorDoc</a></td>
<td>
<a href="areaDetectorReleaseNotes.html">Release notes</a></td>
<td>
See release notes</td>
</tr>
</tbody>
</table>
<h2>
Required Modules</h2>
<table border="1" summary="Required Modules">
<tbody>
<tr align="center">
<th>
Module Version</th>
<th>
Requires module</th>
<th>
Release needed</th>
<th>
Required for</th>
</tr>
<tr>
<td rowspan="6">
1-2</td>
<td>
EPICS base</td>
<td>
3.14.8.2</td>
<td>
Base support</td>
</tr>
<tr>
<td>
asyn</td>
<td>
4-10</td>
<td>
Socket and interface support</td>
</tr>
<tr>
<td>
calc</td>
<td>
2-6-5</td>
<td>
scalcout record, needed by sscan database and useful for other databases</td>
</tr>
<tr>
<td>
sscan</td>
<td>
2-5-6</td>
<td>
Busy record</td>
</tr>
<tr>
<td>
mca</td>
<td>
6-10</td>
<td>
mca record for getting time sequence of ROI counts</td>
</tr>
<tr>
<td>
autosave</td>
<td>
4-3</td>
<td>
Save/restore</td>
</tr>
<tr>
<td rowspan="4">
1-1</td>
<td>
EPICS base</td>
<td>
3.14.8.2</td>
<td>
Base support</td>
</tr>
<tr>
<td>
asyn</td>
<td>
4-10</td>
<td>
Socket and interface support</td>
</tr>
<tr>
<td>
sscan</td>
<td>
2-5-6</td>
<td>
Busy record</td>
</tr>
<tr>
<td>
autosave</td>
<td>
4-3</td>
<td>
Save/restore</td>
</tr>
<tr>
<td rowspan="4">
1-0</td>
<td>
EPICS base</td>
<td>
3.14.8.2</td>
<td>
Base support</td>
</tr>
<tr>
<td>
asyn</td>
<td>
4-10</td>
<td>
Socket and interface support</td>
</tr>
<tr>
<td>
sscan</td>
<td>
2-5-6</td>
<td>
Busy record</td>
</tr>
<tr>
<td>
autosave</td>
<td>
4-3</td>
<td>
Save/restore</td>
</tr>
</tbody>
</table>
<h2>
Installation and Building</h2>
<p>
After obtaining a copy of the distribution, it must be installed and built for use
at your site. These steps only need to be performed once for the site (unless versions
of the module running under different releases of EPICS and/or the other required
modules are needed).</p>
<ol>
<li>Create an installation directory for the module, usually this will end with<br />
<br />
<tt>.../support/</tt>
<br />
</li>
<li>Place the distribution file in this directory. Then issue the commands (Unix style)
<pre>tar xvzf areaDetectorRX-Y.tgz
</pre>
where X-Y is the release.</li>
<li>This creates a &lt;top&gt; application.<br />
<pre>.../support/areaDetectorRX-Y
</pre>
</li>
<li>Edit the <tt>config[ure]/RELEASE</tt> file and set the paths to your installation
of EPICS base and to your versions of supporting modules.</li>
<li>Run <tt>gnumake</tt> in the top level directory and check for any compilation
errors.</li>
<li>Please email&nbsp; <a href="mailto:rivers@cars.uchicago.edu">Mark Rivers</a>&nbsp;
so that a record can be kept of which sites are using this software.</li>
</ol>
<h2>
In Use</h2>
<p>
This software was originally developed by Mark Rivers.</p>
<ul>
<li>ANL/APS : In use at CARS beamlines.</li>
<li>Australian Synchrotron : In use at microspectroscopy beamline, ID5.</li>
</ul>
</body>
</html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>areaDetector: EPICS software for area detectors</title>
</head>
<body>
<h1>
areaDetector: EPICS software for area detectors</h1>
<p>
Module Owner: Mark Rivers: University of Chicago</p>
<p>
This page is the home of <b>areaDetector</b>, an application for controlling area
(2-D) detectors, including CCDs, pixel array detectors, and online imaging plates.
</p>
<p>
<b>NOTE:</b> This module will replace the <a href="http://cars.uchicago.edu/software/epics/ccd.html">
ccd</a> and <a href="http://cars.uchicago.edu/software/epics/epilatusROI.html">pilatusROI</a>
modules. &nbsp;</p>
<p>
Devices supported in <b>areaDetector</b> include:</p>
<p>
From <a href="http://www.dectris.com">Dectris</a>
</p>
<ul>
<li>The <a href="http://www.dectris.com/sites/pilatus100k.html">Pilatus</a> pixel-array
detector.</li>
</ul>
<p>
From <a href="http://www.prosilica.com">Prosilica</a>
</p>
<ul>
<li>High-speed, high-resolution CCD cameras. These use GigE and Firewire interfaces.</li>
</ul>
<p>
From <a href="http://www.mar-usa.com/">MAR</a> (coming soon)</p>
<ul>
<li>MAR-165 CCD camera.</li>
<li>MAR-345 online image plate reader</li>
</ul>
<p>
From <a href="http://www.roperscientific.com/">Roper</a> (coming soon)</p>
<ul>
<li>All CCD cameras supported by the WinView program.&nbsp; This includes the entire
Princeton Instruments line, as well as most of the Photometrics line. </li>
</ul>
<p>
From <a href="http://www.bruker-axs.de/">Bruker</a> (coming soon)</p>
<ul>
<li>The SMART CCD camera line with Photometrics cameras. This requires the PCI interface
card, replacing the old ISA bus card, and requires controlling the detector with
WinView, not the SMART software.</li>
</ul>
<p>
Please email any comments and bug reports to <a href="mailto:%20rivers@cars.uchicago.edu">
Mark Rivers</a> who is responsible for coordinating development and releases.</p>
<h2>
Where to find it</h2>
<p>
The areaDetector module is in the EPICS Applications SVN repository on <a href="http://epics.svn.sourceforge.net/viewvc/epics/applications/trunk/areaDetector/">
SourceForge.</a> Persons wishing to collaborate on this project can contact Mark
Rivers to get write access to this application there.
</p>
<p>
You can download the software from the links in the table below:</p>
<table border="1" summary="Where to find the software">
<tbody>
<tr align="center">
<th>
Module Version</th>
<th>
Release Date</th>
<th>
Filename</th>
<th>
Documentation</th>
<th>
Release Notes</th>
<th>
Known Problems</th>
</tr>
<tr>
<td>
1-2</td>
<td>
19-Sep-2008</td>
<td>
<a href="http://cars.uchicago.edu/software/pub/areaDetectorR1-1.tgz">areaDetectorR1-2.tgz</a></td>
<td>
<a href="areaDetectorDoc.html">areaDetectorDoc</a></td>
<td>
<a href="areaDetectorReleaseNotes.html">Release notes</a></td>
<td>
See release notes</td>
</tr>
<tr>
<td>
1-1</td>
<td>
10-May-2008</td>
<td>
<a href="http://cars.uchicago.edu/software/pub/areaDetectorR1-1.tgz">areaDetectorR1-1.tgz</a></td>
<td>
<a href="areaDetectorDoc.html">areaDetectorDoc</a></td>
<td>
<a href="areaDetectorReleaseNotes.html">Release notes</a></td>
<td>
See release notes</td>
</tr>
<tr>
<td>
1-0</td>
<td>
11-Apr-2008</td>
<td>
<a href="http://cars.uchicago.edu/software/pub/areaDetectorR1-0.tgz">areaDetectorR1-0.tgz</a></td>
<td>
<a href="areaDetectorDoc.html">areaDetectorDoc</a></td>
<td>
<a href="areaDetectorReleaseNotes.html">Release notes</a></td>
<td>
See release notes</td>
</tr>
</tbody>
</table>
<h2>
Required Modules</h2>
<table border="1" summary="Required Modules">
<tbody>
<tr align="center">
<th>
Module Version</th>
<th>
Requires module</th>
<th>
Release needed</th>
<th>
Required for</th>
</tr>
<tr>
<td rowspan="6">
1-2</td>
<td>
EPICS base</td>
<td>
3.14.8.2</td>
<td>
Base support</td>
</tr>
<tr>
<td>
asyn</td>
<td>
4-10</td>
<td>
Socket and interface support</td>
</tr>
<tr>
<td>
calc</td>
<td>
2-6-5</td>
<td>
scalcout record, needed by sscan database and useful for other databases</td>
</tr>
<tr>
<td>
sscan</td>
<td>
2-5-6</td>
<td>
Busy record</td>
</tr>
<tr>
<td>
mca</td>
<td>
6-10</td>
<td>
mca record for getting time sequence of ROI counts</td>
</tr>
<tr>
<td>
autosave</td>
<td>
4-3</td>
<td>
Save/restore</td>
</tr>
<tr>
<td rowspan="4">
1-1</td>
<td>
EPICS base</td>
<td>
3.14.8.2</td>
<td>
Base support</td>
</tr>
<tr>
<td>
asyn</td>
<td>
4-10</td>
<td>
Socket and interface support</td>
</tr>
<tr>
<td>
sscan</td>
<td>
2-5-6</td>
<td>
Busy record</td>
</tr>
<tr>
<td>
autosave</td>
<td>
4-3</td>
<td>
Save/restore</td>
</tr>
<tr>
<td rowspan="4">
1-0</td>
<td>
EPICS base</td>
<td>
3.14.8.2</td>
<td>
Base support</td>
</tr>
<tr>
<td>
asyn</td>
<td>
4-10</td>
<td>
Socket and interface support</td>
</tr>
<tr>
<td>
sscan</td>
<td>
2-5-6</td>
<td>
Busy record</td>
</tr>
<tr>
<td>
autosave</td>
<td>
4-3</td>
<td>
Save/restore</td>
</tr>
</tbody>
</table>
<h2>
Installation and Building</h2>
<p>
After obtaining a copy of the distribution, it must be installed and built for use
at your site. These steps only need to be performed once for the site (unless versions
of the module running under different releases of EPICS and/or the other required
modules are needed).</p>
<ol>
<li>Create an installation directory for the module, usually this will end with<br />
<br />
<tt>.../support/</tt>
<br />
</li>
<li>Place the distribution file in this directory. Then issue the commands (Unix style)
<pre>tar xvzf areaDetectorRX-Y.tgz
</pre>
where X-Y is the release.</li>
<li>This creates a &lt;top&gt; application.<br />
<pre>.../support/areaDetectorRX-Y
</pre>
</li>
<li>Edit the <tt>config[ure]/RELEASE</tt> file and set the paths to your installation
of EPICS base and to your versions of supporting modules.</li>
<li>Run <tt>gnumake</tt> in the top level directory and check for any compilation
errors.</li>
<li>Please email&nbsp; <a href="mailto:rivers@cars.uchicago.edu">Mark Rivers</a>&nbsp;
so that a record can be kept of which sites are using this software.</li>
</ol>
<h2>
In Use</h2>
<p>
This software was originally developed by Mark Rivers.</p>
<ul>
<li>ANL/APS : In use at CARS beamlines.</li>
<li>Australian Synchrotron : In use at microspectroscopy beamline, ID5.</li>
</ul>
</body>
</html>