RRM 3-13 Scan

From EPICSWIKI
Revision as of 21:51, 1 September 2005 by AndrewJohnson (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

EPICS Record Reference Manual


scan

Ned D. Arnold
Advanced Photon Source
Argonne National Laboratory

Introduction

The basic function of a scan record is to move positioners through a series of steps and record detector data at each of the positions, the whole sequence being referred to as a scan. Once the scan parameters are properly initialized, the scan record coordinates the entire scan and notifies any interested clients when the scan is complete. The data is stored in arrays within the record rather than collected point to point by an external application program. This allows for much faster scans than those coordinated from an external application program on a point to point basis.

A single scan record supports a one dimensional scan. It is also possible to link scan records together to define multi-dimensional scans in a complex configuration.

Each scan record can control up to four positioners and acquire data from up to four process variables (typically detector data or measured positions of devices) during a scan. Two additional output variables can be defined to trigger other process variables (usually detectors) between the positioning phase and the data acquisition phase. These outputs will be referred to as detector triggers.

Although the typical use of a scan record is to move positioners and record detector data at each position, it can also be used for other applications. Any controllable device can be scanned through incremental values while recording data from any other process variables. For example, one of the positioner process variables could be used to vary the gain of a detector or the speed of a motor during a scan. Another example would be to use the scan record to vary several power supplies and record the beam position at each value of the supplies. In this context, the scan record becomes a general purpose "Vary w, x, y, z and record a, b, c, d" record. Therefore, throughout this document the word positioner and controller will be used synonymously. When referring to the data being recorded at each point, the word detector will be used.

All of the process variable names used to identify positioners, detectors, and detector triggers are specified using reassignable links. This allows a scan to be configured on the fly.

Scan parameters, including the names of controllers and detectors, can be saved and restored using the BURT.

NOTE: In this version, the PVs used in the reassignable fields must reside in the same IOC.

A Simple Single Dimensional Scan

The simplest database configuration for using a scan record is shown in Figure 1. A thorough understanding of the operation of this configuration will allow more complex scans to be developed easily.

When the scan is initiated, the scan record commands several positioners (TRANSFORM record and MOTOR record) to move to their starting positions. The WAIT_1 record detects when all movement is complete and forces the SCAN record to process again. The SCAN record realizes that the positioning is complete and thus triggers the Detectors. The WAIT_2 record detects when data is valid and forces the SCAN record to process yet again. The SCAN record will then read the Detector Data and command the positioners to their next step. This will continue until the SCAN record has completed the appropriate number of steps. At the end of the scan, the SCAN record contains data arrays for each of the detectors, as well as arrays that contain the positions to which each controller was commanded at each point. A simple x-y plot using this data will provide the detector data vs. position results.

Figure 1: Typical Database Support for a SCAN

Figure 1


Two Dimensional Scanning

Figure 2 illustrates using two scan records to accomplish a two dimensional scan. The SCAN_X record controls the positioners for the X axis, while the SCAN_Y record controls the Y positioner.

To initiate a scan, the SCAN_Y record is commanded to begin. It commands its positioners to the specified starting point. The WAIT_1 record detects when all motors are stopped and forces the SCAN_Y record to process again. The SCAN_Y record will now write to its Detector Trigger, which in this case begins a scan of the SCAN_X record. The SCAN_X record will now go through its entire programmed scan, acquiring data from the detectors at each point.

When the SCAN_X record is complete, the WAIT_4 record will force the processing of SCAN_Y, which will increment the position of the y-controller and initiate the x scan once again.

This approach to configuring a two dimensional scan is very flexible. Note that to test the x scan, one could write to the begin scan field of SCAN_X which would perform an entire x scan. Although the SCAN_Y record would get processed after the x scan was complete (via the WAIT_4 record), nothing would happen because it was not in the middle of a scan. In addition, any of the motors can be moved individually when a scan is not in process without any unexpected behavior (detectors would not be triggered unless the operator did it deliberately). One could even build a three dimensional scan by adding an additional scan record that initiates the y-scan after positioning a z-controller.

Figure 2: A Two Dimensional Scan

Figure 2


Parameter Fields

Scan Parameters

Several options are available to control the execution of a scan. All parameters must be properly configured prior to initiating the scan.

Positioner Parameters

Each scan record may control up to four positioners that are commanded to a new desired position after collecting data at each point. The positioners are defined by typing in an ASCII string that represents the process variable name of the controller.

There are three modes for determining the desired value for the positioner. The desired mode is specified in the P1SM-P4SM fields: Linear, Table, and On-The-Fly. If a positioner is specified as Linear, its desired value is determined by using parameters such as start position, step increment, number of points, and end position (which are explained below). If a positioner is specified as Table, its next position is found in an array that has been loaded into the record prior to initiating a scan. If the positioner is specified as On-The-Fly, it is commanded to the end position after the first data point is collected and not changed again for the duration of the scan.


FieldSummaryTypeDCTInitialAccessModifyRec Proc MonitorPP
P1SMPositioner 1 Step ModeRECCHOICEYes0YesYesNoNo
P2SMPositioner 2 Step ModRECCHOICEYes0YesYesNoNo
P3SMPositioner 3 Step ModeRECCHOICEYes0YesYesNoNo
P4SMPositioner 4 Step ModeRECCHOICEYes0YesYesNoNo


Linear Mode Parameters

If a positioner's step mode field (P1SM) specifies Linear, a scan can be fully defined by three parameters, e.g., the start position (P1SP), the step increment (P1SI), and the number of data points (NPTS). A scan involving N controllers is defined by merely 2N+1 parameters, since NPTS applies to all positioners. For the convenience of interactive users, and to support channel access clients that define scans differently, the first positioner can be specified by as many as six parameters: starting position (P1SP), ending position (P1EP), center position (P1CP), position width (P1WD), step increments (P1SP), and NPTS. For the other three positioners, the same parameters are available minus the NPTS field, since that applies to all. The parameters that pertain to the same positioner are a set. The record imposes an upper limit (MPTS) on NPTS. Both MPTS and NPTS are configured by the user. The positioner width, configurable in the P1WD-P4WD fields, may be negative.


FieldSummaryTypeDCTInitialAccessModifyRec Proc MonitorPP
NPTSNumber of Points SHORTYes100YesYesYesNo
MPTSMaximum Number of PointsSHORTYes100YesNoNoNo
P1SPPositioner 1 Starting PointFLOATYes0YesYesYesNo
P2SPPositioner 2 Starting PointFLOATYes0YesYesYesNo
P3SPPositioner 3 Starting PointFLOATYes0YesYesYesNo
P4SPPositioner 4 Starting PointFLOATYes0YesYesYesNo
P1EPPositioner 1 Ending PointFLOATYes0YesYesYesNo
P2EPPositioner 2 Ending PointFLOATYes0YesYesYesNo
P3EPPositioner 3 Ending PointFLOATYes0YesYesYesNo
P4EPPositioner 4 Ending PointFLOATYes0YesYesYesNo
P1CPPositioner 1 Center PointFLOATYes0YesYesYesNo
P2CPPositioner 2 Center PointFLOATYes0YesYesYesNo
P3CPPositioner 3 Center PointFLOATYes0YesYesYesNo
P4CPPositioner 4 Center PointFLOATYes0YesYesYesNo
P1WDPositioner 1 WidthFLOATYes0YesYesYesNo
P2WDPositioner 2 WidthFLOATYes0YesYesYesNo
P3WDPositioner 3 WidthFLOATYes0YesYesYesNo
P4WDPositioner 4 WidthFLOATYes0YesYesYesNo
P1SIPositioner 1 Step IncrementFLOATYes0YesYesYesNo
P2SIPositioner 2 Step IncrementFLOATYes0YesYesYesNo
P3SIPositioner 3 Step IncrementFLOATYes0YesYesYesNo
P4SIPositioner 4 Step IncrementFLOATYes0YesYesYesNo


Some of these fields can be redundant. For instance, the positioner width (P1WD-P4WD) is simply the distance from the starting position to the ending position (PnEP - PnSP). The record calculates redundant parameters for the same set, if the parameters are left undefined. However, the user can still configure the redundant parameters anyway.

There is no unique prescription for removing inconsistencies among redundant parameters, and no hard-coded set of preferences among parameters is likely to please everyone. Therefore, the scan record allows the user to "freeze" parameters with flags so that they will not be changed by the record's internal attempts to ensure consistency among the parameter set. Frozen parameters can be changed by the user and by any other client, but not by the record. It is the user's responsibility to ensure that frozen parameters do not prevent freely specifying unfrozen parameters. For example, if both PnSI and NPTS are frozen, changes to PnWD will be rejected. Similarly, if both PnSP and PnCP are frozen, changes to PnEP and PnWD will have no effect. By default, PnSP, PnSI, and NPTS are frozen. When the record cannot adjust the parameters to be consistent, a flag is raised in the alert field (ALRT) and a message reported in the state message field (SMSG).

The freeze flag override field (FFO) has two choices: Use F-Flags and Override. Override causes the current settings of all the freeze flags to be saved and monitors to be called for those that have changed. Use F-Flags causes the flags saved with the Override command to be restored if any have changed. Changing the choice of this field at run-time causes the special record support routines to perform these actions. So if Override is chosen at run-time, then all current settings are saved, and can be restored at a later time by changing the FFO field to Use F-Flags.


FieldSummaryTypeDCTInitialAccessModifyRec Proc MonitorPP
FPTSFreeze Flag for NPTSRECCHOICEYes1YesYesNoNo
FFOFreeze Flag OverrideRECCHOICEYesNullYesYesNoNo
PnFSPositioner n Freeze Flag for PnSPRECCHOICEYes1YesYesNoNo
PnFEPositioner n Freeze Flag for PnEPRECCHOICEYes0YesYesNoNo
PnFIPositioner n Freeze Flag for PnSIRECCHOICEYes1YesYesNoNo
PnFCPositioner n Freeze Flag for PnCPRECCHOICEYes0YesYesNoNo
PnFWPositioner n Freeze Flag for PnWDRECCHOICEYes0YesYesNoNo


Although this approach may seem to present the user with an overwhelming number of choices when it comes to linear scans, it should be noted that by default the user only has to configure NPTS, and the starting position (PnSP) and the step increment (PnSI) fields for each positioner in order to fully define the scan of a positioner. The operator interface (usually DM, medm or another CA client) need only present the user with these fields. However, by changing the freeze flags from the defaults and presenting the user with different fields to fill in, the scan can be defined in a completely flexible way. The result is that a simple scan can be defined easily, but advanced users are not limited in flexibility.


Lookup Mode Parameters

For those positioners using the linear mode, each desired position value (contained in the PnDV fields) is placed in the arrays referenced by the PnPA fields that are used for the lookup mode. Therefore, after the scan is complete, these arrays will always contain the sequence of positions to which the controller was commanded by the linear algorithm. For look-up mode, the user provides the values for the PnPA arrays prior to run-time. These arrays will contain no useful data if on-the-fly mode is used.


FieldSummaryTypeDCTInitialAccessModifyRec Proc MonitorPP
P1PAPositioner 1 Position ArrayFLOAT[ ]NoNullYesYesYesNo
P2PAPositioner 2 Position ArrayFLOAT[ ]NoNullYesYesYesNo
P3PAPositioner 3 Position ArrayFLOAT[ ]NoNullYesYesYesNo
P4PAPositioner 4 Position ArrayFLOAT[ ]NoNullYesYesYesNo


Position Verification, Readback Process Variable, and Delta Parameters

For each positioner, the user may specify a process variable in the R1PV-R4PV fields that corresponds to the actual (or measured) position of the motor. If this readback field is configured, the scan record will confirm after each movement that the actual position is within a specified delta to the desired position. The delta is specified in the R1DL-R4DL fields. If the delta is exceeded, the scan will abort and the record will go into an alarm state. A text field within the record (SMSG) will inform the operator of the error condition


FieldSummaryTypeDCTInitialAccessModifyRec Proc MonitorPP
R1PVReadback 1 Process Variable STRING [40]YesNullYesYesNoNo
R2PVReadback 2 Process Variable STRING [40]YesNullYesYesNoNo
R3PVReadback 3 Process Variable STRING [40]YesNullYesYesNoNo
R4PVReadback 4 Process Variable STRING [40]YesNullYesYesNoNo
R1DLReadback 1 Delta FLOATYes0YesYesNoNo
R2DLReadback 2 Delta FLOATYes0YesYesNoNo
R3DLReadback 3 Delta FLOATYes0YesYesNoNo
R4DLReadback 4 Delta FLOATYes0YesYesNoNo


Detector Trigger Process Variables and Desired Command

If valid process variable names are entered into the detector trigger fields (TIPV-T2PV) fields, the scan record will write the specified desired command (a floating point number) to that process variable between the positioning phase and the data acquisition phase.

If neither detector trigger field contains a valid PV, the scan record will skip this step and acquire the data immediately. Note that specifying a Detector Trigger requires the scan record to be processed an additional time each point.


FieldSummaryTypeDCTInitialAccessModifyRec Proc MonitorPP
T1PVDetector Trigger 1 Process Variable STRING [40]YesNullYesYesNoNo
T2PVDetector Trigger 2 Process Variable STRING [40]YesNullYesYesNoNo
T1CDTrigger 1 CommandFLOATYes0YesYesNoNo
T2CD Trigger 2 CommandFLOATYes0YesYesNoNo


Data Acquisition Parameters

Each scan record can acquire data from up to four process variables at each point in the scan. This data will most commonly be from a detector or from a position readback (which would record the actual motor positions at each point and could then be compared to the desired position array).

The scan results will most frequently be read as position arrays (P1PA-P4PA), which are mentioned above, and arrays of detector data (D1PV-D4PV) where each detector data element corresponds to the position element.

For single dimension scans, the scan is complete when the Execute Scan flag (the EXCS) field is set back to zero by the record processing routine (during the scan it is set to 1). The application program can then read the position arrays and the data arrays (or have a monitor set on them so the record will post its monitors when complete).

For two dimension scans similar to Figure 2, the application program should read the arrays from the SCAN_X record after the completion of each x scan and correlate it to the current y controller information. This will allow the application program to display data after each x scan. The scan record will buffer the data for only one x scan, so the application must read the arrays before the next x scan is completed. If the scan is too fast, the application program can contribute to the wait record algorithm such that the y -controllers are not moved until the application program has completely read the previous SCAN_X data.

On slow scans, the application program may want to see that the scan is processed on a point by point basis. Therefore, the scan record will post monitors on fields that it updates each point, but it will not post monitors faster than 20 times per second. If a scan is proceeding at a rate less than 20 points per second, every point will be posted. If a scan is proceeding at 100 steps per second, scalar values will be posted every 5th point (approx.). In either case, the array data will contain every point at the completion of the scan. It is not recommended that the application program use the point to point data except for keeping the operator aware of the progress of the scan.


FieldSummaryTypeDCTInitialAccessModifyRec Proc MonitorPP
D1PVData 1 Process Variable STRING [40]YesNullYesYesNoNo
D2PVData 2 Process Variable STRING [40]YesNullYesYesNoNo
D3PVData 3 Process Variable STRING [40]YesNullYesYesNoNo
D4PVData 4 Process Variable STRING [40]YesNullYesYesNoNo
EXSCExecute Scan FlagSHORTNo0YesYesYesNo
D1DADetector 1 Data ArrayFLOAT[ ]NoNullYesNoYesNo
D2DADetector 2 Data ArrayFLOAT[ ]NoNullYesNoYesNo
D3DADetector 3 Data ArrayFLOAT[ ]NoNullYesNoYesNo
D4DADetector 4 Data ArrayFLOAT[ ]NoNullYesNoYesNo


Operator Display Parameters

Prior to beginning an actual scan, the record can be commanded to check the scan parameters to ensure that all positioner requests are within reasonable limits. The record will do a "dry run" by calculating every positioner value (or looking it up in the table) and comparing it with the high range and low range values (P1HR-P4HR and P1LR-P4LR) associated with that positioner's Process Variable. (Drive limits are an attribute of most process variables). If any step would exceed the drive limits, the operator is notified via the SMSG field.

Other than that, the High Range and Low Range value fields are only used as the display limits for an operator interface. The same is true for the rest of these fields, which are configured to affect the information displayed to the operator. Each positioner and the detector for each positioner have the following fields:

  • An Engineering Units Field (P1EU-P4EU, D1EU-D4EU), which has a string that is given to it by the user.
  • A Precision Field (P1PR-P4PR, D1PR-D4PR), which holds an integer that controls the decimal precision that the corresponding field is displayed with. For instance, P1PR controls the decimal precision for positioner 1 array elements.

See Fields Common to All Record Types for more on the record name (NAME) and description (DESC) fields.


FieldSummaryTypeDCTInitialAccessModifyRec Proc MonitorPP
P1EUPositioner 1 Eng. UnitsSTRING [16]Yes16YesYesNoNo
P1HRPos. 1 High RangeFLOATYes0YesYesNoNo
P1LRPos. 1 Low RangeFLOATYes0YesYesNoNo
P1PRPos. 1 PrecisionSHORTYes0YesYesNoNo
P2EUPos. 2 Eng UnitsSTRING [16]Yes16YesYesNoNo
P2HRPos. 2 High RangeFLOATYes0YesYesNoNo
P2LRPos. 2 Low RangeFLOATYes0YesYesNoNo
P2PRPos. 2 PrecisionSHORTYes0YesYesNoNo
P3EUPos. 3 Eng UnitsSTRING [16]Yes16YesYesNoNo
P3HRPos. 3 High RangeFLOATYes0YesYesNoNo
P3LRPos. 3 Low RangeFLOATYes0YesYesNoNo
P3PRPos. 3 PrecisionSHORTYes0YesYesNoNo
P4EUPos. 4 Eng UnitsSTRING [16]Yes16YesYesNoNo
P4HRPos. 4 High RangeFLOATYes0YesYesNoNo
P4LRPos. 4 Low RangeFLOATYes0YesYesNoNo
P4PRPos. 4 PrecisionSHORTYes0YesYesNoNo
D1EUDetector 1 Eng. UnitsSTRING [16]Yes16YesYesNoNo
D1HRDet. 1 High RangeFLOATYes0YesYesNoNo
D1LRDet. 1 Low RangeFLOATYes0YesYesNoNo
D1PRDet. 1 PrecisionSHORTYes0YesYesNoNo
D2EUDet. 2 Eng. UnitsSTRING [16]Yes16YesYesNoNo
D2HRDet. 2 High RangeFLOATYes0YesYesNoNo
D2LRDet. 2 Low RangeFLOATYes0YesYesNoNo
D2PRDet. 2 PrecisionSHORTYes0YesYesNoNo
D3EUDet. 3 Eng. UnitsSTRING [16]Yes16YesYesNoNo
D3HRDet. 3 High RangeFLOATYes0YesYesNoNo
D3LRDet. 3 Low RangeFLOATYes0YesYesNoNo
D3PRDet. 3 PrecisionSHORTYes0YesYesNoNo
D4EUDet. 4 Eng. UnitsSTRING [16]Yes16YesYesNoNo
D4HRDet. 4 High RangeFLOATYes0YesYesNoNo
D4LRDet. 4 Low RangeFLOATYes0YesYesNoNo
D4PRDet. 4 PrecisionSHORTYes0YesYesNoNo
NAMERecord NameSTRING [29]Yes0YesNoNoNo
DESCDescriptionSTRING [29]YesNullYesYesNoNo


Run-time Parameters

These fields are used to process the record, to implement monitors for certain fields, and/or to keep track of data for processing and/or for the operator. None of these fields are configurable by a database configuration tool. Most of them can be accessed at run-time, and many can be modified at run-time.

The Code Version (VERS) field reflects the version of scan record processing routines.

The VAL field is not used.

The State Message (SMSG) field holds a message sent by the record that alerts the operator to an error condition. It can be cleared by writing a 0 to the Command (CMND) field. The CMND field sends two commands: Clear the State Message field (SMSG), which corresponds to 0; and Execute a "dry run", checking the desired position against the range limits for each positioner, this command corresponding to 1.

The Alert (ALRT) field is a flag which indicates if an error condition currently exists. 1 means YES; 0, NO. The cause of the condition will be displayed in the SMSG field.

The Current Point (CPT) field contains the current point of an active scan. The Desired Value fields for each positioner (P1DV-P4DV) contain the desired value of each positioner for the current point (CPT) in the scan. The Readback Current Value (R1CV-R4CV) fields contain the current readback value for each positioner. The Detector Current Value (D1CV-D4CV) contain each detector's current value for the current point in the scan. The event posting for these fields is throttled to 20 Hz, so for fast scans not every value will be posted.

The PCPT, PXSC, P1LV-P4LV, R1LV-R4LV, and D1LV-D4LV fields all contain the previous or "last" value for their corresponding fields. For instance, the R1LV field contains the last value for the R1CV field. These fields are used to implement monitors for the corresponding field. For instance, if CPT does not equal PCPT when the record is processed, then monitors are triggered for CPT.

The Name Valid fields (xxNV) are flag fields which indicate if the corresponding process variable field contains an existing process variable. For instance, the P1NV field indicates if the P1PV field contains valid process variable; the R4NV field indicates whether R4PV contains a valid, existing process variable, and so on. These fields are used to decide if a process variable has been configured by the user. If not, the fields associated with that variable are ignored.

The Database Address fields (xxDB) are of normally of interest only to the record itself, and are not even accessible at run-time. They contain pointers to the dbAddr structures of the corresponding process variables. For instance, P1DB points to the dbAddr structure of P1PV.


FieldSummaryTypeDCTInitialAccessModifyRec Proc MonitorPP
VERSCode VersionFLOATNo1.0YesNoNoNo
VALValue Field DOUBLENo0YesYesNoNo
SMSGState Message STRING [40]NoNullYesYesYesNo
CMNDCommand FieldENUMNo0YesYesYesNo
ALRTAlert Field UCHARNo0YesNoYesNo
RPVTRecord Private NOACCESSNoNullNoNoNoNo
PXSCPrevious Execute ScanUCHARNo0YesNoNoNo
CPTCurrent PointSHORTNo0YesNoYes*No
PCPTPrevious Current Point SHORTNo0YesNoNoNo
TOLPTime of Last Posting ULONGNo0YesNoNoNo
P1NVPos. 1 Name ValidLONGNo0YesYesYesNo
P2NVPos. 2 Name ValidLONGNo0YesYesYesNo
P3NVPos. 3 Name ValidLONGNo0YesYesYesNo
P4NVPos. 4 Name ValidLONGNo0YesYesYesNo
R1NVReadback 1 Name ValidLONGNo0YesYesYesNo
R2NVRbk. 2 Name ValidLONGNo0YesYesYesNo
R3NVRbk. 3 Name ValidLONGNo0YesYesYesNo
R4NVRbk. 4 Name ValidLONGNo0YesYesYesNo
T1NVTrigger 1 Name ValidLONGNo0YesYesYesNo
T2NVTrigger 2 Name ValidLONGNo0YesYesYesNo
D1NVData 1 Name ValidLONGNo0YesYesYesNo
D2NVData 2 Name ValidLONGNo0YesYesYesNo
D3NVData 3 Name ValidLONGNo0YesYesYesNo
D4NVData 4 Name ValidLONGNo0YesYesYesNo
P1DVPos. 1 Desired ValueFLOATNo0YesNoYes*No
P1LVPos. 1 Last ValueFLOATNo0YesNoNoNo
R1CVReadback 1 Current ValueFLOATNo0YesNoYes*No
R1LVReadback 1 Last ValueFLOATNo0YesNoNoNo
P2DVPos. 2 Desired ValueFLOATNo0YesNoYes*No
P2LVPos. 2 Last ValueFLOATNo0YesNoNoNo
R2CVReadback 4 Current ValueFLOATNo0YesNoYes*No
R2LVReadback 2 Last ValueFLOATNo0YesNoNoNo
P3DVPos. 3 Desired ValueFLOATNo0YesNoYes*No
P3LVPos. 3 Last ValueFLOATNo0YesNoNoNo
R3CVReadback 4 Current ValueFLOATNo0YesNoYes*No
R3LVReadback 3 Last ValueFLOATNo0YesNoNoNo
P4DVPos. 4 Desired ValueFLOATNo0YesNoYes*No
P4LVPos. 4 Last ValueFLOATNo0YesNoNoNo
R4CVReadback 4 Current ValueFLOATNo0YesNoYes*No
R4LVReadback 4 Last ValueFLOATNo0YesNoNoNo
D1CVDetector 1 Current ValueFLOATNo0YesNoYes*No
D1LVDetector 1 Last ValueFLOATNo0YesNoNoNo
D2CVDetector 2 Current ValueFLOATNo0YesNoYes*No
D2LVDetector 2 Last ValueFLOATNo0YesNoNoNo
D3CVDetector 3 Current ValueFLOATNo0YesNoYes*No
D3LVDetector 3 Last ValueFLOATNo0YesNoNoNo
D4CVDetector 4 Current ValueFLOATNo0YesNoYes*No
D4LVDetector 4 Last ValueFLOATNo0YesNoNoNo
P1DBPos. 1 dbAddrNOACCESSNoNullNoNoNoNo
P2DBPos. 2 dbAddrNOACCESSNoNullNoNoNoNo
P3DBPos. 3 dbAddrNOACCESSNoNullNoNoNoNo
P4DBPos. 4 dbAddrNOACCESSNoNullNoNoNoNo
R1DBReadback 1 dbAddrNOACCESSNoNullNoNoNoNo
R2DBReadback 2 dbAddrNOACCESSNoNullNoNoNoNo
R3DBReadback 3 dbAddrNOACCESSNoNullNoNoNoNo
R4DBReadback 4 dbAddrNOACCESSNoNullNoNoNoNo
T1DBTrigger 1 dbAddrNOACCESSNoNullNoNoNoNo
T2DBTrigger 2 dbAddrNOACCESSNoNullNoNoNoNo
D1DBDetector 1 dbAddrNOACCESSNoNullNoNoNoNo
D2DBDetector 2 dbAddrNOACCESSNoNullNoNoNoNo
D3DBDetector 3 dbAddrNOACCESSNoNullNoNoNoNo
D4DBDetector 4 dbAddrNOACCESSNoNullNoNoNoNo




EPICS Record Reference Manual - 19 MAY 1998