diff --git a/documentation/adscDoc.html b/documentation/adscDoc.html index c4a8c33..d5bff74 100644 --- a/documentation/adscDoc.html +++ b/documentation/adscDoc.html @@ -1,12 +1,12 @@ - + areaDetector ADSC driver -
+

areaDetector ADSC driver

@@ -15,7 +15,7 @@ Lewis Muir

University of Chicago

-
+

Table of Contents

    diff --git a/documentation/areaDetectorDoc.html b/documentation/areaDetectorDoc.html index 06f943c..ab5d78d 100755 --- a/documentation/areaDetectorDoc.html +++ b/documentation/areaDetectorDoc.html @@ -13,8 +13,6 @@

    University of Chicago

    -

    -  

    Contents

    -

    - asynNDArrayDriver

    +

    + asynNDArrayDriver

    asynNDArrayDriver inherits from asynPortDriver. It implements the asynGenericPointer functions, assuming that these reference NDArray objects. This is the class from @@ -665,8 +664,8 @@ public:

  1. report This method calls the report function in the asynPortDriver base class. It then calls the NDArrayPool->report() method if details > 5.
    2. -

    - ADDriver

    +

    + ADDriver

    ADDriver inherits from asynNDArrayDriver. This is the class from which area detector drivers are directly derived. Its public interface is defined as follows: @@ -701,8 +700,8 @@ public: file name in the ADFullFileName parameter from the ADFilePath, ADFileName, ADFileNumber, and ADFileTemplate parameters. -

    - ADStdDriverParams

    +

    + ADStdDriverParams

    The file ADStdDriverParams.h defines the following:

    @@ -761,18 +760,18 @@ typedef enum ending in _RBV, that contains the actual value (Read Back Value) of the parameter.
  2. EPICS record type: The record type of the record. Waveform records are used to hold long strings, with length (NELM) = 256 bytes and EPICS data type (FTVL) - = UCHAR. This removes the 40 character restriction on path name lengths that arise - if an EPICS "string" PV is used. medm allows one to edit and display such records - correctly. EPICS clients will typically need to convert the path name from a string - to an integer or byte array before sending the path name to EPICS. This is easy - to do in clients like SPEC, Matlab, and IDL.
    3. + = UCHAR. This removes the 40 character restriction string lengths that arise if + an EPICS "string" PV is used. MEDM allows one to edit and display such records correctly. + EPICS clients will typically need to convert the path name from a string to an integer + or byte array before sending the path name to EPICS. This is easy to do in clients + like SPEC, Matlab, and IDL.

    Note that for parameters whose values are defined by enum values (e.g ADImageMode, ADTriggerMode, ADFileFormat, ADStatus), drivers can use a different set of enum values for these parameters. They can override the enum menu in ADBase.template - with detector-specific choices by loading a detector-specific template file after - loading ADBase.template. + with detector-specific choices by loading a detector-specific template file that + redefines that record field after loading ADBase.template.

    @@ -1352,7 +1351,7 @@ typedef enum + Full file name constructed using the algorithm described in ADFileTemplate + 1 each time a file is saved (0=No, 1=Yes) + Auto-save flag (0=No, 1=Yes) controlling whether a file is automatically saved each + time acquisition completes. + Controls the exposure period in seconds. It applies only in Internal or External + Trigger modes when NumImages > 1.
    r/o - Full file name FULL_FILE_NAME @@ -1370,7 +1369,7 @@ typedef enum r/w Auto-increment flag. Controls whether FileNumber is automatically incremented by - 1 each time an acquisition completes (0=No, 1=Yes) AUTO_INCREMENT @@ -1388,7 +1387,8 @@ typedef enum r/w - Auto-save flag (0=No, 1=Yes) AUTO_SAVE @@ -1656,5 +1656,9 @@ typedef enum
  3. Pilatus driver
  4. ADSC driver
    5. +

    + In addition to these drivers, Brian Tieman is writing a driver for the Perkin-Elmer + flat-panel amorphous silicon detector. Drivers for the MAR-CCD, MAR-345 online image + plate, and the Roper Scientific CCD cameras will be written in the near future.

    diff --git a/documentation/pilatusDoc.html b/documentation/pilatusDoc.html index 813c435..a2a9966 100755 --- a/documentation/pilatusDoc.html +++ b/documentation/pilatusDoc.html @@ -7,7 +7,7 @@

    areaDetector Pilatus driver

    - September 17, 2008

    + September 21, 2008

    Mark Rivers

    @@ -115,8 +115,8 @@

    		$(P$(R)ExposurePeriod - Controls the exposure period in seconds. It is only in Internal or External Trigger - modes when NumImages > 1.
    @@ -159,17 +159,18 @@ 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 in - areaDetectorDoc.html is used as a basename. The following examples show the - interpretation of the basename. - 
          Basename            Files produced
+          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.
+          
    +Basename            Files produced
      
-      test6.tif           test6_00000.tif,  test6_00001.tif, ...
-      test6_.tif          test6_00000.tif,  test6_00001.tif, ...
-      test6_000.tif       test6_000.tif,    test6_001.tif, ...
-      test6_014.tif       test6_014.tif,    test6_015.tif, ...
-      test6_0008.tif      test6_0008.tif,   test6_0009.tif, ...
-      test6_2_0035.tif    test6_2_0035.tif, test6_2_0036.tif, ...
+test6.tif           test6_00000.tif,  test6_00001.tif, ...
+test6_.tif          test6_00000.tif,  test6_00001.tif, ...
+test6_000.tif       test6_000.tif,    test6_001.tif, ...
+test6_014.tif       test6_014.tif,    test6_015.tif, ...
+test6_0008.tif      test6_0008.tif,   test6_0009.tif, ...
+test6_2_0035.tif    test6_2_0035.tif, test6_2_0036.tif, ...
       
    
           The numbers following the last '_' are taken as a format template, and as a start
           value. The minimum format is 3; there is no maximum; the default is 5. The format
@@ -179,8 +180,8 @@

    It is useful to use NDPluginROI to define an ROI containing the entire Pilatus detector. - This ROI can be monitored to make sure that the 20-bit limit of 1,048,575 is not - being approached in any pixel. + The MaxValue_RBV PV in this ROI can be monitored to make sure that the 20-bit limit + of 1,048,575 is not being approached in any pixel.

    Pilatus specific parameters

    @@ -317,24 +318,26 @@ a valid bad pixel file then no bad pixel mapping is performed. The bad pixel map is used before making the NDArray callbacks. It does not modify the data in the files that camserver writes. This is a simple ASCII file with the following format: - 
          badX1,badY1 replacementX1,replacementY1 
-      badX2,badY2 replacementX2,replacementY2
-      ...
-
    + 
    +badX1,badY1 replacementX1,replacementY1 
+badX2,badY2 replacementX2,replacementY2
+...
+
    The X and Y coordinates range from 0 to NXPixels-1 and NYPixels-1. Up to 100 bad pixels can be defined. The bad pixel mapping simply replaces the bad pixels with another pixel's value. It does not do any averaging. It is felt that this is sufficient - for the purpose for which pilatusROI was written, namely fast on-line viewing of - ROIs and ImageData. More sophisticated algorithms can be used for offline analysis + for the purpose for which this driver was written, namely fast on-line viewing of + ROIs and image data. More sophisticated algorithms can be used for offline analysis of the image files themselves. The following is an example bad pixel file for a GSECARS detector: - 
              263,3   262,3
-          264,3   266,3
-          263,3   266,3
-          300,85  299,85
-          300,86  299,86
-          471,129 472,129
-
    + 
              
+263,3   262,3
+264,3   266,3
+263,3   266,3
+300,85  299,85
+300,86  299,86
+471,129 472,129
+
    BAD_PIXEL_FILE @@ -378,8 +381,9 @@ All pixels with intensity < PilatusMinFlatField in the flat field are replaced with averageFlatField. When images are collected before the NDArray callbacks are performed the following per-pixel correction is applied: - 
                ImageData[i] = (averageFlatField * ImageData[i])/flatField[i];
-
    + 
    +ImageData[i] = (averageFlatField * ImageData[i])/flatField[i];
+
    FLAT_FIELD_FILE @@ -453,8 +457,9 @@ 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);
+  
       
+pilatusDetectorConfig(const char *portName, const char *camserverPort, 
+                      int maxSizeX, int maxSizeY, int maxBuffers, size_t maxMemory);
   
    
   
@@ -600,8 +605,8 @@ create_monitor_set("auto_settings.req", 30,"P=13PIL1:,D=cam1:")
     Note that the general purpose screen ADBase.adl can be used, but it exposes many
     controls that are not applicable to the Pilatus.
    
-    pilatusDetector.adl is the main screen used to control the pilatusROI
-    SNL program. All records except those for ROIs are accessed through this screen.
+    pilatusDetector.adl is the main screen used to control the Pilatus
+    driver. All records except those for ROIs are accessed through this screen.
   
    
     
    
@@ -610,8 +615,8 @@ create_monitor_set("auto_settings.req", 30,"P=13PIL1:,D=cam1:")
   
    
     NDROI8.adl is used to define the ROIs, and to display the statistics
     for each ROI. In this example there are 3 valid ROIs defined. ROI 0 is the entire
-    detector.  ROI 1 is a 100x50 rectangle starting at [300,60], and ROI 2 is a
-    50x30 rectangle starting at [320,70]..
    
+    detector, ROI 1 is a 100x50 rectangle starting at [300,60], and ROI 2 is a 50x30
+    rectangle starting at [320,70].
    
   
    
     
    
       NDROI8.adl
    
@@ -745,21 +750,21 @@ def user_getcounts '{
     Performance measurements
    
   
    
     The following measurements were done to demonstrate the performance that can be
-    obtained with pilatusROI.
    
+    obtained with the areaDetector Pilatus driver.
    
   
      
-    
    1. AcquireMode=Internal, NImages=1000, ExposureTime=.005, ExposurePeriod=.01, NExposures=1.
+    
    2. AcquireMode=Internal, NumImages=1000, AcquireTime=.005, AcquirePeriod=.01, NumExposures=1.
       The time to collect this series should be exactly 10.0 seconds. The actual time
       was measured using the EPICS camonitor program. It printed the time when acquisition
-      was started (Acquire changed to Busy) and when acquisition was complete (Acquire
-      changed to Done). The time was 10.274 seconds. This includes the time for camserver
+      was started (Acquire changed to Acquire=1) and when acquisition was complete (Acquire
+      changed to Done=0). The time was 10.022 seconds. This includes the time for camserver
       to save all 1000 images to disk (366 MB), and for pilatusROI to read each file,
       correct the bad pixels and flat field, compute the ROIs, and post the ROIs to EPICS.
-      It also posted the images to EPICS at 1Hz (10 images total). The total additional
-      time was less than 0.3 seconds for all 1000 images.
      3. 
+      It also posted all of the images to EPICS. The total additional time was less than
+      0.03 seconds for all 1000 images.
     
    3. AcquireMode=Internal, NImages=1, ExposureTime=.01, NExposures=1. An EPICS sscan
       record was used to collect 1000 points. There were no positioner PVs (to eliminate
-      motor overhead). The only detector trigger was the pilatusROI Acquire PV. The only
-      detector PV was ROI1TotalCounts. In this mode camserver is being told to individually
+      motor overhead). The only detector trigger was the Pilatus Acquire PV. The only
+      detector PV was ROI1:0:Total_RBV. In this mode camserver is being told to individually
       collect each file. If there were no overhead then time to collect this series should
       be exactly 10.0 seconds. The actual time measured using the EPICS camonitor program
       was 49.161 seconds. The overhead is thus 39.161 seconds, or 39 ms per point. In
diff --git a/documentation/prosilicaDoc.html b/documentation/prosilicaDoc.html
index a7d3989..2c37859 100755
--- a/documentation/prosilicaDoc.html
+++ b/documentation/prosilicaDoc.html
@@ -7,14 +7,12 @@
     
      
       areaDetector Prosilica driver
      
     
      
-      September 17, 2008
      
+      September 20, 2008
     
      
       Mark Rivers
      
     
      
       University of Chicago
      
   
    
-  
    
-     
    
     Contents
    
     Prosilica Driver
    
@@ -32,8 +31,8 @@
     to the Prosilica cameras. The driver is currently only supported under Windows (EPICS
     win32-x86 architecture) because the vendor library is provided as a Windows DLL.
     The vendor library provided by Prosilica does callbacks to a user-supplied function
-    each time there is a new frame. Thus, it is not necessary to create a thread for
-    callbacks in this driver.
+    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
@@ -246,7 +245,7 @@
         
    
+          PS_PACKETS_REQUESTED
    
     
   
   
   
   
   
   
    
           Number of packets requested
         
-          PS_PACKETS_RESENT
         
           $(P)$(R)PSPacketsRequested_RBV
         
@@ -302,10 +301,21 @@
       prosilica.adl
     prosilica.png
   
    
-    The following is an IDL epics_ad_display screen (discussed below) illustrating the
-    Prosilica detector images.
+    The following is an IDL 
+      epics_ad_display screen displaying the Prosilica detector images.
   
    
   
    
+    
    
+      epics_ad_display.pro
    
     prosilica_tvscl.jpg
    
+  
    
+    Future enhancements
    
+  
    
+    The driver does not currently support color. This will be added in the near future.
+  
    
+  
    
+    Work is needed on connection management. If the camera is unplugged or powered off
+    which the areaDetector driver is running it does not gracefully recover.
+  
    
 
 
diff --git a/documentation/simDetectorDoc.html b/documentation/simDetectorDoc.html
index 636b9c4..5f1baac 100755
--- a/documentation/simDetectorDoc.html
+++ b/documentation/simDetectorDoc.html
@@ -7,7 +7,7 @@
     
    
       areaDetector Simulation driver
    
     
    
-      September 5, 2008
    
+      September 20, 2008
     
    
       Mark Rivers
    
     
    
@@ -22,7 +22,7 @@
     
  5. Simulation driver specific parameters
    6. 
     
  6. Unsupported standard driver parameters
    7. 
     
  7. Screenshots
    8. 
-    
  8. Configuring
    9. 
+    
  9. Configuration
    10. 
   
   
    
     Introduction
    
@@ -35,27 +35,27 @@
     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);
+  
    +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);
 
    
   
    
-    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.
+    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.
   
    
   
    
     The simulation driver initially sets the image[i, j] = i*gainX + j*gainY * gain
@@ -73,19 +73,19 @@ public:
     is started that thread computes new images and then calls back any registered plugins
     as follows:
   
    
-  
    -        /* 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);
+  
    +        /* 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
    
@@ -95,7 +95,7 @@ public:
   
-        
@@ -183,46 +183,74 @@ public:
   
    
     The following is the MEDM screen ADBase.adl connected to a simulation detector.
   
    
-  
    
+  
    
+    
    
+      ADBase.adl
    
     ADBase_sim.png
-  
    
+  
    
     The following is the MEDM screen that provides access to the specific parameters
     for the simulation detector.
   
    
-  
    
+  
    
+    
    
+      simDetector.adl
    
     simDetector.png
-  
    
+  
    
-    The following is an IDL epics_ad_display screen using image_display (discussed below)
-    illustrating 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
-  
    
-  
    
-    Configuring
    
+  
    
+  
    
+    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:
   
    
-  
    
-    
    int simDetectorConfig(const char *portName, int maxSizeX, int maxSizeY, int
-      dataType, int maxBuffers, size_t maxMemory)
    
-    
    
-      
    
-        
    portName
    
-        
    
-          ASYN port name for the driver instance
    
-        
    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
    
-        
    
+  
    +simDetectorConfig(const char *portName, int maxSizeX, int maxSizeY, 
+                  int dataType, int maxBuffers, size_t maxMemory)
+  
    
+  
    
     
       
    
+        
           Parameter Definitions in simDetector.cpp and EPICS Record Definitions in simDetector.template
       
    
       
    
   
   
   
    
+    
+      
+        
+        
+      
+      
+        
+        
+      
+      
+        
+        
+      
+      
+        
+        
+      
+      
+        
+        
+      
+      
+        
+        
+      
+      
+        
+        
+      
+    
+  
    
+          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.
           
      
@@ -235,21 +263,29 @@ public:
             
    • 6=NDFloat32
      • 
             
    • 7=NDFloat64
      • 
           
    
-        
-        
    maxBuffers
    
-        
    
+        
    
+          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
    
-        
    
+          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 (~33MB).
-      
-    
-  
+          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