EPICSWIKI - User contributions [en]

RRM 3-14 Calcout

2013-11-22T17:01:40Z

LewisMuir: /* Output Parameters */ Note OCAL field as PP Yes and OVAL as PP No

[[RRM 3-14|EPICS Record Reference Manual]]

= Calcout - Calculation Output Record =

The Calculation Output or "Calcout" record is similar to the Calc record with the added feature of having outputs (an "output link" and an "output event") which are conditionally executed based on the result of the calculation. This feature allows conditional branching to be implemented within an EPICS database (e.g., process Record_A only if Record_B has a value of 0). The Calcout record is also similar to the Wait record (with additional features) but uses EPICS standard INLINK and OUTLINK fields rather than the DBF_STRING fields used in the Wait record. For new databases, it is recommended that the Calcout record be used instead of the Wait record.

== Parameter Fields ==

The fields in this record fall into these categories:

* scan parameters
* read parameters
* expression parameters
* output parameters
* operator display parameters
* alarm parameters
* monitor parameters
* run-time parameters

=== Scan Parameters ===

The Calcout record has the standard fields for specifying under what circumstances the record will be processed. These fields are listed in [[RRM 3-14 dbCommon#Scan Fields|Scan Fields]]. In addition, [[RRM 3-14 Concepts#Scanning Specification|Scanning Specification]] explains how these fields are used. Since the Calcout record supports no direct interfaces to hardware, it cannot be scanned on I/O interrupt, so its SCAN field cannot be <CODE>I/O Intr</CODE>.

=== Read Parameters ===

The read parameters for the Calcout record consist of 12 input links INPA, INPB, ... INPL. The fields can be database links, channel access links, or constants. If they are links, they must specify another record's field. If they are constants, they will be initialized with the value they are configured with and can be changed via <CODE>dbPuts</CODE>. These fields cannot be hardware addresses. In addition, the Calcout record contains the INAV, INBV, . . . INLV fields which indicate the status of the link fields, for example, whether or not the specified PV was found and a link to it established. See [[#Operator Display Parameters|Operator Display Parameters]] for an explanation of these fields.

See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on how to specify database links.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TR>
<TD>INPA<TD>Input Link A<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPB<TD>Input Link B<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPC<TD>Input Link C<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPD<TD>Input Link D<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPE<TD>Input Link E<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPF<TD>Input Link F<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPG<TD>Input Link G<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPH<TD>Input Link H<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPI<TD>Input Link I<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPJ<TD>Input Link J<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPK<TD>Input Link K<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPL<TD>Input Link L<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A
</TABLE>

=== Expression ===

Like the Calc record, the Calcout record has a CALC field in which the developer can enter an infix expression which the record routine will evaluate when it processes the record. The resulting value is placed in the VAL field. This value can then be used by the OOPT field (see [[#Output Parameters|Output Parameters]]) to determine whether or not to write to the output link or post an output event. It can also be the value that is written to the output link. The CALC expression is actually converted to opcode and stored in Reverse Polish Notation in the RPCL field. It is this expression which is actually used to calculate VAL. The Reverse Polish expression is evaluated more efficiently during run-time than an infix expression. CALC can be changed at run-time, and a special record routine will call a function to convert it to Reverse Polish Notation.

The infix expressions that can be used are very similar to the C expression syntax, but with some additions and subtle differences in operator meaning and precedence. The string may contain a series of expressions separated by a semi-colon character ';' any one of which may actually provide the calculation result; however all of the other expressions included must assign their result to a variable. All alphabetic elements described below are case independent, so upper and lower case letters may be used and mixed in the variable and function names as desired. Spaces may be used anywhere within an expression except between the characters that make up a single expression element.

The range of expressions supported by the calculation record are separated into literals, constants, operands, algebraic operators, trigonometric operators, relational operators, logical operators, the assignment operator, parentheses and commas, and the question mark or '?:' operator.

-----
'''NOTE:''' A complete up-to-date description of the calculation expression can be found in the '''Application Developer's Guide''', chapter libCom / calc / Infix Expression Syntax (19.2.1 for EPICS 3.14.11).
-----

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>CALC<TD>Calculation<TD>STRING[36]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>VAL<TD>Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>RPCL<TD>Reverse Polish<TD>NOACCESS<TD>No<TD>0<TD>No<TD>No<TD>N/A<TD>No
</TABLE>

==== Literals ====

* Standard double precision floating point numbers
* Inf: Infinity
* Nan: Not a Number

==== Constants ====

* PI: returns the mathematical constant <tt>π</tt>
* D2R: evaluates to <tt>π</tt>/180 which, when used as a multiplier, converts an angle from degrees to radians
* R2D: evaluates to 180/<tt>π</tt> which as a multiplier converts an angle from radians to degrees

==== Operands ====

The expression can use the values retrieved from the INP''x'' links as operands, though constants can be used as operands too. These values retrieved from the input links are stored in the A-L fields. The values to be used in the expression are simply referenced by the field letter. For instance, the value obtained from the INPA link is stored in the field A, and the value obtained from INPB is stored in field B. The field names can be included in the expression which will operate on their respective values, as in A+B.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>A<TD>Input Value A<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>B<TD>Input Value B<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>C<TD>Input Value C<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>D<TD>Input Value D<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>E<TD>Input Value E<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>F<TD>Input Value F<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>G<TD>Input Value G<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>H<TD>Input Value H<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>I<TD>Input Value I<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>J<TD>Input Value J<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>K<TD>Input Value K<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>L<TD>Input Value L<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes
</TABLE>

The keyword <tt>VAL</tt> returns the current contents of the expression's result field, i.e. the VAL field for the CALC expression and the OVAL field for the OCAL expression. (These fields can be written to by a CA put, so it might ''not'' be the result from last time the expression was evaluated).

Also, the RNDM unary function can be included as an operand in the expression in order to generate a random number between 0 and 1.

==== Algebraic Operators ====

* ABS: Absolute value (unary)
* SQR: Square root (unary)
* MIN: Minimum (any number of args)
* MAX: Maximum (any number of args)
* FINITE: returns non-zero if none of the arguments are NaN or Inf (any number of args)
* ISNAN: returns non-zero if any of the arguments is NaN or Inf (any number of args)
* CEIL: Ceiling (unary)
* FLOOR: Floor (unary)
* LOG: Log base 10 (unary)
* LOGE: Natural log (unary)
* EXP: Exponential function (unary)
* ^: Exponential (binary)
* ** : Exponential (binary)
* + : Addition (binary)
* - : Subtraction (binary)
* * : Multiplication (binary)
* / : Division (binary)
* % : Modulo (binary)
* NOT: Negate (unary)

==== Trigonometric Operators ====

* SIN: Sine
* SINH: Hyperbolic sine
* ASIN: Arc sine
* COS: Cosine
* COSH: Hyperbolic cosine
* ACOS: Arc cosine
* TAN: Tangent
* TANH: Hyperbolic tangent
* ATAN: Arc tangent

==== Relational Operators ====

* >= : Greater than or equal to
* > : Greater than
* <= : Less than or equal to
* <: Less than
* # : Not equal to
* = : Equal to

==== Logical Operators ====

* && : And
* || : Or
* ! : Not

==== Bitwise Operators ====

* | : Bitwise Or
* & : Bitwise And
* OR : Bitwise Or
* AND: Bitwise And
* XOR: Bitwise Exclusive Or
* ~ : One's Complement
* << : Left shift
* >> : Right shift

==== Assignment Operator ====

* := : assigns a value (right hand side) to a variable (i.e. field)

==== Parentheses and Comma ====

The open and close parentheses are supported. Nested parenthesis are supported.

The comma is supported when used to separate the arguments of a binary function.

==== Conditional Expression ====

The C language's question mark operator is supported. The format is:

condition ? True result : False result

=== Example Expressions ===

==== Algebraic ====

A + B + 10

* Result is A + B + 10

==== Relational ====

(A + B) < (C + D)

* Result is 1 if (A+B) < (C+D)
* Result is 0 if (A+B) >= (C+D)

==== Question Mark ====

(A+B)<(C+D)?E:F+L+10

* Result is E if (A+B) < (C+D)
* Result is F+L+10 if (A+B) >= (C+D)

==== Logical ====

A&B

* Causes the following to occur:
** Convert A to integer
** Convert B to integer
** Bit-wise And A and B
** Convert result to floating point

=== Output Parameters ===

These parameters specify and control the output capabilities of the Calcout record. They determine when to write the output, where to write it, and what the output will be. The OUT link specifies the Process Variable to which the result will be written. The OOPT field determines the condition that causes the output link to be written to. It's a menu field that has six choices:

* <CODE>Every Time</CODE> -- write output every time record is processed.
* <CODE>On Change</CODE> -- write output every time VAL changes, i.e., every time the result of the expression changes.
* <CODE>When Zero</CODE> -- when record is processed, write output if VAL is zero.
* <CODE>When Non-zero</CODE> -- when record is processed, write output if VAL is non-zero.
* <CODE>Transition To Zero</CODE> -- when record is processed, write output only if VAL is zero and last value was non-zero.
* <CODE>Transition To Non-zero</CODE> -- when record is processed, write output only if VAL is non-zero and last value was zero.

The DOPT field determines what data is written to the output link when the output is executed. The field is a menu field with two options: <CODE>Use CALC</CODE> or <CODE>Use OCAL</CODE>. If <CODE>Use CALC</CODE> is specified, when the record writes its output it will write the result of the expression in the CALC record, that is, it will write the value of the VAL field. If <CODE>Use OCAL</CODE> is specified, the record will instead write the result of the expression in the OCAL field, which is contained in the OVAL field. The OCAL field is exactly like the CALC field and has the same functionality: it can contain the string representation of an expression which is evaluated at run-time. Thus, if necessary, the record can use the result of the CALC expression to determine if data should be written and can use the result of the OCAL expression as the data to write.

If the OEVT field specifies a non-zero integer and the condition in the OOPT field is met, the record will post a corresponding event. If the ODLY field is non-zero, the record pauses for the specified number of seconds before executing the OUT link or posting the output event. During this waiting period the record is "active" and will not be processed again until the wait is over. The field DLYA is equal to 1 during the delay period. The resolution of the delay entry is system dependent.

The IVOA field specifies what action to take with the OUT link if the Calcout record enters an INVALID alarm status. The options are <CODE>Continue normally</CODE>, <CODE>Don't drive outputs</CODE>, and <CODE>Set output to IVOV</CODE>. If the IVOA field is <CODE>Set output to IVOV</CODE>, the data entered into the IVOV field is written to the OUT link if the record alarm severity is INVALID.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>OUT<TD>Output Specification<TD>OUTLINK<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>N/A<TD>No<TR>
<TD>OOPT<TD>Output Execute Option<TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DOPT<TD>Output Data Option<TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>OCAL<TD> Output Calculation<TD>STRING[36]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>OVAL<TD>Output Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>OEVT<TD>Event To Issue<TD>SHORT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>ODLY<TD>Output Execution Delay<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>IVOA<TD>Invalid Output Action<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>IVOV<TD>Invalid Output Value<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Operator Display Parameters ===

These parameters are used to present meaningful data to the operator. Some are also meant to represent the status of the record at run-time. An example of an interactive MEDM display screen that displays the status of the Calcout record is located here.

The EGU field contains a string of up to 16 characters which is supplied by the user and which describes the values being operated upon. The string is retrieved whenever the routine <CODE>get_units</CODE> is called. The EGU string is solely for an operator's sake and does not have to be used.

The HOPR and LOPR fields only refer to the limits of the VAL, HIHI, HIGH, LOW, and LOLO fields. PREC controls the precision of the VAL field.

The INAV-INLV fields indicate the status of the link to the PVs specified in the INPA-INPL fields, respectively. The field can have three possible values:

* <CODE>Ext PV NC</CODE> -- the PV wasn't found on this IOC and a Channel Access link hasn't been established.
* <CODE>Ext PV OK</CODE> -- the PV wasn't found on this IOC and a Channel Access link has been established.
* <CODE>Local PV</CODE> -- the PV was found on this IOC.
* <CODE>Constant</CODE> -- the corresponding link field is a constant.

The OUTV field indicates the status of the OUT link. It has the same possible values as the INAV-INLV fields.

The CLCV and OLCV fields indicate the validity of the expression in the CALC and OCAL fields, respectively. If the expression is invalid, the field is set to one.

The DLYA field is set to one during the delay interval specified in ODLY.

See [[RRM 3-14 dbCommon#Fields Common to All Record Types|Fields Common to All Record Types]] for more on the record name (NAME) and description (DESC) fields.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>EGU<TD>Engineering Units<TD>STRING [16]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>PREC<TD>Display Precision<TD>SHORT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>HOPR<TD>High Operating Range<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>LOPR<TD>Low Operating Range<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>INAV<TD>Link Status of INPA<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INBV<TD>Link Status of INPB<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INCV<TD>Link Status of INPC<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INDV<TD>Link Status of INPD<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INEV<TD>Link Status of INPE<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INFV<TD>Link Status of INPF<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INGV<TD>Link Status of INPG<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INHV<TD>Link Status of INPH<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INIV<TD>Link Status of INPI<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INJV<TD>Link Status of INPJ<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INKV<TD>Link Status of INPK<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INLV<TD>Link Status of INPL<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>OUTV<TD>OUT PV Status<TD>RECCHOICE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>CLCV<TD>CALC Valid<TD>LONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>OCLV<TD>OCAL Valid<TD>LONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DLYA<TD>Output Delay Active<TD>USHORT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>NAME<TD>Record Name<TD>STRING [29]<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>DESC<TD>Description<TD>STRING [29]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Alarm Parameters ===

The possible alarm conditions for the Calc record are the SCAN, READ, Calculation, and limit alarms. The SCAN and READ alarms are called by the record support routines. The Calculation alarm is called by the record processing routine when the CALC expression is an invalid one, upon which an error message is generated.

The following alarm parameters which are configured by the user define the limit alarms for the VAL field and the severity corresponding to those conditions.

The HYST field defines an alarm deadband for each limit. See [[RRM 3-14 Concepts#Alarm Specification|Alarm Specification]] for a complete explanation of alarms and these fields. [[RRM 3-14 dbCommon#Alarm Fields|Alarm Fields]] lists other fields related to a alarms that are common to all record types.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>HIHI<TD>Hihi Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HIGH<TD>High Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LOW<TD>Low Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LOLO<TD>Lolo Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HHSV<TD>Severity for a Hihi Alarm<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HSV<TD>Severity for a High Alarm<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LSV<TD>Severity for a Low Alarm<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LLSV<TD>Severity for a Lolo Alarm<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HYST<TD>Alarm Deadband<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Monitor Parameters ===

These parameters are used to determine when to send monitors for the value fields. The monitors are sent when the value field exceeds the last monitored field by the appropriate deadband, the ADEL for archiver monitors and the MDEL field for all other types of monitors. If these fields have a value of zero, every time the value changes, monitors are triggered; if they have a value of -1, every time the record is scanned, monitors are triggered. See [[RRM 3-14 Concepts#Monitor Specification|Monitor Specification]] for a complete explanation of monitors.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>ADEL<TD>Archive Deadband<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>MDEL<TD>Monitor, i.e. value change, Deadband<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Run-time Parameters ===

These fields are not configurable using a configuration too and none are modifiable at run-time. They are used to process the record.

The LALM field is used to implement the hysteresis factor for the alarm limits.

The LA-LL fields are used to decide when to trigger monitors for the corresponding fields. For instance, if LA does not equal the value for A, monitors for A are triggered. The MLST and MLST fields are used in the same manner for the VAL field.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>LALM<TD>Last Alarmed Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>ALST<TD>Archive Last Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>MLST<TD>Monitor Last Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LA<TD>Previous Input Value for A<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LB<TD>Previous Input Value for B<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LC<TD>Previous Input Value for C<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LD<TD>Previous Input Value for D<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LE<TD>Previous Input Value for E<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LF<TD>Previous Input Value for F<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LG<TD>Previous Input Value for G<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LH<TD>Previous Input Value for H<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LI<TD>Previous Input Value for I<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LJ<TD>Previous Input Value for J<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LK<TD>Previous Input Value for K<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LL<TD>Previous Input Value for L<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No
</TABLE>

== Record Support ==

=== Record Support Routines ===

==== init_record ====

For each constant input link, the corresponding value field is initialized with the constant value if the input link is CONSTANT or a channel access link is created if the input link is PV_LINK.

A routine postfix is called to convert the infix expression in CALC and OCAL to reverse polish notation. The result is stored in RPCL and ORPC, respectively.

==== process ====

See next section.

==== special ====

This is called if CALC or OCAL is changed. special calls postfix.

==== get_value ====

Fills in the values of struct valueDes so that they refer to VAL.

==== get_units ====

Retrieves EGU.

==== get_precision ====

Retrieves PREC.

==== get_graphic_double ====

Sets the upper display and lower display limits for a field. If the field is VAL, HIHI, HIGH, LOW, or LOLO, the limits are set to HOPR and LOPR, else if the field has upper and lower limits defined they will be used, else the upper and lower maximum values for the field type will be used.

==== get_control_double ====

Sets the upper control and the lower control limits for a field. If the field is VAL, HIHI, HIGH, LOW, or LOLO, the limits are set to HOPR and LOPR, else if the field has upper and lower limits defined they will be used, else the upper and lower maximum values for the field type will be used.

==== get_alarm_double ====

Sets the following values:

upper_alarm_limit = HIHI
upper_warning_limit = HIGH
lower_warning_limit = LOW
lower_alarm_limit = LOLO

=== Record Processing ===

==== process() ====

The <CODE>process()</CODE> routine implements the following algorithm:

# Fetch all arguments.
# Call routine calcPerform(), which calculates VAL from the postfix version of the expression given in CALC. If calcPerform() returns success, UDF is set to FALSE.
# Check alarms. This routine checks to see if the new VAL causes the alarm status and severity to change. If so, NSEV, NSTA and LALM are set. It also honors the alarm hysteresis factor (HYST). Thus the value must change by at least HYST before the alarm status and severity changes.
# Determine if the Output Execution Option (OOPT) is met. If it is met, either execute the output link (and output event) immediately (if ODLY = 0), or schedule a callback after the specified interval. See the explanation for the <CODE>execOutput()</CODE> routine below.
# Check to see if monitors should be invoked.
#* Alarm monitors are invoked if the alarm status or severity has changed.
#* Archive and value change monitors are invoked if ADEL and MDEL conditions are met.
#* Monitors for A-L are checked whenever other monitors are invoked.
#* NSEV and NSTA are reset to 0.
# If no output delay was specified, scan forward link if necessary, set PACT FALSE, and return.

==== execOutput() ====

# If DOPT field specifies the use of OCAL, call the routine calcPerform for the postfix version of the expression in OCAL. Otherwise, use VAL.
# If the Alarm Severity is INVALID, follow the option as designated by the field IVOA.
# If the Alarm Severity is not INVALID or IVOA specifies "Continue Normally", put the value of OVAL to the OUT link and post the event in OEVT (if non-zero).
# If an output delay was implemented, process the forward link.

----

EPICS Record Reference Manual - 19 MAY 1998

RRM 3-14 Calcout

2013-11-22T16:58:58Z

LewisMuir: /* Expression */ Note CALC field as PP Yes

[[RRM 3-14|EPICS Record Reference Manual]]

= Calcout - Calculation Output Record =

The Calculation Output or "Calcout" record is similar to the Calc record with the added feature of having outputs (an "output link" and an "output event") which are conditionally executed based on the result of the calculation. This feature allows conditional branching to be implemented within an EPICS database (e.g., process Record_A only if Record_B has a value of 0). The Calcout record is also similar to the Wait record (with additional features) but uses EPICS standard INLINK and OUTLINK fields rather than the DBF_STRING fields used in the Wait record. For new databases, it is recommended that the Calcout record be used instead of the Wait record.

== Parameter Fields ==

The fields in this record fall into these categories:

* scan parameters
* read parameters
* expression parameters
* output parameters
* operator display parameters
* alarm parameters
* monitor parameters
* run-time parameters

=== Scan Parameters ===

The Calcout record has the standard fields for specifying under what circumstances the record will be processed. These fields are listed in [[RRM 3-14 dbCommon#Scan Fields|Scan Fields]]. In addition, [[RRM 3-14 Concepts#Scanning Specification|Scanning Specification]] explains how these fields are used. Since the Calcout record supports no direct interfaces to hardware, it cannot be scanned on I/O interrupt, so its SCAN field cannot be <CODE>I/O Intr</CODE>.

=== Read Parameters ===

The read parameters for the Calcout record consist of 12 input links INPA, INPB, ... INPL. The fields can be database links, channel access links, or constants. If they are links, they must specify another record's field. If they are constants, they will be initialized with the value they are configured with and can be changed via <CODE>dbPuts</CODE>. These fields cannot be hardware addresses. In addition, the Calcout record contains the INAV, INBV, . . . INLV fields which indicate the status of the link fields, for example, whether or not the specified PV was found and a link to it established. See [[#Operator Display Parameters|Operator Display Parameters]] for an explanation of these fields.

See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on how to specify database links.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TR>
<TD>INPA<TD>Input Link A<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPB<TD>Input Link B<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPC<TD>Input Link C<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPD<TD>Input Link D<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPE<TD>Input Link E<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPF<TD>Input Link F<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPG<TD>Input Link G<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPH<TD>Input Link H<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPI<TD>Input Link I<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPJ<TD>Input Link J<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPK<TD>Input Link K<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPL<TD>Input Link L<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A
</TABLE>

=== Expression ===

Like the Calc record, the Calcout record has a CALC field in which the developer can enter an infix expression which the record routine will evaluate when it processes the record. The resulting value is placed in the VAL field. This value can then be used by the OOPT field (see [[#Output Parameters|Output Parameters]]) to determine whether or not to write to the output link or post an output event. It can also be the value that is written to the output link. The CALC expression is actually converted to opcode and stored in Reverse Polish Notation in the RPCL field. It is this expression which is actually used to calculate VAL. The Reverse Polish expression is evaluated more efficiently during run-time than an infix expression. CALC can be changed at run-time, and a special record routine will call a function to convert it to Reverse Polish Notation.

The infix expressions that can be used are very similar to the C expression syntax, but with some additions and subtle differences in operator meaning and precedence. The string may contain a series of expressions separated by a semi-colon character ';' any one of which may actually provide the calculation result; however all of the other expressions included must assign their result to a variable. All alphabetic elements described below are case independent, so upper and lower case letters may be used and mixed in the variable and function names as desired. Spaces may be used anywhere within an expression except between the characters that make up a single expression element.

The range of expressions supported by the calculation record are separated into literals, constants, operands, algebraic operators, trigonometric operators, relational operators, logical operators, the assignment operator, parentheses and commas, and the question mark or '?:' operator.

-----
'''NOTE:''' A complete up-to-date description of the calculation expression can be found in the '''Application Developer's Guide''', chapter libCom / calc / Infix Expression Syntax (19.2.1 for EPICS 3.14.11).
-----

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>CALC<TD>Calculation<TD>STRING[36]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>VAL<TD>Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>RPCL<TD>Reverse Polish<TD>NOACCESS<TD>No<TD>0<TD>No<TD>No<TD>N/A<TD>No
</TABLE>

==== Literals ====

* Standard double precision floating point numbers
* Inf: Infinity
* Nan: Not a Number

==== Constants ====

* PI: returns the mathematical constant <tt>π</tt>
* D2R: evaluates to <tt>π</tt>/180 which, when used as a multiplier, converts an angle from degrees to radians
* R2D: evaluates to 180/<tt>π</tt> which as a multiplier converts an angle from radians to degrees

==== Operands ====

The expression can use the values retrieved from the INP''x'' links as operands, though constants can be used as operands too. These values retrieved from the input links are stored in the A-L fields. The values to be used in the expression are simply referenced by the field letter. For instance, the value obtained from the INPA link is stored in the field A, and the value obtained from INPB is stored in field B. The field names can be included in the expression which will operate on their respective values, as in A+B.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>A<TD>Input Value A<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>B<TD>Input Value B<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>C<TD>Input Value C<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>D<TD>Input Value D<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>E<TD>Input Value E<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>F<TD>Input Value F<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>G<TD>Input Value G<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>H<TD>Input Value H<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>I<TD>Input Value I<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>J<TD>Input Value J<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>K<TD>Input Value K<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>L<TD>Input Value L<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes
</TABLE>

The keyword <tt>VAL</tt> returns the current contents of the expression's result field, i.e. the VAL field for the CALC expression and the OVAL field for the OCAL expression. (These fields can be written to by a CA put, so it might ''not'' be the result from last time the expression was evaluated).

Also, the RNDM unary function can be included as an operand in the expression in order to generate a random number between 0 and 1.

==== Algebraic Operators ====

* ABS: Absolute value (unary)
* SQR: Square root (unary)
* MIN: Minimum (any number of args)
* MAX: Maximum (any number of args)
* FINITE: returns non-zero if none of the arguments are NaN or Inf (any number of args)
* ISNAN: returns non-zero if any of the arguments is NaN or Inf (any number of args)
* CEIL: Ceiling (unary)
* FLOOR: Floor (unary)
* LOG: Log base 10 (unary)
* LOGE: Natural log (unary)
* EXP: Exponential function (unary)
* ^: Exponential (binary)
* ** : Exponential (binary)
* + : Addition (binary)
* - : Subtraction (binary)
* * : Multiplication (binary)
* / : Division (binary)
* % : Modulo (binary)
* NOT: Negate (unary)

==== Trigonometric Operators ====

* SIN: Sine
* SINH: Hyperbolic sine
* ASIN: Arc sine
* COS: Cosine
* COSH: Hyperbolic cosine
* ACOS: Arc cosine
* TAN: Tangent
* TANH: Hyperbolic tangent
* ATAN: Arc tangent

==== Relational Operators ====

* >= : Greater than or equal to
* > : Greater than
* <= : Less than or equal to
* <: Less than
* # : Not equal to
* = : Equal to

==== Logical Operators ====

* && : And
* || : Or
* ! : Not

==== Bitwise Operators ====

* | : Bitwise Or
* & : Bitwise And
* OR : Bitwise Or
* AND: Bitwise And
* XOR: Bitwise Exclusive Or
* ~ : One's Complement
* << : Left shift
* >> : Right shift

==== Assignment Operator ====

* := : assigns a value (right hand side) to a variable (i.e. field)

==== Parentheses and Comma ====

The open and close parentheses are supported. Nested parenthesis are supported.

The comma is supported when used to separate the arguments of a binary function.

==== Conditional Expression ====

The C language's question mark operator is supported. The format is:

condition ? True result : False result

=== Example Expressions ===

==== Algebraic ====

A + B + 10

* Result is A + B + 10

==== Relational ====

(A + B) < (C + D)

* Result is 1 if (A+B) < (C+D)
* Result is 0 if (A+B) >= (C+D)

==== Question Mark ====

(A+B)<(C+D)?E:F+L+10

* Result is E if (A+B) < (C+D)
* Result is F+L+10 if (A+B) >= (C+D)

==== Logical ====

A&B

* Causes the following to occur:
** Convert A to integer
** Convert B to integer
** Bit-wise And A and B
** Convert result to floating point

=== Output Parameters ===

These parameters specify and control the output capabilities of the Calcout record. They determine when to write the output, where to write it, and what the output will be. The OUT link specifies the Process Variable to which the result will be written. The OOPT field determines the condition that causes the output link to be written to. It's a menu field that has six choices:

* <CODE>Every Time</CODE> -- write output every time record is processed.
* <CODE>On Change</CODE> -- write output every time VAL changes, i.e., every time the result of the expression changes.
* <CODE>When Zero</CODE> -- when record is processed, write output if VAL is zero.
* <CODE>When Non-zero</CODE> -- when record is processed, write output if VAL is non-zero.
* <CODE>Transition To Zero</CODE> -- when record is processed, write output only if VAL is zero and last value was non-zero.
* <CODE>Transition To Non-zero</CODE> -- when record is processed, write output only if VAL is non-zero and last value was zero.

The DOPT field determines what data is written to the output link when the output is executed. The field is a menu field with two options: <CODE>Use CALC</CODE> or <CODE>Use OCAL</CODE>. If <CODE>Use CALC</CODE> is specified, when the record writes its output it will write the result of the expression in the CALC record, that is, it will write the value of the VAL field. If <CODE>Use OCAL</CODE> is specified, the record will instead write the result of the expression in the OCAL field, which is contained in the OVAL field. The OCAL field is exactly like the CALC field and has the same functionality: it can contain the string representation of an expression which is evaluated at run-time. Thus, if necessary, the record can use the result of the CALC expression to determine if data should be written and can use the result of the OCAL expression as the data to write.

If the OEVT field specifies a non-zero integer and the condition in the OOPT field is met, the record will post a corresponding event. If the ODLY field is non-zero, the record pauses for the specified number of seconds before executing the OUT link or posting the output event. During this waiting period the record is "active" and will not be processed again until the wait is over. The field DLYA is equal to 1 during the delay period. The resolution of the delay entry is system dependent.

The IVOA field specifies what action to take with the OUT link if the Calcout record enters an INVALID alarm status. The options are <CODE>Continue normally</CODE>, <CODE>Don't drive outputs</CODE>, and <CODE>Set output to IVOV</CODE>. If the IVOA field is <CODE>Set output to IVOV</CODE>, the data entered into the IVOV field is written to the OUT link if the record alarm severity is INVALID.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>OUT<TD>Output Specification<TD>OUTLINK<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>N/A<TD>No<TR>
<TD>OOPT<TD>Output Execute Option<TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DOPT<TD>Output Data Option<TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>OCAL<TD> Output Calculation<TD>STRING[36]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>OVAL<TD>Output Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>OEVT<TD>Event To Issue<TD>SHORT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>ODLY<TD>Output Execution Delay<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>IVOA<TD>Invalid Output Action<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>IVOV<TD>Invalid Output Value<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Operator Display Parameters ===

These parameters are used to present meaningful data to the operator. Some are also meant to represent the status of the record at run-time. An example of an interactive MEDM display screen that displays the status of the Calcout record is located here.

The EGU field contains a string of up to 16 characters which is supplied by the user and which describes the values being operated upon. The string is retrieved whenever the routine <CODE>get_units</CODE> is called. The EGU string is solely for an operator's sake and does not have to be used.

The HOPR and LOPR fields only refer to the limits of the VAL, HIHI, HIGH, LOW, and LOLO fields. PREC controls the precision of the VAL field.

The INAV-INLV fields indicate the status of the link to the PVs specified in the INPA-INPL fields, respectively. The field can have three possible values:

* <CODE>Ext PV NC</CODE> -- the PV wasn't found on this IOC and a Channel Access link hasn't been established.
* <CODE>Ext PV OK</CODE> -- the PV wasn't found on this IOC and a Channel Access link has been established.
* <CODE>Local PV</CODE> -- the PV was found on this IOC.
* <CODE>Constant</CODE> -- the corresponding link field is a constant.

The OUTV field indicates the status of the OUT link. It has the same possible values as the INAV-INLV fields.

The CLCV and OLCV fields indicate the validity of the expression in the CALC and OCAL fields, respectively. If the expression is invalid, the field is set to one.

The DLYA field is set to one during the delay interval specified in ODLY.

See [[RRM 3-14 dbCommon#Fields Common to All Record Types|Fields Common to All Record Types]] for more on the record name (NAME) and description (DESC) fields.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>EGU<TD>Engineering Units<TD>STRING [16]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>PREC<TD>Display Precision<TD>SHORT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>HOPR<TD>High Operating Range<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>LOPR<TD>Low Operating Range<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>INAV<TD>Link Status of INPA<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INBV<TD>Link Status of INPB<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INCV<TD>Link Status of INPC<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INDV<TD>Link Status of INPD<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INEV<TD>Link Status of INPE<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INFV<TD>Link Status of INPF<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INGV<TD>Link Status of INPG<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INHV<TD>Link Status of INPH<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INIV<TD>Link Status of INPI<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INJV<TD>Link Status of INPJ<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INKV<TD>Link Status of INPK<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INLV<TD>Link Status of INPL<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>OUTV<TD>OUT PV Status<TD>RECCHOICE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>CLCV<TD>CALC Valid<TD>LONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>OCLV<TD>OCAL Valid<TD>LONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DLYA<TD>Output Delay Active<TD>USHORT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>NAME<TD>Record Name<TD>STRING [29]<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>DESC<TD>Description<TD>STRING [29]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Alarm Parameters ===

The possible alarm conditions for the Calc record are the SCAN, READ, Calculation, and limit alarms. The SCAN and READ alarms are called by the record support routines. The Calculation alarm is called by the record processing routine when the CALC expression is an invalid one, upon which an error message is generated.

The following alarm parameters which are configured by the user define the limit alarms for the VAL field and the severity corresponding to those conditions.

The HYST field defines an alarm deadband for each limit. See [[RRM 3-14 Concepts#Alarm Specification|Alarm Specification]] for a complete explanation of alarms and these fields. [[RRM 3-14 dbCommon#Alarm Fields|Alarm Fields]] lists other fields related to a alarms that are common to all record types.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>HIHI<TD>Hihi Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HIGH<TD>High Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LOW<TD>Low Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LOLO<TD>Lolo Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HHSV<TD>Severity for a Hihi Alarm<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HSV<TD>Severity for a High Alarm<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LSV<TD>Severity for a Low Alarm<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LLSV<TD>Severity for a Lolo Alarm<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HYST<TD>Alarm Deadband<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Monitor Parameters ===

These parameters are used to determine when to send monitors for the value fields. The monitors are sent when the value field exceeds the last monitored field by the appropriate deadband, the ADEL for archiver monitors and the MDEL field for all other types of monitors. If these fields have a value of zero, every time the value changes, monitors are triggered; if they have a value of -1, every time the record is scanned, monitors are triggered. See [[RRM 3-14 Concepts#Monitor Specification|Monitor Specification]] for a complete explanation of monitors.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>ADEL<TD>Archive Deadband<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>MDEL<TD>Monitor, i.e. value change, Deadband<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Run-time Parameters ===

These fields are not configurable using a configuration too and none are modifiable at run-time. They are used to process the record.

The LALM field is used to implement the hysteresis factor for the alarm limits.

The LA-LL fields are used to decide when to trigger monitors for the corresponding fields. For instance, if LA does not equal the value for A, monitors for A are triggered. The MLST and MLST fields are used in the same manner for the VAL field.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>LALM<TD>Last Alarmed Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>ALST<TD>Archive Last Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>MLST<TD>Monitor Last Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LA<TD>Previous Input Value for A<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LB<TD>Previous Input Value for B<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LC<TD>Previous Input Value for C<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LD<TD>Previous Input Value for D<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LE<TD>Previous Input Value for E<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LF<TD>Previous Input Value for F<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LG<TD>Previous Input Value for G<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LH<TD>Previous Input Value for H<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LI<TD>Previous Input Value for I<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LJ<TD>Previous Input Value for J<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LK<TD>Previous Input Value for K<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LL<TD>Previous Input Value for L<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No
</TABLE>

== Record Support ==

=== Record Support Routines ===

==== init_record ====

For each constant input link, the corresponding value field is initialized with the constant value if the input link is CONSTANT or a channel access link is created if the input link is PV_LINK.

A routine postfix is called to convert the infix expression in CALC and OCAL to reverse polish notation. The result is stored in RPCL and ORPC, respectively.

==== process ====

See next section.

==== special ====

This is called if CALC or OCAL is changed. special calls postfix.

==== get_value ====

Fills in the values of struct valueDes so that they refer to VAL.

==== get_units ====

Retrieves EGU.

==== get_precision ====

Retrieves PREC.

==== get_graphic_double ====

Sets the upper display and lower display limits for a field. If the field is VAL, HIHI, HIGH, LOW, or LOLO, the limits are set to HOPR and LOPR, else if the field has upper and lower limits defined they will be used, else the upper and lower maximum values for the field type will be used.

==== get_control_double ====

Sets the upper control and the lower control limits for a field. If the field is VAL, HIHI, HIGH, LOW, or LOLO, the limits are set to HOPR and LOPR, else if the field has upper and lower limits defined they will be used, else the upper and lower maximum values for the field type will be used.

==== get_alarm_double ====

Sets the following values:

upper_alarm_limit = HIHI
upper_warning_limit = HIGH
lower_warning_limit = LOW
lower_alarm_limit = LOLO

=== Record Processing ===

==== process() ====

The <CODE>process()</CODE> routine implements the following algorithm:

# Fetch all arguments.
# Call routine calcPerform(), which calculates VAL from the postfix version of the expression given in CALC. If calcPerform() returns success, UDF is set to FALSE.
# Check alarms. This routine checks to see if the new VAL causes the alarm status and severity to change. If so, NSEV, NSTA and LALM are set. It also honors the alarm hysteresis factor (HYST). Thus the value must change by at least HYST before the alarm status and severity changes.
# Determine if the Output Execution Option (OOPT) is met. If it is met, either execute the output link (and output event) immediately (if ODLY = 0), or schedule a callback after the specified interval. See the explanation for the <CODE>execOutput()</CODE> routine below.
# Check to see if monitors should be invoked.
#* Alarm monitors are invoked if the alarm status or severity has changed.
#* Archive and value change monitors are invoked if ADEL and MDEL conditions are met.
#* Monitors for A-L are checked whenever other monitors are invoked.
#* NSEV and NSTA are reset to 0.
# If no output delay was specified, scan forward link if necessary, set PACT FALSE, and return.

==== execOutput() ====

# If DOPT field specifies the use of OCAL, call the routine calcPerform for the postfix version of the expression in OCAL. Otherwise, use VAL.
# If the Alarm Severity is INVALID, follow the option as designated by the field IVOA.
# If the Alarm Severity is not INVALID or IVOA specifies "Continue Normally", put the value of OVAL to the OUT link and post the event in OEVT (if non-zero).
# If an output delay was implemented, process the forward link.

----

EPICS Record Reference Manual - 19 MAY 1998

RRM 3-14 Long Output

2012-10-30T20:27:04Z

LewisMuir: /* Desired Output Parameters */ Improve wording about DOL constant

[[RRM 3-14|EPICS Record Reference Manual]]

= longout - Long Output =

The normal use for the long output or "longout" record type is to store long integer values of up to 32 bits and write them to hardware devices. The <CODE>Soft Channel</CODE> device support routine can also be used to write values to other records via database or channel access links. The OUT field determines how the record is used. The record supports alarm limits and graphics and control limits.

== Parameter Fields ==

The fields in this record fall into the following categories:

* scan parameters
* desired output parameters
* write parameters
* operator display parameters
* alarm parameters
* monitor parameters
* simulation mode parameters

=== Scan Parameters ===

The longout record has the standard fields for specifying under what circumstances it will be processed. These fields are listed in [[RRM 3-14 dbCommon#Scan Fields|Scan Fields]]. In addition, [[RRM 3-14 Concepts#Scanning Specification|Scanning Specification]] explains how these fields are used. Note that I/O event scanning is only supported for those card types that interrupt.

=== Desired Output Parameters ===

The record must specify where the desired output originates, i.e., the 32 bit integer value it is to write. The output mode select (OMSL) field determines whether the output originates from another record or from database access. When set to <CODE>closed_loop</CODE>, the desired output is retrieved from the link specified in the desired output (DOL) field--which can specify either a database or channel access link--and placed into the VAL field. When set to <CODE>supervisory</CODE>, the desired output can be written into the VAL field via dpPuts at run-time.

A third type of value for the DOL field is a constant in which case, when the record is initialized, the VAL field will be initialized with this constant value.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TR>
<TD>DOL<TD>Desired Output Location (input link)<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>OMSL<TD>Output Mode Select<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TR>
<TD>VAL<TD>Value Field<TD>LONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes
</TABLE>

=== Write Parameters ===

The OUT link field determines where the record is to send its output. For records that write values to hardware devices, the OUT output link field must specify the address of the I/O card, and the DTYP field must specify the name of the corresponding device support module. You can see a list of the device support modules currently supported at the user's local site by using the <CODE>dbst</CODE> utility in R3.13.

For soft records, the OUT output link can be a constant, a database link, or a channel access link. If the link is a constant, the result is no output. The DTYP field must then specify the <CODE>Soft Channel</CODE> device support routine.

See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on the format of hardware addresses and database links.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TR>
<TD>OUT<TD>Output Link<TD>OUTLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>DTYP<TD>Device Type<TD>DEVCHOICE<TD>Yes<TD>0<TD>Yes<TD>No<TD>No
</TABLE>

=== Operator Display Parameters ===

These parameters are used to present meaningful data to the operator. They display the value and other parameters of the long output either textually or graphically.

EGU is a string of up to 16 characters describing the units that the long output measures. It is retrieved by the <CODE>get_units</CODE> record support routine.

The HOPR and LOPR fields set the upper and lower display limits for the VAL, HIHI, HIGH, LOW, and LOLO fields. Both the <CODE>get_graphic_double</CODE> and <CODE>get_control_double</CODE> record support routines retrieve these fields.

See [[RRM 3-14 dbCommon#Fields Common to All Record Types|Fields Common to All Record Types]] for more on the record name (NAME) and description (DESC) fields.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>EGU<TD>Engineering Units<TD>STRING [16]<TD>Yes<TD>null<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>HOPR<TD>High Operating Range<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>LOPR<TD>Low Operating Range<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>NAME<TD>Record Name<TD>STRING [29]<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD> <TR>
<TD>DESC<TD>Description<TD>STRING [29]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Alarm Parameters ===

The possible alarm conditions for long inputs are the SCAN, READ, INVALID, and limit alarms. The SCAN and READ alarms are not configurable by the user because their severity is always MAJOR. The INVALID alarm is called by the record support routine when the record or device support routines cannot write the record's output. The IVOA field specifies the action to take in this case.

The limit alarms are configured by the user in the HIHI, LOLO, HIGH, and LOW fields using floating-point values. For each of these fields, there is a corresponding severity field which can be either NO_ALARM, MINOR, or MAJOR. The HYST field contains the alarm deadband around each limit alarm.

See the See [[RRM 3-14 Concepts#Alarm Specification|Alarm Specification]] for a complete explanation of alarms and these fields. For an explanation of the IVOA and IVOV fields, see [[RRM 3-14 Common#Output Records|Output Records]]. [[RRM 3-14 dbCommon#Alarm Fields|Alarm Fields]] lists other fields related to a alarms that are common to all record types.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>HIHI<TD>Hihi Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HIGH<TD>High Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LOW<TD>Low Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LOLO<TD>Lolo Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HHSV<TD>Hihi Alarm Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HSV<TD>High Alarm Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LSV<TD>Low Alarm Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LLSV<TD>Lolo Alarm Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HYST<TD>Alarm Deadband<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>IVOA<TD>Invalid Alarm Output Action<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>IVOV<TD>Invalid Alarm Output Value, in eng. units<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Monitor Parameters ===

These parameters are used to determine when to send monitors placed on the value field. The monitors are sent when the value field exceeds the last monitored field by the appropriate delta. If these fields have a value of zero, everytime the value changes, a monitor will be triggered; if they have a value of -1, everytime the record is scanned, monitors are triggered. The ADEL field is the delta for archive monitors, and the MDEL field is the delta for all other types of monitors. See [[RRM 3-14 Concepts#Monitor Specification|Monitor Specification]] for a complete explanation of monitors.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>ADEL<TD>Archive Deadband<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>MDEL<TD>Monitor, i.e. value change, Deadband<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Run-time and Simulation Mode Parameters ===

The LALM, MLST, and ALST fields are used to implement the hysteresis factors for monitor callbacks. Only if the difference between these fields and the corresponding value field is greater than the appropriate delta (MDEL, ADEL, HYST)--only then are monitors triggered. For instance, only if the difference between VAL and MLST is greater than MDEL are the monitors triggered for VAL.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>LALM<TD>Last Alarm Monitor Trigger Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>ALST<TD>Last Archiver Monitor Trigger Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>MLST<TD>Last Value Change Monitor Trigger Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No
</TABLE>

The following fields are used to operate the long output in the simulation mode. See [[RRM 3-14 Common#Fields Common to Many Record Types|Fields Common to Many Record Types]] for more information on the simulation mode fields

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>SIOL<TD>Simulation Value Location<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>SIML<TD>Simulation Mode Location<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>SIMM<TD>Simulation Mode<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>SIMS<TD>Simulation Mode Alarm Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

== Record Support ==

=== Record Support Routines ===

==== init_record ====

This routine initializes SIMM if SIML is a constant or creates a channel access link if SIML is PV_LINK. If SIOL is PV_LINK a channel access link is created.

This routine next checks to see that device support is available. The routine next checks to see if the device support write routine is defined.

If either device support or the device support write routine does not exist, an error message is issued and processing is terminated.

If DOL is a constant, then VAL is initialized to its value and UDF is set to FALSE. If DOL type is a PV_LINK then dbCaAddInlink is called to create a channel access link.

If device support includes init_record, it is called.

==== process ====

See next section.

==== get_value ====

Fills in the values of struct valueDes so that they refer to VAL.

==== get_units ====

Retrieves EGU.

==== get_graphic_double ====

Sets the upper display and lower display limits for a field. If the field is VAL, HIHI, HIGH, LOW, or LOLO, the limits are set to HOPR and LOPR, else if the field has upper and lower limits defined they will be used, else the upper and lower maximum values for the field type will be used.

==== get_control_double ====

Sets the upper control and the lower control limits for a field. If the field is VAL, HIHI, HIGH, LOW, or LOLO, the limits are set to HOPR and LOPR, else if the field has upper and lower limits defined they will be used, else the upper and lower maximum values for the field type will be used.

==== get_alarm_double ====

Sets the following values:

upper_alarm_limit = HIHI
upper_warning_limit = HIGH
lower_warning_limit = LOW
lower_alarm_limit = LOLO

=== Record Processing ===

Routine process implements the following algorithm:

# Check to see that the appropriate device support module exists. If it doesn't, an error message is issued and processing is terminated with the PACT field still set to TRUE. This ensures that processes will no longer be called for this record. Thus error storms will not occur.
# If PACT is FALSE and OMSL is CLOSED_LOOP recGblGetLinkValue is called to read the current value of VAL. See [[RRM 3-14 Common#Output Records|Output Records]] for more information. If the return status of recGblGetLinkValue is zero then UDF is set to FALSE.
# Check alarms. This routine checks to see if the new VAL causes the alarm status and severity to change. If so, NSEV, NSTA and LALM are set. It also honors the alarm hysteresis factor (HYST). Thus the value must change by more than HYST before the alarm status and severity is lowered.
# Check severity and write the new value. See [[RRM 3-14 Common#Invalid Alarm Output Action|Invalid Alarm Output Action]] for information on how INVALID alarms affect output records.
# If PACT has been changed to TRUE, the device support write output routine has started but has not completed writing the new value. In this case, the processing routine merely returns, leaving PACT TRUE.
# Check to see if monitors should be invoked:
#* Alarm monitors are invoked if the alarm status or severity has changed.
#* Archive and value change monitors are invoked if ADEL and MDEL conditions are met.
#* NSEV and NSTA are reset to 0.
# Scan forward link if necessary, set PACT FALSE, and return.

== Device Support ==

=== Fields Of Interest To Device Support ===

Each long output record must have an associated set of device support routines. The primary responsibility of the device support routines is to output a new value whenever write_longout is called. The device support routines are primarily interested in the following fields:

<TABLE BORDER="1">
<TH>Name<TH>Summary<TH>Description<TR>
<TD>PACT<TD>Processing Active<TD rowspan=4>See [[RRM 3-14 dbCommon#Fields Common to All Record Types|Fields Common to All Record Types]] for an explanation of these fields.<TR>
<TD>DPVT<TD>Device Private<TR>
<TD>NSEV<TD>New Alarm Severity<TR>
<TD>NSTA<TD>New Alarm Status<TR>
<TD>OUT<TD>Output Link<TD>This field is used by the device support routines to locate its output.
</TABLE>

=== Device Support Routines ===

Device support consists of the following routines:

==== init ====

init()

This routine is called once during IOC initialization.

==== init_record ====

init_record(precord)

This routine is optional. If provided, it is called by the record support init_record routine.

==== get_ioint_info ====

get_ioint_info(int cmd,struct dbCommon *precord,IOSCANPVT *ppvt)

This routine is called by the ioEventScan system each time the record is added or deleted from an I/O event scan list. cmd has the value (0,1) if the record is being (added to, deleted from) an I/O event list. It must be provided for any device type that can use the ioEvent scanner.

==== write_longout ====

write_longout(precord)

This routine must output a new value. It returns the following values:

* 0: Success.
* Other: Error.

=== Device Support For Soft Records ===

The <CODE>Soft Channel</CODE> module writes the current value of VAL.

If the OUT link type is PV_LINK, then dbCaAddInlink is called by init_record.

write_longout calls recGblPutLinkValue to write the current value of VAL.

See [[RRM 3-14 Common#Soft Output|Soft Output]] for a further explanation.

----

EPICS Record Reference Manual - 19 MAY 1998

RRM 3-14 Long Output

2012-10-30T20:18:36Z

LewisMuir: /* Desired Output Parameters */ Remove claim that OMSL cannot be closed_loop with a constant in DOL

[[RRM 3-14|EPICS Record Reference Manual]]

= longout - Long Output =

The normal use for the long output or "longout" record type is to store long integer values of up to 32 bits and write them to hardware devices. The <CODE>Soft Channel</CODE> device support routine can also be used to write values to other records via database or channel access links. The OUT field determines how the record is used. The record supports alarm limits and graphics and control limits.

== Parameter Fields ==

The fields in this record fall into the following categories:

* scan parameters
* desired output parameters
* write parameters
* operator display parameters
* alarm parameters
* monitor parameters
* simulation mode parameters

=== Scan Parameters ===

The longout record has the standard fields for specifying under what circumstances it will be processed. These fields are listed in [[RRM 3-14 dbCommon#Scan Fields|Scan Fields]]. In addition, [[RRM 3-14 Concepts#Scanning Specification|Scanning Specification]] explains how these fields are used. Note that I/O event scanning is only supported for those card types that interrupt.

=== Desired Output Parameters ===

The record must specify where the desired output originates, i.e., the 32 bit integer value it is to write. The output mode select (OMSL) field determines whether the output originates from another record or from database access. When set to <CODE>closed_loop</CODE>, the desired output is retrieved from the link specified in the desired output (DOL) field--which can specify either a database or channel access link--and placed into the VAL field. When set to <CODE>supervisory</CODE>, the desired output can be written into the VAL field via dpPuts at run-time.

The DOL field can also be configured as a constant so that when the record is initialized, the VAL field will be initialized with this constant value.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TR>
<TD>DOL<TD>Desired Output Location (input link)<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>OMSL<TD>Output Mode Select<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TR>
<TD>VAL<TD>Value Field<TD>LONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes
</TABLE>

=== Write Parameters ===

The OUT link field determines where the record is to send its output. For records that write values to hardware devices, the OUT output link field must specify the address of the I/O card, and the DTYP field must specify the name of the corresponding device support module. You can see a list of the device support modules currently supported at the user's local site by using the <CODE>dbst</CODE> utility in R3.13.

For soft records, the OUT output link can be a constant, a database link, or a channel access link. If the link is a constant, the result is no output. The DTYP field must then specify the <CODE>Soft Channel</CODE> device support routine.

See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on the format of hardware addresses and database links.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TR>
<TD>OUT<TD>Output Link<TD>OUTLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>DTYP<TD>Device Type<TD>DEVCHOICE<TD>Yes<TD>0<TD>Yes<TD>No<TD>No
</TABLE>

=== Operator Display Parameters ===

These parameters are used to present meaningful data to the operator. They display the value and other parameters of the long output either textually or graphically.

EGU is a string of up to 16 characters describing the units that the long output measures. It is retrieved by the <CODE>get_units</CODE> record support routine.

The HOPR and LOPR fields set the upper and lower display limits for the VAL, HIHI, HIGH, LOW, and LOLO fields. Both the <CODE>get_graphic_double</CODE> and <CODE>get_control_double</CODE> record support routines retrieve these fields.

See [[RRM 3-14 dbCommon#Fields Common to All Record Types|Fields Common to All Record Types]] for more on the record name (NAME) and description (DESC) fields.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>EGU<TD>Engineering Units<TD>STRING [16]<TD>Yes<TD>null<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>HOPR<TD>High Operating Range<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>LOPR<TD>Low Operating Range<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>NAME<TD>Record Name<TD>STRING [29]<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD> <TR>
<TD>DESC<TD>Description<TD>STRING [29]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Alarm Parameters ===

The possible alarm conditions for long inputs are the SCAN, READ, INVALID, and limit alarms. The SCAN and READ alarms are not configurable by the user because their severity is always MAJOR. The INVALID alarm is called by the record support routine when the record or device support routines cannot write the record's output. The IVOA field specifies the action to take in this case.

The limit alarms are configured by the user in the HIHI, LOLO, HIGH, and LOW fields using floating-point values. For each of these fields, there is a corresponding severity field which can be either NO_ALARM, MINOR, or MAJOR. The HYST field contains the alarm deadband around each limit alarm.

See the See [[RRM 3-14 Concepts#Alarm Specification|Alarm Specification]] for a complete explanation of alarms and these fields. For an explanation of the IVOA and IVOV fields, see [[RRM 3-14 Common#Output Records|Output Records]]. [[RRM 3-14 dbCommon#Alarm Fields|Alarm Fields]] lists other fields related to a alarms that are common to all record types.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>HIHI<TD>Hihi Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HIGH<TD>High Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LOW<TD>Low Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LOLO<TD>Lolo Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HHSV<TD>Hihi Alarm Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HSV<TD>High Alarm Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LSV<TD>Low Alarm Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LLSV<TD>Lolo Alarm Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HYST<TD>Alarm Deadband<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>IVOA<TD>Invalid Alarm Output Action<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>IVOV<TD>Invalid Alarm Output Value, in eng. units<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Monitor Parameters ===

These parameters are used to determine when to send monitors placed on the value field. The monitors are sent when the value field exceeds the last monitored field by the appropriate delta. If these fields have a value of zero, everytime the value changes, a monitor will be triggered; if they have a value of -1, everytime the record is scanned, monitors are triggered. The ADEL field is the delta for archive monitors, and the MDEL field is the delta for all other types of monitors. See [[RRM 3-14 Concepts#Monitor Specification|Monitor Specification]] for a complete explanation of monitors.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>ADEL<TD>Archive Deadband<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>MDEL<TD>Monitor, i.e. value change, Deadband<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Run-time and Simulation Mode Parameters ===

The LALM, MLST, and ALST fields are used to implement the hysteresis factors for monitor callbacks. Only if the difference between these fields and the corresponding value field is greater than the appropriate delta (MDEL, ADEL, HYST)--only then are monitors triggered. For instance, only if the difference between VAL and MLST is greater than MDEL are the monitors triggered for VAL.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>LALM<TD>Last Alarm Monitor Trigger Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>ALST<TD>Last Archiver Monitor Trigger Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>MLST<TD>Last Value Change Monitor Trigger Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No
</TABLE>

The following fields are used to operate the long output in the simulation mode. See [[RRM 3-14 Common#Fields Common to Many Record Types|Fields Common to Many Record Types]] for more information on the simulation mode fields

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>SIOL<TD>Simulation Value Location<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>SIML<TD>Simulation Mode Location<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>SIMM<TD>Simulation Mode<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>SIMS<TD>Simulation Mode Alarm Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

== Record Support ==

=== Record Support Routines ===

==== init_record ====

This routine initializes SIMM if SIML is a constant or creates a channel access link if SIML is PV_LINK. If SIOL is PV_LINK a channel access link is created.

This routine next checks to see that device support is available. The routine next checks to see if the device support write routine is defined.

If either device support or the device support write routine does not exist, an error message is issued and processing is terminated.

If DOL is a constant, then VAL is initialized to its value and UDF is set to FALSE. If DOL type is a PV_LINK then dbCaAddInlink is called to create a channel access link.

If device support includes init_record, it is called.

==== process ====

See next section.

==== get_value ====

Fills in the values of struct valueDes so that they refer to VAL.

==== get_units ====

Retrieves EGU.

==== get_graphic_double ====

Sets the upper display and lower display limits for a field. If the field is VAL, HIHI, HIGH, LOW, or LOLO, the limits are set to HOPR and LOPR, else if the field has upper and lower limits defined they will be used, else the upper and lower maximum values for the field type will be used.

==== get_control_double ====

Sets the upper control and the lower control limits for a field. If the field is VAL, HIHI, HIGH, LOW, or LOLO, the limits are set to HOPR and LOPR, else if the field has upper and lower limits defined they will be used, else the upper and lower maximum values for the field type will be used.

==== get_alarm_double ====

Sets the following values:

upper_alarm_limit = HIHI
upper_warning_limit = HIGH
lower_warning_limit = LOW
lower_alarm_limit = LOLO

=== Record Processing ===

Routine process implements the following algorithm:

# Check to see that the appropriate device support module exists. If it doesn't, an error message is issued and processing is terminated with the PACT field still set to TRUE. This ensures that processes will no longer be called for this record. Thus error storms will not occur.
# If PACT is FALSE and OMSL is CLOSED_LOOP recGblGetLinkValue is called to read the current value of VAL. See [[RRM 3-14 Common#Output Records|Output Records]] for more information. If the return status of recGblGetLinkValue is zero then UDF is set to FALSE.
# Check alarms. This routine checks to see if the new VAL causes the alarm status and severity to change. If so, NSEV, NSTA and LALM are set. It also honors the alarm hysteresis factor (HYST). Thus the value must change by more than HYST before the alarm status and severity is lowered.
# Check severity and write the new value. See [[RRM 3-14 Common#Invalid Alarm Output Action|Invalid Alarm Output Action]] for information on how INVALID alarms affect output records.
# If PACT has been changed to TRUE, the device support write output routine has started but has not completed writing the new value. In this case, the processing routine merely returns, leaving PACT TRUE.
# Check to see if monitors should be invoked:
#* Alarm monitors are invoked if the alarm status or severity has changed.
#* Archive and value change monitors are invoked if ADEL and MDEL conditions are met.
#* NSEV and NSTA are reset to 0.
# Scan forward link if necessary, set PACT FALSE, and return.

== Device Support ==

=== Fields Of Interest To Device Support ===

Each long output record must have an associated set of device support routines. The primary responsibility of the device support routines is to output a new value whenever write_longout is called. The device support routines are primarily interested in the following fields:

<TABLE BORDER="1">
<TH>Name<TH>Summary<TH>Description<TR>
<TD>PACT<TD>Processing Active<TD rowspan=4>See [[RRM 3-14 dbCommon#Fields Common to All Record Types|Fields Common to All Record Types]] for an explanation of these fields.<TR>
<TD>DPVT<TD>Device Private<TR>
<TD>NSEV<TD>New Alarm Severity<TR>
<TD>NSTA<TD>New Alarm Status<TR>
<TD>OUT<TD>Output Link<TD>This field is used by the device support routines to locate its output.
</TABLE>

=== Device Support Routines ===

Device support consists of the following routines:

==== init ====

init()

This routine is called once during IOC initialization.

==== init_record ====

init_record(precord)

This routine is optional. If provided, it is called by the record support init_record routine.

==== get_ioint_info ====

get_ioint_info(int cmd,struct dbCommon *precord,IOSCANPVT *ppvt)

This routine is called by the ioEventScan system each time the record is added or deleted from an I/O event scan list. cmd has the value (0,1) if the record is being (added to, deleted from) an I/O event list. It must be provided for any device type that can use the ioEvent scanner.

==== write_longout ====

write_longout(precord)

This routine must output a new value. It returns the following values:

* 0: Success.
* Other: Error.

=== Device Support For Soft Records ===

The <CODE>Soft Channel</CODE> module writes the current value of VAL.

If the OUT link type is PV_LINK, then dbCaAddInlink is called by init_record.

write_longout calls recGblPutLinkValue to write the current value of VAL.

See [[RRM 3-14 Common#Soft Output|Soft Output]] for a further explanation.

----

EPICS Record Reference Manual - 19 MAY 1998

RRM 3-14 Long Output

2012-10-30T20:15:06Z

LewisMuir: /* Desired Output Parameters */ Remove fanout reference

[[RRM 3-14|EPICS Record Reference Manual]]

= longout - Long Output =

The normal use for the long output or "longout" record type is to store long integer values of up to 32 bits and write them to hardware devices. The <CODE>Soft Channel</CODE> device support routine can also be used to write values to other records via database or channel access links. The OUT field determines how the record is used. The record supports alarm limits and graphics and control limits.

== Parameter Fields ==

The fields in this record fall into the following categories:

* scan parameters
* desired output parameters
* write parameters
* operator display parameters
* alarm parameters
* monitor parameters
* simulation mode parameters

=== Scan Parameters ===

The longout record has the standard fields for specifying under what circumstances it will be processed. These fields are listed in [[RRM 3-14 dbCommon#Scan Fields|Scan Fields]]. In addition, [[RRM 3-14 Concepts#Scanning Specification|Scanning Specification]] explains how these fields are used. Note that I/O event scanning is only supported for those card types that interrupt.

=== Desired Output Parameters ===

The record must specify where the desired output originates, i.e., the 32 bit integer value it is to write. The output mode select (OMSL) field determines whether the output originates from another record or from database access. When set to <CODE>closed_loop</CODE>, the desired output is retrieved from the link specified in the desired output (DOL) field--which can specify either a database or channel access link--and placed into the VAL field. When set to <CODE>supervisory</CODE>, the desired output can be written into the VAL field via dpPuts at run-time.

The DOL field can be configured as constant, so that when the record is initialized, the VAL field will be initialized with this VALUE. If DOL is a constant, then the OMSL loop cannot be <CODE>closed_loop</CODE>.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TR>
<TD>DOL<TD>Desired Output Location (input link)<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>OMSL<TD>Output Mode Select<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TR>
<TD>VAL<TD>Value Field<TD>LONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes
</TABLE>

=== Write Parameters ===

The OUT link field determines where the record is to send its output. For records that write values to hardware devices, the OUT output link field must specify the address of the I/O card, and the DTYP field must specify the name of the corresponding device support module. You can see a list of the device support modules currently supported at the user's local site by using the <CODE>dbst</CODE> utility in R3.13.

For soft records, the OUT output link can be a constant, a database link, or a channel access link. If the link is a constant, the result is no output. The DTYP field must then specify the <CODE>Soft Channel</CODE> device support routine.

See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on the format of hardware addresses and database links.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TR>
<TD>OUT<TD>Output Link<TD>OUTLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>DTYP<TD>Device Type<TD>DEVCHOICE<TD>Yes<TD>0<TD>Yes<TD>No<TD>No
</TABLE>

=== Operator Display Parameters ===

These parameters are used to present meaningful data to the operator. They display the value and other parameters of the long output either textually or graphically.

EGU is a string of up to 16 characters describing the units that the long output measures. It is retrieved by the <CODE>get_units</CODE> record support routine.

The HOPR and LOPR fields set the upper and lower display limits for the VAL, HIHI, HIGH, LOW, and LOLO fields. Both the <CODE>get_graphic_double</CODE> and <CODE>get_control_double</CODE> record support routines retrieve these fields.

See [[RRM 3-14 dbCommon#Fields Common to All Record Types|Fields Common to All Record Types]] for more on the record name (NAME) and description (DESC) fields.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>EGU<TD>Engineering Units<TD>STRING [16]<TD>Yes<TD>null<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>HOPR<TD>High Operating Range<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>LOPR<TD>Low Operating Range<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>NAME<TD>Record Name<TD>STRING [29]<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD> <TR>
<TD>DESC<TD>Description<TD>STRING [29]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Alarm Parameters ===

The possible alarm conditions for long inputs are the SCAN, READ, INVALID, and limit alarms. The SCAN and READ alarms are not configurable by the user because their severity is always MAJOR. The INVALID alarm is called by the record support routine when the record or device support routines cannot write the record's output. The IVOA field specifies the action to take in this case.

The limit alarms are configured by the user in the HIHI, LOLO, HIGH, and LOW fields using floating-point values. For each of these fields, there is a corresponding severity field which can be either NO_ALARM, MINOR, or MAJOR. The HYST field contains the alarm deadband around each limit alarm.

See the See [[RRM 3-14 Concepts#Alarm Specification|Alarm Specification]] for a complete explanation of alarms and these fields. For an explanation of the IVOA and IVOV fields, see [[RRM 3-14 Common#Output Records|Output Records]]. [[RRM 3-14 dbCommon#Alarm Fields|Alarm Fields]] lists other fields related to a alarms that are common to all record types.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>HIHI<TD>Hihi Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HIGH<TD>High Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LOW<TD>Low Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LOLO<TD>Lolo Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HHSV<TD>Hihi Alarm Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HSV<TD>High Alarm Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LSV<TD>Low Alarm Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LLSV<TD>Lolo Alarm Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HYST<TD>Alarm Deadband<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>IVOA<TD>Invalid Alarm Output Action<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>IVOV<TD>Invalid Alarm Output Value, in eng. units<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Monitor Parameters ===

These parameters are used to determine when to send monitors placed on the value field. The monitors are sent when the value field exceeds the last monitored field by the appropriate delta. If these fields have a value of zero, everytime the value changes, a monitor will be triggered; if they have a value of -1, everytime the record is scanned, monitors are triggered. The ADEL field is the delta for archive monitors, and the MDEL field is the delta for all other types of monitors. See [[RRM 3-14 Concepts#Monitor Specification|Monitor Specification]] for a complete explanation of monitors.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>ADEL<TD>Archive Deadband<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>MDEL<TD>Monitor, i.e. value change, Deadband<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Run-time and Simulation Mode Parameters ===

The LALM, MLST, and ALST fields are used to implement the hysteresis factors for monitor callbacks. Only if the difference between these fields and the corresponding value field is greater than the appropriate delta (MDEL, ADEL, HYST)--only then are monitors triggered. For instance, only if the difference between VAL and MLST is greater than MDEL are the monitors triggered for VAL.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>LALM<TD>Last Alarm Monitor Trigger Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>ALST<TD>Last Archiver Monitor Trigger Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>MLST<TD>Last Value Change Monitor Trigger Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No
</TABLE>

The following fields are used to operate the long output in the simulation mode. See [[RRM 3-14 Common#Fields Common to Many Record Types|Fields Common to Many Record Types]] for more information on the simulation mode fields

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>SIOL<TD>Simulation Value Location<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>SIML<TD>Simulation Mode Location<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>SIMM<TD>Simulation Mode<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>SIMS<TD>Simulation Mode Alarm Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

== Record Support ==

=== Record Support Routines ===

==== init_record ====

This routine initializes SIMM if SIML is a constant or creates a channel access link if SIML is PV_LINK. If SIOL is PV_LINK a channel access link is created.

This routine next checks to see that device support is available. The routine next checks to see if the device support write routine is defined.

If either device support or the device support write routine does not exist, an error message is issued and processing is terminated.

If DOL is a constant, then VAL is initialized to its value and UDF is set to FALSE. If DOL type is a PV_LINK then dbCaAddInlink is called to create a channel access link.

If device support includes init_record, it is called.

==== process ====

See next section.

==== get_value ====

Fills in the values of struct valueDes so that they refer to VAL.

==== get_units ====

Retrieves EGU.

==== get_graphic_double ====

Sets the upper display and lower display limits for a field. If the field is VAL, HIHI, HIGH, LOW, or LOLO, the limits are set to HOPR and LOPR, else if the field has upper and lower limits defined they will be used, else the upper and lower maximum values for the field type will be used.

==== get_control_double ====

Sets the upper control and the lower control limits for a field. If the field is VAL, HIHI, HIGH, LOW, or LOLO, the limits are set to HOPR and LOPR, else if the field has upper and lower limits defined they will be used, else the upper and lower maximum values for the field type will be used.

==== get_alarm_double ====

Sets the following values:

upper_alarm_limit = HIHI
upper_warning_limit = HIGH
lower_warning_limit = LOW
lower_alarm_limit = LOLO

=== Record Processing ===

Routine process implements the following algorithm:

# Check to see that the appropriate device support module exists. If it doesn't, an error message is issued and processing is terminated with the PACT field still set to TRUE. This ensures that processes will no longer be called for this record. Thus error storms will not occur.
# If PACT is FALSE and OMSL is CLOSED_LOOP recGblGetLinkValue is called to read the current value of VAL. See [[RRM 3-14 Common#Output Records|Output Records]] for more information. If the return status of recGblGetLinkValue is zero then UDF is set to FALSE.
# Check alarms. This routine checks to see if the new VAL causes the alarm status and severity to change. If so, NSEV, NSTA and LALM are set. It also honors the alarm hysteresis factor (HYST). Thus the value must change by more than HYST before the alarm status and severity is lowered.
# Check severity and write the new value. See [[RRM 3-14 Common#Invalid Alarm Output Action|Invalid Alarm Output Action]] for information on how INVALID alarms affect output records.
# If PACT has been changed to TRUE, the device support write output routine has started but has not completed writing the new value. In this case, the processing routine merely returns, leaving PACT TRUE.
# Check to see if monitors should be invoked:
#* Alarm monitors are invoked if the alarm status or severity has changed.
#* Archive and value change monitors are invoked if ADEL and MDEL conditions are met.
#* NSEV and NSTA are reset to 0.
# Scan forward link if necessary, set PACT FALSE, and return.

== Device Support ==

=== Fields Of Interest To Device Support ===

Each long output record must have an associated set of device support routines. The primary responsibility of the device support routines is to output a new value whenever write_longout is called. The device support routines are primarily interested in the following fields:

<TABLE BORDER="1">
<TH>Name<TH>Summary<TH>Description<TR>
<TD>PACT<TD>Processing Active<TD rowspan=4>See [[RRM 3-14 dbCommon#Fields Common to All Record Types|Fields Common to All Record Types]] for an explanation of these fields.<TR>
<TD>DPVT<TD>Device Private<TR>
<TD>NSEV<TD>New Alarm Severity<TR>
<TD>NSTA<TD>New Alarm Status<TR>
<TD>OUT<TD>Output Link<TD>This field is used by the device support routines to locate its output.
</TABLE>

=== Device Support Routines ===

Device support consists of the following routines:

==== init ====

init()

This routine is called once during IOC initialization.

==== init_record ====

init_record(precord)

This routine is optional. If provided, it is called by the record support init_record routine.

==== get_ioint_info ====

get_ioint_info(int cmd,struct dbCommon *precord,IOSCANPVT *ppvt)

This routine is called by the ioEventScan system each time the record is added or deleted from an I/O event scan list. cmd has the value (0,1) if the record is being (added to, deleted from) an I/O event list. It must be provided for any device type that can use the ioEvent scanner.

==== write_longout ====

write_longout(precord)

This routine must output a new value. It returns the following values:

* 0: Success.
* Other: Error.

=== Device Support For Soft Records ===

The <CODE>Soft Channel</CODE> module writes the current value of VAL.

If the OUT link type is PV_LINK, then dbCaAddInlink is called by init_record.

write_longout calls recGblPutLinkValue to write the current value of VAL.

See [[RRM 3-14 Common#Soft Output|Soft Output]] for a further explanation.

----

EPICS Record Reference Manual - 19 MAY 1998

RRM 3-14 Binary Output

2012-10-30T20:00:17Z

LewisMuir: /* Alarm Parameters */ Improve description of IVOA field

[[RRM 3-14|EPICS Record Reference Manual]]

= bo - Binary Output =

The normal use for this record type is to store a simple bit (0 or 1) value to be sent to a Digital Output module. It can also be used to write binary values into other records via database or channel access links. This record can implement both latched and momentary binary outputs depending on how the HIGH field is configured.

== Parameter Fields ==

The binary output's fields fall into the following categories:

* scan parameters
* convert and write parameters
* operator display parameters
* alarm parameters
* run-time parameters

=== Scan Parameters ===

The binary output record has the standard fields for specifying under what circumstances the record will be processed. These fields are listed in [[RRM 3-14 dbCommon#Scan Fields|Scan Fields]]. In addition, [[RRM 3-14 Concepts#Scanning Specification|Scanning Specification]] explains how these fields are used. Note that I/O event scanning is only supported for those card types that interrupt.

=== Desired Output Parameters ===

The binary output record must specify where its desired output originates. The desired output needs to be in engineering units.

The first field that determines where the desired output originates is the output mode select (OMSL) field, which can have two possible values: <CODE>closed_loop</CODE> or <CODE>supervisory</CODE>. If <CODE>supervisory</CODE> is specified, the value in the VAL field can be set externally via dbPuts at run-time. If <CODE>closed_loop</CODE> is specified, the VAL field's value is obtained from the address specified in the desired output location (DOL) field which can be a database link, a channel access link, or a constant. To achieve continuous control, a database link to a control algorithm record should be entered in the DOL field.

[[RRM 3-14 Concepts#Address Specification|Address Specification]] presents more information on database addresses and links. [[RRM 3-14 Concepts#Scanning Specification|Scanning Specification]] explains the effect of database linkage on scanning.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>DOL<TD>Desired Output Location (Input Link)<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>OMSL<TD>Output Mode Select<TD>[[RRM 3-14 Menu Choices#menuOmsl|menuOmsl]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Convert and Write Parameters ===

These parameters are used to determine where the binary output writes to and how to convert the engineering units to a raw signal. After VAL is set and forced to be either 1 or 0, as the result of either a dbPut or a new value being retrieved from the link in the DOL field, then what happens next depends on which device support routine is used and how the HIGH field is configured.

If the <CODE>Soft Channel</CODE> device support routine is specified, then the device support routine writes the VAL field's value to the address specified in the OUT field. Otherwise, RVAL is the value finally written by the device support routines after being converted.

If VAL is equal to 0, then the record processing routine sets RVAL equal to zero. When VAL is not equal to 0, then RVAL is set equal to the value contained in the MASK field. (MASK is set by the device support routines and is of no concern to the user.) Also when VAL is not 0 and after RVAL is set equal to MASK, the record processing routine checks to see if the HIGH field is greater than 0. If it is, then the routine will process the record again with VAL set to 0 after the number of seconds specified by HIGH. Thus, HIGH implements a momentary output which changes the state of the device back to 0 after ''N'' number of seconds.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>DTYP<TD>Device Type<TD>DEVCHOICE<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD> <TR>
<TD>OUT<TD>Output Link<TD>OUTLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>VAL<TD>Value Field<TD>ENUM<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>RVAL<TD>Raw Data Value<TD>ULONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>HIGH<TD>Seconds to Hold High<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>ZNAM<TD>Zero Name<TD>STRING [20]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>ONAM<TD>One Name<TD>STRING [20]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes
</TABLE>

==== Conversion Parameters ====

The ZNAM field has the string that corresponds to the 0 state, and the ONAM field holds the string that corresponds to the 1 state. These fields, other than being used to tell the operator what each state represents, are used to perform conversions if the value fetched by DOL is a string. If it is, VAL is set to the state correspond to that string. For instance, if the value fetched is the string "Off" and the ZNAM string is "Off," then VAL is set to 0.

After VAL is set, if VAL is equal to 0, then the record processing routine sets RVAL equal to zero. When VAL is not equal to 0, then RVAL is set equal to the value contained in the MASK field. (MASK is set by the device support routines and is of no concern to the user.) Also when VAL is equal to 1 and after RVAL is set equal to MASK, the record processing routine checks to see if the HIGH field is greater than 0. If it is, then the routine process the record again with VAL=0 after the number of seconds specified by HIGH. Thus, HIGH implements a latched output which changes the state of the device or link to 1, then changes it back to 0 after N number of seconds.

<TABLE BORDER="1">
<TD>ZNAM<TD>ASCII string defining state zero<TR>
<TD>ONAM<TD>ASCII string defining state one<TR>
<TD>HIGH<TD>If this value is greater than zero, then whenever VAL is set equal to 1, it is reset to zero after HIGH seconds.
</TABLE>

==== Output Specification ====

The OUT field specifies where the binary output record writes its output. It must specify the address of an I/O card if the record sends its output to hardware, and the DTYP field must contain a the corresponding device support module. Be aware that the address format differs according to the I/O bus used. See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on the format of hardware addresses. You can see a list of the device support modules currently supported at the user's local site by using the <CODE>dbst</CODE> utility in R3.13.

Otherwise, if the record is configured to use the soft device support modules, then it can be either a database link, a channel access link, or a constant. Be aware that nothing will be written when OUT is a constant. See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on the format of database and channel access addresses. Also, see [[#Device Support For Soft Records|Device Support For Soft Records]] in this chapter for more on output to other records.

=== Operator Display Parameters ===

These parameters are used to present meaningful data to the operator. The <CODE>get_enum_str</CODE> record support routine can retrieve the state string corresponding to the VAL's state. So if the value is 1, <CODE>get_enum_str</CODE> will return the string in the ONAM field; and if 0, <CODE>get_enum_str</CODE> will return the ZNAM string.

See [[RRM 3-14 dbCommon#Fields Common to All Record Types|Fields Common to All Record Types]] for more on the record name (NAME) and description (DESC) fields.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>ZNAM<TD>Zero Name<TD>STRING [20]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>ONAM<TD>One Name<TD>STRING [20]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>NAME<TD>Record Name<TD>STRING [29]<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>DESC<TD>Description<TD>STRING [29]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Alarm Parameters ===

These parameters are used to determine the binary output's alarm condition and to determine the severity of that condition. The possible alarm conditions for binary outputs are the SCAN, READ , INVALID, and state alarms. The user can configure the state alarm conditions using these fields.

The possible values for these fields are <CODE>NO_ALARM</CODE>, <CODE>MINOR</CODE>, and <CODE>MAJOR</CODE>. The ZSV holds the severity for the zero state; OSV for the one state. COSV is used to cause an alarm whenever the state changes between the states (0-1, or 1-0) and its severity is configured as MINOR or MAJOR.

See [[RRM 3-14 Common#Invalid Alarm Output Action|Invalid Alarm Output Action]] for more information on the IVOA and IVOV fields. [[RRM 3-14 dbCommon#Alarm Fields|Alarm Fields]] lists other fields related to a alarms that are common to all record types.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>ZSV<TD>Zero Severity<TD>[[RRM 3-14 Menu Choices#menuAlarmSevr|menuAlarmSevr]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>OSV<TD>One Severity<TD>[[RRM 3-14 Menu Choices#menuAlarmSevr|menuAlarmSevr]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>COSV<TD>Change of State Severity<TD>[[RRM 3-14 Menu Choices#menuAlarmSevr|menuAlarmSevr]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>IVOA<TD>Invalid Alarm Output Action<TD>[[RRM 3-14 Menu Choices#menuIvoa|menuIvoa]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>IVOV<TD>Invalid Alarm Output Value<TD>USHORT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Run-Time and Simulation Mode Parameters ===

These parameters are used by the run-time code for processing the binary output. They are not configurable using a configuration tool. They represent the current state of the binary output.

ORAW is used to determine if monitors should be triggered for RVAL at the same time they are triggered for VAL.

MASK is given a value by the device support routines and should not concern the user.

The RBV field is also set by device support. It is the actual read back value obtained from the hardware itself or from the associated device driver. The ORBV field is used to decide if monitors should be triggered for RBV at the same time monitors are triggered for changes in VAL.

The LALM field holds the value of the last occurrence of the change of state alarm. It is used to implement the change of state alarm, and thus only has meaning if COSV is MINOR or MAJOR.

The MLST is used by the <CODE>process</CODE> record support routine to determine if archive and value change monitors are invoked. They are if MLST is not equal to VAL.

The WPDT field is a private field for honoring seconds to hold HIGH.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>ORAW<TD>Old Raw Value<TD>ULONG<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>MASK<TD>Hardware Mask<TD>ULONG<TD>No<TD>compute<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>RBV<TD>Readback Value<TD>ULONG<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>ORBV<TD>Old Readback Value<TD>ULONG<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LALM<TD>Last Alarmed Value<TD>USHORT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>MLST<TD>Last Monitored Value<TD>USHORT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>RPVT<TD>Record Private<TD>NOACCESS<TD>No<TD>0<TD>No<TD>No<TD>No<TD>No<TR>
<TD>WDPT<TD>Watchdog Pointer<TD>NOACCESS<TD>No<TD>0<TD>No<TD>No<TD>No<TD>No
</TABLE>

The following fields are used to operate the binary output in the simulation mode. See [[RRM 3-14 Common#Fields Common to Many Record Types|Fields Common to Many Record Types]] for more information on these fields.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>SIOL<TD>Simulation Value Location<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>SIML<TD>Simulation Mode Location<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>SIMM<TD>Simulation Mode<TD>[[RRM 3-14 Menu Choices#menuSimm|menuSimm]]<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>SIMS<TD>Simulation Mode Alarm Severity<TD>[[RRM 3-14 Menu Choices#menuAlarmSevr|menuAlarmSevr]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

== Record Support ==

=== Record Support Routines ===

==== init_record ====

This routine initializes SIMM if SIML is a constant or creates a channel access link if SIML is PV_LINK. If SIOL is PV_LINK a channel access link is created .

This routine next checks to see that device support is available. The routine next checks to see if the device support write routine is defined.

If either device support or the device support write routine does not exist, an error message is issued and processing is terminated.

If DOL is a constant, then VAL is initialized to 1 if its value is nonzero or initialized to 0 if DOL is zero, and UDF is set to FALSE.

If device support includes init_record, it is called. VAL is set using RVAL, and UDF is set to FALSE.

==== process ====

See next section.

==== get_value ====

Fills in the values of struct valueDes so that they refer to VAL.

==== get_enum_str ====

Retrieves ASCII string corresponding to VAL.

==== get_enum_strs ====

Retrieves ASCII strings for ZNAM and ONAM.

==== put_enum_str ====

Checks if string matches ZNAM or ONAM, and if it does, sets VAL.

=== Record Processing ===

Routine process implements the following algorithm:

# Check to see that the appropriate device support module exists. If it doesn't, an error message is issued and processing is terminated with the PACT field still set to TRUE. This ensures that processes will no longer be called for this record. Thus error storms will not occur.
# If PACT is FALSE
#* if DOL is DB_LINK and OMSL is CLOSED_LOOP
#** get value from DOL
#** check for link alarm
#** force VAL to be 0 or 1
#** if MASK is defined
#*** if VAL is 0 set RVAL = 0
#** else set RVAL = MASK
# Check alarms: This routine checks to see if the new VAL causes the alarm status and severity to change. If so, NSEV, NSTA and LALM are set.
# Check severity and write the new value. See [[RRM 3-14 Common#Invalid Alarm Output Action|Invalid Alarm Output Action]] for more information on how INVALID alarms affect output.
# If PACT has been changed to TRUE, the device support write output routine has started but has not completed writing the new value. In this case, the processing routine merely returns, leaving PACT TRUE.
# Check WAIT. If VAL is 1 and WAIT is greater than 0, process again with a VAL=0 after WAIT seconds.
# Check to see if monitors should be invoked.
#* Alarm monitors are invoked if the alarm status or severity has changed.
#* Archive and value change monitors are invoked if MLST is not equal to VAL.
#* Monitors for RVAL and for RBV are checked whenever other monitors are invoked.
#* NSEV and NSTA are reset to 0.
# Scan forward link if necessary, set PACT FALSE, and return.

== Device Support ==

=== Fields Of Interest To Device Support ===

Each binary output record must have an associated set of device support routines. The primary responsibility of the device support routines is to write a new value whenever write_bo is called. The device support routines are primarily interested in the following fields:

<TABLE BORDER="1">
<TH>Name<TH>Summary<TH>Description<TR>
<TD>PACT<TD>Processing Active<TD rowspan=4>See [[RRM 3-14 dbCommon#Fields Common to All Record Types|Fields Common to All Record Types]] for an explanation of these fields.<TR>
<TD>DPVT<TD>Device Private<TR>
<TD>NSEV<TD>New Alarm Severity<TR>
<TD>NSTA<TD>New Alarm Status<TR>
<TD>VAL<TD>Value Field<TD>This field is only of interest to device support routines that do not use MASK and RVAL.<TR>
<TD>OUT<TD>Output Link<TD>This field is used by the device support routines to locate its output.<TR>
<TD>RVAL<TD>Raw Data Value<TD>If MASK is defined then record support sets RVAL=(0,MASK) if VAL is (0, not zero).<TR>
<TD>MASK<TD>Hardware mask.<TD>The device support module must set this field. Not that if VAL is 1, then record processing sets RVAL = MASK.<TR>
<TD>RBV<TD>Read Back Value<TD>This is the actual read back value obtained from the hardware itself or from the associated device driver. It is the responsibility of the device support routine to give this field a value.
</TABLE>

=== Device Support routines ===

Device support consists of the following routines:

==== report ====

report(FILE fp, paddr)

Not currently used.

==== init ====

init()

This routine is called once during IOC initialization.

==== init_record ====

init_record(precord)

This routine is optional. If provided, it is called by the record support init_record routine. It should determine MASK if it is needed.

* 0: Success. RVAL modified (VAL will be set accordingly)
* 2: Success. VAL modified
* other: Error.

==== get_ioint_info ====

get_ioint_info(int cmd,struct dbCommon *precord,IOSCANPVT *ppvt)

This routine is called by the ioEventScan system each time the record is added or deleted from an I/O event scan list. cmd has the value (0,1) if the record is being (added to, deleted from) an I/O event list. It must be provided for any device type that can use the ioEvent scanner.

==== write_bo ====

write_bo(precord)

This routine must output an new value. It returns the following values:

* 0: Success.
* other: Error.

=== Device Support For Soft Records ===

Two soft device support modules <CODE>Soft Channel</CODE> and <CODE>Raw Soft Channel</CODE> are provided for output records not related to actual hardware devices. The OUT link type must be either a CONSTANT, DB_LINK, or CA_LINK.

==== Soft Channel ====

This module writes the current value of VAL.

If the OUT link type is PV_LINK, then dbCaAddInlink is called by init_record. init_record always returns a value of 2, which means that no conversion will ever be attempted. write_bo calls recGblPutLinkValue to write the current value of VAL. See [[RRM 3-14 Common#Soft Output|Soft Output]] for details.

==== Raw Soft Channel ====

This module is like the previous except that it writes the current value of RVAL.

----

EPICS Record Reference Manual - 19 MAY 1998

RRM 3-14 Binary Output

2012-10-30T19:56:18Z

LewisMuir: /* Desired Output Parameters */ DOL field can be a constant

[[RRM 3-14|EPICS Record Reference Manual]]

= bo - Binary Output =

The normal use for this record type is to store a simple bit (0 or 1) value to be sent to a Digital Output module. It can also be used to write binary values into other records via database or channel access links. This record can implement both latched and momentary binary outputs depending on how the HIGH field is configured.

== Parameter Fields ==

The binary output's fields fall into the following categories:

* scan parameters
* convert and write parameters
* operator display parameters
* alarm parameters
* run-time parameters

=== Scan Parameters ===

The binary output record has the standard fields for specifying under what circumstances the record will be processed. These fields are listed in [[RRM 3-14 dbCommon#Scan Fields|Scan Fields]]. In addition, [[RRM 3-14 Concepts#Scanning Specification|Scanning Specification]] explains how these fields are used. Note that I/O event scanning is only supported for those card types that interrupt.

=== Desired Output Parameters ===

The binary output record must specify where its desired output originates. The desired output needs to be in engineering units.

The first field that determines where the desired output originates is the output mode select (OMSL) field, which can have two possible values: <CODE>closed_loop</CODE> or <CODE>supervisory</CODE>. If <CODE>supervisory</CODE> is specified, the value in the VAL field can be set externally via dbPuts at run-time. If <CODE>closed_loop</CODE> is specified, the VAL field's value is obtained from the address specified in the desired output location (DOL) field which can be a database link, a channel access link, or a constant. To achieve continuous control, a database link to a control algorithm record should be entered in the DOL field.

[[RRM 3-14 Concepts#Address Specification|Address Specification]] presents more information on database addresses and links. [[RRM 3-14 Concepts#Scanning Specification|Scanning Specification]] explains the effect of database linkage on scanning.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>DOL<TD>Desired Output Location (Input Link)<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>OMSL<TD>Output Mode Select<TD>[[RRM 3-14 Menu Choices#menuOmsl|menuOmsl]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Convert and Write Parameters ===

These parameters are used to determine where the binary output writes to and how to convert the engineering units to a raw signal. After VAL is set and forced to be either 1 or 0, as the result of either a dbPut or a new value being retrieved from the link in the DOL field, then what happens next depends on which device support routine is used and how the HIGH field is configured.

If the <CODE>Soft Channel</CODE> device support routine is specified, then the device support routine writes the VAL field's value to the address specified in the OUT field. Otherwise, RVAL is the value finally written by the device support routines after being converted.

If VAL is equal to 0, then the record processing routine sets RVAL equal to zero. When VAL is not equal to 0, then RVAL is set equal to the value contained in the MASK field. (MASK is set by the device support routines and is of no concern to the user.) Also when VAL is not 0 and after RVAL is set equal to MASK, the record processing routine checks to see if the HIGH field is greater than 0. If it is, then the routine will process the record again with VAL set to 0 after the number of seconds specified by HIGH. Thus, HIGH implements a momentary output which changes the state of the device back to 0 after ''N'' number of seconds.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>DTYP<TD>Device Type<TD>DEVCHOICE<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD> <TR>
<TD>OUT<TD>Output Link<TD>OUTLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>VAL<TD>Value Field<TD>ENUM<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>RVAL<TD>Raw Data Value<TD>ULONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>HIGH<TD>Seconds to Hold High<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>ZNAM<TD>Zero Name<TD>STRING [20]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>ONAM<TD>One Name<TD>STRING [20]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes
</TABLE>

==== Conversion Parameters ====

The ZNAM field has the string that corresponds to the 0 state, and the ONAM field holds the string that corresponds to the 1 state. These fields, other than being used to tell the operator what each state represents, are used to perform conversions if the value fetched by DOL is a string. If it is, VAL is set to the state correspond to that string. For instance, if the value fetched is the string "Off" and the ZNAM string is "Off," then VAL is set to 0.

After VAL is set, if VAL is equal to 0, then the record processing routine sets RVAL equal to zero. When VAL is not equal to 0, then RVAL is set equal to the value contained in the MASK field. (MASK is set by the device support routines and is of no concern to the user.) Also when VAL is equal to 1 and after RVAL is set equal to MASK, the record processing routine checks to see if the HIGH field is greater than 0. If it is, then the routine process the record again with VAL=0 after the number of seconds specified by HIGH. Thus, HIGH implements a latched output which changes the state of the device or link to 1, then changes it back to 0 after N number of seconds.

<TABLE BORDER="1">
<TD>ZNAM<TD>ASCII string defining state zero<TR>
<TD>ONAM<TD>ASCII string defining state one<TR>
<TD>HIGH<TD>If this value is greater than zero, then whenever VAL is set equal to 1, it is reset to zero after HIGH seconds.
</TABLE>

==== Output Specification ====

The OUT field specifies where the binary output record writes its output. It must specify the address of an I/O card if the record sends its output to hardware, and the DTYP field must contain a the corresponding device support module. Be aware that the address format differs according to the I/O bus used. See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on the format of hardware addresses. You can see a list of the device support modules currently supported at the user's local site by using the <CODE>dbst</CODE> utility in R3.13.

Otherwise, if the record is configured to use the soft device support modules, then it can be either a database link, a channel access link, or a constant. Be aware that nothing will be written when OUT is a constant. See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on the format of database and channel access addresses. Also, see [[#Device Support For Soft Records|Device Support For Soft Records]] in this chapter for more on output to other records.

=== Operator Display Parameters ===

These parameters are used to present meaningful data to the operator. The <CODE>get_enum_str</CODE> record support routine can retrieve the state string corresponding to the VAL's state. So if the value is 1, <CODE>get_enum_str</CODE> will return the string in the ONAM field; and if 0, <CODE>get_enum_str</CODE> will return the ZNAM string.

See [[RRM 3-14 dbCommon#Fields Common to All Record Types|Fields Common to All Record Types]] for more on the record name (NAME) and description (DESC) fields.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>ZNAM<TD>Zero Name<TD>STRING [20]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>ONAM<TD>One Name<TD>STRING [20]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>NAME<TD>Record Name<TD>STRING [29]<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>DESC<TD>Description<TD>STRING [29]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Alarm Parameters ===

These parameters are used to determine the binary output's alarm condition and to determine the severity of that condition. The possible alarm conditions for binary outputs are the SCAN, READ , INVALID, and state alarms. The user can configure the state alarm conditions using these fields.

The possible values for these fields are <CODE>NO_ALARM</CODE>, <CODE>MINOR</CODE>, and <CODE>MAJOR</CODE>. The ZSV holds the severity for the zero state; OSV for the one state. COSV is used to cause an alarm whenever the state changes between the states (0-1, or 1-0) and its severity is configured as MINOR or MAJOR.

See [[RRM 3-14 Common#Invalid Alarm Output Action|Invalid Alarm Output Action]] for more information on the IVOA and IVOV fields. [[RRM 3-14 dbCommon#Alarm Fields|Alarm Fields]] lists other fields related to a alarms that are common to all record types.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>ZSV<TD>Zero Severity<TD>[[RRM 3-14 Menu Choices#menuAlarmSevr|menuAlarmSevr]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>OSV<TD>One Severity<TD>[[RRM 3-14 Menu Choices#menuAlarmSevr|menuAlarmSevr]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>COSV<TD>Change of State Severity<TD>[[RRM 3-14 Menu Choices#menuAlarmSevr|menuAlarmSevr]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>IVOA<TD>Invalid Alarm<TD>[[RRM 3-14 Menu Choices#menuIvoa|menuIvoa]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>IVOV<TD>Invalid Alarm Output Value<TD>USHORT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Run-Time and Simulation Mode Parameters ===

These parameters are used by the run-time code for processing the binary output. They are not configurable using a configuration tool. They represent the current state of the binary output.

ORAW is used to determine if monitors should be triggered for RVAL at the same time they are triggered for VAL.

MASK is given a value by the device support routines and should not concern the user.

The RBV field is also set by device support. It is the actual read back value obtained from the hardware itself or from the associated device driver. The ORBV field is used to decide if monitors should be triggered for RBV at the same time monitors are triggered for changes in VAL.

The LALM field holds the value of the last occurrence of the change of state alarm. It is used to implement the change of state alarm, and thus only has meaning if COSV is MINOR or MAJOR.

The MLST is used by the <CODE>process</CODE> record support routine to determine if archive and value change monitors are invoked. They are if MLST is not equal to VAL.

The WPDT field is a private field for honoring seconds to hold HIGH.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>ORAW<TD>Old Raw Value<TD>ULONG<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>MASK<TD>Hardware Mask<TD>ULONG<TD>No<TD>compute<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>RBV<TD>Readback Value<TD>ULONG<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>ORBV<TD>Old Readback Value<TD>ULONG<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LALM<TD>Last Alarmed Value<TD>USHORT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>MLST<TD>Last Monitored Value<TD>USHORT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>RPVT<TD>Record Private<TD>NOACCESS<TD>No<TD>0<TD>No<TD>No<TD>No<TD>No<TR>
<TD>WDPT<TD>Watchdog Pointer<TD>NOACCESS<TD>No<TD>0<TD>No<TD>No<TD>No<TD>No
</TABLE>

The following fields are used to operate the binary output in the simulation mode. See [[RRM 3-14 Common#Fields Common to Many Record Types|Fields Common to Many Record Types]] for more information on these fields.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>SIOL<TD>Simulation Value Location<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>SIML<TD>Simulation Mode Location<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>SIMM<TD>Simulation Mode<TD>[[RRM 3-14 Menu Choices#menuSimm|menuSimm]]<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>SIMS<TD>Simulation Mode Alarm Severity<TD>[[RRM 3-14 Menu Choices#menuAlarmSevr|menuAlarmSevr]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

== Record Support ==

=== Record Support Routines ===

==== init_record ====

This routine initializes SIMM if SIML is a constant or creates a channel access link if SIML is PV_LINK. If SIOL is PV_LINK a channel access link is created .

This routine next checks to see that device support is available. The routine next checks to see if the device support write routine is defined.

If either device support or the device support write routine does not exist, an error message is issued and processing is terminated.

If DOL is a constant, then VAL is initialized to 1 if its value is nonzero or initialized to 0 if DOL is zero, and UDF is set to FALSE.

If device support includes init_record, it is called. VAL is set using RVAL, and UDF is set to FALSE.

==== process ====

See next section.

==== get_value ====

Fills in the values of struct valueDes so that they refer to VAL.

==== get_enum_str ====

Retrieves ASCII string corresponding to VAL.

==== get_enum_strs ====

Retrieves ASCII strings for ZNAM and ONAM.

==== put_enum_str ====

Checks if string matches ZNAM or ONAM, and if it does, sets VAL.

=== Record Processing ===

Routine process implements the following algorithm:

# Check to see that the appropriate device support module exists. If it doesn't, an error message is issued and processing is terminated with the PACT field still set to TRUE. This ensures that processes will no longer be called for this record. Thus error storms will not occur.
# If PACT is FALSE
#* if DOL is DB_LINK and OMSL is CLOSED_LOOP
#** get value from DOL
#** check for link alarm
#** force VAL to be 0 or 1
#** if MASK is defined
#*** if VAL is 0 set RVAL = 0
#** else set RVAL = MASK
# Check alarms: This routine checks to see if the new VAL causes the alarm status and severity to change. If so, NSEV, NSTA and LALM are set.
# Check severity and write the new value. See [[RRM 3-14 Common#Invalid Alarm Output Action|Invalid Alarm Output Action]] for more information on how INVALID alarms affect output.
# If PACT has been changed to TRUE, the device support write output routine has started but has not completed writing the new value. In this case, the processing routine merely returns, leaving PACT TRUE.
# Check WAIT. If VAL is 1 and WAIT is greater than 0, process again with a VAL=0 after WAIT seconds.
# Check to see if monitors should be invoked.
#* Alarm monitors are invoked if the alarm status or severity has changed.
#* Archive and value change monitors are invoked if MLST is not equal to VAL.
#* Monitors for RVAL and for RBV are checked whenever other monitors are invoked.
#* NSEV and NSTA are reset to 0.
# Scan forward link if necessary, set PACT FALSE, and return.

== Device Support ==

=== Fields Of Interest To Device Support ===

Each binary output record must have an associated set of device support routines. The primary responsibility of the device support routines is to write a new value whenever write_bo is called. The device support routines are primarily interested in the following fields:

<TABLE BORDER="1">
<TH>Name<TH>Summary<TH>Description<TR>
<TD>PACT<TD>Processing Active<TD rowspan=4>See [[RRM 3-14 dbCommon#Fields Common to All Record Types|Fields Common to All Record Types]] for an explanation of these fields.<TR>
<TD>DPVT<TD>Device Private<TR>
<TD>NSEV<TD>New Alarm Severity<TR>
<TD>NSTA<TD>New Alarm Status<TR>
<TD>VAL<TD>Value Field<TD>This field is only of interest to device support routines that do not use MASK and RVAL.<TR>
<TD>OUT<TD>Output Link<TD>This field is used by the device support routines to locate its output.<TR>
<TD>RVAL<TD>Raw Data Value<TD>If MASK is defined then record support sets RVAL=(0,MASK) if VAL is (0, not zero).<TR>
<TD>MASK<TD>Hardware mask.<TD>The device support module must set this field. Not that if VAL is 1, then record processing sets RVAL = MASK.<TR>
<TD>RBV<TD>Read Back Value<TD>This is the actual read back value obtained from the hardware itself or from the associated device driver. It is the responsibility of the device support routine to give this field a value.
</TABLE>

=== Device Support routines ===

Device support consists of the following routines:

==== report ====

report(FILE fp, paddr)

Not currently used.

==== init ====

init()

This routine is called once during IOC initialization.

==== init_record ====

init_record(precord)

This routine is optional. If provided, it is called by the record support init_record routine. It should determine MASK if it is needed.

* 0: Success. RVAL modified (VAL will be set accordingly)
* 2: Success. VAL modified
* other: Error.

==== get_ioint_info ====

get_ioint_info(int cmd,struct dbCommon *precord,IOSCANPVT *ppvt)

This routine is called by the ioEventScan system each time the record is added or deleted from an I/O event scan list. cmd has the value (0,1) if the record is being (added to, deleted from) an I/O event list. It must be provided for any device type that can use the ioEvent scanner.

==== write_bo ====

write_bo(precord)

This routine must output an new value. It returns the following values:

* 0: Success.
* other: Error.

=== Device Support For Soft Records ===

Two soft device support modules <CODE>Soft Channel</CODE> and <CODE>Raw Soft Channel</CODE> are provided for output records not related to actual hardware devices. The OUT link type must be either a CONSTANT, DB_LINK, or CA_LINK.

==== Soft Channel ====

This module writes the current value of VAL.

If the OUT link type is PV_LINK, then dbCaAddInlink is called by init_record. init_record always returns a value of 2, which means that no conversion will ever be attempted. write_bo calls recGblPutLinkValue to write the current value of VAL. See [[RRM 3-14 Common#Soft Output|Soft Output]] for details.

==== Raw Soft Channel ====

This module is like the previous except that it writes the current value of RVAL.

----

EPICS Record Reference Manual - 19 MAY 1998

RRM 3-14 Calcout

2012-10-19T15:59:04Z

LewisMuir: /* Constants */ Fix pi character

[[RRM 3-14|EPICS Record Reference Manual]]

= Calcout - Calculation Output Record =

The Calculation Output or "Calcout" record is similar to the Calc record with the added feature of having outputs (an "output link" and an "output event") which are conditionally executed based on the result of the calculation. This feature allows conditional branching to be implemented within an EPICS database (e.g., process Record_A only if Record_B has a value of 0). The Calcout record is also similar to the Wait record (with additional features) but uses EPICS standard INLINK and OUTLINK fields rather than the DBF_STRING fields used in the Wait record. For new databases, it is recommended that the Calcout record be used instead of the Wait record.

== Parameter Fields ==

The fields in this record fall into these categories:

* scan parameters
* read parameters
* expression parameters
* output parameters
* operator display parameters
* alarm parameters
* monitor parameters
* run-time parameters

=== Scan Parameters ===

The Calcout record has the standard fields for specifying under what circumstances the record will be processed. These fields are listed in [[RRM 3-14 dbCommon#Scan Fields|Scan Fields]]. In addition, [[RRM 3-14 Concepts#Scanning Specification|Scanning Specification]] explains how these fields are used. Since the Calcout record supports no direct interfaces to hardware, it cannot be scanned on I/O interrupt, so its SCAN field cannot be <CODE>I/O Intr</CODE>.

=== Read Parameters ===

The read parameters for the Calcout record consist of 12 input links INPA, INPB, ... INPL. The fields can be database links, channel access links, or constants. If they are links, they must specify another record's field. If they are constants, they will be initialized with the value they are configured with and can be changed via <CODE>dbPuts</CODE>. These fields cannot be hardware addresses. In addition, the Calcout record contains the INAV, INBV, . . . INLV fields which indicate the status of the link fields, for example, whether or not the specified PV was found and a link to it established. See [[#Operator Display Parameters|Operator Display Parameters]] for an explanation of these fields.

See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on how to specify database links.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TR>
<TD>INPA<TD>Input Link A<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPB<TD>Input Link B<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPC<TD>Input Link C<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPD<TD>Input Link D<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPE<TD>Input Link E<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPF<TD>Input Link F<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPG<TD>Input Link G<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPH<TD>Input Link H<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPI<TD>Input Link I<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPJ<TD>Input Link J<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPK<TD>Input Link K<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPL<TD>Input Link L<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A
</TABLE>

=== Expression ===

Like the Calc record, the Calcout record has a CALC field in which the developer can enter an infix expression which the record routine will evaluate when it processes the record. The resulting value is placed in the VAL field. This value can then be used by the OOPT field (see [[#Output Parameters|Output Parameters]]) to determine whether or not to write to the output link or post an output event. It can also be the value that is written to the output link. The CALC expression is actually converted to opcode and stored in Reverse Polish Notation in the RPCL field. It is this expression which is actually used to calculate VAL. The Reverse Polish expression is evaluated more efficiently during run-time than an infix expression. CALC can be changed at run-time, and a special record routine will call a function to convert it to Reverse Polish Notation.

The infix expressions that can be used are very similar to the C expression syntax, but with some additions and subtle differences in operator meaning and precedence. The string may contain a series of expressions separated by a semi-colon character ';' any one of which may actually provide the calculation result; however all of the other expressions included must assign their result to a variable. All alphabetic elements described below are case independent, so upper and lower case letters may be used and mixed in the variable and function names as desired. Spaces may be used anywhere within an expression except between the characters that make up a single expression element.

The range of expressions supported by the calculation record are separated into literals, constants, operands, algebraic operators, trigonometric operators, relational operators, logical operators, the assignment operator, parentheses and commas, and the question mark or '?:' operator.

-----
'''NOTE:''' A complete up-to-date description of the calculation expression can be found in the '''Application Developer's Guide''', chapter libCom / calc / Infix Expression Syntax (19.2.1 for EPICS 3.14.11).
-----

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>CALC<TD>Calculation<TD>STRING[36]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>VAL<TD>Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>RPCL<TD>Reverse Polish<TD>NOACCESS<TD>No<TD>0<TD>No<TD>No<TD>N/A<TD>No
</TABLE>

==== Literals ====

* Standard double precision floating point numbers
* Inf: Infinity
* Nan: Not a Number

==== Constants ====

* PI: returns the mathematical constant <tt>π</tt>
* D2R: evaluates to <tt>π</tt>/180 which, when used as a multiplier, converts an angle from degrees to radians
* R2D: evaluates to 180/<tt>π</tt> which as a multiplier converts an angle from radians to degrees

==== Operands ====

The expression can use the values retrieved from the INP''x'' links as operands, though constants can be used as operands too. These values retrieved from the input links are stored in the A-L fields. The values to be used in the expression are simply referenced by the field letter. For instance, the value obtained from the INPA link is stored in the field A, and the value obtained from INPB is stored in field B. The field names can be included in the expression which will operate on their respective values, as in A+B.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>A<TD>Input Value A<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>B<TD>Input Value B<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>C<TD>Input Value C<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>D<TD>Input Value D<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>E<TD>Input Value E<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>F<TD>Input Value F<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>G<TD>Input Value G<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>H<TD>Input Value H<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>I<TD>Input Value I<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>J<TD>Input Value J<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>K<TD>Input Value K<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>L<TD>Input Value L<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes
</TABLE>

The keyword <tt>VAL</tt> returns the current contents of the expression's result field, i.e. the VAL field for the CALC expression and the OVAL field for the OCAL expression. (These fields can be written to by a CA put, so it might ''not'' be the result from last time the expression was evaluated).

Also, the RNDM unary function can be included as an operand in the expression in order to generate a random number between 0 and 1.

==== Algebraic Operators ====

* ABS: Absolute value (unary)
* SQR: Square root (unary)
* MIN: Minimum (any number of args)
* MAX: Maximum (any number of args)
* FINITE: returns non-zero if none of the arguments are NaN or Inf (any number of args)
* ISNAN: returns non-zero if any of the arguments is NaN or Inf (any number of args)
* CEIL: Ceiling (unary)
* FLOOR: Floor (unary)
* LOG: Log base 10 (unary)
* LOGE: Natural log (unary)
* EXP: Exponential function (unary)
* ^: Exponential (binary)
* ** : Exponential (binary)
* + : Addition (binary)
* - : Subtraction (binary)
* * : Multiplication (binary)
* / : Division (binary)
* % : Modulo (binary)
* NOT: Negate (unary)

==== Trigonometric Operators ====

* SIN: Sine
* SINH: Hyperbolic sine
* ASIN: Arc sine
* COS: Cosine
* COSH: Hyperbolic cosine
* ACOS: Arc cosine
* TAN: Tangent
* TANH: Hyperbolic tangent
* ATAN: Arc tangent

==== Relational Operators ====

* >= : Greater than or equal to
* > : Greater than
* <= : Less than or equal to
* <: Less than
* # : Not equal to
* = : Equal to

==== Logical Operators ====

* && : And
* || : Or
* ! : Not

==== Bitwise Operators ====

* | : Bitwise Or
* & : Bitwise And
* OR : Bitwise Or
* AND: Bitwise And
* XOR: Bitwise Exclusive Or
* ~ : One's Complement
* << : Left shift
* >> : Right shift

==== Assignment Operator ====

* := : assigns a value (right hand side) to a variable (i.e. field)

==== Parentheses and Comma ====

The open and close parentheses are supported. Nested parenthesis are supported.

The comma is supported when used to separate the arguments of a binary function.

==== Conditional Expression ====

The C language's question mark operator is supported. The format is:

condition ? True result : False result

=== Example Expressions ===

==== Algebraic ====

A + B + 10

* Result is A + B + 10

==== Relational ====

(A + B) < (C + D)

* Result is 1 if (A+B) < (C+D)
* Result is 0 if (A+B) >= (C+D)

==== Question Mark ====

(A+B)<(C+D)?E:F+L+10

* Result is E if (A+B) < (C+D)
* Result is F+L+10 if (A+B) >= (C+D)

==== Logical ====

A&B

* Causes the following to occur:
** Convert A to integer
** Convert B to integer
** Bit-wise And A and B
** Convert result to floating point

=== Output Parameters ===

These parameters specify and control the output capabilities of the Calcout record. They determine when to write the output, where to write it, and what the output will be. The OUT link specifies the Process Variable to which the result will be written. The OOPT field determines the condition that causes the output link to be written to. It's a menu field that has six choices:

* <CODE>Every Time</CODE> -- write output every time record is processed.
* <CODE>On Change</CODE> -- write output every time VAL changes, i.e., every time the result of the expression changes.
* <CODE>When Zero</CODE> -- when record is processed, write output if VAL is zero.
* <CODE>When Non-zero</CODE> -- when record is processed, write output if VAL is non-zero.
* <CODE>Transition To Zero</CODE> -- when record is processed, write output only if VAL is zero and last value was non-zero.
* <CODE>Transition To Non-zero</CODE> -- when record is processed, write output only if VAL is non-zero and last value was zero.

The DOPT field determines what data is written to the output link when the output is executed. The field is a menu field with two options: <CODE>Use CALC</CODE> or <CODE>Use OCAL</CODE>. If <CODE>Use CALC</CODE> is specified, when the record writes its output it will write the result of the expression in the CALC record, that is, it will write the value of the VAL field. If <CODE>Use OCAL</CODE> is specified, the record will instead write the result of the expression in the OCAL field, which is contained in the OVAL field. The OCAL field is exactly like the CALC field and has the same functionality: it can contain the string representation of an expression which is evaluated at run-time. Thus, if necessary, the record can use the result of the CALC expression to determine if data should be written and can use the result of the OCAL expression as the data to write.

If the OEVT field specifies a non-zero integer and the condition in the OOPT field is met, the record will post a corresponding event. If the ODLY field is non-zero, the record pauses for the specified number of seconds before executing the OUT link or posting the output event. During this waiting period the record is "active" and will not be processed again until the wait is over. The field DLYA is equal to 1 during the delay period. The resolution of the delay entry is system dependent.

The IVOA field specifies what action to take with the OUT link if the Calcout record enters an INVALID alarm status. The options are <CODE>Continue normally</CODE>, <CODE>Don't drive outputs</CODE>, and <CODE>Set output to IVOV</CODE>. If the IVOA field is <CODE>Set output to IVOV</CODE>, the data entered into the IVOV field is written to the OUT link if the record alarm severity is INVALID.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>OUT<TD>Output Specification<TD>OUTLINK<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>N/A<TD>No<TR>
<TD>OOPT<TD>Output Execute Option<TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DOPT<TD>Output Data Option<TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>OCAL<TD> Output Calculation<TD>STRING[36]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>OVAL<TD>Output Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>OEVT<TD>Event To Issue<TD>SHORT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>ODLY<TD>Output Execution Delay<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>IVOA<TD>Invalid Output Action<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>IVOV<TD>Invalid Output Value<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Operator Display Parameters ===

These parameters are used to present meaningful data to the operator. Some are also meant to represent the status of the record at run-time. An example of an interactive MEDM display screen that displays the status of the Calcout record is located here.

The EGU field contains a string of up to 16 characters which is supplied by the user and which describes the values being operated upon. The string is retrieved whenever the routine <CODE>get_units</CODE> is called. The EGU string is solely for an operator's sake and does not have to be used.

The HOPR and LOPR fields only refer to the limits of the VAL, HIHI, HIGH, LOW, and LOLO fields. PREC controls the precision of the VAL field.

The INAV-INLV fields indicate the status of the link to the PVs specified in the INPA-INPL fields, respectively. The field can have three possible values:

* <CODE>Ext PV NC</CODE> -- the PV wasn't found on this IOC and a Channel Access link hasn't been established.
* <CODE>Ext PV OK</CODE> -- the PV wasn't found on this IOC and a Channel Access link has been established.
* <CODE>Local PV</CODE> -- the PV was found on this IOC.
* <CODE>Constant</CODE> -- the corresponding link field is a constant.

The OUTV field indicates the status of the OUT link. It has the same possible values as the INAV-INLV fields.

The CLCV and OLCV fields indicate the validity of the expression in the CALC and OCAL fields, respectively. If the expression is invalid, the field is set to one.

The DLYA field is set to one during the delay interval specified in ODLY.

See [[RRM 3-14 dbCommon#Fields Common to All Record Types|Fields Common to All Record Types]] for more on the record name (NAME) and description (DESC) fields.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>EGU<TD>Engineering Units<TD>STRING [16]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>PREC<TD>Display Precision<TD>SHORT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>HOPR<TD>High Operating Range<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>LOPR<TD>Low Operating Range<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>INAV<TD>Link Status of INPA<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INBV<TD>Link Status of INPB<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INCV<TD>Link Status of INPC<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INDV<TD>Link Status of INPD<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INEV<TD>Link Status of INPE<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INFV<TD>Link Status of INPF<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INGV<TD>Link Status of INPG<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INHV<TD>Link Status of INPH<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INIV<TD>Link Status of INPI<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INJV<TD>Link Status of INPJ<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INKV<TD>Link Status of INPK<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INLV<TD>Link Status of INPL<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>OUTV<TD>OUT PV Status<TD>RECCHOICE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>CLCV<TD>CALC Valid<TD>LONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>OCLV<TD>OCAL Valid<TD>LONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DLYA<TD>Output Delay Active<TD>USHORT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>NAME<TD>Record Name<TD>STRING [29]<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>DESC<TD>Description<TD>STRING [29]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Alarm Parameters ===

The possible alarm conditions for the Calc record are the SCAN, READ, Calculation, and limit alarms. The SCAN and READ alarms are called by the record support routines. The Calculation alarm is called by the record processing routine when the CALC expression is an invalid one, upon which an error message is generated.

The following alarm parameters which are configured by the user define the limit alarms for the VAL field and the severity corresponding to those conditions.

The HYST field defines an alarm deadband for each limit. See [[RRM 3-14 Concepts#Alarm Specification|Alarm Specification]] for a complete explanation of alarms and these fields. [[RRM 3-14 dbCommon#Alarm Fields|Alarm Fields]] lists other fields related to a alarms that are common to all record types.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>HIHI<TD>Hihi Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HIGH<TD>High Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LOW<TD>Low Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LOLO<TD>Lolo Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HHSV<TD>Severity for a Hihi Alarm<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HSV<TD>Severity for a High Alarm<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LSV<TD>Severity for a Low Alarm<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LLSV<TD>Severity for a Lolo Alarm<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HYST<TD>Alarm Deadband<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Monitor Parameters ===

These parameters are used to determine when to send monitors for the value fields. The monitors are sent when the value field exceeds the last monitored field by the appropriate deadband, the ADEL for archiver monitors and the MDEL field for all other types of monitors. If these fields have a value of zero, every time the value changes, monitors are triggered; if they have a value of -1, every time the record is scanned, monitors are triggered. See [[RRM 3-14 Concepts#Monitor Specification|Monitor Specification]] for a complete explanation of monitors.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>ADEL<TD>Archive Deadband<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>MDEL<TD>Monitor, i.e. value change, Deadband<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Run-time Parameters ===

These fields are not configurable using a configuration too and none are modifiable at run-time. They are used to process the record.

The LALM field is used to implement the hysteresis factor for the alarm limits.

The LA-LL fields are used to decide when to trigger monitors for the corresponding fields. For instance, if LA does not equal the value for A, monitors for A are triggered. The MLST and MLST fields are used in the same manner for the VAL field.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>LALM<TD>Last Alarmed Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>ALST<TD>Archive Last Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>MLST<TD>Monitor Last Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LA<TD>Previous Input Value for A<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LB<TD>Previous Input Value for B<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LC<TD>Previous Input Value for C<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LD<TD>Previous Input Value for D<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LE<TD>Previous Input Value for E<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LF<TD>Previous Input Value for F<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LG<TD>Previous Input Value for G<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LH<TD>Previous Input Value for H<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LI<TD>Previous Input Value for I<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LJ<TD>Previous Input Value for J<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LK<TD>Previous Input Value for K<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LL<TD>Previous Input Value for L<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No
</TABLE>

== Record Support ==

=== Record Support Routines ===

==== init_record ====

For each constant input link, the corresponding value field is initialized with the constant value if the input link is CONSTANT or a channel access link is created if the input link is PV_LINK.

A routine postfix is called to convert the infix expression in CALC and OCAL to reverse polish notation. The result is stored in RPCL and ORPC, respectively.

==== process ====

See next section.

==== special ====

This is called if CALC or OCAL is changed. special calls postfix.

==== get_value ====

Fills in the values of struct valueDes so that they refer to VAL.

==== get_units ====

Retrieves EGU.

==== get_precision ====

Retrieves PREC.

==== get_graphic_double ====

Sets the upper display and lower display limits for a field. If the field is VAL, HIHI, HIGH, LOW, or LOLO, the limits are set to HOPR and LOPR, else if the field has upper and lower limits defined they will be used, else the upper and lower maximum values for the field type will be used.

==== get_control_double ====

Sets the upper control and the lower control limits for a field. If the field is VAL, HIHI, HIGH, LOW, or LOLO, the limits are set to HOPR and LOPR, else if the field has upper and lower limits defined they will be used, else the upper and lower maximum values for the field type will be used.

==== get_alarm_double ====

Sets the following values:

upper_alarm_limit = HIHI
upper_warning_limit = HIGH
lower_warning_limit = LOW
lower_alarm_limit = LOLO

=== Record Processing ===

==== process() ====

The <CODE>process()</CODE> routine implements the following algorithm:

# Fetch all arguments.
# Call routine calcPerform(), which calculates VAL from the postfix version of the expression given in CALC. If calcPerform() returns success, UDF is set to FALSE.
# Check alarms. This routine checks to see if the new VAL causes the alarm status and severity to change. If so, NSEV, NSTA and LALM are set. It also honors the alarm hysteresis factor (HYST). Thus the value must change by at least HYST before the alarm status and severity changes.
# Determine if the Output Execution Option (OOPT) is met. If it is met, either execute the output link (and output event) immediately (if ODLY = 0), or schedule a callback after the specified interval. See the explanation for the <CODE>execOutput()</CODE> routine below.
# Check to see if monitors should be invoked.
#* Alarm monitors are invoked if the alarm status or severity has changed.
#* Archive and value change monitors are invoked if ADEL and MDEL conditions are met.
#* Monitors for A-L are checked whenever other monitors are invoked.
#* NSEV and NSTA are reset to 0.
# If no output delay was specified, scan forward link if necessary, set PACT FALSE, and return.

==== execOutput() ====

# If DOPT field specifies the use of OCAL, call the routine calcPerform for the postfix version of the expression in OCAL. Otherwise, use VAL.
# If the Alarm Severity is INVALID, follow the option as designated by the field IVOA.
# If the Alarm Severity is not INVALID or IVOA specifies "Continue Normally", put the value of OVAL to the OUT link and post the event in OEVT (if non-zero).
# If an output delay was implemented, process the forward link.

----

EPICS Record Reference Manual - 19 MAY 1998

RRM 3-14 Analog Output

2012-10-18T23:07:11Z

LewisMuir: /* Desired Output Parameters */ fix grammar

[[RRM 3-14|EPICS Record Reference Manual]]

= ao - Analog Output =

The normal use for this record type is to output values to digital-analog converters. It is used for all analog outputs to hardware. It can also be used to write floating point values to other records via database or channel access links. How the user configures the output link determines if the record sends its value to a hardware device, a channel access link, or a database link. The desired output can be controlled by either an operator or a state program, or it can be fetched from another record.

The record supports alarm limits, conversion from/to engineering units, and graphics and control limits.

== Parameter Fields ==

The analog output's fields fall into the following categories:

* scan parameters
* desired output parameters
* convert and write parameters
* operator display parameters
* alarm parameters
* monitor parameters
* run-time parameters.

=== Scan Parameters ===

The analog output record has the standard fields for specifying under what circumstances the record will be processed. These fields are listed in [[RRM 3-14 dbCommon#Scan Fields|Scan Fields]]. In addition, [[RRM 3-14 Concepts#Scanning Specification|Scanning Specification]] explains how these fields are used. Note that I/O event scanning is only supported for those card types that interrupt.

=== Desired Output Parameters ===

The analog output record must specify where the desired output to be written should originate. The desired output should be in engineering units. The first field that determines where the desired output originates is the output mode select field (OMSL), which has two choices--closed_loop or supervisory. If supervisory is specified, the value in the VAL field can be set externally via dbPuts at run-time. If closed_loop is specified, the VAL field's value is obtained from the address specified in the desired output location field (DOL), which can be either a database link or a channel access link. To achieve continuous control, a database link to a control algorithm record should be entered in the DOL field.

When VAL is obtained from DOL, the OIF field decides whether the value obtained from DOL is an increment to be added to the current VAL or if the value obtained from DOL is the actual value. The OIF field has two choices, Incremental or Full. The OIF and OMSL fields, in addition to being configurable, can also be changed during run-time. (OIF is not used when OMSL is set to SUPERVISORY.)

The VAL field's value is forced to be within the limits specified in the fields DRVH and DRVL, which are configured by the designer:

DRVL<=VAL<=DRVH

Note: If nothing is entered for DRVH and DRVL, the output value will never change.

The VAL field is then adjusted by the OROC field's value if the OROC field is not zero. The OROC field determines the maximum change in value that occurs each time the record is processed. The value adjusted by OROC is then used by OVAL. If the address contained in the output link (see next section) is a channel access or database link and if Soft Channel device support is specified, the value in OVAL is sent to the address in the OUT field. Otherwise, a conversion process is performed. The next section on convert and write parameters explains how this value is converted before being written.

See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on specifying links. [[RRM 3-14 Concepts#Scanning Specification|Scanning Specification]] explains the effect of database linkage on scanning.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify
<TH>Rec Proc Monitor<TH>PP<TR>
<TD>OMSL<TD>Output Mode Select<TD>[[RRM 3-14 Menu Choices#menuOmsl|menuOmsl]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DOL<TD>Desired Output Location (an Input Link)<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>OIF<TD>Out Full or Incremental<TD>[[RRM 3-14 Menu Choices#aoOIF|aoOIF]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DRVH<TD>Drive High<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>DRVL<TD>Drive Low<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>VAL<TD>Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>OROC<TD>Maximum Output Rate of Change<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>OVAL<TD>Output Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No
</TABLE>

=== Convert and Write Parameters ===

For analog output records that do not use the Soft Channel device support routine, the specified conversions (if any) are performed on the OVAL field and the resulting value in the RVAL field is sent to the address contained in the output link after it is adjusted by the values in the AOFF and ASLO fields.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify
<TH>Rec Proc Monitor<TH>PP<TR>
<TD>OUT<TD>Output Link<TD>OUTLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>DTYP<TD>Device Type<TD>DEVCHOICE<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD> <TR>
<TD>LINR<TD>Type of Conversion<TD>[[RRM 3-14 Menu Choices#menuConvert|menuConvert]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>RVAL<TD>Raw Value<TD>LONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>ROFF<TD>Raw Value Offset<TD>LONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>EGUF<TD>Engineering Units Full<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>EGUL<TD>Engineering Units Low<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>AOFF<TD>Adjustment Offset<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>ASLO<TD>Adjustment Slope<TD>DOUBLE<TD>Yes<TD>1<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>ESLO<TD>Slope for Linear Conversions<TD>DOUBLE<TD>Yes<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>EOFF<TD>Offset for Linear Conversions<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD>No
</TABLE>

==== Conversion Related Fields and the Conversion Process ====

Except for analog outputs that use Soft Channel device support, the LINR field determines if a conversion is performed and which conversion algorithm is used to convert OVAL to RVAL. The LINR field can specify LINEAR or SLOPE for linear conversions, NO CONVERSION for no conversions at all, or the name of a breakpoint table such as typeKdegC for breakpoint conversions.

Note that the ESLO, EOFF, EGUF, and EGUL fields are only used for linear conversions. Also note that none of these fields have any significance for records that use the Soft Channel device support module.

<TABLE BORDER="1">
<TD>EGUF<TD rowspan=2>The user must calculate these fields when configuring the database for records that use LINEAR conversions. They are used to calculate the values for ESLO and EOFF. See [[RRM 3-14 Concepts#Conversion Specification|Conversion Specification]] for more information on how to calculate these fields.<TR>
<TD>EGUL<TR>
<TD>AOFF<TD rowspan=2>These fields are adjustment parameters for the raw output values. They are applied to the raw output value after conversion from engineering units.<TR>
<TD>ASLO<TR>
<TD>ESLO<TD rowspan=2>Computed by device support using EGUF and EGUL when LINR specifies LINEAR. These values must be supplied by the user when LINR specifies SLOPE. Used only when LINR specifies LINEAR or SLOPE.<TR>
<TD>EOFF<TR>
<TD>ROFF<TD>Deprecated. New device supports should not set this to anything other than 0. It was used to offset raw value. For backwards compatibility, it is still added to the raw value (RVAL) when value is converted.<TR>
</TABLE>

Conversion proceeds as follows:

: 1. If LINR==LINEAR or LINR==SLOPE, then X = (VAL - EOFF) / ESLO, else if LINR==NO_CONVERSION, then X = VAL, else X is obtained via breakpoint table.

: 2. X = (X - AOFF) / ASLO

: 3. RVAL = round(X) - ROFF

To see how the Raw Soft Channel device support routine uses these fields, see [[#Device Support For Soft Records|Device Support For Soft Records]] in this chapter for more information.

==== Output Specification ====

The analog output record sends its desired output to the address in the OUT field. For analog outputs that write their values to devices, the OUT field must specify the address of the I/O card. In addition, the DTYP field must contain the name of the device support module. Be aware that the address format differs according to the I/O bus used. See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on the format of hardware addresses. The user can see a list of the device support modules currently supported at the user's local site by using the dbst utility in R3.13.

For soft records the output link can be a database link, a channel access link, or a constant value. If the link is a constant, no output is sent. See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on the format of database and channel access addresses.

=== Operator Display Parameters ===

These parameters are used to present meaningful data to the operator. They display the value and other parameters of the analog output either textually or graphically.

EGU is a string of up to 16 characters describing the units that the analog output measures. It is retrieved by the get_units record support routine.

The HOPR and LOPR fields set the upper and lower display limits for the VAL, OVAL, PVAL, HIHI, HIGH, LOW, and LOLO fields. Both the get_graphic_double and get_control_double record support routines retrieve these fields. If these values are defined, they must be in the range: DRVL<=LOPR<=HOPR<=DRVH.

The PREC field determines the floating point precision with which to display VAL, OVAL and PVAL. It is used whenever the get_precision record support routine is called.

See [[RRM 3-14 dbCommon#Miscellaneous Fields|Fields Common to All Record Types]] for more on the record name (NAME) and description (DESC) fields.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>EGU<TD>Engineering Units<TD>STRING [16]<TD>Yes<TD>null<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>HOPR<TD>High Operating Range<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>LOPR<TD>Low Operating Range<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>PREC<TD>Display Precision<TD>SHORT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>NAME<TD>Record Name<TD>STRING [29]<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>DESC<TD>Description<TD>STRING [29]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Alarm Parameters ===

The possible alarm conditions for analog outputs are the SCAN, READ, INVALID and limit alarms. The SCAN, READ, and INVALID alarms are called by the record or device support routines.

The limit alarms are configured by the user in the HIHI, LOLO, HIGH, and LOW fields, which must be floating-point values. For each of these fields, there is a corresponding severity field which can be either NO_ALARM, MINOR, or MAJOR.

See [[RRM 3-14 Concepts#Alarm Specification|Alarm Specification]] for a complete explanation of alarms and these fields. See [[RRM 3-14 Common#Invalid Alarm Output Action|Invalid Alarm Output Action]] for more information on the IVOA and IVOV fields. [[RRM 3-14 dbCommon#Alarm Fields|Alarm Fields]] lists other fields related to a alarms that are common to all record types.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify
<TH>Rec Proc Monitor<TH>PP<TR>
<TD>HIHI<TD>Hihi Alarm Limit<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HIGH<TD>High Alarm Limit<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LOW<TD>Low Alarm Limit<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LOLO<TD>Lolo Alarm Limit<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HHSV<TD>Hihi Alarm Severity<TD>[[RRM 3-14 Menu Choices#menuAlarmSevr|menuAlarmSevr]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HSV<TD>High Alarm Severity<TD>[[RRM 3-14 Menu Choices#menuAlarmSevr|menuAlarmSevr]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LSV<TD>Low Alarm Severity<TD>[[RRM 3-14 Menu Choices#menuAlarmSevr|menuAlarmSevr]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LLSV<TD>Lolo Alarm Severity<TD>[[RRM 3-14 Menu Choices#menuAlarmSevr|menuAlarmSevr]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HYST<TD>Alarm Deadband<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>IVOA<TD>Invalid Alarm Output Action<TD>[[RRM 3-14 Menu Choices#menuIvoa|menuIvoa]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>IVOV<TD>Invalid Alarm Output Value, in eng. units<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Monitor Parameters ===

These parameters are used to specify deadbands for monitors on the VAL field. The monitors are sent when the value field exceeds the last monitored field by the specified deadband. If these fields have a value of zero, everytime the value changes, a monitor will be triggered; if they have a value of -1, everytime the record is processed, monitors are triggered. ADEL is the deadband for archive monitors, and MDEL the deadband for all other types of monitors. See [[RRM 3-14 Concepts#Monitor Specification|Monitor Specification]] for a complete explanation of monitors.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify
<TH>Rec Proc Monitor<TH>PP<TR>
<TD>ADEL<TD>Archive Deadband<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>MDEL<TD>Monitor, i.e. value change, Deadband<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Run-Time Parameters and Simulation Mode Parameters ===

These parameters are used by the run-time code for processing the analog output. They are not configurable. They represent the current state of the record. The record support routines use some of them for more efficient processing.

The ORAW field is used to decide if monitors should be triggered for RVAL when monitors are triggered for VAL. The RBV field is the actual read back value obtained from the hardware itself or from the associated device driver. It is the responsibility of the device support routine to give this field a value.

ORBV is used to decide if monitors should be triggered for RBV at the same time monitors are triggered for changes in VAL.

The LALM, MLST, and ALST fields are used to implement the hysteresis factors for monitor callbacks.

The INIT field is used to initialize the LBRK field and for smoothing.

The PBRK field contains a pointer to the current breakpoint table (if any), and LBRK contains a pointer to the last breakpoint table used.

The OMOD field indicates whether OVAL differs from VAL. It will be different if VAL or OVAL have changed since the last time the record was processed, or if VAL has been adjusted by OROC during the current processing.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify
<TH>Rec Proc Monitor<TH>PP<TR>
<TD>ORAW<TD>Old Raw Value<TD>LONG<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>RBV<TD>Read Back Value<TD>LONG<TD>No<TD>0<TD>Yes<TD>No<TD>Yes<TD>No<TR>
<TD>ORBV<TD>Old read back value<TD>LONG<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LALM<TD>Last Alarm Monitor Trigger Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>ALST<TD>Last Archiver Monitor Trigger Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>MLST<TD>Last Value Change Monitor Trigger Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INIT<TD>Initialize<TD>SHORT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>PBRK<TD>Address of Breakpoint Table<TD>NOACCESS<TD>No<TD>4<TD>No<TD>No<TD>No<TD> <TR>
<TD>LBRK<TD>Last Breakpoint<TD>SHORT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>PVAL<TD>Previous Data Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>OMOD<TD>OVAL modified?<TD>LONG<TD>No<TD>Null<TD>Yes<TD>No<TD>No<TD>No
</TABLE>

The following fields are used to operate the analog output in the simulation mode. See [[RRM 3-14 Common#Simulation Mode 2|Fields Common to Many Record Types]] for more information on these fields.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify
<TH>Rec Proc Monitor<TH>PP<TR>
<TD>SIOL<TD>Simulation Value Location<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>SIML<TD>Simulation Mode Location<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>SIMM<TD>Simulation Mode<TD>[[RRM 3-14 Menu Choices#menuSimm|menuSimm]]<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>SIMS<TD>Simulation Mode Alarm Severity<TD>[[RRM 3-14 Menu Choices#menuAlarmSevr|menuAlarmSevr]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No</TABLE>

== Record Support ==

=== Record Support Routines ===

The following are the record support routines that would be of interest to an application developer. Other routines are the get_units, get_precision, get_graphic_double, and get_control_double routines.

==== init_record ====

This routine initializes SIMM if SIML is a constant or creates a channel access link if SIML is PV_LINK. If SIOL is PV_LINK a channel access link is created.

This routine next checks to see that device support is available. If DOL is a constant, then VAL is initialized with its value and UDF is set to FALSE.

The routine next checks to see if the device support write routine is defined. If either device support or the device support write routine does not exist, an error message is issued and processing is terminated.

For compatibility with old device supports that don't know EOFF, if both EOFF and ESLO have their default value, EOFF is set to EGUL.

If device support includes init_record, it is called.

INIT is set TRUE. This causes PBRK, LBRK, and smoothing to be re-initialized. If "backwards" linear conversion is requested, then VAL is computed from RVAL using the algorithm:

VAL = ((RVAL+ROFF) * ASLO + AOFF) * ESLO + EOFF

and UDF is set to FALSE.

For breakpoint conversion, a call is made to cvtEngToRawBpt and UDF is then set to FALSE. PVAL is set to VAL.

==== process ====

See next section.

==== special ====

The only special processing for analog output records is SPC_LINCONV which is invoked whenever either of the fields LINR, EGUF, EGUL or ROFF is changed If the device support routine special_linconv exists it is called.

INIT is set TRUE. This causes PBRK, LBRK, and smoothing to be re-initialized.

==== get_value ====

Fills in the values of struct valueDes so that they refer to VAL.

==== get_alarm_double ====

Sets the following values:

upper_alarm_limit = HIHI
upper_warning_limit = HIGH
lower_warning_limit = LOW
lower_alarm_limit = LOLO

=== Record Processing ===

Routine process implements the following algorithm:

# Check to see that the appropriate device support module exists. If it doesn't, an error message is issued and processing is terminated with the PACT field set to TRUE. This ensures that processes will no longer be called for this record. Thus error storms will not occur.
# Check PACT: If PACT is FALSE call fetch_values and convert which perform the following steps:
#* fetch_values:
#** if DOL is DB_LINK and OMSL is CLOSED_LOOP then get value from DOL
#** if OIF is INCREMENTAL then set value = value + VAL else value = VAL
#* convert:
#** If Drive limits are defined force value to be within limits
#** Set VAL equal to value
#** Set UDF to FALSE.
#** If OVAL is undefined set it equal to value
#** If OROC is defined and not 0 make |value-OVAL| <=OROC
#** Set OVAL equal to value
#** Compute RVAL from OVAL. using linear or break point table conversion. For linear conversions the algorithm is RVAL = (OVAL-EOFF)/ESLO.
#** For break point table conversion a call is made to cvtEngToRawBpt.
#** After that, for all conversion types AOFF, ASLO, and ROFF are calculated in, using the formula RVAL = (RVAL -AOFF) / ASLO - ROFF.
# Check alarms: This routine checks to see if the new VAL causes the alarm status and severity to change. If so, NSEV, NSTA and y are set. It also honors the alarm hysteresis factor (HYST). Thus the value must change by at least HYST before the alarm status and severity is reduced.
# Check severity and write the new value. See [[RRM 3-14 Common#Invalid Alarm Output Action|Invalid Alarm Output Action]] for details on how invalid alarms affect output records.
# If PACT has been changed to TRUE, the device support write output routine has started but has not completed writing the new value. In this case, the processing routine merely returns, leaving PACT TRUE.
# Check to see if monitors should be invoked:
#* Alarm monitors are invoked if the alarm status or severity has changed.
#* Archive and value change monitors are invoked if ADEL and MDEL conditions are met.
#* Monitors for RVAL and for RBV are checked whenever other monitors are invoked.
#* NSEV and NSTA are reset to 0.
# Scan forward link if necessary, set PACT and INIT FALSE, and return.

== Device Support ==

=== Fields Of Interest To Device Support ===

Each analog output record must have an associated set of device support routines. The primary responsibility of the device support routines is to output a new value whenever write_ao is called. The device support routines are primarily interested in the following fields:

<TABLE BORDER="1">
<TH>Name<TH>Summary<TH>Description<TR>
<TD>PACT<TD>Processing Active<TD rowspan=4>See [[RRM 3-14 dbCommon|Fields Common to All Record Types]] for an explanation of these fields.<TR>
<TD>DPVT<TD>Device Private<TR>
<TD>NSEV<TD>New Alarm Severity<TR>
<TD>NSTA<TD>New Alarm Status<TR>
<TD>OUT<TD>Output Link<TD>This field is used by the device support routines to locate its output.<TR>
<TD>EGUF<TD>Engineering Units Full<TD rowspan=2>These fields are used to calculate ESLO. Note that these fields correspond to the high and low hardware limits.<TR>
<TD>EGUL<TD>Engineering Unit Low<TR>
<TD>ESLO<TD>Slope<TD rowspan=2>These fields are used for linear conversions from raw to engineering units. The device support routines must calculate these fields unless they obtain values already in engineering units.<TR>
<TD>EOFF<TD>Offset<TR>
<TD>RVAL<TD>Raw Value<TD>This is the value to write to OUT.
</TABLE>

=== Device Support routines ===

Device support consists of the following routines:

==== init ====

init()

This routine is called once during IOC initialization.

==== init_record ====

init_record(precord)

This routine is optional. If provided, it is called by the record support init_record routine. It returns a zero for success or a 2 for success, don't convert. To support linear conversion, EOFF and ESLO should be set to their proper values (see special_linconv below).

==== get_ioint_info ====

get_ioint_info(int cmd,struct dbCommon *precord,IOSCANPVT *ppvt)

This routine is called by the ioEventScan system each time the record is added or deleted from an I/O event scan list. cmd has the value (0,1) if the record is being (added to, deleted from) an I/O event list. It must be provided for any device type that can use the ioEvent scanner.

==== write_ao ====

write_ao(precord)

This routine must output a new value. Asynchronous device support routines will return with PACT set to TRUE. If PACT is TRUE, the process routine will just return and not continue processing. When the asynchronous routine completes, it can call process which will again call write_ao. When finished, write_ao should set PACT to FALSE and return one the following values:

: 0: Success.
: other: Error.

==== special_linconv ====

special_linconv(precord,after)

This routine is called whenever either of the fields LINR, EGUF or EGUL is modified. To support LINEAR conversion, EOFF and ESLO must be set accordingly. The record support sets EOFF to EGUL before calling this routine which is a common situation when RAWL is zero below.

A useful formula for calculating EOFF and ESLO is this one:

EOFF = (RAWF * EGUL - RAWL * EGUF) / (RAWF - RAWL)
ESLO = (EGUF - EGUL) / (RAWF - RAWL)

Here, RAWL and RAWF are the lowest resp. highest possible raw value. For instance, a 16 bit bipolar DAC might have RAWL=-0x7fff, RAWF=0x7fff.

=== Device Support For Soft Records ===

Two soft device support modules Soft Channel and Raw Soft Channel are provided for output records not related to actual hardware devices. The OUT link type must be either a CONSTANT, DB_LINK, or CA_LINK.

==== Soft Channel ====

This module writes the current value of OVAL.

If the OUT link type is PV_LINK, then dbCaAddInlink is called by init_record. init_record always returns a value of 2, which means that no conversion will ever be attempted.

write_ao calls recGblPutLinkValue to write the current value of VAL. See [[RRM 3-14 Common#Soft Output|Soft Output]] for details.

==== Raw Soft Channel ====

This module is like the previous except that it writes the current value of RVAL.

RRM 3-14 Editing Tasks

2012-10-18T21:17:17Z

LewisMuir: /* Record Documentation/Distribution Anomalies */ Add missing "Async Soft Channel" device support documentation

== To Do List ==

The purpose of this list is to bring the existing R3.14 Record Reference Manual up to match the current R3.14.9 implementation.

* Read [[RRM 3-14 Concepts|Database Concepts]] and revise as necessary.
** Maybe replace the existing CapFast diagrams with VDCT equivalents.
* For [[RRM 3-14 dbCommon|Fields Common to All Record Types]] update the field tables and descriptions according to how dbCommon has changed.
* Check [[RRM 3-14 Common|Fields Common to Many Record Types]] for typical changes made across all record types.
* For each existing record chapter we need to update its for
** Changes to individual fields
** Changes made to the record processing description
** Fix shortcomings of the existing text, e.g.
*** Missing sections
*** Device support report() function prototypes
* For [[RRM 3-14 Menu Choices|Menu Choices]] check and update the list of menus and choices in each.

=== Record Documentation/Distribution Anomalies ===

These records have "Async Soft Channel" device support but do not document this:

* Analog Output
* Binary Output
* Calculation Output
* Long Output
* Multi-Bit Binary Output
* Multi-Bit Binary Output Direct
* String Output

These records are documented here but not present in any distribution of EPICS Base:

* Archive
* CPID

These records are not documented here, but are present in both the R3.13.10 and R3.14.x distributions:

* Analog Array Input
* Analog Array Output

These records are neither documented here nor present in any distribution of Base, but being commonly used they are candidates for possible inclusion in the documentation:

* Enhanced PID
* genSub
* Motor
* Transform
* Table
* waveformAnalysis
* ... other ...

Don't add pages for these obsolete records, which were present in the R3.13.10 distribution but removed in R3.14.x:

* Event Generator Event
* Event Generator
* Event Receiver Event
* Event Receiver
* GSub (not Andy Foster's genSub)
* recDynLink
* recWaitCa

RRM 3-14

2012-10-18T20:25:26Z

LewisMuir: /* EPICS 3-14 Record Reference Manual */ Alphabetically order aai and aao record types

<H2 style="color:#C00000">Help Needed!</H2>

This documentation has been revised since the older 3-13 version, but the software has been updated significantly since the docs were written so there may still be a number of inaccuracies here. The [[RRM 3-14 Editing Tasks|Editing Tasks]] page gives some ideas on what else might need doing.

== EPICS 3-14 Record Reference Manual ==

Philip Stanley, Janet Anderson, Marty Kraimer

Wikified by Andrew Johnson and Kazimierz Gofron

* [[RRM 3-14 Copyright|Copyright]]
* [[RRM 3-14 Preface|Preface]]

* [[RRM 3-14 Concepts|Database Concepts]]
* [[RRM 3-14 dbCommon|Fields Common to All Record Types]]
* [[RRM 3-14 Common|Fields Common to Many Record Types]]

* [[RRM 3-14 Array Analog Input|aai - Array Analog Input]]
* [[RRM 3-14 Array Analog Output|aao - Array Analog Output]]
* [[RRM 3-14 Analog Input|ai - Analog Input]]
* [[RRM 3-14 Analog Output|ao - Analog Output]]
* [[RRM 3-14 Array Subroutine|aSub - Array Subroutine]]
* [[RRM 3-14 Binary Input|bi - Binary Input]]
* [[RRM 3-14 Binary Output|bo - Binary Output]]
* [[RRM 3-14 Calculation|calc - Calculation]]
* [[RRM 3-14 Calcout|calcout - Calculation Output]]
* [[RRM 3-14 Compression|compress - Compression]]
* [[RRM 3-14 Data Fanout|dfanout - Data Fanout]]
* [[RRM 3-14 Event|event - Event]]
* [[RRM 3-14 Fanout|fanout - Fanout]]
* [[RRM 3-14 Histogram|histogram - Histogram]]
* [[RRM 3-14 Long Input|longin - Long Input]]
* [[RRM 3-14 Long Output|longout - Long Output]]
* [[RRM 3-14 Multi-Bit Binary Input|mbbi - Multi-Bit Binary Input]]
* [[RRM 3-14 Multi-Bit Binary Input Direct|mbbiDirect - Multi-Bit Binary Input Direct]]
* [[RRM 3-14 Multi-Bit Binary Output|mbbo - Multi-Bit Binary Output]]
* [[RRM 3-14 Multi-Bit Binary Output Direct|mbboDirect - Multi-Bit Binary Output Direct]]
* [[RRM 3-14 Permissive|permissive - Permissive]]
* [[RRM 3-14 Select|sel - Select]]
* [[RRM 3-14 Sequence|seq - Sequence]]
* [[RRM 3-14 State|state - State]]
* [[RRM 3-14 String Input|stringin - String Input]]
* [[RRM 3-14 String Output|stringout - String Output]]
* [[RRM 3-14 SubArray|subArray - Sub-Array]]
* [[RRM 3-14 Subroutine|sub - Subroutine]]
* [[RRM 3-14 Waveform|waveform - Waveform]]

* [[RRM 3-14 Menu Choices|Appendix: Menu Choices]]

----

=== Record Types Not in Base ===

* [[RRM 3-14 Archive|archive - Archive]]
* [[RRM 3-14 CPID Control|cpid - CPID Control]]
* [[RRM 3-14 PID Control|pid - PID Control]]
* [[RRM 3-14 Pulse Counter|pulseCounter - Pulse Counter]]
* [[RRM 3-14 Pulse Delay|pulseDelay - Pulse Delay]]
* [[RRM 3-14 Pulse Train|pulseTrain - Pulse Train]]
* [[RRM 3-14 Scan|scan - Scan]]
* [[RRM 3-14 Stepper Motor|steppermotor - Stepper Motor]]
* [[RRM 3-14 Timer|timer - Timer]]
* [[RRM 3-14 Wait|wait - Wait]]

RRM 3-14 Array Analog Output

2012-10-18T20:17:59Z

LewisMuir: Create stub page for aao record type

[[RRM 3-14|EPICS Record Reference Manual]]

= aao - Array Analog Output =

This record type is currently undocumented. Please help write it.

RRM 3-14 Array Analog Input

2012-10-18T20:16:52Z

LewisMuir: Create stub page for aai record type

[[RRM 3-14|EPICS Record Reference Manual]]

= aai - Array Analog Input =

This record type is currently undocumented. Please help write it.

RRM 3-14

2012-10-18T20:09:55Z

LewisMuir: /* EPICS 3-14 Record Reference Manual */ Add stubs for aai and aao record types

<H2 style="color:#C00000">Help Needed!</H2>

This documentation has been revised since the older 3-13 version, but the software has been updated significantly since the docs were written so there may still be a number of inaccuracies here. The [[RRM 3-14 Editing Tasks|Editing Tasks]] page gives some ideas on what else might need doing.

== EPICS 3-14 Record Reference Manual ==

Philip Stanley, Janet Anderson, Marty Kraimer

Wikified by Andrew Johnson and Kazimierz Gofron

* [[RRM 3-14 Copyright|Copyright]]
* [[RRM 3-14 Preface|Preface]]

* [[RRM 3-14 Concepts|Database Concepts]]
* [[RRM 3-14 dbCommon|Fields Common to All Record Types]]
* [[RRM 3-14 Common|Fields Common to Many Record Types]]

* [[RRM 3-14 Analog Input|ai - Analog Input]]
* [[RRM 3-14 Analog Output|ao - Analog Output]]
* [[RRM 3-14 Array Analog Input|aai - Array Analog Input]]
* [[RRM 3-14 Array Analog Output|aao - Array Analog Output]]
* [[RRM 3-14 Array Subroutine|aSub - Array Subroutine]]
* [[RRM 3-14 Binary Input|bi - Binary Input]]
* [[RRM 3-14 Binary Output|bo - Binary Output]]
* [[RRM 3-14 Calculation|calc - Calculation]]
* [[RRM 3-14 Calcout|calcout - Calculation Output]]
* [[RRM 3-14 Compression|compress - Compression]]
* [[RRM 3-14 Data Fanout|dfanout - Data Fanout]]
* [[RRM 3-14 Event|event - Event]]
* [[RRM 3-14 Fanout|fanout - Fanout]]
* [[RRM 3-14 Histogram|histogram - Histogram]]
* [[RRM 3-14 Long Input|longin - Long Input]]
* [[RRM 3-14 Long Output|longout - Long Output]]
* [[RRM 3-14 Multi-Bit Binary Input|mbbi - Multi-Bit Binary Input]]
* [[RRM 3-14 Multi-Bit Binary Input Direct|mbbiDirect - Multi-Bit Binary Input Direct]]
* [[RRM 3-14 Multi-Bit Binary Output|mbbo - Multi-Bit Binary Output]]
* [[RRM 3-14 Multi-Bit Binary Output Direct|mbboDirect - Multi-Bit Binary Output Direct]]
* [[RRM 3-14 Permissive|permissive - Permissive]]
* [[RRM 3-14 Select|sel - Select]]
* [[RRM 3-14 Sequence|seq - Sequence]]
* [[RRM 3-14 State|state - State]]
* [[RRM 3-14 String Input|stringin - String Input]]
* [[RRM 3-14 String Output|stringout - String Output]]
* [[RRM 3-14 SubArray|subArray - Sub-Array]]
* [[RRM 3-14 Subroutine|sub - Subroutine]]
* [[RRM 3-14 Waveform|waveform - Waveform]]

* [[RRM 3-14 Menu Choices|Appendix: Menu Choices]]

----

=== Record Types Not in Base ===

* [[RRM 3-14 Archive|archive - Archive]]
* [[RRM 3-14 CPID Control|cpid - CPID Control]]
* [[RRM 3-14 PID Control|pid - PID Control]]
* [[RRM 3-14 Pulse Counter|pulseCounter - Pulse Counter]]
* [[RRM 3-14 Pulse Delay|pulseDelay - Pulse Delay]]
* [[RRM 3-14 Pulse Train|pulseTrain - Pulse Train]]
* [[RRM 3-14 Scan|scan - Scan]]
* [[RRM 3-14 Stepper Motor|steppermotor - Stepper Motor]]
* [[RRM 3-14 Timer|timer - Timer]]
* [[RRM 3-14 Wait|wait - Wait]]

RRM 3-14 Array Subroutine

2012-10-18T19:48:02Z

LewisMuir: Correct border attribute on tables

[[RRM 3-14|EPICS Record Reference Manual]]

= aSub - Array Subroutine =

The aSub record is a variant of the 'sub' (subroutine) record with array or scalar
input and output fields, whose types are user specifiable at database-configure time, and associated input and output links.

The routine to be called at process time can be changed dynamically after the database has been loaded.
The name of the routine can either be fetched in over a link from another record or written directly into
the SNAM field.

The user can configure the record to decide when events will be posted for the output fields. This can be:
Never, Always or just when any element of an array changes value.

The VAL field holds the value returned from the routine called during record processing, which is a status value that controls whether the output links are used or not.

== Field Summary ==
<table border="1">
<th>Field<th>Type<th>DCT<th>Initial<th>Access<th>Modify<th>Rec Proc Monitor<th>PP
<tr><td>VAL<td>LONG<td>No<td>0<td>Yes<td>Yes<td>Yes<td>No
<tr><td>OVAL<td>LONG<td>No<td>0<td>Yes<td>Yes<td>No<td>No
<tr><td>LFLG<td>MENU(IGNORE, READ)<td>Yes<td>IGNORE<td>Yes<td>Yes<td>No<td>No
<tr><td>EFLG<td>MENU(NEVER, ON CHANGE, ALWAYS)<td>Yes<td>ALWAYS<td>Yes<td>Yes<td>No<td>No
<tr><td>SUBL<td>INLINK<td>Yes<td>0<td>No<td>No<td>NA<td>No
<tr><td>INAM<td>STRING<td>Yes<td>Null<td>Yes<td>No<td>No<td>No
<tr><td>SNAM<td>STRING<td>Yes<td>Null<td>Yes<td>Yes<td>No<td>No
<tr><td>ONAM<td>STRING<td>Yes<td>Null<td>Yes<td>No<td>No<td>No
<tr><td>SADR<td>LONG<td>No<td>0<td>Yes<td>No<td>Yes<td>No
<tr><td>BRSV<td>MENU<td>Yes<td>0<td>Yes<td>Yes<td>No<td>Yes
<tr><td>PREC<td>SHORT<td>Yes<td>0<td>Yes<td>Yes<td>No<td>No
<tr><td><td><td><td><td><td><td><td>
<tr><td>INPA<td>INLINK<td>Yes<td>0<td>No<td>No<td>NA<td>No
<tr><td>INPB<td>INLINK<td>Yes<td>0<td>No<td>No<td>NA<td>No
<tr><td>...<td>...<td>...<td>...<td>...<td>...<td>...<td>...
<tr><td>INPU<td>INLINK<td>Yes<td>0<td>No<td>No<td>NA<td>No
<tr><td><td><td><td><td><td><td><td>
<tr><td>A<td>NOACCESS<td>No<td>0<td>No<td>Yes<td>No<td>No
<tr><td>B<td>NOACCESS<td>No<td>0<td>No<td>Yes<td>No<td>No
<tr><td>...<td>...<td>...<td>...<td>...<td>...<td>...<td>...
<tr><td>U<td>NOACCESS<td>No<td>0<td>No<td>Yes<td>No<td>No
<tr><td><td><td><td><td><td><td><td>
<tr><td>FTA<td>MENU<td>Yes<td>DOUBLE<td>Yes<td>No<td>No<td>No
<tr><td>FTB<td>MENU<td>Yes<td>DOUBLE<td>Yes<td>No<td>No<td>No
<tr><td>...<td>...<td>...<td>...<td>...<td>...<td>...<td>...
<tr><td>FTU<td>MENU<td>Yes<td>DOUBLE<td>Yes<td>No<td>No<td>No
<tr><td><td><td><td><td><td><td><td>
<tr><td>NOA<td>ULONG<td>Yes<td>1<td>Yes<td>No<td>No<td>No
<tr><td>NOB<td>ULONG<td>Yes<td>1<td>Yes<td>No<td>No<td>No
<tr><td>...<td>...<td>...<td>...<td>...<td>...<td>...<td>...
<tr><td>NOU<td>ULONG<td>Yes<td>1<td>Yes<td>No<td>No<td>No
<tr><td><td><td><td><td><td><td><td>
<tr><td>NEA<td>ULONG<td>Yes<td>1<td>Yes<td>No<td>No<td>No
<tr><td>NEB<td>ULONG<td>Yes<td>1<td>Yes<td>No<td>No<td>No
<tr><td>...<td>...<td>...<td>...<td>...<td>...<td>...<td>...
<tr><td>NEU<td>ULONG<td>Yes<td>1<td>Yes<td>No<td>No<td>No
<tr><td><td><td><td><td><td><td><td>
<tr><td>OUTA<td>OUTLINK<td>Yes<td>0<td>No<td>No<td>NA<td>No
<tr><td>OUTB<td>OUTLINK<td>Yes<td>0<td>No<td>No<td>NA<td>No
<tr><td>...<td>...<td>...<td>...<td>...<td>...<td>...<td>...
<tr><td>OUTU<td>OUTLINK<td>Yes<td>0<td>No<td>No<td>NA<td>No
<tr><td><td><td><td><td><td><td><td>
<tr><td>VALA<td>NOACCESS<td>No<td>0<td>No<td>Yes<td>Yes<td>No
<tr><td>VALB<td>NOACCESS<td>No<td>0<td>No<td>Yes<td>Yes<td>No
<tr><td>...<td>...<td>...<td>...<td>...<td>...<td>...<td>...
<tr><td>VALU<td>NOACCESS<td>No<td>0<td>No<td>Yes<td>Yes<td>No
<tr><td><td><td><td><td><td><td><td>
<tr><td>OVLA<td>NOACCESS<td>No<td>0<td>No<td>No<td>No<td>No
<tr><td>OVLB<td>NOACCESS<td>No<td>0<td>No<td>No<td>No<td>No
<tr><td>...<td>...<td>...<td>...<td>...<td>...<td>...<td>...
<tr><td>OVLU<td>NOACCESS<td>No<td>0<td>No<td>No<td>No<td>No
<tr><td><td><td><td><td><td><td><td>
<tr><td>FTVA<td>MENU<td>Yes<td>DOUBLE<td>Yes<td>No<td>No<td>No
<tr><td>FTVB<td>MENU<td>Yes<td>DOUBLE<td>Yes<td>No<td>No<td>No
<tr><td>...<td>...<td>...<td>...<td>...<td>...<td>...<td>...
<tr><td>FTVU<td>MENU<td>Yes<td>DOUBLE<td>Yes<td>No<td>No<td>No
<tr><td><td><td><td><td><td><td><td>
<tr><td>NOVA<td>ULONG<td>Yes<td>1<td>Yes<td>No<td>No<td>No
<tr><td>NOVB<td>ULONG<td>Yes<td>1<td>Yes<td>No<td>No<td>No
<tr><td>...<td>...<td>...<td>...<td>...<td>...<td>...<td>...
<tr><td>NOVU<td>ULONG<td>Yes<td>1<td>Yes<td>No<td>No<td>No
<tr><td><td><td><td><td><td><td><td>
<tr><td>NEVA<td>ULONG<td>Yes<td>1<td>Yes<td>No<td>No<td>No
<tr><td>NEVB<td>ULONG<td>Yes<td>1<td>Yes<td>No<td>No<td>No
<tr><td>...<td>...<td>...<td>...<td>...<td>...<td>...<td>...
<tr><td>NEVU<td>ULONG<td>Yes<td>1<td>Yes<td>No<td>No<td>No
</table>

== Field Descriptions ==

<table border="1">
<th>Name<th>Summary<th>Description

<tr><td>VAL<td>Value returned from process routine<td>This field holds the value returned from the user defined process routine, which must be zero for the output links OUTA...OUTU to be processed.

<tr><td>OVAL<td>Old VAL<td>Previous VAL, used to decide when to post events.

<tr><td>LFLG<td>Link Flag<td>Tells the record whether to read or ignore the SUBL link. If the value is READ, then the name of the subroutine to be called at process time is read from SUBL. If the value is IGNORE, the name of the subroutine is that currently held in SNAM.

<tr><td>EFLG<td>Event Flag<td>Tells the record when to post change events on the output fields VALA,...,VALU. If the value is NEVER, events are never posted. If the value is ALWAYS, events are posted everytime the record processes. If the value is ON CHANGE, events are posted when any element of an array changes value. This flag controls value, log (archive) and alarm change events.

<tr><td>SUBL<td>Subroutine Link<td>Where to get the subroutine name from.

<tr><td>INAM<td>Initialisation Routine <td>This is the name of the initialisation routine to be called once,
at iocInit.

<tr><td>SNAM<td>Process Routine<td>This is the name of the routine to be called when the record processes. Note, this can be overwritten by the SUBL link, if
LFLG is set to READ.

<tr><td>ONAM<td>Process Routine<td>Old process subroutine name.

<tr><td>SADR<td>Subroutine Address <td>The address of the routine called at process time.

<tr><td>BRSV<td>Severity for a subroutine return value less than 0. <td>Specifies the Alarm severity.

<tr><td>PREC<td>Display Precision <td>Specifies the number of decimal places with which to display the values of the fields VALA,...,VALU.

<tr><td>INPA,..., INPU<td>Input Link A,..., Input Link U
<td>The input links from where the values of A,...,U are fetched
during record processing.

<tr><td>A,...,U<td>Input Fields
<td>The input fields which hold the scalar values or arrays fetched
in across the input links INPA,...,INPU.

<tr><td>FTA,..., FTU<td>Field Type of A Field Type of U
<td>Field types of the input values. These can be any of the following:
"STRING","CHAR","UCHAR","SHORT","USHORT","LONG","ULONG","FLOAT","DOUBLE, "ENUM".

<tr><td>NOA..., NOU<td>Max elements in A,.. Max elements in U
<td>The number of elements of storage allocated for each input field. Default is 1 (scalar value). An array is specified by setting this field to greater than 1.

<tr><td>NEA..., NEU<td>Number of elements in A,.. Number of elements in U
<td>The current number of elements stored in each input field. Field contains an array if this field is greater than 1.

<tr><td>OUTA,..., OUTU<td>Output Link A,.. Output Link U
<td>The output links on which the scalars or arrays located at VALA,...,VALU are placed during record processing.

<tr><td>VALA,.., VALU<td>Output Fields
<td>The output fields which hold the scalar values or arrays
pushed out across the output links OUTA,...,OUTU.

<tr><td>FTVA,..., FTVU<td>Field Type of VALA Field Type of VALU
<td>Field types of the output values. These can be CHAR,
STRING, DOUBLE, LONG, etc.

<tr><td>OVLA,.., OVLU<td>Previous Outputs
<td>The previous values of the outputs. These are used to decide
when to post events if EFLG is set to ON CHANGE.

<tr><td>NOVA,..., NOVU<td>Max elements in VALA,.. Max elements in VALU
<td>The number of elements of storage allocated for each output field. Default is 1 (scalar value). An array is specified by setting this field to greater than 1.

<tr><td>NEVA,..., NEVU<td>Number of elements in VALA,.. Number of elements in VALU
<td>The current number of elements stored in each output field. Field contains an array if this field is greater than 1.

</table>

== Record Support Routines ==
=== init_record ===

This routine is called twice at iocInit. On the first call it does the
following:

* Calloc sufficient space to hold the number of input scalars and/or arrays defined by the settings of the fields FTA-FTU and NOA-NOU. Initialize fields NE* to the values of the associated NO* field values.
* Calloc sufficient space to hold the number of output scalars and/or arrays defined by the settings of the fields FTVA-FTVU and NOVA-NOVU. For the output fields, also calloc space to hold the previous value of a field. This is required when the decision is made on whether or not to post events.

On the second call, it does the following:

* Initializes SUBL if it is a constant link.
* Initializes each constant input link.
* If the field INAM is set, look-up the address of the routine and call it.
* If the field LFLG is set to IGNORE and SNAM is defined, look-up the address of the process routine.

=== process ===
This routine implements the following algorithm:

* If PACT is FALSE, perform normal processing
* If PACT is TRUE, perform asynchronous-completion processing

Normal processing:

* Set PACT to TRUE.
* If the field LFLG is set to READ, get the subroutine name from the SUBL link. If the name is not NULL and it is not the same as the previous subroutine name, lookup the subroutine address. Set the old subroutine name, ONAM, equal to the current name, SNAM.
* Fetch the values from the input links.
* Set PACT to FALSE
* If all input-link fetches succeeded, call the routine specified by SNAM.
* Set VAL equal to the return value from the routine specified by SNAM.
* If the SNAM routine set PACT to TRUE, then return. In this case, we presume the routine has arranged that process will be called at some later time for asynchronous completion.
* Set PACT to TRUE.
* If VAL is zero, write the output values using the output links.
* Get the time of processing and put it into the timestamp field.
* If VAL has changed, post a change-of value and log event for this field. If EFLG is set to ALWAYS, post change-of-value and log events for every output field. If EFLG is set to ON CHANGE, post change-of-value and log events for every output field which has changed. In the case of an array, an event will be posted if any single element of the array has changed. If EFLG is set to NEVER, no change-of-value or log events are posted for the output fields.
* Process the record on the end of the forward link, if one exists.
* Set PACT to FALSE.

Asynchronous-completion processing:

* Call the routine specified by SNAM (again).
* Set VAL equal to the return value from the routine specified by SNAM.
* Set PACT to TRUE.
* If VAL is zero, write the output values using the output links.
* Get the time of processing and put it into the timestamp field.
* If VAL has changed, post a change-of value and log event for this field. If EFLG is set to ALWAYS, post change-of-value and log events for every output field. If EFLG is set to ON CHANGE, post change-of-value and log events for every output field which has changed. In the case of an array, an event will be posted if any single element of the array has changed. If EFLG is set to NEVER, no change-of-value or log events are posted for the output fields.
* Process the record on the end of the forward link, if one exists.
* Set PACT to FALSE.

=== get_precision ===

Sets the display precision to the value of PREC for any of the output fields
VALA,..., VALU. This routine could be called for any of these fields.

=== cvt_dbaddr ===

The purpose of this routine is to fill in the struct dbAddr for the field of the
record for which it has been called. Typically, the number of elements in the
field, the field type and the size of the field will be set in this routine.
For arrays, this record support routine is essential.

=== get_array_info ===

This routine returns the current number of elements and the offset of the first
value for an array. For this record, the offset field is always 0.

=== put_array_info ===

This routine is called after new values have been placed in an array.

=== special ===

This routine is called whenever the SNAM field changes. It is called twice, once
before the change and once after. On the first call, the routine simply
returns. On the second call, after SNAM has changed, it implements the
following algorithm:

* If LFLG is set to IGNORE and SNAM is not NULL, then look-up the address of the routine specified by SNAM. Set the SADR field equal to the subroutine address.
* Post change-of-value and log events for the SADR field, if this has changed.

== Use of the aSub Record ==

The aSub record has input-value fields (A-U) and output-value fields (VALA-VALU), which are completely independent. The input-value fields have associated input links (INPA-INPU), and the output-value fields have associated output links (OUTA-OUTU). Both inputs and outputs have type fields (FTA-FTU, FTVA-FTVU, which default to 'DOUBLE') and number-of-element fields (NOA-NOU, NOVA-NOVU, which default to '1'). The output links OUTA-OUTU will only be processed if the subroutine returns a zero (OK) status value.

=== Example database fragment ===

To use the A field to read an array from some other record, then, you would need a database fragment that might look something like this:

record(aSub,"my_asub_record") {
field(SNAM,"my_asub_routine")
...
field(FTA, "LONG")
field(NOA, "100")
field(INPA, "myWaveform_1 NPP NMS")
...
}

If you wanted some other record to be able to write to the A field, then you would delete the input link above. If you wanted the A field to hold a scalar value, you would either delete the NOA specification, or specify it as "1".

=== Example subroutine fragment ===

The associated subroutine code that uses the A field might look like this:

static long my_asub_routine(aSubRecord *prec) {
long i, *a;
double sum=0;
...
a = (long *)prec->a;
for (i=0; i<prec->noa; i++) {
sum += a[i];
}
...
return 0; /* process output links */
}

Note that the subroutine code must always handle the value fields (A-U, VALA-VALU) as arrays, even if they contain only a single element.

=== Required export code ===

Aside from your own code, you must export and register your subroutines so the record can locate them. The simplest way is as follows:

#include <registryFunction.h>
#include <epicsExport.h>

static long my_asub_routine(aSubRecord *prec) {
...
}
epicsRegisterFunction(my_asub_routine);

=== Required database-definition code ===

The .dbd file loaded by the ioc must then contain the following line, which tells the linker to include your object file in the IOC binary:

function(my_asub_routine)

=== Device support, writing to hardware ===

The aSub record does not call any device support routines. If you want to write to hardware, you might use your output fields and links to write to some other record that can write to hardware.

=== Dynamically Changing the User Routine called during Record Processing ===

The aSub record allows the user to dynamically change which routine is called when the record processes. This can be done in two ways:

* The LFLG field can be set to READ so that the name of the routine is read from the SUBL link. Thus, whatever is feeding this link can change the name of the routine before the aSub record is processed. In this case, the record looks in the symbol table for the symbol name whenever the name of routine fetched from the link changes.
* The LFLG field can be set to IGNORE. In this case, the routine called during record processing is that specified in the SNAM field. Under these conditions, the SNAM field can be changed by a Channel Access write to that field. During development when trying several versions of the routine, it is not necessary to reboot the IOC and reload the database. A new routine can be loaded with the vxWorks ld command, and Channel Access or the dbpf command used to put the name of the routine into the record's SNAM field. The record will look up the symbol name in the symbol table whenever the SNAM field gets modified. The same routine name can even be used as the vxWorks symbol lookup returns the latest version of the code to have been loaded.

RRM 3-14 Subroutine

2012-10-18T19:38:14Z

LewisMuir: /* Subroutine Connection */ Change INAM and SNAM length to 40

[[RRM 3-14|EPICS Record Reference Manual]]

= sub - Subroutine =

The subroutine record is used to call a C initialization routine and a recurring scan routine. There is no device support for this record.

== Parameter Fields ==

The fields fall into several categories:

* scan parameters
* read parameters
* subroutine connection parameters
* operator display parameters
* alarm parameters
* monitor parameters
* run-time parameters.

=== Scan Parameters ===

The subroutine record has the standard fields for specifying under what circumstances it will be processed. These fields are listed in [[RRM 3-14 dbCommon#Scan Fields|Scan Fields]]. In addition, [[RRM 3-14 Concepts#Scanning Specification|Scanning Specification]] explains how these fields are used.

=== Read Parameters ===

The subroutine record has twelve input links (INPA-INPL), each of which has a corresponding value field (A-L). These fields are used to retrieve and store values that can be passed to the subroutine that the record calls.

The input links can be either channel access or database links, or constants. When constants, the corresponding value field for the link is initialized with the constant value and the field's value can be changed at run-time via dbPuts. Otherwise, the values for (A-F) are fetched from the input links when the record is processed. See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on specifying links.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>INPA<TD>Input A<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>INPB<TD>Input B<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>INPC<TD>Input C<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>INPD<TD>Input D<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>INPE<TD>Input E<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>INPF<TD>Input F<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>INPG<TD>Input G<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>INPH<TD>Input H<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>INPI<TD>Input I<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>INPJ<TD>Input J<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>INPK<TD>Input K<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>INPL<TD>Input L<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>A<TD>A Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>B<TD>B Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>C<TD>C Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>D<TD>D Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>E<TD>E Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>F<TD>F Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>G<TD>G Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>H<TD>H Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>I<TD>I Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>J<TD>J Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>K<TD>K Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>L<TD>L Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes
</TABLE>

=== Subroutine Connection ===

These fields are used to connect to the C subroutine. The name of the subroutine should be entered in the SNAM field.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>INAM<TD>Initialization Name <TD>STRING [40]<TD>Yes<TD>Null<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>SNAM<TD>Subroutine Name<TD>STRING [40]<TD>Yes<TD>Null<TD>Yes<TD>No<TD>No<TD>No
</TABLE>

=== Operator Display Parameters ===

These parameters are used to present meaningful data to the operator. They display the value and other parameters of the subroutine either textually or graphically.

EGU is a string of up to 16 characters that could describe any units used by the subroutine record. It is retrieved by the <CODE>get_units</CODE> record support routine.

The HOPR and LOPR fields set the upper and lower display limits for the VAL, A-L, LA-LL, HIHI, LOLO, LOW, and HIGH fields. Both the <CODE>get_graphic_double</CODE> and <CODE>get_control_double</CODE> record support routines retrieve these fields.

The PREC field determines the floating point precision with which to display VAL. It is used whenever the <CODE>get_precision</CODE> record support routine is called.

See [[RRM 3-14 dbCommon#Fields Common to All Record Types|Fields Common to All Record Types]] for more on the record name (NAME) and description (DESC) fields.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>EGU<TD>Engineering Units<TD>STRING [16]<TD>Yes<TD>null<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>HOPR<TD>High Operating Range<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>LOPR<TD>Low Operating Range<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>PREC<TD>Display Precision<TD>SHORT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>NAME<TD>Record Name<TD>STRING [29]<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>DESC<TD>Description<TD>STRING [29]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Alarm Parameters ===

The possible alarm conditions for subroutine records are the SCAN, READ, limit alarms, and an alarm that can be triggered if the subroutine returns a negative value. The SCAN and READ alarms are called by the record or device support routines. The limit alarms are configured by the user in the HIHI, LOLO, HIGH, and LOW fields using numerical values. They apply to the VAL field. For each of these fields, there is a corresponding severity field which can be either NO_ALARM, MINOR, or MAJOR.

The BRSV field is where the user can set the alarm severity in case the subroutine returns a negative value. See [[RRM 3-14 Concepts#Alarm Specification|Alarm Specification]] for a complete explanation of alarms and these fields. [[RRM 3-14 dbCommon#Alarm Fields|Alarm Fields]] lists other fields related to a alarms that are common to all record types.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>HIHI<TD>Hihi Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HIGH<TD>High Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LOW<TD>Low Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LOLO<TD>Lolo Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HHSV<TD>Hihi Alarm Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HSV<TD>High Alarm Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LSV<TD>Low Alarm Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LLSV<TD>Lolo Alarm Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>BRSV<TD>Severity for a subroutine return value less than 0.<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HYST<TD>Alarm Deadband<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Monitor Parameters ===

These parameters are used to determine when to send monitors placed on the VAL field. The appropriate monitors are invoked when VAL differs from the values in the ALST and MLST run-time fields, i.e., when the value of VAL changes by more than the deadband specified in these fields. The ADEL and MDEL fields specify a minimum delta which the change must surpass before the value-change monitors are invoked. If these fields have a value of zero, everytime the value changes, a monitor will be triggered; if they have a value of -1, everytime the record is processed, monitors are triggered. The ADEL field is used by archive monitors and the MDEL field for all other types of monitors. See [[RRM 3-14 Concepts#Monitor Specification|Monitor Specification]] for a complete explanation of monitors and deadbands.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>ADEL<TD>Archive Deadband<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>MDEL<TD>Monitor, i.e. value change, Deadband<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Run-time Parameters ===

These parameters are used by the run-time code for processing the subroutine record. They are not configured using a database configuration tool. They represent the current state of the record. Many of them are used by the record processing routines or the monitors.

VAL should be set by the subroutine. SADR holds the subroutine address and is set by the record processing routine. STYP, the subroutine symbol type, is also set by the record processing routine.

The rest of these fields--LALM, ALST, MLST, and the LA-LL fields--are used to implement the monitors. For example, when LA is not equal to A, the value-change monitors are called for that field.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>VAL<TD>Value Field<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>SADR<TD>Subroutine Address <TD>NOACCESS<TD>No<TD>0<TD>No<TD>No<TD>No<TD> <TR>
<TD>STYP<TD>Subroutine Symbol Type<TD>SHORT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LALM<TD>Last Alarm Monitor Trigger Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>ALST<TD>Last Archiver Monitor Trigger Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>MLST<TD>Last Value Change Monitor Trigger Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LA<TD>Last A Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LB<TD>Last B Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LC<TD>Last C Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LD<TD>Last D Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LE<TD>Last E Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LF<TD>Last F Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LG<TD>Last G Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LH<TD>Last H Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LI<TD>Last I Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LJ<TD>Last J Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LK<TD>Last K Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LL<TD>Last L Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No
</TABLE>

== Record Support ==

=== Record Support Routines ===

==== init_record ====

For each constant input link, the corresponding value field is initialized with the constant value. For each input link that is of type PV_LINK, a channel access link is created.

If an initialization subroutine is defined, it is located and called.

The processing subroutine is located and its address and type stored in SADR and STYP.

==== process ====

See next section.

==== get_value ====

Fills in the values of struct valueDes so that they refer to VAL.

==== get_units ====

Retrieves EGU.

==== get_precision ====

Retrieves PREC when VAL is the field being referenced. Otherwise, calls <CODE>recGblGetPrec()</CODE>.

==== get_graphic_double ====

Sets the upper display and lower display limits for a field. If the field is VAL, A-L, LA-LL, HIHI, HIGH, LOW, or LOLO, the limits are set to HOPR and LOPR, else if the field has upper and lower limits defined they will be used, else the upper and lower maximum values for the field type will be used.

==== get_control_double ====

Sets the upper control and the lower control limits for a field. If the field is VAL, A-L, LA-LL, HIHI, HIGH, LOW, or LOLO, the limits are set to HOPR and LOPR, else if the field has upper and lower limits defined they will be used, else the upper and lower maximum values for the field type will be used.

==== get_alarm_double ====

Sets the following values:

upper_alarm_limit = HIHI
upper_warning_limit = HIGH
lower_warning_limit = LOW
lower_alarm_limit = LOLO

=== Record Processing ===

Routine process implements the following algorithm:

# If PACT is FALSE then fetch all arguments.
# Call the subroutine and check return value.
#* Call subroutine
#* Set PACT TRUE
#* If return value is 1, return
# Check alarms. This routine checks to see if the new VAL causes the alarm status and severity to change. If so, NSEV, NSTA and LALM are set. It also honors the alarm hysteresis factor (HYST). Thus the value must change by more than HYST before the alarm status and severity is lowered.
# Check to see if monitors should be invoked.
#* Alarm monitors are invoked if the alarm status or severity has changed.
#* Archive and value change monitors are invoked if ADEL and MDEL conditions are met.
#* Monitors for A-L are invoked if value has changed.
#* NSEV and NSTA are reset to 0.
# Scan forward link if necessary, set PACT FALSE, and return.

=== Example Synchronous Subroutine ===

This is an example subroutine that merely increments VAL each time process is called.

#include <vxWorks.h>
#include <types.h>
#include <stdioLib.h>
#include <dbDefs.h>
#include <subRecord.h>
#include <dbCommon.h>
#include <recSup.h>

long subInit(struct subRecord *psub)
{
printf("subInit was called\n");
return(0);
}

long subProcess(struct subRecord *psub)
{
psub->val++;
return(0);
}

=== Example Asynchronous Subroutine ===

This example shows an asynchronous subroutine. It uses (actually misuses) fields A and B. Field A is taken as the number of seconds until asynchronous completion. Field B is a flag to decide if messages should be printed. Lets assume A > 0 and B = 1. The following sequence of actions will occcur:

# subProcess is called with pact FALSE. It performs the following steps.
#* Computes, from A, the number of ticks until asynchronous completion should occur.
#* Prints a message stating that it is requesting an asynchronous callback.
#* Calls the vxWorks watchdog start routine.
#* Sets pact TRUE and returns a value of 0. This tells record support to complete without checking alarms, monitors, or the forward link.
# When the time expires, the system wide callback task calls myCallback. myCallback locks the record, calls process, and unlocks the record.
# Process again calls subProcess, but now pact is TRUE. Thus the following is done:
#* VAL is incremented.
#* A completion message is printed.
#* subProcess returns 0. The record processing routine will complete record processing.

#include <vxWorks.h>
#include <types.h>
#include <stdioLib.h>
#include <wdLib.h>
#include <callback.h>
#include <dbDefs.h>
#include <dbAccess.h>
#include <subRecord.h>

/* control block for callback*/
struct callback {
CALLBACK callback;
struct dbCommon *precord;
WDOG_ID wd_id;
};

void myCallback(struct callback *pcallback)
{
struct dbCommon *precord=pcallback->precord;
struct rset *prset=(struct rset *)(precord->rset);
dbScanLock(precord);
(*prset->process)(precord);
dbScanUnlock(precord);
}

long subInit(struct subRecord *psub)
{
struct callback *pcallback;
pcallback = (struct callback *)(calloc(1,sizeof(struct callback)));
psub->dpvt = (void *)pcallback;
callbackSetCallback(myCallback,pcallback);
pcallback->precord = (struct dbCommon *)psub;
pcallback->wd_id = wdCreate();
printf("subInit was called\n");
return 0;
}

long subProcess(struct subRecord *psub)
{
struct callback *pcallback=(struct callback *)(psub->dpvt);
/* sub.inp must be a CONSTANT*/
if (psub->pact) {
psub->val++;
if (psub->b)
printf("%s subProcess Completed\n", psub->name);
return 0;
} else {
int wait_time = (long)(psub->a * vxTicksPerSecond);
if (wait_time <= 0){
if (psub->b)
printf("%s subProcess sync processing\n", psub->name);
psub->pact = TRUE;
return 0;
}
if (psub->b){
callbackSetPriority(psub->prio, pcallback);
printf("%s Starting async processing\n", psub->name);
wdStart(pcallback->wd_id, wait_time, callbackRequest, (int)pcallback);
return 1;
}
}
return 0;
}

----

EPICS Record Reference Manual - 19 MAY 1998

RRM 3-14 Permissive

2012-10-12T14:26:54Z

LewisMuir: /* Client-server Parameters */ remove unneeded "the"

[[RRM 3-14|EPICS Record Reference Manual]]

= Permissive =

The permissive record is for communication between a server and a client. An example would be a sequence program server and an operator interface client. By using multiple permissive records a sequence program can communicate its current state to the client.

== Parameter Fields ==

The fields in this record fall into the following categories:

* scan parameters
* client-server parameters
* operator display parameters
* monitor parameters

=== Scan Parameters ===

The permissive record has the standard fields for specifying under what circumstances the record will be processed. These fields are listed in [[RRM 3-14 dbCommon#Scan Fields|Scan Fields]]. In addition, [[RRM 3-14 Concepts#Scanning Specification|Scanning Specification]] explains how these fields are used. Since the permissive record supports no direct interfaces to hardware, its SCAN field cannot be <CODE>I/O Intr</CODE>.

=== Client-server Parameters ===

The client and server communicate through the VAL and watchdog flag (WFLG) fields. At initialization, both fields are set equal to 0, which means OFF. The server sets WFLG equal to ON when it is ready to accept a request. The client monitors WFLG and when WFLG equals 1, the client-server action is performed (a private matter between server and client).

When WFLG is off--when the server is busy--the client program may turn the VAL field from OFF to ON. After the server finishes its task, it will notice that VAL is ON and will turn both WFLG and VAL OFF and performs the requested service.

Note that when WFLG is ON, the client program ''must not'' turn VAL to on.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>VAL <TD>Value Field<TD>USHORT<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>WFLG <TD>Watchdog Flag<TD>USHORT<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes
</TABLE>

=== Operator Display Parameters ===

The label field (LABL) contains a string given to it that should describe the record in further detail. In addition to the DESC field. See [[RRM 3-14 dbCommon#Fields Common to All Record Types|Fields Common to All Record Types]] for more on the record name (NAME) and description (DESC) fields.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>LABL <TD> Label<TD>STRING [20]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>NAME<TD>Record Name<TD>STRING [29]<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>DESC<TD>Description<TD>STRING [29]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Alarm Parameters ===

The Permissive record has the alarm parameters common to all record types. [[RRM 3-14 dbCommon#Alarm Fields|Alarm Fields]] lists other fields related to a alarms that are common to all record types.

=== Run-time Parameters ===

These fields are used to trigger monitors for each field. Monitors for the VAL field are triggered when OVAL, the old value field, does not equal VAL. Likewise, OFLG causes monitors to be invoked for WFLG when WFLG does not equal OLFG.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>OVAL<TD> Old Value <TD>USHORT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>OFLG<TD> Old Flag Value<TD>USHORT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No
</TABLE>

== Record Support ==

=== Record Support Routines ===

Two record support routines are provided: process, and get_value.

==== process ====

process sets UDF to FALSE, triggers monitors on VAL and WFLG when they change, and scans the forward link if necessary.

==== get_value ====

get_value fills in struct <CODE>valueDes</CODE> so that it refers to VAL.

----

EPICS Record Reference Manual - 19 MAY 1998

RRM 3-14 Binary Input

2011-02-24T15:30:42Z

LewisMuir: /* Alarm Parameters */ "NO ALARM" should be "NO_ALARM"

[[RRM 3-14|EPICS Record Reference Manual]]

= bi - Binary Input =

The normal use for this record type is to obtain a binary value of 0 or 1. Most device support modules obtain values from hardware and place the value in RVAL. For these devices record processing sets VAL = (0,1) if RVAL is (0, not 0). Devices support modules may optionally read a value directly into VAL.

Soft device modules are provided to obtain input via database or channel access links or via dbPutField or dbPutLink requests. Two soft device support modules are provided: <CODE>Soft Channel</CODE> and <CODE>Raw Soft Channel</CODE>. The first allows VAL to be an arbitrary unsigned short integer. The second reads the value into RVAL just like normal hardware modules.

== Parameter Fields ==

The binary input's fields fall into the following categories:

* scan parameters
* read and convert parameters
* operator display parameters
* alarm parameters
* run-time parameters

=== Scan Parameters ===

The binary input record has the standard fields for specifying under what circumstances the record will be processed. These fields are listed in [[RRM 3-14 dbCommon#Scan Fields|Scan Fields]]. In addition, [[RRM 3-14 Concepts#Scanning Specification|Scanning Specification]] explains how these fields are used. Note that I/O event scanning is only supported for those card types that interrupt.

=== Read and Convert Parameters ===

The read and convert fields determine from where the binary input gets its input from and how to convert the raw signal to engineering units. The INP field contains the address from where device support retrieves the value. If the binary input record gets its value from hardware, the address of the card must be entered in he INP field, and the name of the device support module must be entered in the DTYP field. See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on the format of hardware addresses. Be aware that the format differs between types of cards. You can see a list of the device support modules currently supported at the user's local site by using the <CODE>dbst</CODE> utility (R3.13).

For records that specify the <CODE>Soft Channel</CODE> or <CODE>Raw Soft Channel</CODE> device support routines, the INP field can be a channel or database access link, or a constant. If a constant, VAL can be changed directly by dbPuts. See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on the format of database and channel access addresses. Also, see [[#Device Support for Soft Records|Device Support for Soft Records]] in this chapter for more information on soft device support.

If the record gets its value from hardware or uses the <CODE>Raw Soft Channel</CODE> device support, the device support routines place the value into the RVAL field which is then converted using the process described in the next section.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify
<TH>Rec Proc Monitor<TH>PP<TR>
<TD>INP<TD>Input Link<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>DTYP<TD>Device Type<TD>DEVCHOICE<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD> <TR>
<TD>ZNAM<TD>Zero Name<TD>STRING [20]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>ONAM<TD>One Name<TD>STRING [20]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>RVAL<TD>Raw Value<TD>ULONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>VAL<TD>Value Field<TD>ENUM<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes
</TABLE>

==== Conversion Fields ====

The VAL field is set equal to (0, 1) if the RVAL field is (0, not 0), unless the device support module reads a value directly into VAL or the <CODE>Soft Channel</CODE> device support is used. The value can also be fetched as one of the strings specified in the ZNAM or ONAM fields. The ZNAM field has the string that corresponds to the 0 state, so when the value is fetched as this string, <CODE>put_enum_str</CODE> will return a 0 will. The ONAM field holds the string that corresponds to the 1 state, so when the value is fetched as this string, <CODE>put_enum_str</CODE> returns a 1.

<TABLE BORDER="1">
<TD>ZNAM<TD>ASCII string defining state zero<TR>
<TD>ONAM<TD>ASCII string defining state one
</TABLE>

=== Operator Display Parameters ===

These parameters are used to present meaningful data to the operator. The <CODE>get_enum_str</CODE> record support routine can retrieve the state string corresponding to VAL's state. So if the value is 1, <CODE>get_enum_str</CODE> will return the string in the ONAM field; and if 0, <CODE>get_enum_str</CODE> will return the ZNAM string.

See [[RRM 3-14 dbCommon#Miscellaneous Fields|Fields Common to All Record Types]] for more on the record name (NAME) and description (DESC) fields.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify
<TH>Rec Proc Monitor<TH>PP<TR>
<TD>ZNAM<TD>Zero Name<TD>STRING [20]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>ONAM<TD>One Name<TD>STRING [20]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>NAME<TD>Record Name<TD>STRING [29]<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>DESC<TD>Description<TD>STRING [29]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Alarm Parameters ===

These parameters are used to determine if the binary input is in alarm condition and to determine the severity of that condition. The possible alarm conditions for binary inputs are the SCAN, READ state alarms, and change of state alarm. The SCAN and READ alarms are called by the device support routines.

The user can choose the severity for each state in the ZSV and OSV. The possible values for these fields are NO_ALARM, MINOR, and MAJOR. The ZSV holds the severity for the zero state; OSV, for the one state. COSV causes an alarm whenever the state changes between 0 and 1 and the severity is configured as MINOR or MAJOR.

See [[RRM 3-14 Concepts#Alarm Specification|Alarm Specification]] for a complete explanation of discrete alarm states. [[RRM 3-14 dbCommon#Alarm Fields|Alarm Fields]] lists other fields related to a alarms that are common to all record types.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify
<TH>Rec Proc Monitor<TH>PP<TR>
<TD>ZSV<TD>Zero Severity<TD>GBLCHOICE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>OSV<TD>One Severity<TD>GBLCHOICE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>COSV<TD>Change of State Severity<TD>GBLCHOICE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes
</TABLE>

=== Run-time Parameters and Simulation Mode Parameters ===

These parameters are used by the run-time code for processing the binary input. They are not configured using a database configuration tool.

ORAW is used to determine if monitors should be triggered for RVAL at the same time they are triggered for VAL.

MASK is given a value by the device support routines. This value is used to manipulate the record's value, but is only the concern of the hardware device support routines.

The LALM field holds the value of the last occurrence of the change of state alarm. It is used to implement the change of state alarm, and thus only has meaning if COSV is MINOR or MAJOR.

The MLST is used by the <CODE>process</CODE> record support routine to determine if archive and value change monitors are invoked. They are if MLST is not equal to VAL.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify
<TH>Rec Proc Monitor<TH>PP<TR>
<TD>ORAW<TD>Old Raw Value<TD>ULONG<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>MASK<TD>Hardware mask<TD>ULONG<TD>No<TD>compute<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LALM<TD>Last Alarmed value<TD>USHORT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>MLST<TD>Last Monitored Value<TD>USHORT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No
</TABLE>

The following fields are used to operate the binary input in the simulation mode. See [[RRM 3-14 Common#Simulation Mode|Fields Common to Many Record Types]] for more information on these fields.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify
<TH>Rec Proc Monitor<TH>PP<TR>
<TD>SIOL<TD>Simulation Value Location<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>SVAL<TD>Simulation Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>SIML<TD>Simulation Mode Location<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>SIMM<TD>Simulation Mode<TD>GBLCHOICE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>SIMS<TD>Simulation Mode Alarm Severity<TD>GBLCHOICE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

== Record Support ==

=== Record Support Routines ===

==== init_record ====

This routine initializes SIMM with the value of SIML if SIML type is CONSTANT link or creates a channel access link if SIML type is PV_LINK. SVAL is likewise initialized if SIOL is CONSTANT or PV_LINK.

This routine next checks to see that device support is available and a device support read routine is defined. If either does not exist, an error message is issued and processing is terminated.

If device support includes init_record, it is called.

==== process ====

See next section.

==== get_value ====

Fills in the values of struct valueDes so that they refer to VAL.

==== get_enum_str ====

Retrieves ASCII string corresponding to VAL.

==== get_enum_strs ====

Retrieves ASCII strings for ZNAM and ONAM.

==== put_enum_str ====

Checks if string matches ZNAM or ONAM, and if it does, sets VAL.

=== Record Processing ===

Routine process implements the following algorithm:

# Check to see that the appropriate device support module exists. If it doesn't, an error message is issued and processing is terminated with the PACT field still set to TRUE. This ensures that processes will no longer be called for this record. Thus error storms will not occur.
# readValue is called. See [[RRM 3-14 Common#Input Records|Input Records]] for details.
# If PACT has been changed to TRUE, the device support read routine has started but has not completed reading a new input value. In this case, the processing routine merely returns, leaving PACT TRUE.
# Convert<pre>
status=read_bi
PACT = TRUE
TIME = tslocaltime
if status is 0, then set VAL=(0,1) if RVAL is (0, not 0) and UDF = False
if status is 2, set status = 0</pre>
# Check alarms: This routine checks to see if the new VAL causes the alarm status and severity to change. If so, NSEV and NSTA and LALM are set. Note that if VAL is greater than 1, no checking is performed.
# Check to see if monitors should be invoked:
#* Alarm monitors are invoked if the alarm status or severity has changed.
#* Archive and value change monitors are invoked if MLST is not equal to VAL.
#* Monitors for RVAL are checked whenever other monitors are invoked.
#* NSEV and NSTA are reset to 0.
# Scan forward link if necessary, set PACT FALSE, and return.

== Device Support ==

=== Fields Of Interest To Device Support ===

Each binary input record must have an associated set of device support routines. The primary responsibility of the device support routines is to obtain a new raw input value whenever read_bi is called. The device support routines are primarily interested in the following fields:

<TABLE BORDER="1"><TH>Name<TH>Summary<TH>Description<TR>
<TD>PACT<TD>Processing Active<TD rowspan=5>See [[RRM 3-14 dbCommon|Fields Common to All Record Types]] for an explanation of these fields.<TR>
<TD>DPVT<TD>Device Private<TR>
<TD>UDF<TD>VAL Undefined<TR>
<TD>NSEV<TD>New Alarm Severity<TR>
<TD>NSTA<TD>New Alarm Status<TR>
<TD>VAL<TD>Value Field<TD>This field is set by a device support routines only if it doesn't want record support to set it.<TR>
<TD>INP<TD>Input Link<TD>This field is used by the device support routines to locate its input.<TR>
<TD>RVAL<TD>Raw Value<TD>It is the responsibility of the device support routine to give this field a value.<TR>
<TD>MASK<TD>Hardware mask.<TD>The device support routine must give this field a value if it needs to use it.</TABLE>

=== Device Support routines ===

Device support consists of the following routines:

==== report ====

report(FILE fp, paddr)

Not currently used.

==== init ====

init()

This routine is called once during IOC initialization.

==== init_record ====

init_record(precord)

This routine is optional. If provided, it is called by the record support init_record routine.

==== get_ioint_info ====

get_ioint_info(int cmd,struct dbCommon *precord,IOSCANPVT *ppvt)

This routine is called by the ioEventScan system each time the record is added or deleted from an I/O event scan list. cmd has the value (0,1) if the record is being (added to, deleted from) an I/O event list. It must be provided for any device type that can use the ioEvent scanner.

==== read_bi ====

read_bi(precord)

This routine must provide a new input value. It returns the following values:

: 0: Success. A new raw value is placed in RVAL. The record support module forces VAL to be (0,1) if RVAL is (0, not 0).

: 2: Success, but don't modify VAL.

: other: Error.

=== Device Support for Soft Records ===

Two soft device support modules Soft Channel and Raw Soft Channel are provided for input records not related to actual hardware devices. The INP link type must be either CONSTANT, DB_LINK, or CA_LINK.

==== Soft Channel ====

read_bi always returns a value of 2, which means that no conversion is performed.

If the INP link type is constant, then the constant value is stored into VAL by init_record, and UDF is set to FALSE. VAL can be changed via dbPut requests. If the INP link type is PV_LINK, then dbCaAddInlink is called by init_record.

read_bi calls recGblGetLinkValue to read the current value of VAL. See [[RRM 3-14 Common#Soft Input|Soft Input]] for details.

If the return status of recGblGetLinkValue is zero, then read_bi sets UDF to FALSE. The status of recGblGetLinkValue is returned.

==== Raw Soft Channel ====

This module is like the previous except that values are read into RVAL.

read_bi returns a value of 0. Thus the record processing routine will force VAL to be 0 or 1.

----

EPICS Record Reference Manual - 19 MAY 1998

How to check out EPICS Base with Bazaar

2010-08-27T17:34:48Z

LewisMuir: /* Shelving Local Changes */ Fixed typo

Bazaar can support several different approaches; the one you should use depends on who you are and what you expect to do with the code-base. It usually allows you to change your mind later though, so don't worry if you pick the wrong model to start with, you can modify your configuration as you need later on (although I'm not going to give instructions on how to do that here, read the Bazaar documentation).

You must have Bazaar version 2.x installed; older versions do not support the same repository format. I am currently using version 2.0.3, but any release in the 2.x series should be fine.

Bazaar has extensive built-in help text, just type 'bzr help <command>' for more information on <command> or 'bzr help topics' for a list of other help topics. The complete documentation for the tool can be found online [http://doc.bazaar.canonical.com/bzr.2.0/en/ here].

If you have problems connecting to launchpad and your network requires you to use an HTTP proxy server, make sure that you have both the http_proxy and https_proxy environment variables set appropriately.

If you are behind a firewall and the 'lp:' shorthand does not work, try the following transport specification:
bzr checkout bzr+ssh://<lp-user-name>@bazaar.launchpad.net/~epics-core/epics-base/3.14/

__TOC__

== Non-developers ==

These options apply to EPICS users who do not expect to make changes to the source code themselves, but who want to be able to access the latest official development versions of the code or to look at how it has changed between different past revisions.

=== Check out a working tree (CVS model, remote history) ===

Use this option if you just want to a copy of the latest version of Base from the repository (for example to build and test) but don't expect to modify the code at all, or to look at its history much. This approach is very similar to using CVS since you only download a copy of the particular revision you're interested in, but it require network connectivity for all activities that access the repository in any way. An EPICS Base 3.14 working tree uses about 12MB of disk space at the time of writing.

The following command will create a directory tree called base-3.14 containing the latest code that was checked in to the 3.14 branch of Base:
bzr checkout --lightweight lp:epics-base/3.14 base-3.14

The lp: path above specifies a branch to check out from the launchpad server. The branch at lp:epics-base/3.14 is a branch containing all the development work for the R3.14 releases of Base. There are similar branches for the older series, although we're not expecting anyone to check any of these out; they're provided for historical reasons. The development on the branch called trunk will eventually become the 3.15 series.

If you want to check out a specific tagged version, in this case we're requesting the R3.14.11 release, use this command instead:
bzr checkout --lightweight -r tag:R3.14.11 lp:epics-base/3.14 base-3.14

To update a lightweight working tree at a later date with the latest changes from the branch, use this command inside the tree:
bzr update

You can use the command 'bzr tags' from inside the working tree to list all the tags known on this branch.

Unlike CVS, 'bzr update' cannot apply changes that move your tree to a different historical revision; for that you use the command below, in this case to move to the R3.14.10 release tag:
bzr revert -r tag:R3.14.10

If you made any local changes to the files in the working tree your changes will be retained through a 'bzr update' or 'bzr revert' operation. Any local changes that overlap with changes from the repository will create a conflict and have to be resolved by hand, just as happens with CVS.

If you find yourself using Bazaar commands inside the tree more than once or twice, you should probably check out a branch instead, which makes a local copy of the complete history of the branch and removes the need for network activity to access that history.

=== Check out a branch (local history) ===

This option is similar to the previous one but also gives you a local copy of the complete history of the branch. This speeds up all activities that need to examine the repository history, but since the local branch is still bound to the central repository at launchpad.net you can't commit any changes to it without write permission for the repository branch. A 3.14 branch needs about 28MB of disk space at the time of writing.

The following command will create a directory tree called base-3.14 containing the latest code and all of the history that was checked in to the 3.14 branch of Base:
bzr checkout lp:epics-base/3.14 base-3.14

The lp: path above specifies a branch to check out from the launchpad server. The branch at lp:epics-base/3.14 is a branch containing all the development work for the R3.14 releases of Base. There are similar branches for the older series, although we're not expecting anyone to check any of these out; they're provided for historical reasons. The development on the branch called trunk will eventually become the 3.15 series.

If you want to check out a particular tagged version, use this command instead:
bzr checkout -r tag:R3.14.11 lp:~epics-core/epics-base/3.14 base-3.14.11

Inside the working tree, Bazaar supports the expected commands 'bzr log' and 'bzr diff' to examine file history. Use 'bzr help revisionspec' for information on specifying particular revisions to examine.

To update your working tree with the latest changes from the parent branch at some later date, use this command inside the tree:
bzr update
Note that if you're working in a regular branch and not a checkout, the command to use is
bzr pull
and if you have committed changes to your branch that are not in the parent
bzr merge

Note that 'bzr pull' or 'bzr update' cannot move your tree to a different historical revision like in CVS, for that you use this command:
bzr revert -r tag:R3.14.10

You can use 'bzr tags' when inside the working tree to list all the tags known on this branch.

If you made any local changes to the files in the working tree your changes will be retained through a 'bzr update' or 'bzr revert' operation. Any local changes that overlap with changes from the repository will create a conflict and have to be resolved by hand, just as happens with CVS.

If you want to keep some permanent local changes, consider unbinding your tree from the central repository branch, which converts it to a regular branch. This will allow you to commit local changes into your local repository. The 'bzr unbind' command does this, and can be undone again with 'bzr bind'.

== Developers ==

Developers usually want to be able to commit changes to a local repository while they're working on a new feature or bug-fix. Once those changes are complete they will publish and propose them for review; once approved a member of the epics-core team will merge the new code into the appropriate central repository and it will appear in the next release of that development series.

=== Repository Initialization ===

Unless you are only going to work on one modification to epics-base, you should create a local repository, which will be used as the backing-store to hold the history of all your development work on EPICS Base, and will be shared by all your bazaar branches. Doing this saves network bandwidth, as it avoids having to download the past history of changes to epics-base from Launchpad more than once. This command will create an epics-base directory in your home directory, inside of which you will check out your branches (you can use a different name or location, but it should be a parent or grand-parent directory of where you'll create your task branches):
bzr init-repo ~/epics-base

=== Creating a Task Branch ===

Bazaar encourages developers to create a separate branch for each separate feature or bug fix being developed, which would normally be created as a sibling to the mirror branch we checked out above. While working on the fix you are free to commit changes whenever you like, which are recorded in your local repository:
cd ~/epics-base
bzr branch lp:epics-base fix-123
cd fix-123
# ''Hack...''
bzr ci -m 'Hacked the frooz-bodger to stop it wibbling'

If a particular commit fixes a bug that is registered on Launchpad, you can have Bazaar record that fact at the time like this:
bzr ci --fixes=lp:123

When you are sure that your branch fully implements the new feature or bug-fix that you've been working on and you want the core developers to take a look at it, you should publish it on launchpad and propose it for merging (see [[#Publishing a Branch]] below).

=== Updates and Merging ===

While you're working on your task branch, other developers' changes may be being merged into the central branch. In most cases there will be little conflict between their work and yours, thus you should ''not'' normally merge changes from the central branch into yours before your branch has been proposed for merger. Merging changes from the central branch before requesting the review adds those changes to your merge proposal, which makes the reviewers' task harder. Minor conflicts are to be expected in the release notes, but these will be fixed by the core developer who merges your branch after it has been approved.

==== Pulling Updates ====

If you have not committed any changes to your fix-123 branch yet, you can pull all the central changes into your branch in a single command:
cd fix-123
bzr pull
# ''Should report any conflicts''

If you're not sure whether you've made any commits or not, you can ask Bazaar:
cd fix-123
bzr missing
# ''Reports commit differences between trees''

==== Merging Updates ====

If a change does get merged to the central branch which significantly affects your work (and you have already made at least one commit to your branch), you should bring this to the attention of the core developers and ask them how to proceed. If they tell you to merge in from the central branch, make sure you have no uncommitted changes (by either committing or shelving them), then:
cd fix-123
bzr merge
# ''Fix any conflicts, then tell Bazaar like this:''
bzr resolve ''file''
# ''Finally commit the merge''
bzr ci -m 'Merged with latest 3.14 changes'

If Bazaar reports any conflicts from the 'bzr merge' command, you ''must'' resolve them with 'bzr resolve' before attempting to commit the result. You will find a pristine copy of your version in ''file''.THIS, the other version in ''file''.OTHER and the common ancestor in ''file''.BASE, and collectively these should help you to see what's happening. The command 'bzr remerge' might also be useful in some circumstances, it allows you to redo the merge using some other merge algorithms. The .THIS, .OTHER and .BASE files will be deleted when you run the 'bzr resolve' command.

If you decide that a merge was a mistake and want to undo it, the 'bzr revert' command will undo all uncommitted changes and restore your tree to the way it was after the last commit.

==== Rebasing a Private Branch ====

If it is suggested that you rebase your private branch rather than merging the changes from the central branch into it, you will need the rebase Bazaar plugin installed (also now called the rewrite plugin). Use 'bzr plugins' to find out if it is already present or not. If not, you can find it at [http://wiki.bazaar.canonical.com/Rewrite Rewrite Plugin].

The 'bzr rebase' command is used like this:
cd fix-123
bzr rebase
# ''Fix any conflicts, then tell Bazaar like this:''
bzr resolve ''file''
# ''Now continue the rebase:''
bzr rebase-continue
# ''Repeat resolve and rebase-continue commands until done''

'''Never''' rebase a branch that you have published and which other people may be using as the basis for other development work. Rebasing rewrites the history of your branch, and can result in major spaghetti problems unless you know what you're doing. If in any doubt, make a copy of your branch first ('bzr branch fix-123 clone-123') and do the rebase operation on the copy while leaving the original untouched. Test the rebased branch to make sure your new functionality still works before continuing development or publishing the result.

=== Shelving Local Changes ===

If you have some local changes that you don't want to commit (say some CONFIG_SITE changes needed to build the code at your site) but you're about to use a command such as 'bzr merge' that doesn't work if there are uncommitted changes, you can use 'bzr shelve configure/CONFIG_SITE' to temporarily remove them, and 'bzr unshelve' later to bring them back. The shelve command will show you each unsaved change in the named file(s) in turn and ask whether you want to shelve it or not (the '--all' option skips that part). Read the 'bzr help shelve' output for more details.

=== Publishing a Branch ===

Anyone can publish branches of the epics-base project on Launchpad, where other people can find and use them. You must have registered for an account at [https://launchpad.net/ Launchpad.net] first and uploaded your ssh public-key. Then:
bzr launchpad-login ''userid''
cd ~/epics-base/fix-123
bzr push lp:~''user-id''/epics-base/fix-123

== Core Developers ==

In addition to developing your own features and fixes, if you are a member of the epics-core team you will be able to merge changes (either your own or someone else's) into the official branches in the central repository. That task is simplified if you keep a checkout (mirror) of the relevant central branch, which you can also use to directly commit tiny changes to the repository.

The model described here corresponds to the "decentralized with shared mainline" workflow given in the [http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/distributed_intro.html Bazaar User Guide].

=== Initial Checkout ===

First initialize a local repository in a parent directory which will be used as the backing-store to hold the history of all your development work on EPICS Base. Make sure you are logged into Launchpad, then checkout a mirror branch of Base inside your repository directory:
bzr init-repo ~/epics-base
bzr launchpad-login ''userid''
cd ~/epics-base
bzr checkout lp:epics-base/3.14 mirror-3.14

This mirror branch should not be used directly for developing new code or major bug fixing, but can be used for making "obviously correct" changes to things like comments or string literals. Major work should take place in a different tree usually called a ''feature'' or ''task branch''.

The mirror branch allows you to merge tested sets of changes from your feature branches into the central repository, or to try out merging other branches while performing code reviews. Remember that performing a commit in the mirror branch is only possible if you are an epics-core member, and will immediately push the change to the official branch on the Launchpad website.

=== Creating a Task Branch ===

Bazaar encourages developers to create a separate branch for each separate feature or bug fix being developed, which would normally be created as a sibling to the mirror branch we checked out above. While working on the fix you are free to commit changes whenever you like, which are recorded in your local repository:
cd ~/epics-base
bzr branch mirror-3.14 fix-123
cd fix-123
# ''Hack...''
bzr ci -m 'Hacked the frooz-bodger to stop it wibbling'

If a particular commit fixes a bug that is registered on Launchpad, you should have Bazaar record that fact at the time like this:
bzr ci --fixes=lp:123

When you are sure that your branch fully implements the new feature or bug-fix that you've been working on and you want the other core developers to review it, you should publish it on launchpad and propose it for merging (see [[#Publishing a Branch]] below).

=== Updating the Mirror ===

Update your mirror branch frequently to fetch changes from the central repository. Since you aren't using this checkout area for development there should never be any conflicts when you do this:
cd ~/epics-base
bzr update mirror-3.14

=== Pulling Updates ===

If you have not committed any changes to one or more of your feature branches, you can pull the changes from the update into those branches very easily, and Bazaar will merge them with your uncommitted edits. After updating the mirror-3.14 tree as above, you just do this:
cd fix-123
bzr pull
# ''Should report any conflicts''

If you're not sure whether you've made any commits or not, you can ask Bazaar:
cd fix-123
bzr missing
# ''Reports commit differences between trees''

=== Updates and Merging ===

While you're working on your task branch, other developers' changes may be being merged into the central branch. In most cases there will be little conflict between their work and yours, thus you should ''not'' normally merge changes from the central branch into yours before your branch has been proposed for merger. Merging changes from the central branch before requesting the review adds those changes to your merge proposal, which makes the reviewers' task harder. Minor conflicts are to be expected in the release notes, but they should only be fixed when you merge in your branch after it has been approved.

==== Merging vs. Rebasing ====

Rebasing a branch is a controversial issue in some communities, there are proponents and nay-sayers on whether it should be used or not. Here are a couple of the discussions:
* [http://softwareswirl.blogspot.com/2009/04/truce-in-merge-vs-rebase-war.html A truce in the merge vs. rebase war?]
* [http://fourkitchens.com/blog/2009/04/20/alternatives-rebasing-bazaar Alternatives to rebasing in Bazaar]

Ralph and Andrew are of the opinion that rebasing is an acceptable technique in private branches.

===== Merging Updates =====

If you decide to merge in the central branch changes into your work, the steps are:
cd ~/epics-base/feature
bzr merge
# ''Fix any conflicts, then tell Bazaar like this:''
bzr resolve ''file''
# ''Finally commit the merge''
bzr ci -m 'Merged changes from 3.14 branch'

Note that you should either shelve (see below) or check in any uncommitted local modifications into the task branch before doing the above merge step, if you try to use 'bzr merge --force' instead you risk mixing up your changes with someone else's, which can be confusing and tricky to resolve.

If Bazaar reports any conflicts from the 'bzr merge' command, you ''must'' resolve them with 'bzr resolve' before attempting to commit the result. You will find a pristine copy of your version in ''file''.THIS, the other version in ''file''.OTHER and the common ancestor in ''file''.BASE, and collectively these should help you to see what's happening. The command 'bzr remerge' might also be useful in some circumstances, it allows you to redo the merge using some other merge algorithms. The .THIS, .OTHER and .BASE files will be deleted when you run the 'bzr resolve' command.

If you decide that the merge was a mistake and want to undo it, the 'bzr revert' command will undo all uncommitted changes and restore your tree to the way it was after the last commit.

===== Rebasing a Private Branch =====

If it is suggested that you rebase your private branch rather than merging the changes from the central branch into it, you will need the rebase Bazaar plugin installed (also now called the rewrite plugin). Use 'bzr plugins' to find out if it is already present or not. If not, you can find it at [http://wiki.bazaar.canonical.com/Rewrite Rewrite Plugin].

The 'bzr rebase' command is used like this:
cd fix-123
bzr rebase
# ''Fix any conflicts, then tell Bazaar like this:''
bzr resolve ''file''
# ''Now continue the rebase:''
bzr rebase-continue
# ''Repeat resolve and rebase-continue commands until done''

'''Never''' rebase a branch that you have published and which other people may be using as the basis for other development work. Rebasing rewrites the history of your branch, and can result in major spaghetti problems unless you know what you're doing. If in any doubt, make a copy of your branch first ('bzr branch fix-123 clone-123') and do the rebase operation on the copy while leaving the original untouched. Test the rebased branch to make sure your new functionality still works before continuing development or publishing the result.

=== Merging Task or Feature Branches ===

The ability to commit changes to the central repository is restricted to members of the epics-core team at [https://launchpad.net/ Launchpad.net], but Bazaar and Launchpad will still allow you to publish branches containing your own development even if you do not belong to that team; a core developer may subsequently merge and commit the changes from your branch into the official one.

Note that you can undo a merge anytime before the final commit by using the 'bzr revert' command.

==== Merging a Local Branch ====

For epics-core members, a feature branch of your own that has been reviewed and approved is merged and committed to the central branch as follows:
cd ~/epics-base/mirror-3.14
bzr update
bzr missing ../fix-123
# ''Check that you're about to merge the right changes''
bzr merge ../fix-123
# ''Fix any conflicts, then tell Bazaar like this:''
bzr resolve ''file''
# ''Finally commit the merge''
bzr ci -m 'Fixed bug #123'

After you have merged and committed your changes from a feature branch into the central branch(es) at launchpad, you can delete the branch directory, you don't have to do anything special with Bazaar.

==== Merging a Launchpad Branch ====

If you're merging someone else's branch which is published on Launchpad, you can use the lp:~user/epics-base/branch-name URL for their branch directly, it is not necessary to download or checkout a copy of a branch to merge it:
cd ~/epics-base/mirror-3.14
bzr update
bzr missing lp:~mdavidsaver/epics-base/rec-init
# ''Check that you're about to merge the right changes''
bzr merge lp:~mdavidsaver/epics-base/rec-init
# ''Fix any conflicts, then tell Bazaar like this:''
bzr resolve ''file''
# ''Finally commit the merge''
bzr ci -m "Merged Michael Davidsaver's 'rec-init' branch."

=== Cherry-picking ===

This is not recommended, discuss on core-talk before you use cherry-picking...

To apply a bug-fix change to more than one series branch, say to both 3.14 and the main trunk, Bazaar's merge command allows you to cherry-pick commits from a different branch. If it's just one check-in this is very easy, especially if it's the last commit you made to that source branch. In that case, you would use these commands to merge those changes to the trunk:
cd ~/epics-base/mirror-trunk
bzr update
bzr merge -c -1 ../fix-123
# ''Fix any conflicts and tell bzr like this:''
bzr resolve ''file''
# ''Finally commit the merge''
bzr ci -m 'Fixed bug #123'
The '-c -1' option to 'bzr merge' means "cherry-pick just the last commit", '-c -2' would be the penultimate commit and so on. You can use 'bzr log' in the feature branch to find a specific absolute revision number on that branch and use that instead of the negative numbers. If there were several commits you can give 'bzr merge' a range using the option '-r 44..47' instead, but note that '-r 44' means "merge all changes up to and including revision 44." If you get it wrong, you can always use 'bzr revert' to undo.

=== Shelving Local Changes ===

If you have some local changes that you don't want to commit, say some CONFIG_SITE changes needed to build the code at your site, you can use 'bzr shelve configure/CONFIG_SITE' to temporarily hide them before committing or merging, and 'bzr unshelve' later to bring them back. The shelve command will show you each of the changes in the named file(s) in turn and ask whether you want to shelve it or not. Read the 'bzr help shelve' output for more details.

=== Publishing a Branch ===

Anyone can publish branches of the epics-base project on Launchpad, where other people can find and use them. You must have registered for an account at [https://launchpad.net/ Launchpad.net] first and uploaded your ssh public-key. Then:
bzr launchpad-login ''userid''
cd ~/epics-base/fix-123
bzr push lp:~''user-id''/epics-base/fix-123

Members of the epics-core team can create shared branches that other team members can also commit to by using the group name as the user-id in the Bazaar target path:
bzr push lp:~epics-core/epics-base/feature-xyz

RRM 3-14 Data Fanout

2010-03-06T03:57:44Z

LewisMuir: /* Desired Output Parameters */ Changed "closed loop" to "closed_loop"

[[RRM 3-14|EPICS Record Reference Manual]]

= dfanout - Data Fanout =

: Johnny Tang, Matthew Bickley, and Chip Watson
: Continuous Electron Beam Accelerator Facility
: Southeastern Universities Research Association

The dfanout record or data fanout record is used to forward data to up to eight other records. It's similar to the fanout record except that the capability to forward data has been added to it. It has no associated device support.

== Parameter Fields ==

The fields in this record can be classified into the following categories:

* scan parameters
* desired output parameters
* write parameters
* operator display parameters
* alarm parameters
* monitor parameters
* run-time and simulation mode parameters

=== Scan Parameters ===

The data fanout record has the standard fields for specifying under what circumstances it will be processed. These fields are listed in [[RRM 3-14 dbCommon#Scan Fields|Scan Fields]]. In addition, [[RRM 3-14 Concepts#Scanning Specification|Scanning Specification]] explains how these fields are used. Since the data fanout record supports no direct interfaces to hardware, it cannot be scanned on I/O interrupt, so its SCAN field cannot be <CODE>I/O Intr</CODE>.

=== Desired Output Parameters ===

The data fanout record must specify where the desired output value originates, i.e., the data which it is to forward to the records in its output links. The output mode select (OMSL) field determines whether the output originates from another record or from run-time database access. When set to <CODE>closed_loop</CODE>, the desired output is retrieved from the link specified in the desired output (DOL) field, which can specify either a database or channel access link, and placed into the VAL field. When set to <CODE>supervisory</CODE>, the desired output can be written to the VAL field via dpPuts at run-time.

The DOL field can also be a constant in which case the VAL field is initialized to the constant value.

Note that there are no conversion parameters, so the desired output value undergoes no conversions before it is sent out to the output links.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>DOL<TD>Desired Output Location (Input Link)<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>OMSL<TD>Output Mode Select <TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>VAL <TD>Value Field<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes
</TABLE>

=== Write Parameters ===

The OUTA-OUTH fields specify where VAL is to be sent. Each field that is to forward data must specify an address to another record. See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on specifying links.

The SELL, SELM, and SELN fields specify which output link(s) are to be used.
SELM is a menu, with the following choices: "All", "Specified", "Mask". If
SELM=="All", then all output links are used, and the values of SELL and SELN
are ignored.

If SELM=="Specified", then the value of SELN is used to specify a single link
which will be used. If SELN==0, then no link will be used; if SELN==1, then OUTA will be used, and so on.

SELN can either have its value set directly, or have its value retrieved from
another EPICS PV. If SELL is a valid PV link, then SELN will be set to the
value of the linked PV

If SELM=="Mask", then SELN will be treated as a bit mask. If bit one of SELN
is set, then OUTA will be used, if bit two is set, OUTB will be used. Thus
if SELN==5, OUTC and OUTA will be used.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>OUTA<TD>Output Link A<TD>OUTLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>OUTB<TD>Output Link B<TD>OUTLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>OUTC<TD>Output Link C<TD>OUTLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>OUTD<TD>Output Link D<TD>OUTLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>OUTE<TD>Output Link E<TD>OUTLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>OUTF<TD>Output Link F<TD>OUTLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>OUTG<TD>Output Link G<TD>OUTLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>OUTH<TD>Output Link H<TD>OUTLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No
</TABLE>

=== Operator Display Parameters ===

These parameters are used to present meaningful data to the operator. They display the value and other parameters of the data fanout record either textually or graphically.

The EGU field can contain a string of up to 16 characters describing the value in the VAL field.

The HOPR and LOPR fields determine the upper and lower display limits for graphics displays and the upper and lower control limits for control displays. They apply to the VAL, HIHI, HIGH, LOW, and LOLO fields. The record support routines <CODE>get_graphic_double</CODE> or <CODE>get_control_double</CODE> retrieve HOPR and LOPR

See [[RRM 3-14 dbCommon#Fields Common to All Record Types|Fields Common to All Record Types]] for more on the record name (NAME) and description (DESC) fields.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>EGU<TD>Engineering Units<TD>STRING [16]<TD>Yes<TD>null<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>HOPR<TD>High Operating Range<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>LOPR<TD>Low Operating Range<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>NAME<TD>Record Name<TD>STRING [29]<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD> <TR>
<TD>DESC<TD>Description<TD>STRING [29]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Alarm Parameters ===

The possible alarm conditions for data fanouts are the SCAN, READ, INVALID, and limit alarms. The SCAN and READ alarms are called by the record routines. The limit alarms are configured by the user in the HIHI, LOLO, HIGH, and LOW fields using floating-point values. The limit alarms apply only to the VAL field. The severity for each of these limits is specified in the corresponding field (HHSV, LLSV, HSV, LSV) and can be either NO_ALARM, MINOR, or MAJOR. In the hysteresis field (HYST) can be entered a number which serves as the deadband on the limit alarms.

See [[RRM 3-14 Concepts#Alarm Specification|Alarm Specification]] for a complete explanation of alarms and these fields. [[RRM 3-14 dbCommon#Alarm Fields|Alarm Fields]] lists other fields related to a alarms that are common to all record types.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>HIHI<TD>Hihi Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HIGH<TD>High Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LOW<TD>Low Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LOLO<TD>Lolo Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HHSV<TD>Hihi Alarm Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HSV<TD>High Alarm Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LSV<TD>Low Alarm Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LLSV<TD>Lolo Alarm Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HYST<TD>Alarm Deadband<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Monitor Parameters ===

These parameters are used to determine when to send monitors placed on the VAL field. The monitors are sent when the value field exceeds the last monitored field by the specified deadband, ADEL for archiver monitors and MDEL for all other types of monitors. If these fields have a value of zero, everytime the value changes, a monitor will be triggered; if they have a value of -1, everytime the record is scanned, monitors are triggered. See [[RRM 3-14 Concepts#Monitor Specification|Monitor Specification]] for a complete explanation of monitors.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>ADEL<TD>Archive Deadband<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>MDEL<TD>Monitor, i.e. value change, Deadband<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Run-Time Parameters and Simulation Mode Parameters ===

These parameters are used by the run-time code for processing the data fanout record. They are not configurable. They are used to implement the hysteresis factors for monitor callbacks.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>LALM<TD>Last Alarm Monitor Trigger Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>ALST<TD>Last Archiver Monitor Trigger Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>MLST<TD>Last Value Change Monitor Trigger Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No
</TABLE>

== Record Support ==

=== Record Support Routines ===

==== init_record() ====

This routine initializes all output links that are defined. Then it initializes DOL is DOL is a constant or PV_LINK. When initializing the output links and the DOL link, a non-zero value is returned if an error occurs.

==== process() ====

See next section.

==== get_value() ====

This routine fills in the members of <CODE>struct valueDes</CODE> with the VAL fields value and characteristics.

==== get_units() ====

The routine copies the string specified in the EGU field to the location specified by a pointer which is passed to the routine.

==== get_graphic_double() ====

If the referenced field is VAL, HIHI, HIGH, LOW, or LOLO, this routine sets the <CODE>upper_disp_limit</CODE> member of the <CODE>dbr_grDouble</CODE> structure to HOPR and the <CODE>lower_disp_limit</CODE> member to LOPR. If the referenced field is not one of the above fields, then the <CODE>recGblGetControlDouble()</CODE> routine is called.

==== get_control_double() ====

Same as the <CODE>get_graphic_double</CODE> routine except that it uses the <CODE>dbr_ctrlDouble</CODE> structure.

==== get_alarm_double() ====

This sets the members of the <CODE>dbr_alDouble</CODE> structure to the specified alarm limits if the referenced field is VAL:

upper_alarm_limit = HIHI
upper_warning_limit = HIGHT
lower_warning_limit = LOW
lower_alarm_limit = LOLO

If the referenced field is not VAL, the <CODE>recGblGetAlarmDouble()</CODE> routine is called.

=== Record Processing ===

# The <CODE>process()</CODE> routine first retrieves a value for DOL and places it in VAL if OMSL is set to closed loop mode. If ann error occurs, then UDF is set to FALSE.
# PACT is set TRUE.
# VAL is then sent to all the records specified in the OUTA-OUTH fields by calling the <CODE>recGblPutLinkValue()</CODE> for each link.
# Alarms are checked and monitors are called if conditions apply.
# The data fanout's own forward link is then processed.
# PACT is set FALSE, and the <CODE>process()</CODE> routine returns. A -1 is returned if there was an error writing values to one of the output links.

----

EPICS Record Reference Manual - 19 MAY 1998

RRM 3-14 Calculation

2009-12-18T17:20:44Z

LewisMuir: /* Alarm Parameters */ Fixed typo.

[[RRM 3-14|EPICS Record Reference Manual]]

= Calc - Calculation =

The calculation or "Calc" record is used to perform algebraic, relational, and logical operations on values retrieved from other records. The result of its operations can then be accessed by another record so that it can be used.

== Parameter Fields ==

The fields in this record fall into these categories:

* scan parameters
* read parameters
* expression parameters
* operator display parameters
* alarm parameters
* monitor parameters
* run-time parameters

=== Scan Parameters ===

The Calc record has the standard fields for specifying under what circumstances the record will be processed. These fields are listed in [[RRM 3-14 dbCommon#Scan Fields|Scan Fields]]. In addition, [[RRM 3-14 Concepts#Scanning Specification|Scanning Specification]] explains how these fields are used. Since the Calc record supports no direct interfaces to hardware, it cannot be scanned on I/O interrupt, so its SCAN field cannot be <CODE>I/O Intr</CODE>.

=== Read Parameters ===

The read parameters for the Calc record consist of 12 input links INPA, INPB, ... INPL. The fields can be database links, channel access links, or constants. If they are links, they must specify another record's field or a channel access link. If they are constants, they will be initialized with the value they are configured with and can be changed via <CODE>dbPuts</CODE>. They cannot be hardware addresses.

See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on how to specify database links.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TR>
<TD>INPA<TD>Input Link A<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPB<TD>Input Link B<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPC<TD>Input Link C<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPD<TD>Input Link D<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPE<TD>Input Link E<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPF<TD>Input Link F<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPG<TD>Input Link G<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPH<TD>Input Link H<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPI<TD>Input Link I<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPJ<TD>Input Link J<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPK<TD>Input Link K<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPL<TD>Input Link L<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A
</TABLE>

=== Expression ===

At the core of the Calc record lie the CALC and RPCL fields. The CALC field contains the infix expression which the record routine will use when it processes the record. The resulting value is placed in the VAL field and can be accessed from there. The CALC expression is actually converted to opcode and stored as in Reverse Polish Notation in the RPCL field. It is this expression which is actually used to calculate VAL. The Reverse Polish expression is evaluated more efficiently during run-time than an infix expression. CALC can be changed at run-time, and a special record routine calls a function to convert it to Reverse Polish Notation.

The range of expressions supported by the calculation record are separated into operands, algebraic operators, trigonometric operators, relational operators, logical operators, parentheses and commas, and the question mark or '?:' operator. The expression can consist of any of these operators, as well as any of the values from the input links which are the operands.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>CALC<TD>Calculation<TD>DBF_STRING<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>RPCL<TD>Reverse Polish<TD>DBF_NOACCESS<TD>No<TD>0<TD>No<TD>No<TD>N/A<TD>No
</TABLE>

==== Operands ====

The expression uses the values retrieved from the INP''x'' links as operands, though constants can be used as operands too. These values retrieved from the input links are stored in the A-L fields. The values to be used in the expression are simply referenced by the field letter. For instance, the value obtained from the INPA link is stored in the field A, and the value obtained from INPB is stored in field B. The field names can be included in the expression which will operate on their respective values, as in A+B. Also, the RNDM unary function can be included as an operand in the expression in order to generate a random number between 0 and 1.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>A<TD>Input Value A<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>B<TD>Input Value B<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>C<TD>Input Value C<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>D<TD>Input Value D<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>E<TD>Input Value E<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>F<TD>Input Value F<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>G<TD>Input Value G<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>H<TD>Input Value H<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>I<TD>Input Value I<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>J<TD>Input Value J<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>K<TD>Input Value K<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>L<TD>Input Value L<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes
</TABLE>

==== Algebraic Operators ====

* ABS: Absolute value (unary)
* SQR: Square root (unary)
* MIN: Minimum (binary function)
* MAX: Maximum (binary function)
* CEIL: Ceiling (unary)
* FLOOR: Floor (unary)
* LOG: Log base 10 (unary)
* LOGE: Natural log (unary)
* EXP: Exponential function (unary)
* ^: Exponential (binary)
* ** : Exponential (binary)
* + : Addition (binary)
* - : Subtraction (binary)
* * : Multiplication (binary)
* / : Division (binary)
* % : Modulo (binary)
* NOT: Negate (unary)

==== Trigonometric Operators ====

* SIN: Sine
* SINH: Hyperbolic sine
* ASIN: Arc sine
* COS: Cosine
* COSH: Hyperbolic cosine
* ACOS: Arc cosine
* TAN: Tangent
* TANH: Hyperbolic tangent
* ATAN: Arc tangent

==== Relational Operators ====

* >= : Greater than or equal to
* > : Greater than
* <= : Less than or equal to
* <: Less than
* # : Not equal to
* = : Equal to

==== Logical Operators ====

* && : And
* || : Or
* ! : Not

==== Bitwise Operators ====

* | : Bitwise Or
* & : Bitwise And
* OR : Bitwise Or
* AND: Bitwise And
* XOR: Bitwise Exclusive Or
* ~ : One's Complement
* << : Left shift
* >> : Right shift

==== Parentheses and Comma ====

The open and close parentheses are supported. Nested parenthesis are supported.

The comma is supported when used to separate the arguments of a binary function.

==== Conditional Expression ====

The C language's question mark operator is supported. The format is:

(condition)? True result : False result

=== Expression Examples ===

==== Algebraic ====

A + B + 10

* Result is A + B

==== Relational ====

(A + B) < (C + D)

* Result is 1 if (A+B) < (C+D)
* Result is 0 if (A+B) >= (C+D)

==== Question Mark ====

(A+B)<(C+D)?E:F+L+10

* Result is E if (A+B) < (C+D)
* Result is F+L+10 if (A+B) >= (C+D)

(A+B)<(C+D)?E

* Result is E if (A+B) < (C+D)
* Result is unchanged if (A+B) >= (C+D)

==== Logical ====

A&B

* Causes the following to occur:
** Convert A to integer
** Convert B to integer
** Bit-wise And A and B
** Convert result to floating point

=== Operator Display Parameters ===

These parameters are used to present meaningful data to the operator. These fields are used to display VAL and the other parameters of the calculation record either textually or graphically.

The EGU field contains a string of up to 16 characters which is supplied by the user and which describes the values being operated upon. The string is retrieved whenever the routine <CODE>get_units</CODE> is called. The EGU string is solely for an operator's sake and does not have to be used.

The HOPR and LOPR fields only refer to the limits of the VAL, HIHI, HIGH, LOW, and LOLO fields. PREC controls the precision of the VAL field.

See [[RRM 3-14 dbCommon#Fields Common to All Record Types|Fields Common to All Record Types]] for more on the record name (NAME) and description (DESC) fields.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>EGU<TD>Engineering Units<TD>STRING [16]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>PREC<TD>Display Precision<TD>SHORT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>HOPR<TD>High Operating Range<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>LOPR<TD>Low Operating Range<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>NAME<TD>Record Name<TD>STRING [29]<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>DESC<TD>Description<TD>STRING [29]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Alarm Parameters ===

The possible alarm conditions for the Calc record are the SCAN, READ, Calculation, and limit alarms. The SCAN and READ alarms are called by the record support routines. The Calculation alarm is called by the record processing routine when the CALC expression is an invalid one, upon which an error message is generated.

The following alarm parameters which are configured by the user define the limit alarms for the VAL field and the severity corresponding to those conditions.

The HYST field defines an alarm deadband for each limit. See [[RRM 3-14 Concepts#Alarm Specification|Alarm Specification]] for a complete explanation of alarms and these fields. [[RRM 3-14 dbCommon#Alarm Fields|Alarm Fields]] lists other fields related to alarms that are common to all record types.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>HIHI<TD>Hihi Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HIGH<TD>High Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LOW<TD>Low Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LOLO<TD>Lolo Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HHSV<TD>Severity for a Hihi Alarm<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HSV<TD>Severity for a High Alarm<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LSV<TD>Severity for a Low Alarm<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LLSV<TD>Severity for a Lolo Alarm<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HYST<TD>Alarm Deadband<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Monitor Parameters ===

These parameters are used to determine when to send monitors for the value fields. The monitors are sent when the value field exceeds the last monitored field by the appropriate deadband, the ADEL for archiver monitors and the MDEL field for all other types of monitors. If these fields have a value of zero, everytime the value changes, monitors are triggered; if they have a value of -1, everytime the record is scanned, monitors are triggered. See [[RRM 3-14 Concepts#Monitor Specification|Monitor Specification]] for a complete explanation of monitors.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>ADEL<TD>Archive Deadband<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>MDEL<TD>Monitor, i.e. value change, Deadband<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Run-time Parameters ===

These fields are not configurable using a configuration too and none are modifiable at run-time. They are used to process the record.

The LALM field is used to implement the hysteresis factor for the alarm limits.

The LA-LL fields are used to decide when to trigger monitors for the corresponding fields. For instance, if LA does not equal the value for A, monitors for A are triggered. The MLST and MLST fields are used in the same manner for the VAL field.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>LALM<TD>Last Alarmed Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>ALST<TD>Archive Last Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>MLST<TD>Monitor Last Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LA<TD>Previous Input Value for A<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LB<TD>Previous Input Value for A<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LC<TD>Previous Input Value for A<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LD<TD>Previous Input Value for A<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LE<TD>Previous Input Value for A<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LF<TD>Previous Input Value for A<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LG<TD>Previous Input Value for A<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LH<TD>Previous Input Value for A<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LI<TD>Previous Input Value for A<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LJ<TD>Previous Input Value for A<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LK<TD>Previous Input Value for A<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LL<TD>Previous Input Value for A<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No
</TABLE>

== Record Support ==

=== Record Support Routines ===

==== init_record ====

For each constant input link, the corresponding value field is initialized with the constant value if the input link is CONSTANT or a channel access link is created if the input link is PV_LINK.

A routine postfix is called to convert the infix expression in CALC to reverse polish notation. The result is stored in RPCL.

==== process ====

See next section.

==== special ====

This is called if CALC is changed. special calls postfix.

==== get_value ====

Fills in the values of struct valueDes so that they refer to VAL.

==== get_units ====

Retrieves EGU.

==== get_precision ====

Retrieves PREC.

==== get_graphic_double ====

Sets the upper display and lower display limits for a field. If the field is VAL, HIHI, HIGH, LOW, or LOLO, the limits are set to HOPR and LOPR, else if the field has upper and lower limits defined they will be used, else the upper and lower maximum values for the field type will be used.

==== get_control_double ====

Sets the upper control and the lower control limits for a field. If the field is VAL, HIHI, HIGH, LOW, or LOLO, the limits are set to HOPR and LOPR, else if the field has upper and lower limits defined they will be used, else the upper and lower maximum values for the field type will be used.

==== get_alarm_double ====

Sets the following values:

upper_alarm_limit = HIHI
upper_warning_limit = HIGH
lower_warning_limit = LOW
lower_alarm_limit = LOLO

=== Record Processing ===

Routine process implements the following algorithm:

# Fetch all arguments.
# Call routine calcPerform, which calculates VAL from the postfix version of the expression given in CALC. If calcPerform returns success UDF is set to FALSE.
# Check alarms. This routine checks to see if the new VAL causes the alarm status and severity to change. If so, NSEV, NSTA and LALM are set. It also honors the alarm hysteresis factor (HYST). Thus the value must change by at least HYST before the alarm status and severity changes.
# Check to see if monitors should be invoked.
#* Alarm monitors are invoked if the alarm status or severity has changed.
#* Archive and value change monitors are invoked if ADEL and MDEL conditions are met.
#* Monitors for A-L are checked whenever other monitors are invoked.
#* NSEV and NSTA are reset to 0.
# Scan forward link if necessary, set PACT FALSE, and return.

----

EPICS Record Reference Manual - 19 MAY 1998

RRM 3-14 String Calcout

2009-05-19T17:48:57Z

LewisMuir: /* Output Parameters */ Fixed IVOA and IVOV mix-up

[[RRM 3-14|EPICS Record Reference Manual]]

= sCalcout Record =

<i>This page actually describes the EPICS-3.14-compatible version of the sCalcout record. Text that does not apply to the 3.13-compatible version is rendered in <font color="blue">blue</font>. Documentation specific to the 3.13-compatible version is currently not available in this format, but may be found in the 'std' module of a 3.13-compatible synApps package.</i>

The String Calculation Output or "sCalcout" record is derived from the Calcout record and extends it by supporting string expressions and operands. The record has 12 numeric fields (A...L) and 12 string fields (AA...LL), which are used as input variables for the expression. It calls an extended version of the EPICS calculation engine that accepts string arguments, supports a variety of string functions, and produces both numeric and string results, in the VAL and SVAL fields, respectively. The record's output link writes string or numeric data, depending on the data type of the field to which it is linked.

== Parameter Fields ==

The fields in this record fall into the following categories:

* Scan Parameters
* Read Parameters
* Expression Parameters
* Output Parameters
* Operator Display Parameters
* Alarm Parameters
* Monitor Parameters
* Run-Time Parameters

=== Scan Parameters ===

The sCalcout record has the standard fields for specifying under what circumstances the record will be processed. These fields are listed in [[RRM 3-14 dbCommon#Scan Fields|Scan Fields]]. In addition, [[RRM 3-14 Concepts#Scanning Specification|Scanning Specification]] explains how these fields are used. Since the sCalcout record supports no direct interfaces to input hardware that might generate an interrupt, it cannot be scanned on I/O interrupt, so its SCAN field cannot be <CODE>I/O Intr</CODE>.

=== Read Parameters ===

The read parameters for the sCalcout record consist of 24 input links: 12 for numeric values (INPA→A, INPB→B, ... INPL→L); and 12 for string values (INAA→AA, INBB→BB, ... INLL→LL). The fields can be database links, channel access links, or constants. If they are links, they must contain a PV name. If they are constants, associated value fields will be initialized with the constants. These fields cannot be hardware addresses. In addition, the sCalcout record contains the fields INAV, INBV, ... INLV, which indicate the status of the links to numeric fields, and the fields IAAV, IBBV, ... ILLV, which indicate the status of the links to string fields. These fields indicate whether or not the specified PV was found and a link to it established. See [[#Operator Display Parameters|Operator Display Parameters]] for an explanation of these fields.

See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on how to specify database links.

<TABLE BORDER="1">
<TR><TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor
<TR><TD>INPA<TD>Input Link A<TD>INLINK<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes
<TR><TD>INPB<TD>Input Link B<TD>INLINK<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes
<TR><TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...
<TR><TD>INPL<TD>Input Link L<TD>INLINK<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes
<TR><TD>INAA<TD>Input Link AA<TD>INLINK<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes
<TR><TD>INBB<TD>Input Link BB<TD>INLINK<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes
<TR><TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...
<TR><TD>INLL<TD>Input Link LL<TD>INLINK<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes
</TABLE>

=== Expression Parameters ===

<TABLE BORDER>

<TR>
<TH>Field</TH>
<TH>Summary</TH>
<TH>Type</TH>
<TH>DCT</TH>
<TH>Initial</TH>
<TH>Access</TH>
<TH>Modify</TH>
<TH>Rec Proc Monitor</TH>
<TH>PP</TH>
</TR>

<TR>
<TD>CALC</TD>
<TD>Infix expression</TD>
<TD>String[40]</TD>
<TD>Yes</TD>
<TD>""</TD>
<TD>Yes</TD>
<TD>Yes</TD>
<TD>Yes</TD>
<TD>No</TD>
</TR>

<TR>
<TD>CLCV</TD>
<TD>CALC Valid</TD>
<TD>Long</TD>
<TD>No</TD>
<TD>0</TD>
<TD>Yes</TD>
<TD>No</TD>
<TD>Yes</TD>
<TD>No</TD>
</TR>

<TR>
<TD>OCAL</TD>
<TD>Infix expression</TD>
<TD>String[40]</TD>
<TD>Yes</TD>
<TD>""</TD>
<TD>Yes</TD>
<TD>Yes</TD>
<TD>Yes</TD>
<TD>No</TD>
</TR>

<TR>
<TD>OCLV</TD>
<TD>OCAL Valid</TD>
<TD>Long</TD>
<TD>No</TD>
<TD>0</TD>
<TD>Yes</TD>
<TD>No</TD>
<TD>Yes</TD>
<TD>No</TD>
</TR>
</TABLE>

Like the Calcout record, the sCalcout record has the fields CALC and OCAL, in which the developer or user can enter an infix expression to be evaluated when the record is processed. The numeric value resulting from evaluation of CALC will be placed in the VAL field, and the resulting string value will be placed in the SVAL field. VAL can then be used by the OOPT field (see [[#Output Parameters|Output Parameters]]) to determine whether or not to write to the output link or post an output event. Either VAL and SVAL can also be written to the output link. (If you elect to write an output value, the record will choose between VAL and SVAL, depending on the data type of the field at the other end of the output link.)

The CALC and OCAL expressions are actually converted to opcodes and stored in postfix notation in the RPCL and ORPC fields. It is these expressions which are actually used to calculate VAL. A postfix expression can be evaluated more efficiently at run-time than an infix expression would be. When CALC or OCAL is changed at run-time, the record-support routine special() will call a function to check it, and convert it to postfix.

In simple cases, OCAL is ignorable. It's use will be described later, in [[#Output Parameters|Output Parameters]].

sCalcout-record expressions are very similar to standard EPICS Calc expressions, such as those used with the Calcout record. But in place of the standard EPICS calc engine (which does not support string fields or operations), sCalcout-record uses the <i>sCalc</i> engine, a separate piece of software, which normally is [[#Availability|distributed]] with the sCalcout record. The differences between these engines that matter for numeric expressions are the following:

* The constants S2R (arc-seconds-to-radians) and R2S are supported.
* <font color="blue">The functions MIN() and MAX() may have more than two arguments.</font>
* <font color="blue">The binary operators '>&' (larger of the operands) and '<&' (smaller) are supported.</font>
* The binary operator '!=' (not equal) is a permitted alternatives '#'.
* The unary operator '@' selects an input field by number. (E.g., '@0' means 'A'. If 'B' has the value 3, '@b' means 'D'.)

Expressions supported by the sCalcout record can involve operands, algebraic operators and functions, trigonometric functions, relational operators, logical operators, string operators and functions, parentheses and commas, and the conditional '?:' operator. Numeric and string operands are supported, and
any operand can be used with any operator or function. If an operand has the "wrong" type for the function or operator with which it is used, the operand will be converted implicitly to the correct type.

Grouping of operands with parentheses is important not only to specify the order in which operations are to be performed, but also to distinguish operands from operators whose names are spelled out, such as the logical operator 'AND'. For example, the expression 'AANDB', which could have meant 'A AND B', will be (mis)interpreted by the parser as 'AA NDB'.

==== Operands ====

The expression can use the values retrieved from the input links as operands, though constants can be used as operands too. These values retrieved from the input links are stored in the A-L, and AA-LL fields. The values to be used in the expression are simply referenced by the field name. For example, the value obtained from the INPA link is stored in the field A, and the value obtained from INPB is stored in field B. The field names can be included in the expression which will operate on their respective values, as in A+B.

<TABLE BORDER>

<TR>
<TH>Field</TH>
<TH>Summary</TH>
<TH>Type</TH>
<TH>DCT</TH>
<TH>Initial</TH>
<TH>Access</TH>
<TH>Modify</TH>
<TH>Rec Proc Monitor</TH>
<TH>PP</TH>
</TR>

<TR>
<TD>A</TD>
<TD>Input Value A</TD>
<TD>DOUBLE</TD>
<TD>No</TD>
<TD>0</TD>
<TD>Yes</TD>
<TD>Yes/No*</TD>
<TD>Yes</TD>
<TD>Yes</TD>
</TR>

<TR>
<TD>B</TD>

<TD>Input Value B</TD>
<TD>DOUBLE</TD>
<TD>No</TD>
<TD>0</TD>
<TD>Yes</TD>
<TD>Yes/No*</TD>
<TD>Yes</TD>
<TD>Yes</TD>
</TR>

<TR>
<TD>...</TD>
<TD>...</TD>
<TD>...</TD>
<TD>...</TD>
<TD>...</TD>
<TD>...</TD>
<TD>...</TD>
<TD>...</TD>
<TD>...</TD>
</TR>

<TR>
<TD>L</TD>
<TD>Input Value L</TD>
<TD>DOUBLE</TD>
<TD>No</TD>
<TD>0</TD>
<TD>Yes</TD>
<TD>Yes/No*</TD>
<TD>Yes</TD>
<TD>Yes</TD>
</TR>

<TR><TD></TR>

<TR>
<TD>AA</TD>
<TD>Input string AA</TD>
<TD>STRING (40)</TD>
<TD>No</TD>
<TD>0</TD>
<TD>Yes</TD>
<TD>Yes/No*</TD>
<TD>Yes</TD>
<TD>Yes</TD>
</TR>

<TR>
<TD>BB</TD>
<TD>Input string BB</TD>
<TD>STRING (40)</TD>
<TD>No</TD>
<TD>0</TD>
<TD>Yes</TD>
<TD>Yes/No*</TD>
<TD>Yes</TD>
<TD>Yes</TD>
</TR>

<TR>
<TD>...</TD>
<TD>...</TD>
<TD>...</TD>
<TD>...</TD>
<TD>...</TD>
<TD>...</TD>
<TD>...</TD>
<TD>...</TD>
<TD>...</TD>
</TR>

<TR>
<TD>LL</TD>
<TD>Input string LL</TD>
<TD>STRING (40)</TD>
<TD>No</TD>
<TD>0</TD>
<TD>Yes</TD>
<TD>Yes/No*</TD>
<TD>Yes</TD>
<TD>Yes</TD>
</TR>

</TABLE>

Legend: * If a non-blank input link is associated with this field, then it may
not be modified. This is true even if the input link is invalid (in which case, the value will be 0, for a numeric field, or "Huh?", for a string field).

There are a few special operands not associated with input fields, but
defined by the record (more exactly, defined by the calc engine the record uses
to evaluate expressions). All but <code>RNDM</code> are constants.

<table border>

<tr>
<td align=center valign=top>PI
<td valign=top>3.141592654

<tr>
<td align=center valign=top>D2R
<td valign=top>Degrees to radians (PI/180)

<tr>
<td align=center valign=top>R2D
<td valign=top>Radians to degrees (1/D2R)

<tr>
<td align=center valign=top>S2R
<td valign=top>Arc seconds to radians (D2R/3600)

<tr>
<td align=center valign=top>R2S
<td valign=top>Radians to arc seconds (1/S2R)

<tr>
<td align=center valign=top>RNDM
<td valign=top>Random number between 0 and 1.

</table>

==== Algebraic Functions/Operators ====

<table border>

<tr>
<th align=center valign=top>Op
<th valign=top>Description
<th valign=top>Example

<tr>
<td align=center valign=top>ABS
<td valign=top>Absolute value (one-argument function)
<td><code>ABS(A)</code>

<tr>
<td align=center valign=top>SQRT
<td valign=top>Square root (one-argument function) (SQR is deprecated)
<td><code>SQRT(A)</code>

<tr>
<td align=center valign=top>MIN
<td valign=top>Minimum (two<font color="blue">-or-more</font>-argument function)
<td><code>MIN(A,B)</code>

<tr>
<td align=center valign=top>MAX
<td valign=top>Maximum (two<font color="blue">-or-more</font>-argument function)
<td><code>MAX(A,B)</code>

<tr>
<td align=center valign=top>CEIL
<td valign=top>Ceiling (one-argument function)
<td><code>CEIL(A)</code>

<tr>
<td align=center valign=top>FLOOR
<td valign=top>Floor (one-argument function)
<td><code>FLOOR(A)</code>

<tr>
<td align=center valign=top>INT
<td valign=top>Nearest integer (one-argument function)
<td><code>INT(A)</code>

<tr>
<td align=center valign=top>NINT
<td valign=top>Nearest integer (one-argument function)
<td><code>NINT(A)</code>

<tr>
<td align=center valign=top>LOG
<td valign=top>Log base 10 (one-argument function)
<td><code>LOG(A)</code>

<tr>
<td align=center valign=top>LN
<td valign=top>Natural logarithm (one-argument function)
<td><code>LN(A)</code>

<tr>
<td align=center valign=top>LOGE
<td valign=top>Deprecated synonym for 'LN'
<td><code>LOGE(A)</code>

<tr>
<td align=center valign=top>EXP
<td valign=top>Exponential function (unary)
<td><code>EXP(A)</code>

<tr>
<td align=center valign=top>^
<td valign=top>Exponential (binary) (Same as '**'.)
<td><code>A^B</code>

<tr>
<td align=center valign=top>**
<td valign=top>Exponential (binary) (Same as '^'.)
<td><code>A**B</code>

<tr>
<td align=center valign=top>+
<td valign=top>Addition (binary)
<td><code>A+B</code>

<tr>
<td align=center valign=top>-
<td valign=top>Subtraction (binary)
<td><code>A-B</code>

<tr>
<td align=center valign=top>*
<td valign=top>Multiplication (binary)
<td><code>A*B</code>

<tr>
<td align=center valign=top>/
<td valign=top>Division (binary)
<td><code>A/B</code>

<tr>
<td align=center valign=top>%
<td valign=top>Modulo (binary)
<td><code>A%B</code>

<tr>
<td align=center valign=top>-
<td valign=top>Negate (unary)
<td><code>-A</code>

<tr>
<td align=center valign=top>NOT
<td valign=top>Negate (unary)
<td><code>NOT A</code>

<tr>
<td align=center valign=top><font color="blue">>&</font>
<td valign=top><font color="blue">Max (binary)</font>
<td><font color="blue"><code>A>?B</code></font>

<tr>
<td align=center valign=top><font color="blue"><&</font>
<td valign=top><font color="blue">Min (binary)</font>
<td><font color="blue"><code>A<?B</code></font>
</table>

==== Trigonometric Functions ====

<table border>

<tr>
<th align=center valign=top>Op
<th valign=top>Description
<th valign=top>Example

<tr>
<td align=center valign=top>SIN
<td valign=top>Sine (one-argument function)
<td><code>SIN(A)</code>

<tr>
<td align=center valign=top>SINH
<td valign=top>Hyperbolic sine (one-argument function)
<td><code>SINH(A)</code>

<tr>
<td align=center valign=top>ASIN
<td valign=top>Arc sine (one-argument function)
<td><code>ASIN(A)</code>

<tr>
<td align=center valign=top>COS
<td valign=top>Cosine (one-argument function)
<td><code>COS(A)</code>

<tr>
<td align=center valign=top>COSH
<td valign=top>Hyperbolic cosine (one-argument function)
<td><code>COSH(A)</code>

<tr>
<td align=center valign=top>ACOS
<td valign=top>Arc cosine (one-argument function)
<td><code>ACOS(A)</code>

<tr>
<td align=center valign=top>TAN
<td valign=top>Tangent (one-argument function)
<td><code>TAN(A)</code>

<tr>
<td align=center valign=top>TANH
<td valign=top>Hyperbolic tangent (one-argument function)
<td><code>TANH(A)</code>

<tr>
<td align=center valign=top>ATAN
<td valign=top>Arc tangent (one-argument function)
<td><code>ATAN(A)</code>

<tr>
<td align=center valign=top>ATAN2
<td valign=top>Alternate form of arctangent (two-argument function)
<td><code>ATAN2(A,B)</code>

</table>

==== Relational Operators ====

<table border>

<tr>
<th align=center valign=top>Op
<th valign=top>Description
<th valign=top>Example

<tr>
<td align=center valign=top>>=
<td valign=top>Greater than or equal to
<td><code>A>=B</code>

<tr>
<td align=center valign=top>>
<td valign=top>Greater than
<td><code>A>B</code>

<tr>
<td align=center valign=top><=
<td valign=top>Less than or equal to
<td><code>A<=B</code>

<tr>
<td align=center valign=top><
<td valign=top>Less than
<td><code>A<B</code>

<tr>
<td align=center valign=top>!=
<td valign=top>Not equal to (same as '#')
<td><code>A!=B</code>

<tr>
<td align=center valign=top>#
<td valign=top>Not equal to (same as '!=')
<td><code>A#B</code>

<tr>
<td align=center valign=top>==
<td valign=top>Equal to (same as '=')
<td><code>A==B</code>

<tr>
<td align=center valign=top>=
<td valign=top>Equal to (same as '==')
<td><code>A=B</code>

</table>

==== Logical Operators ====

<table border>

<tr>
<th align=center valign=top>Op
<th valign=top>Description
<th valign=top>Example

<tr>
<td align=center valign=top>&&
<td valign=top>Logical AND
<td><code>A&&B</code>

<tr>
<td align=center valign=top>||
<td valign=top>Logical OR
<td><code>A||B</code>

<tr>
<td align=center valign=top>!
<td valign=top>Logical NOT
<td><code>!A</code>

</table>

==== Bitwise Operators ====

<table border>

<tr>
<th align=center valign=top>Op
<th valign=top>Description
<th valign=top>Example

<tr>
<td align=center valign=top>|
<td valign=top>Bitwise OR
<td><code>A|B</code>

<tr>
<td align=center valign=top>OR
<td valign=top>Bitwise OR
<td><code>A OR B</code>

<tr>
<td align=center valign=top>&
<td valign=top>Bitwise AND
<td><code>A&B</code>

<tr>
<td align=center valign=top>AND
<td valign=top>Bitwise AND
<td><code>A AND B</code>

<tr>
<td align=center valign=top>XOR
<td valign=top>Bitwise Exclusive OR
<td><code>A XOR B</code>

<tr>
<td align=center valign=top>~
<td valign=top>One's Complement
<td><code>~A</code>

<tr>
<td align=center valign=top><<
<td valign=top>Left shift
<td><code>A<<B</code>

<tr>
<td align=center valign=top>>>
<td valign=top>Right shift
<td><code>A>>B</code>
</table>

==== Parentheses and Comma ====

The open and close parentheses are supported. Nested parenthesis are supported.

The comma is supported when used to separate the arguments of a binary function.

==== Conditional Expression ====

The C language's question mark operator is supported. The format is:

<pre> <expression> ? <expression-true result> : <expression-false result></pre>

==== String Functions/Operators ====

Most two-argument string functions and binary string operators are "overloaded"
numeric functions and operators that perform string operations only if
both of their arguments/operands are strings.

<P><table border>
<tr>
<th align=center valign=top>Op
<th valign=top>Description
<th valign=top>Example

<tr>
<td align=center valign=top>MIN
<td valign=top>Minimum lexically (two<font color="blue">-or-more</font>-argument function)
<td><code>MIN('a','b') </code>→<code> 'a'</code>

<tr>
<td align=center valign=top>MAX
<td>Maximum lexically (two<font color="blue">-or-more</font>-argument function)
<td><code>MAX('a','b') </code>→<code> 'b'</code>

<tr>
<td align=center valign=top>INT
<td>Find first number in string; return nearest integer (one-argument
function)
<td><code>INT('1.9') </code>→<code> 1</code><br>
<code>INT('abc1.9') </code>→<code> 1</code>

<tr>
<td align=center valign=top>NINT
<td>Find first number in string; return nearest integer (one-argument
function)
<td><code>NINT('1.9') </code>→<code> 2</code><br>
<code>NINT('abc1.9') </code>→<code> 2</code>

<tr>
<td align=center valign=top>+
<td>Concatenate (binary)
<td><code>'a'+'b' </code>→<code> 'ab'</code>

<tr>
<td align=center valign=top>-
<td>Delete first occurrence of substring (binary)
<td><code>'abca'-'a' </code>→<code> 'bca'</code>

<tr>
<td align=center valign=top><font color="blue">-|</font>
<td><font color="blue">Delete first occurrence of substring (binary)</font>
<td><font color="blue"><code>'abca'-'a' </code>→<code> 'bca'</code></font>

<tr>
<td align=center valign=top><font color="blue">|-</font>
<td><font color="blue">Delete last occurrence of substring (binary)</font>
<td><font color="blue"><code>'abca'-'a' </code>→<code> 'abc'</code></font>

<tr>
<td align=center valign=top>>=
<td>Lexically greater than or equal (binary)
<td><code>'a'>='b' </code>→<code> 0</code>

<tr>
<td align=center valign=top>>
<td>Lexically greater than (binary)
<td><code>'a'>'b' </code>→<code> 0</code>

<tr>
<td align=center valign=top><=
<td>Lexically less than or equal (binary)
<td><code>'a'<='b' </code>→<code> 1</code>

<tr>
<td align=center valign=top><
<td>Lexically less than (binary)
<td><code>'a'<'b' </code>→<code> 1</code>

<tr>
<td align=center valign=top>!=
<td>Lexically not equal to (binary)
<td><code>'a'!='b' </code>→<code> 1</code>

<tr>
<td align=center valign=top>==
<td>Lexically equal to (binary)
<td><code>'a'=='b' </code>→<code> 0</code>

<tr>
<td align=center valign=top>DBL
<td>Convert argument to double (one-argument function)
<td><code>DBL('1') </code>→<code> 1.0</code><br>
<code>DBL('abc1.23') </code>→<code> 1.23</code>

<tr>
<td align=center valign=top>STR
<td>Convert argument to string (one-argument function)
<td><code>STR(1) </code>→<code> '1.00000000'</code>

<tr>
<td align=center valign=top>BYTE
<td>Convert first character of string argument to double (one-argument function)
<td><code>BYTE('abc') </code>→<code> 97.0</code>

<tr>
<td align=center valign=top>PRINTF
<td valign=top>Return string constructed from format string and string or
double argument (two-argument function)  (NOTE: '$P' is a synonym for PRINTF)

<BR>Allowed format indicators: <B>%cdeEfgGiosuxX</B>
<BR>Disallowed indicators:<B> *</B>
<td><code>PRINTF("%.2f",1.23) </code>→<code> '1.23'</code>

<tr>
<td align=center valign=top>SSCANF
<td>Return string or double parsed from string argument according
to format string (two-argument function) (NOTE: '$S' is a synonym for SSCANF)

<BR>Allowed format indicators: <B>%*[cdeEfgGhilosuxX</B>
<BR>Disallowed indicators: <B>$npw</B>
<td><code>SSCANF('V=1.25', "%*2c%lf") </code>→<code> 1.25</code>

<tr>
<td align=center valign=top><font color="blue">TR_ESC</font>
<td><font color="blue">Translate escape sequences into the characters they represent
(one-argument function). (NOTE: '$T' is a synonym for TR_ESC.)
<BR>TR_ESC() applies dbTranslateEscape() to its argument.
<BR>This function is approximately the opposite of ESC().
<BR>An escaped null character will terminate the result string</font>
<td><font color="blue"><code>TR_ESC("a\x62c") </code>→<code> 'abc'</code></font>

<tr>
<td align=center valign=top><font color="blue">ESC</font>
<td><font color="blue">Translate escape characters into equivalent escape sequences.
(one-argument function) (NOTE: '$E' is a synonym for ESC)
<BR>ESC() applies epicsStrSnEscaped() to its argument.
<BR>This function is approximately the opposite of TR_ESC().
<BR>The first null character found in the input string terminates it.
If there is no null chaacter, the string is assumed to be 40
characters long.</font>
<td><font color="blue"><code>ESC("a<return>c") </code>→<code> 'a\rc'</code></font>

<tr>
<td align=center valign=top>[
<td>Substring
<td><code>'abcdef'[1,3] </code>→<code> 'bcd'</code>
<code><BR>'abcdef'['ab','ef'] </code>→<code> 'cd'</code>
<code><BR>'abcdef'[0,-1] </code>→<code> 'abcdef'</code>

<tr>
<td align=center valign=top>{
<td>Substring substitution
<td><code>'abcdef'{'cd','XX'} </code>→<code> 'abXXef'</code>

<tr>
<td align=center valign=top>"
<td>String indicator
<td><code>"abc"</code>

<tr>
<td align=center valign=top>'
<td>String indicator
<td><code>'abc'</code>

</table>

==== Operand-Array Operators ====

<table border>

<tr>
<th align=center valign=top>Op
<th valign=top>Description
<th valign=top>Example

<tr>
<td align=center valign=top>@
<td>Numeric array element. Regard the numeric fields A-L as an array whose elements
are numbered 0-11, and return the element whose number follows. (unary)
<td><code>@A</code>

<tr>
<td align=center valign=top>@@
<td>String array element. Regard the string fields AA-LL as an array of strings whose
elements are numbered 0-11, and return the element whose number follows. (unary)
<td><code>@@A</code>

</table>

==== Examples ====

===== Algebraic Examples =====
A + B + 10
Result is A + B + 10

===== Relational Examples =====
(A + B) < (C + D)
Result is 1 if (A+B) < (C+D)
Result is 0 if (A+B) >= (C+D)

===== Question Mark Examples =====
(A+B)<(C+D)?E:F+L+10
Result is E if (A+B) < (C+D)
Result is F+L+10 if (A+B) >= (C+D)

(A+B)<(C+D)?E
Result is E if (A+B) < (C+D)
Result is unchanged if (A+B) >= (C+D)

===== Logical Examples =====
A&B
Causes the following to occur:
* Convert A to integer
* Convert B to integer
* Perform bit-wise AND of A and B
* Convert result to floating point

===== String Examples =====
A + "abc"<br>
A + "abc1.2"<br>
A + AA (where AA = "abc1.2")
:Result is A. The strings "abc" and "abc1.2" will be converted implicitly to the number 0.

A + DBL("abc1.2")
:Result is A + 1.2. Explicit conversion to a number (by DBL, INT, or NINT) is more aggressive than implicit conversion, and skips leading non-numeric characters.

"abc" + "def"
:Result is "abcdef".

PRINTF("abc%1.2f", A) (where A = 1.2345)
:Result is "abc1.23".
:NOTE: unlike the c-language function printf(<format>,<arg1>,<arg2>,...), this function accepts only one argument after the format string.

SSCANF(AA, "%*3c%lf") (where AA = "abc1.2")
:Result is "1.20000000". (The format fragment "%*3c" directs sscanf to ignore three characters.)<br>
:NOTE: unlike the c-language function sscanf(<source>,<format>,<dest1>,<dest2>,...), this function cannot store to a variable, but only to the value stack.

BYTE("ABC")
:Result is 65, the ASCII code for "A" in decimal.

"abcdef"[2,4]
:Result is "cde". (The first character of the string is numbered "0".)

"abcdef"[-2,-1]
:Result is "ef". (The last character of the string is numbered "-1".)

"abcdef"["ab","ef"]
:Result is "cd". (If the first argument is a string, it returns the index of the first character after a successful match, or the first character in the string if no match was found. If the second argument is a string, it returns the index of the last character before a successful match, or the last character in the string if no match was found.) In other words, string arguments <i>delimit</i> the substring they are specifying without participating in it.)

A==2 ? "yes" : "no"
:Result is "yes" if A == 2; otherwise, result is "no".

"abcdef"{"bcd","dcb"}
:Result is "adcbef".

"abcdef"{"zzz","dcb"}
:Result is "abcdef". (If no match, then no replacement.)

"abcdef"[1,-2][1,-2]
:Result is "cd"

===== Array Examples =====
@0
:Result is the value of the numeric variable A. ("@0" is just another name for A.)

@@0
:Result is the value of the string variable AA.

@(A+B)
:Result is the value of the numeric variable whose number is given by the sum of A and B.

=== Output Parameters ===

These parameters specify and control the output capabilities of the
sCalcout record. They determine when to write the output, where to write
it, and what the output will be. The OUT link specifies the Process Variable
to which the result will be written. The OOPT field determines the condition
that causes the output link to be written to. It's a menu field that has
six choices:

<table border>
<tr><td valign=top>
<TT>Every Time</TT><td valign=top>write output every time record is processed.

<tr><td valign=top>
<TT>On Change</TT><td valign=top>write output every time VAL changes, i.e., every time the result of the expression changes.

<tr><td valign=top>
<TT>When Zero</TT><td valign=top>when record is processed, write output if VAL is zero.

<tr><td valign=top>
<TT>When Non-zero</TT><td valign=top>when record is processed, write output if VAL is non-zero.

<tr><td valign=top>
<TT>Transition to Zero</TT><td valign=top>when record is processed, write output only if VAL is zero and last value was non-zero.

<tr><td valign=top>
<TT>Transition to Non-zero</TT><td valign=top>when record is processed, write output only if VAL is non-zero and last value was zero.

<tr><td valign=top>
<TT>Never</TT><td valign=top>Don't write output ever.

</table>

The DOPT field determines what data is written to the output link when
the output is executed. The field is a menu field with two options: <TT>Use
CALC</TT> or <TT>Use OCAL</TT>. If <TT>Use CALC</TT> is specified, when
the record writes its output it will write the result of the expression
in the CALC record, that is, it will write the value of the VAL [SVAL]
field to a double [string] destination. If <TT>Use OCAL</TT> is specified,
the record will instead write the result of the expression in the OCAL
field, which is contained in the OVAL field (string result in the OSV)
field. The OCAL field is exactly like the CALC field and has the same functionality:it can contain the string representation of an expression which is evaluated at run-time. Thus, if necessary, the record can use the result of the CALC expression to determine if data should be written and can use the result of the OCAL expression as the data to write.

If the OEVT field specifies a non-zero integer and the condition
in the OOPT field is met, the record will post a corresponding event. If
the ODLY field is non-zero, the record pauses for the specified number
of seconds before executing the OUT link or posting the output event. During
this waiting period the record is "active" and will not be processed again
until the wait is over. The field DLYA is equal to 1 during the delay period.
The resolution of the delay entry is 1/60 of a second (it uses the VxWorks
<TT>tickLib</TT>).

The IVOA field specifies what action to take with the OUT link
if the sCalcout record enters an INVALID alarm status. The options are
<TT>Continue normally</TT>, <TT>Don't drive outputs</TT>, and <TT>Set output
to IVOV</TT>. If the IVOA field is <TT>Set output to IVOV</TT>, the data
entered into the IVOV field is written to the OUT link if the record alarm
severity is INVALID.

<TABLE BORDER>
<TR>
<TH>Field</TH>
<TH>Summary</TH>
<TH>Type</TH>
<TH>DCT</TH>
<TH>Initial</TH>
<TH>Access</TH>
<TH>Modify</TH>
<TH>Rec Proc Monitor</TH>
<TH>PP</TH>
</TR>

<TR>
<TD>OUT</TD>
<TD>Output Specification</TD>
<TD>OUTLINK</TD>
<TD>Yes</TD>
<TD>0</TD>
<TD>Yes</TD>
<TD>Yes</TD>
<TD>N/A</TD>
<TD>No</TD>
</TR>

<TR>
<TD>OOPT</TD>
<TD>Output Execute Option</TD>
<TD>Menu</TD>
<TD>Yes</TD>
<TD>0</TD>
<TD>Yes</TD>
<TD>Yes</TD>
<TD>No</TD>
<TD>No</TD>
</TR>

<TR>
<TD>DOPT</TD>
<TD>Output Data Option</TD>
<TD>Menu</TD>
<TD>Yes</TD>
<TD>0</TD>
<TD>Yes</TD>
<TD>Yes</TD>
<TD>No</TD>
<TD>No</TD>
</TR>

<TR>
<TD>OCAL</TD>
<TD>Output Calculation</TD>
<TD>STRING[36]</TD>
<TD>Yes</TD>
<TD>Null</TD>
<TD>Yes</TD>
<TD>Yes</TD>
<TD>No</TD>
<TD>No</TD>
</TR>

<TR>
<TD>OVAL</TD>
<TD>Output Value</TD>
<TD>DOUBLE</TD>
<TD>No</TD>
<TD>0</TD>
<TD>Yes</TD>
<TD>Yes</TD>
<TD>Yes</TD>
<TD>No</TD>
</TR>

<TR>
<TD>OEVT</TD>
<TD>Event To Issue</TD>
<TD>SHORT</TD>
<TD>Yes</TD>
<TD>0</TD>
<TD>Yes</TD>
<TD>Yes</TD>
<TD>No</TD>
<TD>No</TD>
</TR>

<TR>
<TD>ODLY</TD>
<TD>Output Execution Delay</TD>
<TD>FLOAT</TD>
<TD>Yes</TD>
<TD>0</TD>
<TD>Yes</TD>
<TD>Yes</TD>
<TD>No</TD>
<TD>No</TD>
</TR>

<TR>
<TD>IVOA</TD>
<TD>Invalid Output Action</TD>
<TD>Menu</TD>
<TD>Yes</TD>
<TD>0</TD>
<TD>Yes</TD>
<TD>Yes</TD>
<TD>No</TD>
<TD>No</TD>
</TR>

<TR>
<TD>IVOV</TD>
<TD>Invalid Output Value</TD>
<TD>DOUBLE</TD>
<TD>Yes</TD>
<TD>0</TD>
<TD>Yes</TD>
<TD>Yes</TD>
<TD>No</TD>
<TD>No</TD>
</TR>

<TR>
<TD>OSV</TD>
<TD>Output string value</TD>
<TD>STRING[40]</TD>
<TD>NO</TD>
<TD>0</TD>
<TD>Yes</TD>
<TD>Yes</TD>
<TD>Yes</TD>
<TD>No</TD>
</TR>

<TR>
<TD><font color="blue">WAIT</font></TD>
<TD><font color="blue">Wait for completion?</font></TD>
<TD><font color="blue">Menu</font></TD>
<TD><font color="blue">Yes</font></TD>
<TD><font color="blue">"NoWait"</font></TD>
<TD><font color="blue">Yes</font></TD>
<TD><font color="blue">Yes</font></TD>
<TD><font color="blue">Yes</font></TD>
<TD><font color="blue">No</font></TD>
</TR>
</TABLE>

<font color="blue">
The sCalcout record now uses device support to write to the
<code>OUT</code> link. Soft device supplied with the record is selected with
the .dbd specification <pre> field(DTYP,"Soft Channel") </pre>

This device support uses the record's <code>WAIT</code> field to determine
whether to wait for completion of processing initiated by the <code>OUT</code>
link before causing the record to execute its forward link. The mechanism by
which this waiting for completion is performed requires that the
<code>OUT</code> link have the attribute <code>CA</code> -- i.e., the link text
looks something like

<code> xxx:record.field <b>CA</b> NMS</code>

Currently, the record does not try to ensure that <code>WAIT</code> and
<code>OUT</code> are compatibly configured. If <code>WAIT</code> == "Wait",
but the link looks like

<code> xxx:record.field <b>PP</b> NMS</code>

for example, then the record will not wait for completion before executing
its forward link.
</font>

=== Operator Display Parameters ===

These parameters are used to present meaningful data to the operator.
Some are also meant to represent the status of the record at run-time.
An example of an interactive MEDM display screen that displays the status
of the sCalcout record is located here.

The EGU field contains a string of up to 16 characters which is
supplied by the user and which describes the values being operated upon.
The string is retrieved whenever the routine <TT>get_units</TT> is called.
The EGU string is solely for an operator's sake and does not have to be
used.

The HOPR and LOPR fields only refer to the limits of the VAL,
HIHI, HIGH, LOW, and LOLO fields. PREC controls the precision of the VAL
field.

The INAV-INLV and IAAV-ILLV fields indicate the status of the
link to the PVs specified in the INPA-INPL and INAA-INLL fields, respectively.
The fields can have three possible values:

<table border>

<tr>
<td valign=top>Ext PV NC
<td valign=top>the PV wasn't found on this IOC and a Channel Access link hasn't
been established.
</tr>

<tr>
<td valign=top>Ext PV OK
<td valign=top>the PV wasn't found on this IOC and a Channel Access link has
been established.
</tr>

<tr>
<td valign=top>Local PV
<td valign=top>the PV was found on this IOC.
</tr>

<tr>
<td valign=top>Constant
<td valign=top>the corresponding link field is a constant.
</tr>

</table>

The OUTV field indicates the status of the OUT link. It has the same possible
values as the INAV-INLV fields.

The CLCV and OLCV fields indicate the validity of the expression
in the CALC and OCAL fields, respectively. If the expression is invalid,
the field is set to one.

The DLYA field is set to one during the delay interval specified
in ODLY.

<TABLE BORDER>
<TR>
<TH>Field</TH>
<TH>Summary</TH>
<TH>Type</TH>
<TH>DCT</TH>
<TH>Initial</TH>
<TH>Access</TH>
<TH>Modify</TH>
<TH>Rec Proc Monitor</TH>
<TH>PP</TH>
</TR>

<TR>
<TD>EGU</TD>
<TD>Engineering Units</TD>
<TD>STRING [16]</TD>
<TD>Yes</TD>
<TD>Null</TD>
<TD>Yes</TD>
<TD>Yes</TD>
<TD>No</TD>
<TD>No</TD>
</TR>

<TR>
<TD>PREC</TD>
<TD>Display Precision</TD>
<TD>SHORT</TD>
<TD>Yes</TD>
<TD>0</TD>
<TD>Yes</TD>
<TD>Yes</TD>
<TD>No</TD>
<TD>No</TD>
</TR>

<TR>
<TD>HOPR</TD>
<TD>High Operating Range</TD>
<TD>FLOAT</TD>
<TD>Yes</TD>
<TD>0</TD>
<TD>Yes</TD>
<TD>Yes</TD>
<TD>No</TD>
<TD>No</TD>
</TR>

<TR>
<TD>LOPR</TD>
<TD>Low Operating Range</TD>
<TD>FLOAT</TD>
<TD>Yes</TD>
<TD>0</TD>
<TD>Yes</TD>
<TD>Yes</TD>
<TD>No</TD>
<TD>No</TD>
</TR>

<TR>
<TD>INAV</TD>
<TD>Link Status of INPA</TD>
<TD>Menu</TD>
<TD>No</TD>
<TD>1</TD>
<TD>Yes</TD>
<TD>No</TD>
<TD>No</TD>
<TD>No</TD>
</TR>

<TR>
<TD>INBV</TD>
<TD>Link Status of INPB</TD>
<TD>Menu</TD>
<TD>No</TD>
<TD>1</TD>
<TD>Yes</TD>
<TD>No</TD>
<TD>No</TD>
<TD>No</TD>
</TR>

<TR>
<TD>...</TD>
<TD>...</TD>
<TD>...</TD>
<TD>...</TD>
<TD>...</TD>
<TD>...</TD>
<TD>...</TD>
<TD>...</TD>
<TD>...</TD>
</TR>

<TR>
<TD>INLV</TD>
<TD>Link Status of INPL</TD>
<TD>Menu</TD>
<TD>No</TD>
<TD>1</TD>
<TD>Yes</TD>
<TD>No</TD>
<TD>No</TD>
<TD>No</TD>
</TR>

<TR>
<TD>OUTV</TD>
<TD>OUT PV Status</TD>
<TD>Menu</TD>
<TD>No</TD>
<TD>0</TD>
<TD>Yes</TD>
<TD>No</TD>
<TD>No</TD>
<TD>No</TD>
</TR>

<TR>
<TD>CLCV</TD>
<TD>CALC Valid</TD>
<TD>LONG</TD>
<TD>No</TD>
<TD>0</TD>
<TD>Yes</TD>
<TD>Yes</TD>
<TD>No</TD>
<TD>No</TD>
</TR>

<TR>
<TD>OCLV</TD>
<TD>OCAL Valid</TD>
<TD>LONG</TD>
<TD>No</TD>
<TD>0</TD>
<TD>Yes</TD>
<TD>Yes</TD>
<TD>No</TD>
<TD>No</TD>
</TR>

<TR>
<TD>DLYA</TD>
<TD>Output Delay Active</TD>
<TD>USHORT</TD>
<TD>No</TD>
<TD>0</TD>
<TD>Yes</TD>
<TD>No</TD>
<TD>No</TD>
<TD>No</TD>
</TR>

<TR>
<TD>NAME</TD>
<TD>Record Name</TD>
<TD>STRING [29]</TD>
<TD>Yes</TD>
<TD>0</TD>
<TD>Yes</TD>
<TD>No</TD>
<TD>No</TD>
<TD>No</TD>
</TR>

<TR>
<TD>DESC</TD>
<TD>Description</TD>
<TD>STRING [29]</TD>
<TD>Yes</TD>
<TD>Null</TD>
<TD>Yes</TD>
<TD>Yes</TD>
<TD>No</TD>
<TD>No</TD>
</TR>

<TR>
<TD>IAAV</TD>
<TD>Link Status of INAA</TD>
<TD>Menu</TD>
<TD>No</TD>
<TD>1</TD>
<TD>Yes</TD>
<TD>No</TD>
<TD>No</TD>
<TD>No</TD>
</TR>

<TR>
<TD>IBBV</TD>
<TD>Link Status of INBB</TD>
<TD>Menu</TD>
<TD>No</TD>
<TD>1</TD>
<TD>Yes</TD>
<TD>No</TD>
<TD>No</TD>
<TD>No</TD>
</TR>

<TR>
<TD>...</TD>
<TD>...</TD>
<TD>...</TD>
<TD>...</TD>
<TD>...</TD>
<TD>...</TD>
<TD>...</TD>
<TD>...</TD>
<TD>...</TD>
</TR>

<TR>
<TD>ILLV</TD>
<TD>Link Status of INLL</TD>
<TD>Menu</TD>
<TD>No</TD>
<TD>1</TD>
<TD>Yes</TD>
<TD>No</TD>
<TD>No</TD>
<TD>No</TD>
</TR>
</TABLE>

=== Alarm Parameters ===

The possible alarm conditions for the sCalcout record are the SCAN,
READ, Calculation, and limit alarms. The SCAN and READ alarms are called
by the record support routines. The Calculation alarm is called by the
record processing routine when the CALC expression is an invalid one, upon
which an error message is generated.

The following alarm parameters which are configured by the user
define the limit alarms for the VAL field and the severity corresponding
to those conditions.

The HYST field defines an alarm deadband for each limit. See the
EPICS Record Reference Manual for a complete explanation of alarms
and these fields.

<TABLE BORDER>
<TR>
<TH>Field</TH>
<TH>Summary</TH>
<TH>Type</TH>
<TH>DCT</TH>
<TH>Initial</TH>
<TH>Access</TH>
<TH>Modify</TH>
<TH>Rec Proc Monitor</TH>
<TH>PP</TH>
</TR>

<TR>
<TD>HIHI</TD>
<TD>Hihi Alarm Limit</TD>
<TD>FLOAT</TD>
<TD>Yes</TD>
<TD>0</TD>
<TD>Yes</TD>
<TD>Yes</TD>
<TD>No</TD>
<TD>Yes</TD>
</TR>

<TR>
<TD>HIGH</TD>
<TD>High Alarm Limit</TD>
<TD>FLOAT</TD>
<TD>Yes</TD>
<TD>0</TD>
<TD>Yes</TD>
<TD>Yes</TD>
<TD>No</TD>
<TD>Yes</TD>
</TR>

<TR>
<TD>LOW</TD>
<TD>Low Alarm Limit</TD>
<TD>FLOAT</TD>
<TD>Yes</TD>
<TD>0</TD>
<TD>Yes</TD>
<TD>Yes</TD>
<TD>No</TD>
<TD>Yes</TD>
</TR>

<TR>
<TD>LOLO</TD>
<TD>Lolo Alarm Limit</TD>
<TD>FLOAT</TD>
<TD>Yes</TD>
<TD>0</TD>
<TD>Yes</TD>
<TD>Yes</TD>
<TD>No</TD>
<TD>Yes</TD>
</TR>

<TR>
<TD>HHSV</TD>
<TD>Severity for a Hihi Alarm</TD>
<TD>Menu</TD>
<TD>Yes</TD>
<TD>0</TD>
<TD>Yes</TD>
<TD>Yes</TD>
<TD>No</TD>
<TD>Yes</TD>
</TR>

<TR>
<TD>HSV</TD>
<TD>Severity for a High Alarm</TD>
<TD>Menu</TD>
<TD>Yes</TD>
<TD>0</TD>
<TD>Yes</TD>
<TD>Yes</TD>
<TD>No</TD>
<TD>Yes</TD>
</TR>

<TR>
<TD>LSV</TD>
<TD>Severity for a Low Alarm</TD>
<TD>Menu</TD>
<TD>Yes</TD>
<TD>0</TD>
<TD>Yes</TD>
<TD>Yes</TD>
<TD>No</TD>
<TD>Yes</TD>
</TR>

<TR>
<TD>LLSV</TD>
<TD>Severity for a Lolo Alarm</TD>
<TD>Menu</TD>
<TD>Yes</TD>
<TD>0</TD>
<TD>Yes</TD>
<TD>Yes</TD>
<TD>No</TD>
<TD>Yes</TD>
</TR>

<TR>
<TD>HYST</TD>
<TD>Alarm Deadband</TD>
<TD>DOUBLE</TD>
<TD>Yes</TD>
<TD>0</TD>
<TD>Yes</TD>
<TD>Yes</TD>
<TD>No</TD>
<TD>No</TD>
</TR>

</TABLE>

=== Monitor Parameters ===

These parameters are used to determine when to send monitors for the
value fields. The monitors are sent when the value field exceeds the last
monitored field by the appropriate deadband, the ADEL for archiver monitors
and the MDEL field for all other types of monitors. If these fields have
a value of zero, every time the value changes, monitors are triggered;
if they have a value of -1, every time the record is scanned, monitors
are triggered.

<TABLE BORDER >
<TR>
<TH>Field</TH>
<TH>Summary</TH>
<TH>Type</TH>
<TH>DCT</TH>
<TH>Initial</TH>
<TH>Access</TH>
<TH>Modify</TH>
<TH>Rec Proc Monitor</TH>
<TH>PP</TH>
</TR>

<TR>
<TD>ADEL</TD>
<TD>Archive Deadband</TD>
<TD>DOUBLE</TD>
<TD>Yes</TD>
<TD>0</TD>
<TD>Yes</TD>
<TD>Yes</TD>
<TD>No</TD>
<TD>No</TD>
</TR>

<TR>
<TD>MDEL</TD>
<TD>Monitor, i.e. value change, Deadband</TD>
<TD>DOUBLE</TD>
<TD>Yes</TD>
<TD>0</TD>
<TD>Yes</TD>
<TD>Yes</TD>
<TD>No</TD>
<TD>No</TD>
</TR>

</TABLE>

=== Run-time Parameters ===

These fields are not configurable using a configuration tool and none
are modifiable at run-time. They are used to process the record.

The LALM field is used to implement the hysteresis factor for
the alarm limits.

The LA-LL fields are used to decide when to trigger monitors for
the corresponding fields. For instance, if LA does not equal the value
for A, monitors for A are triggered. The MLST and MLST fields are used
in the same manner for the VAL field.

<TABLE BORDER>
<TR>
<TH>Field</TH>
<TH>Summary</TH>
<TH>Type</TH>
<TH>DCT</TH>
<TH>Initial</TH>
<TH>Access</TH>
<TH>Modify</TH>
<TH>Rec Proc Monitor</TH>
<TH>PP</TH>
</TR>

<TR>
<TD>LALM</TD>
<TD>Last Alarmed Value</TD>
<TD>DOUBLE</TD>
<TD>No</TD>
<TD>0</TD>
<TD>Yes</TD>
<TD>No</TD>
<TD>No</TD>
<TD>No</TD>
</TR>

<TR>
<TD>ALST</TD>
<TD>Archive Last Value</TD>
<TD>DOUBLE</TD>
<TD>No</TD>
<TD>0</TD>
<TD>Yes</TD>
<TD>No</TD>
<TD>No</TD>
<TD>No</TD>
</TR>

<TR>
<TD>MLST</TD>
<TD>Monitor Last Value</TD>
<TD>DOUBLE</TD>
<TD>No</TD>
<TD>0</TD>
<TD>Yes</TD>
<TD>No</TD>
<TD>No</TD>
<TD>No</TD>
</TR>

<TR>
<TD>LA</TD>
<TD>Previous Input Value for A</TD>
<TD>DOUBLE</TD>
<TD>No</TD>
<TD>0</TD>
<TD>Yes</TD>
<TD>No</TD>
<TD>No</TD>
<TD>No</TD>
</TR>

<TR>
<TD>LB</TD>
<TD>Previous Input Value for B</TD>
<TD>DOUBLE</TD>
<TD>No</TD>
<TD>0</TD>
<TD>Yes</TD>
<TD>No</TD>
<TD>No</TD>
<TD>No</TD>
</TR>

<TR>
<TD>...</TD>
<TD>...</TD>
<TD>...</TD>
<TD>...</TD>
<TD>...</TD>
<TD>...</TD>
<TD>...</TD>
<TD>...</TD>
<TD>...</TD>
</TR>

<TR>
<TD>LL</TD>
<TD>Previous Input Value for A</TD>
<TD>DOUBLE</TD>
<TD>No</TD>
<TD>0</TD>
<TD>Yes</TD>
<TD>No</TD>
<TD>No</TD>
<TD>No</TD>
</TR>

<TR>
<TD> </TD>
<TD> </TD>
<TD> </TD>
<TD> </TD>
<TD> </TD>
<TD> </TD>
<TD> </TD>
<TD> </TD>
<TD> </TD>
</TR>

<TR>
<TD>LAA</TD>
<TD>Previous Input Value for AA</TD>
<TD>STRING[40]</TD>
<TD>No</TD>
<TD>0</TD>
<TD>Yes</TD>
<TD>No</TD>
<TD>No</TD>
<TD>No</TD>
</TR>

<TR>
<TD>LBB</TD>
<TD>Previous Input Value for BB</TD>
<TD>STRING[40]</TD>
<TD>No</TD>
<TD>0</TD>
<TD>Yes</TD>
<TD>No</TD>
<TD>No</TD>
<TD>No</TD>
</TR>

<TR>
<TD>...</TD>
<TD>...</TD>
<TD>...</TD>
<TD>...</TD>
<TD>...</TD>
<TD>...</TD>
<TD>...</TD>
<TD>...</TD>
<TD>...</TD>
</TR>

<TR>
<TD>LLL</TD>
<TD>Previous Input Value for LL</TD>
<TD>STRING[40]</TD>
<TD>No</TD>
<TD>0</TD>
<TD>Yes</TD>
<TD>No</TD>
<TD>No</TD>
<TD>No</TD>
</TR>

</TABLE>

== Record Support ==

=== Record Support Routines ===

==== init_record ====

For each constant input link, the corresponding value field is initialized with the constant value if the input link is CONSTANT or a channel access link is created if the input link is PV_LINK.

A routine sCalcPostfix is called to convert the infix expression in CLCA-CLCV to postfix notation. The results are stored in RPCA-RPCP.

==== process ====

The <CODE>process()</CODE> routine implements the following algorithm:

# Fetch values from all valid input links.
# Call sCalcPerform(), which evaluates the expression specified in CALC and stores the result in VAL. If sCalcPerform() returns success, UDF is set to FALSE.
#Check alarms. This routine checks to see if the new VAL causes the alarm status and severity to change. If so, NSEV, NSTA and LALM are set. It also honors the alarm hysteresis factor (HYST). Thus the value must change by at least HYST before the alarm status and severity changes.
# Determine if the Output Execution Option (OOPT) is met. If it is met, either execute the output link (and output event) immediately (if ODLY=0), or schedule a callback to do so after the specified interval. See the explanation for the <TT>execOutput()</TT> routine below.
# Determine what fields should be posted, and with what attributes.
## Post all fields the record has changed.
## Alarm monitors are invoked if the alarm status or severity has changed.
## Archive and value change monitors are invoked if ADEL and MDEL conditions are met.
## NSEV and NSTA are reset to 0
# <font color="blue">Call device support to</font> execute output link.
# If we're not waiting for the output delay to expire, or for a completion callback, process the forward link, set PACT FALSE, and return.

==== special ====

This is called if any of the fields A-L, CALC, OCAL, INPA-INPL, INAA-INLL, or OUT are changed.
For expressions fields, special() calls sCalcPostfix. For value fields, special() keeps track of which fields have changed, because expressions will not be evaluated for fields that have been written to. For link fields, special() starts the process of checking link status.

==== get_units ====

Retrieves EGU.

==== get_precision ====

Retrieves PREC.

==== get_graphic_double ====

Sets the upper display and lower display limits for a field. If the field
is VAL, HIHI, HIGH, LOW, or LOLO, the limits are set to HOPR and LOPR,
else if the field has upper and lower limits defined they will be used,
else the upper and lower maximum values for the field type will be used.

==== get_control_double ====

Sets the upper control and the lower control limits for a field. If the
field is VAL, HIHI, HIGH, LOW, or LOLO, the limits are set to HOPR and
LOPR, else if the field has upper and lower limits defined they will be
used, else the upper and lower maximum values for the field type will be
used.

==== get_alarm_double ====

Sets the following values:

* upper_alarm_limit = HIHI
* upper_warning_limit = HIGH
* lower_warning_limit = LOW
* lower_alarm_limit = LOLO

==== execOutput() ====

# If DOPT field specifies the use of OCAL, call the routine sCalcPerform for the postfix version of the expression in OCAL. Otherwise, use VAL.
# If the Alarm Severity is INVALID, follow the option as designated by the field IVOA.
# If the Alarm Severity is not INVALID or IVOA specifies "Continue Normally", <font color="blue">call device support to</font> write the value of OVAL to <font color="blue">device or</font> PV specified by the OUT link, and post the event in OEVT (if non-zero).

== Availability ==

The sCalcout record is not included with EPICS base. The 3.14-compatible version is available
as part of the [http://www.aps.anl.gov/aod/bcda/synApps/calc/calc.html calc] module, which is part of the [http://www.aps.anl.gov/aod/bcda/synApps synApps] package of EPICS-based synchrotron-beamline software. The 3.13-compatible version is available as part of the [http://www.aps.anl.gov/aod/bcda/synApps/std/std.html std] module of a 3.13-compatible synApps distribution.
----

EPICS Record Reference Manual - 7 JUNE 2006

RRM 3-14 Multi-Bit Binary Output

2009-05-19T16:28:12Z

LewisMuir: /* Alarm Parameters */ Changed "NO ALARM" to "NO_ALARM"

[[RRM 3-14|EPICS Record Reference Manual]]

= mbbo -- Multi-Bit Binary Output =

The normal use for the mbbo record type is to send a binary value (representing one of up to 16 states) to a Digital Output module. It is used for any device that uses more than one bit to control it. The mbbo record can also be used to write discrete values to other records via database or channel access links.

== Parameter Fields ==

The multi-bit binary output fields fall into the following categories:

* scan parameters
* desired output parameters
* write and convert parameters
* operator display parameters
* alarm parameters
* run-time parameters

=== Scan Parameters ===

The mbbo record has the standard fields for specifying under what circumstances it will be processed. These fields are listed in [[RRM 3-14 dbCommon#Scan Fields|Scan Fields]]. In addition, [[RRM 3-14 Concepts#Scanning Specification|Scanning Specification]] explains how these fields are used. Note that I/O event scanning is only supported for those card types that interrupt.

=== Desired Output Parameters ===

The multi-bit binary output record, like all output records, must specify where its output originates. The output mode select (OMSL) field determines whether the output originates from another record or from database access (i.e., the operator). When set to <CODE>closed_loop</CODE>, the desired output is retrieved from the link specified in the desired output (DOL) field--which can specify either a database or channel access link--and placed into the VAL field. When set to <CODE>supervisory</CODE>, the DOL field is ignored and the current value of VAL is simply written. VAL can be changed via dpPuts at run-time when OMSL is <CODE>supervisory</CODE>. The DOL field can also be a constant, in which case the VAL field is initialized to the constant value. If DOL is a constant, OMSL cannot be set to <CODE>closed_loop</CODE>.

The VAL field itself usually consists of an index that specifies one of the states. The actual output written is the value of RVAL, which is converted from VAL following the routine explained in the next section. However, records that use the <CODE>Soft Channel</CODE> device support module write the VAL field's value without any conversion.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>OMSL<TD>Output Mode Select<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DOL<TD>Desired Output Location (an Input Link)<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>VAL<TD>Value Field<TD>ENUM<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes
</TABLE>

=== Convert and Write Parameters ===

The device support routines write the desired output to the location specified in the OUT field. If the record uses soft device support, OUT can contain a constant, a database link, or a channel access link; however, if OUT is a constant, no value will be written.

For records that write their values to hardware devices, the OUT output link must specify the address of the I/O card, and the DTYP field must specify the corresponding device support module. Be aware that the address format differs according to the I/O bus used. See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on the format of hardware addresses. The user can see a list of the device support modules currently supported at the user's local site by using the <CODE>dbst</CODE> utility in R3.13.

For mbbo records that write to hardware, the value written to the output location is the value contained in RVAL, which is converted from VAL, VAL containing an index of one of the 16 states (0-15). RVAL is then set to the corresponding state value, the value in one of the fields ZRVL through FFVL. Then this value is shifted left according to the number in the SHFT field so that the value is in the correct position for the bits being used (the SHFT value is set by device support and is not configurable by the user).

The state value fields ZRVL through FFVL must be configured by the user before run-time. When the state values are not defined, the states defined (SDEF) field is set to FALSE at initialization time by the record routines. When SDEF is FALSE, then the record processing routine does not try to find a match, RVAL is set equal to VAL, the bits are shifted using the number in SHFT, and the value is written thus.

If the OUT output link specifies a database link, channel access link, or constant, then the DTYP field must specify either one of the two soft device support modules--<CODE>Soft Channel</CODE> or <CODE>Raw</CODE> <CODE>Soft Channel</CODE>. <CODE>Soft</CODE> <CODE>Channel</CODE> writes the value of VAL to the output link, without any conversion, while <CODE>Raw Soft Channel </CODE>writes the value from RVAL after it has undergone the above conversion. See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on specifying links.

Note also that when a string is retrieved as the desired output, a record support routine is provided (<CODE>put_enum_str</CODE>) that will set check to see if the string matches one of the strings in the ZRST through FFST fields. If a match is found, RVAL is set equal to the corresponding state value of that string.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>OUT<TD>Output Link<TD>OUTLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>DTYP<TD>Device Type<TD>DEVCHOICE<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD> <TR>
<TD>RVAL<TD>Raw Data Value<TD>ULONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>SHFT<TD>Shift<TD>USHORT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>SDEF<TD>States Defined?<TD>SHORT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>ZRVL<TD>Zero Value<TD>ULONG<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>ONVL<TD>One value<TD>ULONG<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>TWVL<TD>Two Value<TD>ULONG<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>THVL<TD>Three Value<TD>ULONG<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>FRVL<TD>Four Value<TD>ULONG<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>FVVL<TD>Five Value<TD>ULONG<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>SXVL<TD>Six Value<TD>ULONG<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>SVVL<TD>Seven Value<TD>ULONG<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>EIVL<TD>Eight value<TD>ULONG<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>NIVL<TD>Nine Value<TD>ULONG<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>TEVL<TD>Ten Value<TD>ULONG<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>ELVL<TD>Eleven Value<TD>ULONG<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>TVVL<TD>Twelve Value<TD>ULONG<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>TTVL<TD>Thirteen Value<TD>ULONG<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>FTVL<TD>Fourteen Value<TD>ULONG<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>FFVL<TD>Fifteen Value<TD>ULONG<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>ZRST<TD>Zero String<TD>STRING [16]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>ONST<TD>One String<TD>STRING [16]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>TWST<TD>Two String<TD>STRING [16]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>THST<TD>Three String<TD>STRING [16]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>FRST<TD>Four String<TD>STRING [16]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>FVST<TD>Five String<TD>STRING [16]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>SXST<TD>Six String<TD>STRING [16]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>SVST<TD>Seven String<TD>STRING [16]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>EIST<TD>Eight String<TD>STRING [16]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>NIST<TD>Nine String<TD>STRING [16]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>TEST<TD>Ten String<TD>STRING [16]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>ELST<TD>Eleven String<TD>STRING [16]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>TVST<TD>Twelve String<TD>STRING [16]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>TTST<TD>Thirteen String<TD>STRING [16]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>FTST<TD>Fourteen String<TD>STRING [16]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>FFST<TD>Fifteen String<TD>STRING [16]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes
</TABLE>

=== Operator Display Parameters ===

These parameters are used to present meaningful data to the operator. These fields are used to display the value and other parameters of the mbbo record either textually or graphically. The ZRST-FFST fields contain strings describing each of the corresponding states. The <CODE>get_enum_str</CODE> and <CODE>get_enum_strs</CODE> record routines retrieve these strings for the operator. <CODE>Get_enum_str</CODE> gets the string corresponding to the value set in VAL, and <CODE>get_enum_strs</CODE> retrieves all the strings.

See [[RRM 3-14 dbCommon#Fields Common to All Record Types|Fields Common to All Record Types]] for more on the record name (NAME) and description (DESC) fields.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>ZRST,...,FFST<TD>Zero String, One String, ...<TD>STRING [16]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>NAME<TD>Record Name<TD>STRING [29]<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD> <TR>
<TD>DESC<TD>Description<TD>STRING [29]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Alarm Parameters ===

The possible alarm conditions for multi-bit binary outputs are the SCAN, READ, INVALID, and state alarms. The SCAN and READ alarms are called by the support modules and are not configurable by the user, as their severity is always MAJOR.

The IVOA field specifies an action to take from a number of possible choices when the INVALID alarm is triggered. The IVOV field contains a value to be written once the INVALID alarm has been triggered if <CODE>Set output to IVOV</CODE> has been chosen in the IVOA field. The severity of the INVALID alarm is not configurable by the user.

The state alarms are configured in the below severity fields. These fields have the usual possible values for severity fields: NO_ALARM, MINOR, and MAJOR.

The unknown state severity field (UNSV), if set to MINOR or MAJOR, triggers an alarm when the record support routine cannot find a matching value in the state value fields for VAL or when VAL is out of range.

The change of state severity field (COSV) triggers an alarm when the record's state changes, if set to MAJOR or MINOR.

The state severity (ZRSV-FFSV) fields, when set to MAJOR or MINOR, trigger an alarm when VAL equals the corresponding field.

See [[RRM 3-14 Concepts#Alarm Specification|Alarm Specification]] for a complete explanation of discrete alarms and these fields. See [[RRM 3-14 Common#Invalid Alarm Output Action|Invalid Alarm Output Action]] for an explanation of the IVOA and IVOV fields. [[RRM 3-14 dbCommon#Alarm Fields|Alarm Fields]] lists other fields related to a alarms that are common to all record types.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>UNSV<TD>Unknown State Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>COSV<TD>Change of State Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>IVOA<TD>Invalid Alarm Output Action<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>IVOV<TD>Invalid Alarm Output Value, in eng. units<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>ZRSV<TD>0 State Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>ONSV<TD>1 State Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>TWSV<TD>2 State Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>THSV<TD>3 State Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>FRSV<TD>4 State Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>FVSV<TD>5 State Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>SXSV<TD>6 State Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>SVSV<TD>7 State Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>EISV<TD>8 State Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>NISV<TD>9 State Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>TESV<TD>10 State Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>ELSV<TD>11 State Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>TVSV<TD>12 State Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>TTSV<TD>13 State Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>FTSV<TD>14 State Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>FFSV<TD>15 State Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes
</TABLE>

=== Run-Time and Simulation Mode Parameters ===

These parameters are used by the run-time code for processing the multi-bit binary output.

MASK is used by device support routine to read the hardware register. Record support sets low order of MASK the number of bits specified in NOBT. Device support can shift this value.

The LALM field implements the change of state alarm severity by holding the value of VAL when the previous change of state alarm was issued.

MLST holds the value when the last monitor for value change was triggered.

SDEF is used by record support to save time if no states are defined; it is used for converting VAL to RVAL.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>NOBT<TD>Number of Bits<TD>SHORT<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD> <TR>
<TD>ORAW<TD>Old Raw Data<TD>ULONG<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>MASK<TD>Mask<TD>ULONG<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LALM<TD>Last Alarmed<TD>USHORT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>MLST<TD>Monitor Last<TD>USHORT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>SDEF<TD>States Defined?<TD>SHORT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No
</TABLE>

The following fields are used to operate the mbbo record in the simulation mode. See [[RRM 3-14 Common#Fields Common to Many Record Types|Fields Common to Many Record Types]] for more information on the simulation mode fields.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>SIOL<TD>Simulation Value Location<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>SVAL<TD>Simulation Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>SIML<TD>Simulation Mode Location<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>SIMM<TD>Simulation Mode<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>SIMS<TD>Simulation Mode Alarm Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

== Record Support ==

=== Record Support Routines ===

==== init_record ====

This routine initializes SIMM if SIML is a constant or creates a channel access link if SIML is PV_LINK. If SIOL is PV_LINK a channel access link is created.

This routine next checks to see that device support is available. The routine next checks to see if the device support write routine is defined. If either device support or the device support write routine does not exist, an error message is issued and processing is terminated.

If DOL is a constant, then VAL is initialized to its value and UDF is set to FALSE.

MASK is cleared and then the NOBT low order bits are set.

If device support includes init_record, it is called.

init_common is then called to determine if any states are defined. If states are defined, SDEF is set to TRUE.

If device support returns success, VAL is then set from RVAL and UDF is set to FALSE.

==== process ====

See next section.

==== special ====

Computes SDEF when any of the fields ZRVL,...FFVL change value.

==== get_value ====

Fills in the values of struct valueDes so that they refer to VAL.

==== get_enum_str ====

Retrieves ASCII string corresponding to VAL.

==== get_enum_strs ====

Retrieves ASCII strings for ZRST,...FFST.

==== put_enum_str ====

Checks if string matches ZRST,...FFST and if it does, sets VAL.

=== Record Processing ===

Routine process implements the following algorithm:

# Check to see that the appropriate device support module exists. If it doesn't, an error message is issued and processing is terminated with the PACT field still set to TRUE. This ensures that processes will not longer be called for this record. Thus error storms will not occur.
# If PACT is FALSE
#* If DOL is DB_LINK and OMSL is CLOSED_LOOP
#** Get value from DOL
#** Set UDF to FALSE
#** Check for link alarm
#* If any state values are defined
#** If VAL > 15, then raise alarm and go to 4
#** Else using VAL as index set RVAL = one of ZRVL,...FFVL
#* Else set RVAL = VAL
#* Shift RVAL left SHFT bits
# Convert
#* If PACT is FALSE, compute RVAL
#** If VAL is 0,...,15, set RVAL from ZRVL,...,FFVL
#** If VAL out of range, set RVAL = undefined
#* Status = write_mbbo
# Check alarms. This routine checks to see if the new VAL causes the alarm status and severity to change. If so, NSEV, NSTA and LALM are set.
# Check severity and write the new value. See [[RRM 3-14 Common#Simulation Mode|Simulation Mode]] and [[RRM 3-14 Common#Invalid Alarm Output Action|Invalid Alarm Output Action]] for more information.
# If PACT has been changed to TRUE, the device support write output routine has started but has not completed writing the new value. In this case, the processing routine merely returns, leaving PACT TRUE.
# Check to see if monitors should be invoked.
#* Alarm monitors are invoked if the alarm status or severity has changed.
#* Archive and value change monitors are invoked if MLST is not equal to VAL.
#* Monitors for RVAL and RBV are checked whenever other monitors are invoked.
#* NSEV and NSTA are reset to 0.
# Scan forward link if necessary, set PACT FALSE, and return.

== Device Support ==

=== Fields Of Interest To Device Support ===

Each mbbo record must have an associated set of device support routines. The primary responsibility of the device support routines is to obtain a new raw mbbo value whenever write_mbbo is called. The device support routines are primarily interested in the following fields:

<TABLE BORDER="1">
<TH>Name<TH>Summary<TH>Description<TR>
<TD>PACT<TD>Processing Active<TD rowspan=4>See [[RRM 3-14 dbCommon#Fields Common to All Record Types|Fields Common to All Record Types]] for an explanation of these fields.<TR>
<TD>DPVT<TD>Device Private<TR>
<TD>NSEV<TD>New Alarm Severity<TR>
<TD>NSTA<TD>New Alarm Status<TR>
<TD>NOBT<TD>Number of Bits<TD>Number of hardware bits accessed. They must be consecutive.<TR>
<TD>OUT<TD>Output Link<TD>This field is used by the device support routines to locate its output.<TR>
<TD>RVAL<TD>Raw data value.<TD>This is the value to be written to OUT.<TR>
<TD>RBV<TD>Read Back Value<TD>It is the responsibility of the device support modules to set this field.<TR>
<TD>MASK<TD>Mask<TD>This is a mask used to read the hardware. Record support sets the low order NOBT bits. The device support routine can shift the bits. The device support routine should perform the shift in init_record.<TR>
<TD>SHFT<TD>Shift<TD>This can be set by the device support module at init_record time.
</TABLE>

=== Device Support Routines ===

Device support consists of the following routines:

==== report ====

report(FILE fp, paddr)

Not currently used.

==== init ====

init()

This routine is called once during IOC initialization.

==== init_record ====

init_record(precord)

This routine is optional. If provided, it is called by the record support init_record routine. If MASK is used, it should be shifted if necessary and SHFT given a value.

==== get_ioint_info ====

get_ioint_info(int cmd,struct dbCommon *precord,IOSCANPVT *ppvt)

This routine is called by the ioEventScan system each time the record is added or deleted from an I/O event scan list. cmd has the value (0,1) if the record is being (added to, deleted from) an I/O event list. It must be provided for any device type that can use the ioEvent scanner.

==== write_mbbo ====

write_mbbo(precord)

This routine must output a new value. It returns the following values:

* 0: Success.
* Other: Error.

=== Device Support For Soft Records ===

==== Soft Channel ====

The <CODE>Soft Channel</CODE> module writes the current value of VAL.

If the OUT link type is PV_LINK, then dbCaAddInlink is called by init_record.

write_mbbo calls recGblPutLinkValue to write the current value of VAL. See [[RRM 3-14 Common#Soft Output|Soft Output]] for more information.

==== Raw Soft Channel ====

This module writes RVAL to the location specified in the output link. It returns a 0.

----

EPICS Record Reference Manual - 19 MAY 1998

RRM 3-14 Multi-Bit Binary Input

2009-05-19T16:26:53Z

LewisMuir: /* Alarm Parameters */ Changed "NO ALARM" to "NO_ALARM"

[[RRM 3-14|EPICS Record Reference Manual]]

= mbbi -- Multi-Bit Binary Input =

The normal use for the multi-bit binary input record is to read multiple bit inputs from hardware. The binary value represents a state from a range of up to 16 states. The multi-bit input record interfaces with devices that use more than one bit.

Most device support modules obtain values from hardware and place the value in RVAL. For these device support modules record processing uses RVAL to determine the current state (VAL is given a value between 0 and 15). Device support modules may optionally read a value directly into VAL.

Soft device modules are provided to obtain input via database or channel access links or via dbPutField or dbPutLink requests. Two soft device support modules are provided: <CODE>Soft Channel</CODE> allows VAL to be an arbitrary unsigned short integer. <CODE>Raw Soft Channel</CODE> reads the value into RVAL just like normal device support modules.

== Parameter Fields ==

The multi-bit binary input fields fall into the following categories:

* scan parameters
* read and convert parameters
* operator display parameters
* alarm parameters
* run-time and simulation mode parameters

=== Scan parameters ===

The multi-bit binary input record has the standard fields for specifying under what circumstances it will be processed. These fields are listed in [[RRM 3-14 dbCommon#Scan Fields|Scan Fields]]. In addition, [[RRM 3-14 Concepts#Scanning Specification|Scanning Specification]] explains how these fields are used. Note that I/O event scanning is only supported for those card types that interrupt.

=== Read and Convert Parameters ===

The device support routines obtain the record's input from the device or link specified in the INP field. For records that obtain their input from devices, the INP field must contain the address of the I/O card, and the DTYP field must specify the proper device support module. Be aware that the address format differs according to the I/O bus used. See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on the format of hardware addresses. You can see a list of the device support modules currently supported at the user's local site by using the <CODE>dbst</CODE> utility in R3.13.

Two soft device support modules can be specified in DTYP--<CODE>Soft Channel</CODE> and <CODE>Raw Soft Channel</CODE>. <CODE>Raw Soft Channel</CODE> reads the value into RVAL, upon which the normal conversion process is undergone. <CODE>Soft Channel</CODE> reads any unsigned integer directly into VAL. For a soft mbbi record, the INP field can be a constant, a database, or a channel access link. If INP is a constant, then the VAL is initialized to the constant value but can be changed at run-time via dbPutField or dbPutLink. See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on the format of database addresses.

Unless the device support routine specifies no conversion, RVAL is used to determine VAL as follows:

# RVAL is assigned to a temporary variable -- rval = RVAL
# rval is shifted right SHFT number of bits.
# A match is sought between rval and one of the state value fields, ZRVL-FFVL.

Each of the fields, ZRVL-FFVL, represents one of the possible sixteen states (not all sixteen have to be used).

Alternatively, the input value can be read as a string, in which case, a match is sought with one of the strings specified in the ZRST-FFST fields. Then RVAL is set equal to the corresponding value for that string, and the conversion process occurs.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>VAL<TD>Value Field<TD>ENUM<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>INP<TD>Input Link<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>RVAL<TD>Raw Data Value<TD>ULONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>SHFT<TD>Shift<TD>USHORT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>ZRVL<TD>Zero Value<TD>ULONG<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>ONVL<TD>One value<TD>ULONG<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>TWVL<TD>Two Value<TD>ULONG<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>THVL<TD>Three Value<TD>ULONG<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>FRVL<TD>Four Value<TD>ULONG<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>FVVL<TD>Five Value<TD>ULONG<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>SXVL<TD>Six Value<TD>ULONG<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>SVVL<TD>Seven Value<TD>ULONG<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>EIVL<TD>Eight value<TD>ULONG<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>NIVL<TD>Nine Value<TD>ULONG<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>TEVL<TD>Ten Value<TD>ULONG<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>ELVL<TD>Eleven Value<TD>ULONG<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>TVVL<TD>Twelve Value<TD>ULONG<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>TTVL<TD>Thirteen Value<TD>ULONG<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>FTVL<TD>Fourteen Value<TD>ULONG<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>FFVL<TD>Fifteen Value<TD>ULONG<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>ZRST<TD>Zero String<TD>STRING [16]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>ONST<TD>One String<TD>STRING [16]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>TWST<TD>Two String<TD>STRING [16]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>THST<TD>Three String<TD>STRING [16]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>FRST<TD>Four String<TD>STRING [16]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>FVST<TD>Five String<TD>STRING [16]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>SXST<TD>Six String<TD>STRING [16]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>SVST<TD>Seven String<TD>STRING [16]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>EIST<TD>Eight String<TD>STRING [16]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>NIST<TD>Nine String<TD>STRING [16]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>TEST<TD>Ten String<TD>STRING [16]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>ELST<TD>Eleven String<TD>STRING [16]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>TVST<TD>Twelve String<TD>STRING [16]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>TTST<TD>Thirteen String<TD>STRING [16]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>FTST<TD>Fourteen String<TD>STRING [16]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>FFST<TD>Fifteen String<TD>STRING [16]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes
</TABLE>

=== Operator Display Parameters ===

These parameters are used to present meaningful data to the operator. They display the value and other parameters of the mbbi record either textually or graphically. The ZRST-FFST fields contain strings describing one of the possible states of the record. The <CODE>get_enum_str</CODE> and <CODE>get_enum_strs</CODE> record routines retrieve these strings for the operator. <CODE>Get_enum_str</CODE> gets the string corresponding to the value set in VAL, and <CODE>get_enum_strs</CODE> retrieves all the strings.

See [[RRM 3-14 dbCommon#Fields Common to All Record Types|Fields Common to All Record Types]] for more on the record name (NAME) and description (DESC) fields.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>ZRST,...,FFST<TD>Zero String, One String, ...<TD>STRING [16]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HOPR<TD>High Operating Range<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>NAME<TD>Record Name<TD>STRING [29]<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD> <TR>
<TD>DESC<TD>Description<TD>STRING [29]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Alarm Parameters ===

The possible alarm conditions for multi-bit binary inputs are the SCAN, READ, and state alarms. The state alarms are configured in the below severity fields. These fields have the usual possible values for severity fields: NO_ALARM, MINOR, and MAJOR.

The unknown state severity (UNSV) field, if set to MINOR or MAJOR, triggers an alarm when the record support routine cannot find a matching value in the state value fields for <CODE>rval</CODE>.

The change of state severity (COSV) field triggers an alarm when any change of state occurs, if set to MAJOR or MINOR.

The other fields, when set to MAJOR or MINOR, trigger an alarm when VAL equals the corresponding state. See the See [[RRM 3-14 Concepts#Alarm Specification|Alarm Specification]] for a complete explanation of discrete alarms and these fields. [[RRM 3-14 dbCommon#Alarm Fields|Alarm Fields]] lists other fields related to a alarms that are common to all record types.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>UNSV<TD>Unknown State Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>COSV<TD>Change of State Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>ZRSV<TD>0 State Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>ONSV<TD>1 State Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>TWSV<TD>2 State Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>THSV<TD>3 State Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>FRSV<TD>4 State Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>FVSV<TD>5 State Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>SXSV<TD>6 State Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>SVSV<TD>7 State Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>EISV<TD>8 State Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>NISV<TD>9 State Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>TESV<TD>10 State Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>ELSV<TD>11 State Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>TVSV<TD>12 State Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>TTSV<TD>13 State Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>FTSV<TD>14 State Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>FFSV<TD>15 State Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes
</TABLE>

=== Run-time and Simulation Mode Parameters ===

These parameters are used by the run-time code for processing the multi-bit binary input.

MASK is used by device support routine to read the hardware register. It is shifted left NOBT bits by the record processing routine. The user can configure the NOBT field, but the device support routines may set it, in which case the value given to it by the user is simply overridden.

The LALM field implements the change of state alarm severity by holding the value of VAL when the previous change of state alarm was issued.

MLST holds the value when the last monitor for value change was triggered.

SDEF is used by record support to save time if no states are defined.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>SHFT<TD>Shift<TD>USHORT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>ORAW<TD>Old Raw Data<TD>ULONG<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>NOBT<TD>Number of Bits<TD>SHORT<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>MASK<TD>Mask<TD>ULONG<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LALM<TD>Last Alarmed<TD>USHORT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>MLST<TD>Monitor Last<TD>USHORT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>SDEF<TD>States Defined?<TD>SHORT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No
</TABLE>

The following fields are used to operate the mbbi record in the simulation mode. See [[RRM 3-14 Common#Fields Common to Many Record Types|Fields Common to Many Record Types]] for more information on these fields.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>SIOL<TD>Simulation Value Location<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>SVAL<TD>Simulation Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>SIML<TD>Simulation Mode Location<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>SIMM<TD>Simulation Mode<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>SIMS<TD>Simulation Mode Alarm Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

== Record Support ==

=== Record Support Routines ===

==== init_record ====

This routine initializes SIMM with the value of SIML if SIML type is CONSTANT link or creates a channel access link if SIML type is PV_LINK. SVAL is likewise initialized if SIOL is CONSTANT or PV_LINK.

This routine next checks to see that device support is available and a device support read routine is defined. If either does not exist, an error message is issued and processing is terminated.

Clears MASK and then sets the NOBT low order bits.

If device support includes init_record, it is called.

init_common is then called to determine if any states are defined. If states are defined, SDEF is set to TRUE.

==== process ====

See next section.

==== special ====

Calls init_common to compute SDEF when any of the fields ZRVL, ... FFVL change value.

==== get_value ====

Fills in the values of struct valueDes so that they refer to VAL.

==== get_enum_str ====

Retrieves ASCII string corresponding to VAL.

==== get_enum_strs ====

Retrieves ASCII strings for ZRST,...FFST.

==== put_enum_str ====

Checks if string matches ZRST,...FFST and if it does, sets VAL.

=== Record Processing ===

Routine process implements the following algorithm:

# Check to see that the appropriate device support module exists. If it doesn't, an error message is issued and processing is terminated with the PACT field still set to TRUE. This ensures that processes will no longer be called for this record. Thus error storms will not occur.
# readValue is called. See [[RRM 3-14 Common#Input Records|Input Records]] for more information.
# If PACT has been changed to TRUE, the device support read routine has started but has not completed reading a new input value. In this case, the processing routine merely returns, leaving PACT TRUE.
# Convert:
#* status=read_mbbi
#* PACT = TRUE
#* TIME = tsLocalTime
#* If status is 0, then determine VAL
#** Set rval = RVAL
#** Shift rval right SHFT bits
#* If at least one state value is defined
#** Set UDF to TRUE
#* If RVAL is ZRVL,...,FFVL then set
#** VAL equals index of state
#** UDF set to FALSE
#* Else set VAL = undefined
#** Else set VAL = RVAL
#* Set UDF to FALSE
#** If status is 1, return(0)
#* If status is 2, set status = 0
# Check alarms. This routine checks to see if the new VAL causes the alarm status and severity to change. If so, NSEV, NSTA and LALM are set.
# Check to see if monitors should be invoked.
#* Alarm monitors are invoked if the alarm status or severity has changed.
#* Archive and value change monitors are invoked if MLST is not equal to VAL.
#* Monitors for RVAL are checked whenever other monitors are invoked.
#* NSEV and NSTA are reset to 0.
# Scan forward link if necessary, set PACT FALSE, and return.

== Device Support ==

=== Fields Of Interest To Device Support ===

Each input record must have an associated set of device support routines.

The primary responsibility of the device support routines is to obtain a new raw input value whenever read_mbbi is called. The device support routines are primarily interested in the following fields:

<TABLE BORDER="1">
<TH>Name<TH>Summary<TH>Description<TR>
<TD>PACT<TD>Processing Active<TD rowspan=5>See [[RRM 3-14 dbCommon#Fields Common to All Record Types|Fields Common to All Record Types]] for an explanation of these fields.<TR>
<TD>DPVT<TD>Device Private<TR>
<TD>UDF<TD>VAL Undefined<TR>
<TD>NSEV<TD>New Alarm Severity<TR>
<TD>NSTA<TD>New Alarm Status<TR>
<TD>NOBT<TD>Number of Bits<TD>Number of hardware bits accessed. They must be consecutive.<TR>
<TD>VAL<TD>Value Field<TD>This field is set by the device support routines if they don't want record support to set it.<TR>
<TD>INP<TD>Input Link<TD>This field is used by the device support routines to locate its input.<TR>
<TD>RVAL<TD>Raw Data Value<TD>It is the responsibility of the device support routine to give this field a value.<TR>
<TD>MASK<TD>Mask<TD>This is a mask used to read the hardware. Record support sets the low order NOBT bits. The device support routine can shift the bits. The device support routine should perform the shift in init_record.<TR>
<TD>SHFT<TD>Shift<TD>This can be set by the device support module at init_record time.
</TABLE>

=== Device Support Routines ===

Device support consists of the following routines:

==== report ====

report(FILE fp, paddr)

Not currently used.

==== init ====

init()

This routine is called once during IOC initialization.

==== init_record ====

init_record(precord)

This routine is optional. If provided, it is called by the record support init_record routine. If it uses MASK, it should shift it as necessary and also give SHFT a value.

==== get_ioint_info ====

get_ioint_info(int cmd,struct dbCommon *precord,IOSCANPVT *ppvt)

This routine is called by the ioEventScan system each time the record is added or deleted from an I/O event scan list. cmd has the value (0,1) if the record is being (added to, deleted from) an I/O event list. It must be provided for any device type that can use the I/O Event scanner.

==== read_mbbi ====

read_mbbi(precord)

This routine must provide a new input value. It returns the following values:

* 0: Success. A new raw value is placed in RVAL. The record support module determines VAL from RVAL, SHFT, and ZEVL ... FFVL.
* 2: Success, but don't modify VAL.
* Other: Error.

=== Device Support For Soft Records ===

Two soft device support modules <CODE>Soft Channel</CODE> and <CODE>Raw Soft Channel</CODE> are provided for multi-bit binary input records not related to actual hardware devices. The INP link type must be either CONSTANT, DB_LINK, or CA_LINK.

==== Soft Channel ====

read_mbbi always returns a value of 2, which means that no conversion is performed.

If the INP link type is constant, then the constant value is stored into VAL by init_record, and UDF is set to FALSE. VAL can be changed via dbPut requests. If the INP link type is PV_LINK, then dbCaAddInlink is called by init_record.

read_mbbi calls recGblGetLinkValue to read the current value of VAL. See [[RRM 3-14 Common#Soft Input|Soft Input]].

If the return status of recGblGetLinkValue is zero, then read_mbbi sets UDF to FALSE. The status of recGblGetLinkValue is returned.

==== Raw Soft Channel ====

This module is like the previous except that values are read into RVAL, VAL is computed from RVAL, and read_mbbi returns a value of 0. Thus the record processing routine will determine VAL in the normal way.

----

EPICS Record Reference Manual - 19 MAY 1998

RRM 3-14 Calcout

2009-04-24T19:17:50Z

LewisMuir: /* Run-time Parameters */ Fixed description for LB-LL

[[RRM 3-14|EPICS Record Reference Manual]]

= Calcout - Calculation Output Record =

The Calculation Output or "Calcout" record is similar to the Calc record with the added feature of having outputs (an "output link" and an "output event") which are conditionally executed based on the result of the calculation. This feature allows conditional branching to be implemented within an EPICS database (e.g., process Record_A only if Record_B has a value of 0). The Calcout record is also similar to the Wait record (with additional features) but uses EPICS standard INLINK and OUTLINK fields rather than the DBF_STRING fields used in the Wait record. For new databases, it is recommended that the Calcout record be used instead of the Wait record.

== Parameter Fields ==

The fields in this record fall into these categories:

* scan parameters
* read parameters
* expression parameters
* output parameters
* operator display parameters
* alarm parameters
* monitor parameters
* run-time parameters

=== Scan Parameters ===

The Calcout record has the standard fields for specifying under what circumstances the record will be processed. These fields are listed in [[RRM 3-14 dbCommon#Scan Fields|Scan Fields]]. In addition, [[RRM 3-14 Concepts#Scanning Specification|Scanning Specification]] explains how these fields are used. Since the Calcout record supports no direct interfaces to hardware, it cannot be scanned on I/O interrupt, so its SCAN field cannot be <CODE>I/O Intr</CODE>.

=== Read Parameters ===

The read parameters for the Calcout record consist of 12 input links INPA, INPB, ... INPL. The fields can be database links, channel access links, or constants. If they are links, they must specify another record's field. If they are constants, they will be initialized with the value they are configured with and can be changed via <CODE>dbPuts</CODE>. These fields cannot be hardware addresses. In addition, the Calcout record contains the INAV, INBV, . . . INLV fields which indicate the status of the link fields, for example, whether or not the specified PV was found and a link to it established. See [[#Operator Display Parameters|Operator Display Parameters]] for an explanation of these fields.

See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on how to specify database links.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TR>
<TD>INPA<TD>Input Link A<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPB<TD>Input Link B<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPC<TD>Input Link C<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPD<TD>Input Link D<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPE<TD>Input Link E<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPF<TD>Input Link F<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPG<TD>Input Link G<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPH<TD>Input Link H<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPI<TD>Input Link I<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPJ<TD>Input Link J<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPK<TD>Input Link K<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPL<TD>Input Link L<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A
</TABLE>

=== Expression ===

Like the Calc record, the Calcout record has a CALC field in which the developer can enter an infix expression which the record routine will evaluate when it processes the record. The resulting value is placed in the VAL field. This value can then be used by the OOPT field (see [[#Output Parameters|Output Parameters]]) to determine whether or not to write to the output link or post an output event. It can also be the value that is written to the output link. The CALC expression is actually converted to opcode and stored in Reverse Polish Notation in the RPCL field. It is this expression which is actually used to calculate VAL. The Reverse Polish expression is evaluated more efficiently during run-time than an infix expression. CALC can be changed at run-time, and a special record routine will call a function to convert it to Reverse Polish Notation.

The range of expressions supported by the calculation record are separated into operands, algebraic operators, trigonometric operators, relational operators, logical operators, parentheses and commas, and the conditional '?:' operator. The expression can consist of any of these operators, as well as any of the values from the input links which are the operands.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>CALC<TD>Calculation<TD>STRING[36]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>VAL<TD>Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>RPCL<TD>Reverse Polish<TD>NOACCESS<TD>No<TD>0<TD>No<TD>No<TD>N/A<TD>No
</TABLE> Also, the RNDM unary function can be included as an operand in the expression in order to generate a random number between 0 and 1.

==== Operands ====

The expression can use the values retrieved from the INP''x'' links as operands, though constants can be used as operands too. These values retrieved from the input links are stored in the A-L fields. The values to be used in the expression are simply referenced by the field letter. For instance, the value obtained from the INPA link is stored in the field A, and the value obtained from INPB is stored in field B. The field names can be included in the expression which will operate on their respective values, as in A+B.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>A<TD>Input Value A<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>B<TD>Input Value B<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>C<TD>Input Value C<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>D<TD>Input Value D<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>E<TD>Input Value E<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>F<TD>Input Value F<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>G<TD>Input Value G<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>H<TD>Input Value H<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>I<TD>Input Value I<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>J<TD>Input Value J<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>K<TD>Input Value K<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>L<TD>Input Value L<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes
</TABLE>

==== Algebraic Operators ====

* ABS: Absolute value (unary)
* SQR: Square root (unary)
* MIN: Minimum (binary function)
* MAX: Maximum (binary function)
* CEIL: Ceiling (unary)
* FLOOR: Floor (unary)
* LOG: Log base 10 (unary)
* LOGE: Natural log (unary)
* EXP: Exponential function (unary)
* ^: Exponential (binary)
* ** : Exponential (binary)
* + : Addition (binary)
* - : Subtraction (binary)
* * : Multiplication (binary)
* / : Division (binary)
* % : Modulo (binary)
* NOT: Negate (unary)

==== Trigonometric Operators ====

* SIN: Sine
* SINH: Hyperbolic sine
* ASIN: Arc sine
* COS: Cosine
* COSH: Hyperbolic cosine
* ACOS: Arc cosine
* TAN: Tangent
* TANH: Hyperbolic tangent
* ATAN: Arc tangent

==== Relational Operators ====

* >= : Greater than or equal to
* > : Greater than
* <= : Less than or equal to
* <: Less than
* # : Not equal to
* = : Equal to

==== Logical Operators ====

* && : And
* || : Or
* ! : Not

==== Bitwise Operators ====

* | : Bitwise Or
* & : Bitwise And
* OR : Bitwise Or
* AND: Bitwise And
* XOR: Bitwise Exclusive Or
* ~ : One's Complement
* << : Left shift
* >> : Right shift

==== Parentheses and Comma ====

The open and close parentheses are supported. Nested parenthesis are supported.

The comma is supported when used to separate the arguments of a binary function.

==== Conditional Expression ====

The C language's question mark operator is supported. The format is:

(condition)? True result : False result

=== Example Expressions ===

==== Algebraic ====

A + B + 10

* Result is A + B

==== Relational ====

(A + B) < (C + D)

* Result is 1 if (A+B) < (C+D)
* Result is 0 if (A+B) >= (C+D)

==== Question Mark ====

(A+B)<(C+D)?E:F+L+10

* Result is E if (A+B) < (C+D)
* Result is F+L+10 if (A+B) >= (C+D)

(A+B)<(C+D)?E

* Result is E if (A+B) < (C+D)
* Result is unchanged if (A+B) >= (C+D)

==== Logical ====

A&B

* Causes the following to occur:
** Convert A to integer
** Convert B to integer
** Bit-wise And A and B
** Convert result to floating point

=== Output Parameters ===

These parameters specify and control the output capabilities of the Calcout record. They determine when to write the output, where to write it, and what the output will be. The OUT link specifies the Process Variable to which the result will be written. The OOPT field determines the condition that causes the output link to be written to. It's a menu field that has six choices:

* <CODE>Every Time</CODE> -- write output every time record is processed.
* <CODE>On Change</CODE> -- write output every time VAL changes, i.e., every time the result of the expression changes.
* <CODE>When Zero</CODE> -- when record is processed, write output if VAL is zero.
* <CODE>When Non-zero</CODE> -- when record is processed, write output if VAL is non-zero.
* <CODE>Transition To Zero</CODE> -- when record is processed, write output only if VAL is zero and last value was non-zero.
* <CODE>Transition To Non-zero</CODE> -- when record is processed, write output only if VAL is non-zero and last value was zero.

The DOPT field determines what data is written to the output link when the output is executed. The field is a menu field with two options: <CODE>Use CALC</CODE> or <CODE>Use OCAL</CODE>. If <CODE>Use CALC</CODE> is specified, when the record writes its output it will write the result of the expression in the CALC record, that is, it will write the value of the VAL field. If <CODE>Use OCAL</CODE> is specified, the record will instead write the result of the expression in the OCAL field, which is contained in the OVAL field. The OCAL field is exactly like the CALC field and has the same functionality: it can contain the string representation of an expression which is evaluated at run-time. Thus, if necessary, the record can use the result of the CALC expression to determine if data should be written and can use the result of the OCAL expression as the data to write.

If the OEVT field specifies a non-zero integer and the condition in the OOPT field is met, the record will post a corresponding event. If the ODLY field is non-zero, the record pauses for the specified number of seconds before executing the OUT link or posting the output event. During this waiting period the record is "active" and will not be processed again until the wait is over. The field DLYA is equal to 1 during the delay period. The resolution of the delay entry is system dependent.

The IVOA field specifies what action to take with the OUT link if the Calcout record enters an INVALID alarm status. The options are <CODE>Continue normally</CODE>, <CODE>Don't drive outputs</CODE>, and <CODE>Set output to IVOV</CODE>. If the IVOA field is <CODE>Set output to IVOV</CODE>, the data entered into the IVOV field is written to the OUT link if the record alarm severity is INVALID.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>OUT<TD>Output Specification<TD>OUTLINK<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>N/A<TD>No<TR>
<TD>OOPT<TD>Output Execute Option<TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DOPT<TD>Output Data Option<TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>OCAL<TD> Output Calculation<TD>STRING[36]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>OVAL<TD>Output Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>OEVT<TD>Event To Issue<TD>SHORT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>ODLY<TD>Output Execution Delay<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>IVOA<TD>Invalid Output Action<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>IVOV<TD>Invalid Output Value<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Operator Display Parameters ===

These parameters are used to present meaningful data to the operator. Some are also meant to represent the status of the record at run-time. An example of an interactive MEDM display screen that displays the status of the Calcout record is located here.

The EGU field contains a string of up to 16 characters which is supplied by the user and which describes the values being operated upon. The string is retrieved whenever the routine <CODE>get_units</CODE> is called. The EGU string is solely for an operator's sake and does not have to be used.

The HOPR and LOPR fields only refer to the limits of the VAL, HIHI, HIGH, LOW, and LOLO fields. PREC controls the precision of the VAL field.

The INAV-INLV fields indicate the status of the link to the PVs specified in the INPA-INPL fields, respectively. The field can have three possible values:

* <CODE>Ext PV NC</CODE> -- the PV wasn't found on this IOC and a Channel Access link hasn't been established.
* <CODE>Ext PV OK</CODE> -- the PV wasn't found on this IOC and a Channel Access link has been established.
* <CODE>Local PV</CODE> -- the PV was found on this IOC.
* <CODE>Constant</CODE> -- the corresponding link field is a constant.

The OUTV field indicates the status of the OUT link. It has the same possible values as the INAV-INLV fields.

The CLCV and OLCV fields indicate the validity of the expression in the CALC and OCAL fields, respectively. If the expression is invalid, the field is set to one.

The DLYA field is set to one during the delay interval specified in ODLY.

See [[RRM 3-14 dbCommon#Fields Common to All Record Types|Fields Common to All Record Types]] for more on the record name (NAME) and description (DESC) fields.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>EGU<TD>Engineering Units<TD>STRING [16]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>PREC<TD>Display Precision<TD>SHORT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>HOPR<TD>High Operating Range<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>LOPR<TD>Low Operating Range<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>INAV<TD>Link Status of INPA<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INBV<TD>Link Status of INPB<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INCV<TD>Link Status of INPC<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INDV<TD>Link Status of INPD<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INEV<TD>Link Status of INPE<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INFV<TD>Link Status of INPF<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INGV<TD>Link Status of INPG<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INHV<TD>Link Status of INPH<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INIV<TD>Link Status of INPI<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INJV<TD>Link Status of INPJ<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INKV<TD>Link Status of INPK<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INLV<TD>Link Status of INPL<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>OUTV<TD>OUT PV Status<TD>RECCHOICE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>CLCV<TD>CALC Valid<TD>LONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>OCLV<TD>OCAL Valid<TD>LONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DLYA<TD>Output Delay Active<TD>USHORT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>NAME<TD>Record Name<TD>STRING [29]<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>DESC<TD>Description<TD>STRING [29]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Alarm Parameters ===

The possible alarm conditions for the Calc record are the SCAN, READ, Calculation, and limit alarms. The SCAN and READ alarms are called by the record support routines. The Calculation alarm is called by the record processing routine when the CALC expression is an invalid one, upon which an error message is generated.

The following alarm parameters which are configured by the user define the limit alarms for the VAL field and the severity corresponding to those conditions.

The HYST field defines an alarm deadband for each limit. See [[RRM 3-14 Concepts#Alarm Specification|Alarm Specification]] for a complete explanation of alarms and these fields. [[RRM 3-14 dbCommon#Alarm Fields|Alarm Fields]] lists other fields related to a alarms that are common to all record types.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>HIHI<TD>Hihi Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HIGH<TD>High Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LOW<TD>Low Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LOLO<TD>Lolo Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HHSV<TD>Severity for a Hihi Alarm<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HSV<TD>Severity for a High Alarm<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LSV<TD>Severity for a Low Alarm<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LLSV<TD>Severity for a Lolo Alarm<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HYST<TD>Alarm Deadband<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Monitor Parameters ===

These parameters are used to determine when to send monitors for the value fields. The monitors are sent when the value field exceeds the last monitored field by the appropriate deadband, the ADEL for archiver monitors and the MDEL field for all other types of monitors. If these fields have a value of zero, every time the value changes, monitors are triggered; if they have a value of -1, every time the record is scanned, monitors are triggered. See [[RRM 3-14 Concepts#Monitor Specification|Monitor Specification]] for a complete explanation of monitors.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>ADEL<TD>Archive Deadband<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>MDEL<TD>Monitor, i.e. value change, Deadband<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Run-time Parameters ===

These fields are not configurable using a configuration too and none are modifiable at run-time. They are used to process the record.

The LALM field is used to implement the hysteresis factor for the alarm limits.

The LA-LL fields are used to decide when to trigger monitors for the corresponding fields. For instance, if LA does not equal the value for A, monitors for A are triggered. The MLST and MLST fields are used in the same manner for the VAL field.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>LALM<TD>Last Alarmed Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>ALST<TD>Archive Last Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>MLST<TD>Monitor Last Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LA<TD>Previous Input Value for A<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LB<TD>Previous Input Value for B<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LC<TD>Previous Input Value for C<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LD<TD>Previous Input Value for D<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LE<TD>Previous Input Value for E<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LF<TD>Previous Input Value for F<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LG<TD>Previous Input Value for G<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LH<TD>Previous Input Value for H<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LI<TD>Previous Input Value for I<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LJ<TD>Previous Input Value for J<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LK<TD>Previous Input Value for K<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LL<TD>Previous Input Value for L<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No
</TABLE>

== Record Support ==

=== Record Support Routines ===

==== init_record ====

For each constant input link, the corresponding value field is initialized with the constant value if the input link is CONSTANT or a channel access link is created if the input link is PV_LINK.

A routine postfix is called to convert the infix expression in CALC and OCAL to reverse polish notation. The result is stored in RPCL and ORPC, respectively.

==== process ====

See next section.

==== special ====

This is called if CALC or OCAL is changed. special calls postfix.

==== get_value ====

Fills in the values of struct valueDes so that they refer to VAL.

==== get_units ====

Retrieves EGU.

==== get_precision ====

Retrieves PREC.

==== get_graphic_double ====

Sets the upper display and lower display limits for a field. If the field is VAL, HIHI, HIGH, LOW, or LOLO, the limits are set to HOPR and LOPR, else if the field has upper and lower limits defined they will be used, else the upper and lower maximum values for the field type will be used.

==== get_control_double ====

Sets the upper control and the lower control limits for a field. If the field is VAL, HIHI, HIGH, LOW, or LOLO, the limits are set to HOPR and LOPR, else if the field has upper and lower limits defined they will be used, else the upper and lower maximum values for the field type will be used.

==== get_alarm_double ====

Sets the following values:

upper_alarm_limit = HIHI
upper_warning_limit = HIGH
lower_warning_limit = LOW
lower_alarm_limit = LOLO

=== Record Processing ===

==== process() ====

The <CODE>process()</CODE> routine implements the following algorithm:

# Fetch all arguments.
# Call routine calcPerform(), which calculates VAL from the postfix version of the expression given in CALC. If calcPerform() returns success, UDF is set to FALSE.
# Check alarms. This routine checks to see if the new VAL causes the alarm status and severity to change. If so, NSEV, NSTA and LALM are set. It also honors the alarm hysteresis factor (HYST). Thus the value must change by at least HYST before the alarm status and severity changes.
# Determine if the Output Execution Option (OOPT) is met. If it is met, either execute the output link (and output event) immediately (if ODLY = 0), or schedule a callback after the specified interval. See the explanation for the <CODE>execOutput()</CODE> routine below.
# Check to see if monitors should be invoked.
#* Alarm monitors are invoked if the alarm status or severity has changed.
#* Archive and value change monitors are invoked if ADEL and MDEL conditions are met.
#* Monitors for A-L are checked whenever other monitors are invoked.
#* NSEV and NSTA are reset to 0.
# If no output delay was specified, scan forward link if necessary, set PACT FALSE, and return.

==== execOutput() ====

# If DOPT field specifies the use of OCAL, call the routine calcPerform for the postfix version of the expression in OCAL. Otherwise, use VAL.
# If the Alarm Severity is INVALID, follow the option as designated by the field IVOA.
# If the Alarm Severity is not INVALID or IVOA specifies "Continue Normally", put the value of OVAL to the OUT link and post the event in OEVT (if non-zero).
# If an output delay was implemented, process the forward link.

----

EPICS Record Reference Manual - 19 MAY 1998

RRM 3-14 Binary Output

2009-03-18T17:00:15Z

LewisMuir: /* Desired Output Parameters */ Fixed typo

[[RRM 3-14|EPICS Record Reference Manual]]

= bo - Binary Output =

The normal use for this record type is to store a simple bit (0 or 1) value to be sent to a Digital Output module. It can also be used to write binary values into other records via database or channel access links. This record can implement both latched and momentary binary outputs depending on how the HIGH field is configured.

== Parameter Fields ==

The binary output's fields fall into the following categories:

* scan parameters
* convert and write parameters
* operator display parameters
* alarm parameters
* run-time parameters

=== Scan Parameters ===

The binary output record has the standard fields for specifying under what circumstances the record will be processed. These fields are listed in [[RRM 3-14 dbCommon#Scan Fields|Scan Fields]]. In addition, [[RRM 3-14 Concepts#Scanning Specification|Scanning Specification]] explains how these fields are used. Note that I/O event scanning is only supported for those card types that interrupt.

=== Desired Output Parameters ===

The binary output record must specify where its desired output originates. The desired output needs to be in engineering units.

The first field that determines where the desired output originates is the output mode select (OMSL) field, which can have two possible values: <CODE>closed_loop</CODE> or <CODE>supervisory</CODE>. If <CODE>supervisory</CODE> is specified, the value in the VAL field can be set externally via dbPuts at run-time. If <CODE>closed_loop</CODE> is specified, the VAL field's value is obtained from the address specified in the desired output location (DOL) field which can be either a database link or a channel access link. To achieve continuous control, a database link to a control algorithm record should be entered in the DOL field.

[[RRM 3-14 Concepts#Address Specification|Address Specification]] presents more information on database addresses and links. [[RRM 3-14 Concepts#Scanning Specification|Scanning Specification]] explains the effect of database linkage on scanning.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>DOL<TD>Desired Output Location (Input Link)<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>OMSL<TD>Output Mode Select<TD>[[RRM 3-14 Menu Choices#menuOmsl|menuOmsl]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Convert and Write Parameters ===

These parameters are used to determine where the binary output writes to and how to convert the engineering units to a raw signal. After VAL is set and forced to be either 1 or 0, as the result of either a dbPut or a new value being retrieved from the link in the DOL field, then what happens next depends on which device support routine is used and how the HIGH field is configured.

If the <CODE>Soft Channel</CODE> device support routine is specified, then the device support routine writes the VAL field's value to the address specified in the OUT field. Otherwise, RVAL is the value finally written by the device support routines after being converted.

If VAL is equal to 0, then the record processing routine sets RVAL equal to zero. When VAL is not equal to 0, then RVAL is set equal to the value contained in the MASK field. (MASK is set by the device support routines and is of no concern to the user.) Also when VAL is not 0 and after RVAL is set equal to MASK, the record processing routine checks to see if the HIGH field is greater than 0. If it is, then the routine will process the record again with VAL set to 0 after the number of seconds specified by HIGH. Thus, HIGH implements a momentary output which changes the state of the device back to 0 after ''N'' number of seconds.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>DTYP<TD>Device Type<TD>DEVCHOICE<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD> <TR>
<TD>OUT<TD>Output Link<TD>OUTLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>VAL<TD>Value Field<TD>ENUM<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>RVAL<TD>Raw Data Value<TD>ULONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>HIGH<TD>Seconds to Hold High<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>ZNAM<TD>Zero Name<TD>STRING [20]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>ONAM<TD>One Name<TD>STRING [20]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes
</TABLE>

==== Conversion Parameters ====

The ZNAM field has the string that corresponds to the 0 state, and the ONAM field holds the string that corresponds to the 1 state. These fields, other than being used to tell the operator what each state represents, are used to perform conversions if the value fetched by DOL is a string. If it is, VAL is set to the state correspond to that string. For instance, if the value fetched is the string "Off" and the ZNAM string is "Off," then VAL is set to 0.

After VAL is set, if VAL is equal to 0, then the record processing routine sets RVAL equal to zero. When VAL is not equal to 0, then RVAL is set equal to the value contained in the MASK field. (MASK is set by the device support routines and is of no concern to the user.) Also when VAL is equal to 1 and after RVAL is set equal to MASK, the record processing routine checks to see if the HIGH field is greater than 0. If it is, then the routine process the record again with VAL=0 after the number of seconds specified by HIGH. Thus, HIGH implements a latched output which changes the state of the device or link to 1, then changes it back to 0 after N number of seconds.

<TABLE BORDER="1">
<TD>ZNAM<TD>ASCII string defining state zero<TR>
<TD>ONAM<TD>ASCII string defining state one<TR>
<TD>HIGH<TD>If this value is greater than zero, then whenever VAL is set equal to 1, it is reset to zero after HIGH seconds.
</TABLE>

==== Output Specification ====

The OUT field specifies where the binary output record writes its output. It must specify the address of an I/O card if the record sends its output to hardware, and the DTYP field must contain a the corresponding device support module. Be aware that the address format differs according to the I/O bus used. See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on the format of hardware addresses. You can see a list of the device support modules currently supported at the user's local site by using the <CODE>dbst</CODE> utility in R3.13.

Otherwise, if the record is configured to use the soft device support modules, then it can be either a database link, a channel access link, or a constant. Be aware that nothing will be written when OUT is a constant. See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on the format of database and channel access addresses. Also, see [[#Device Support For Soft Records|Device Support For Soft Records]] in this chapter for more on output to other records.

=== Operator Display Parameters ===

These parameters are used to present meaningful data to the operator. The <CODE>get_enum_str</CODE> record support routine can retrieve the state string corresponding to the VAL's state. So if the value is 1, <CODE>get_enum_str</CODE> will return the string in the ONAM field; and if 0, <CODE>get_enum_str</CODE> will return the ZNAM string.

See [[RRM 3-14 dbCommon#Fields Common to All Record Types|Fields Common to All Record Types]] for more on the record name (NAME) and description (DESC) fields.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>ZNAM<TD>Zero Name<TD>STRING [20]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>ONAM<TD>One Name<TD>STRING [20]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>NAME<TD>Record Name<TD>STRING [29]<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>DESC<TD>Description<TD>STRING [29]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Alarm Parameters ===

These parameters are used to determine the binary output's alarm condition and to determine the severity of that condition. The possible alarm conditions for binary outputs are the SCAN, READ , INVALID, and state alarms. The user can configure the state alarm conditions using these fields.

The possible values for these fields are <CODE>NO_ALARM</CODE>, <CODE>MINOR</CODE>, and <CODE>MAJOR</CODE>. The ZSV holds the severity for the zero state; OSV for the one state. COSV is used to cause an alarm whenever the state changes between the states (0-1, or 1-0) and its severity is configured as MINOR or MAJOR.

See [[RRM 3-14 Common#Invalid Alarm Output Action|Invalid Alarm Output Action]] for more information on the IVOA and IVOV fields. [[RRM 3-14 dbCommon#Alarm Fields|Alarm Fields]] lists other fields related to a alarms that are common to all record types.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>ZSV<TD>Zero Severity<TD>[[RRM 3-14 Menu Choices#menuAlarmSevr|menuAlarmSevr]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>OSV<TD>One Severity<TD>[[RRM 3-14 Menu Choices#menuAlarmSevr|menuAlarmSevr]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>COSV<TD>Change of State Severity<TD>[[RRM 3-14 Menu Choices#menuAlarmSevr|menuAlarmSevr]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>IVOA<TD>Invalid Alarm<TD>[[RRM 3-14 Menu Choices#menuIvoa|menuIvoa]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>IVOV<TD>Invalid Alarm Output Value<TD>USHORT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Run-Time and Simulation Mode Parameters ===

These parameters are used by the run-time code for processing the binary output. They are not configurable using a configuration tool. They represent the current state of the binary output.

ORAW is used to determine if monitors should be triggered for RVAL at the same time they are triggered for VAL.

MASK is given a value by the device support routines and should not concern the user.

The RBV field is also set by device support. It is the actual read back value obtained from the hardware itself or from the associated device driver. The ORBV field is used to decide if monitors should be triggered for RBV at the same time monitors are triggered for changes in VAL.

The LALM field holds the value of the last occurrence of the change of state alarm. It is used to implement the change of state alarm, and thus only has meaning if COSV is MINOR or MAJOR.

The MLST is used by the <CODE>process</CODE> record support routine to determine if archive and value change monitors are invoked. They are if MLST is not equal to VAL.

The WPDT field is a private field for honoring seconds to hold HIGH.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>ORAW<TD>Old Raw Value<TD>ULONG<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>MASK<TD>Hardware Mask<TD>ULONG<TD>No<TD>compute<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>RBV<TD>Readback Value<TD>ULONG<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>ORBV<TD>Old Readback Value<TD>ULONG<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LALM<TD>Last Alarmed Value<TD>USHORT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>MLST<TD>Last Monitored Value<TD>USHORT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>RPVT<TD>Record Private<TD>NOACCESS<TD>No<TD>0<TD>No<TD>No<TD>No<TD>No<TR>
<TD>WDPT<TD>Watchdog Pointer<TD>NOACCESS<TD>No<TD>0<TD>No<TD>No<TD>No<TD>No
</TABLE>

The following fields are used to operate the binary output in the simulation mode. See [[RRM 3-14 Common#Fields Common to Many Record Types|Fields Common to Many Record Types]] for more information on these fields.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>SIOL<TD>Simulation Value Location<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>SVAL<TD>Simulation Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>SIML<TD>Simulation Mode Location<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>SIMM<TD>Simulation Mode<TD>[[RRM 3-14 Menu Choices#menuSimm|menuSimm]]<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>SIMS<TD>Simulation Mode Alarm Severity<TD>[[RRM 3-14 Menu Choices#menuAlarmSevr|menuAlarmSevr]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

== Record Support ==

=== Record Support Routines ===

==== init_record ====

This routine initializes SIMM if SIML is a constant or creates a channel access link if SIML is PV_LINK. If SIOL is PV_LINK a channel access link is created .

This routine next checks to see that device support is available. The routine next checks to see if the device support write routine is defined.

If either device support or the device support write routine does not exist, an error message is issued and processing is terminated.

If DOL is a constant, then VAL is initialized to 1 if its value is nonzero or initialized to 0 if DOL is zero, and UDF is set to FALSE.

If device support includes init_record, it is called. VAL is set using RVAL, and UDF is set to FALSE.

==== process ====

See next section.

==== get_value ====

Fills in the values of struct valueDes so that they refer to VAL.

==== get_enum_str ====

Retrieves ASCII string corresponding to VAL.

==== get_enum_strs ====

Retrieves ASCII strings for ZNAM and ONAM.

==== put_enum_str ====

Checks if string matches ZNAM or ONAM, and if it does, sets VAL.

=== Record Processing ===

Routine process implements the following algorithm:

# Check to see that the appropriate device support module exists. If it doesn't, an error message is issued and processing is terminated with the PACT field still set to TRUE. This ensures that processes will no longer be called for this record. Thus error storms will not occur.
# If PACT is FALSE
#* if DOL is DB_LINK and OMSL is CLOSED_LOOP
#** get value from DOL
#** check for link alarm
#** force VAL to be 0 or 1
#** if MASK is defined
#*** if VAL is 0 set RVAL = 0
#** else set RVAL = MASK
# Check alarms: This routine checks to see if the new VAL causes the alarm status and severity to change. If so, NSEV, NSTA and LALM are set.
# Check severity and write the new value. See [[RRM 3-14 Common#Invalid Alarm Output Action|Invalid Alarm Output Action]] for more information on how INVALID alarms affect output.
# If PACT has been changed to TRUE, the device support write output routine has started but has not completed writing the new value. In this case, the processing routine merely returns, leaving PACT TRUE.
# Check WAIT. If VAL is 1 and WAIT is greater than 0, process again with a VAL=0 after WAIT seconds.
# Check to see if monitors should be invoked.
#* Alarm monitors are invoked if the alarm status or severity has changed.
#* Archive and value change monitors are invoked if MLST is not equal to VAL.
#* Monitors for RVAL and for RBV are checked whenever other monitors are invoked.
#* NSEV and NSTA are reset to 0.
# Scan forward link if necessary, set PACT FALSE, and return.

== Device Support ==

=== Fields Of Interest To Device Support ===

Each binary output record must have an associated set of device support routines. The primary responsibility of the device support routines is to write a new value whenever write_bo is called. The device support routines are primarily interested in the following fields:

<TABLE BORDER="1">
<TH>Name<TH>Summary<TH>Description<TR>
<TD>PACT<TD>Processing Active<TD rowspan=4>See [[RRM 3-14 dbCommon#Fields Common to All Record Types|Fields Common to All Record Types]] for an explanation of these fields.<TR>
<TD>DPVT<TD>Device Private<TR>
<TD>NSEV<TD>New Alarm Severity<TR>
<TD>NSTA<TD>New Alarm Status<TR>
<TD>VAL<TD>Value Field<TD>This field is only of interest to device support routines that do not use MASK and RVAL.<TR>
<TD>OUT<TD>Output Link<TD>This field is used by the device support routines to locate its output.<TR>
<TD>RVAL<TD>Raw Data Value<TD>If MASK is defined then record support sets RVAL=(0,MASK) if VAL is (0, not zero).<TR>
<TD>MASK<TD>Hardware mask.<TD>The device support module must set this field. Not that if VAL is 1, then record processing sets RVAL = MASK.<TR>
<TD>RBV<TD>Read Back Value<TD>This is the actual read back value obtained from the hardware itself or from the associated device driver. It is the responsibility of the device support routine to give this field a value.
</TABLE>

=== Device Support routines ===

Device support consists of the following routines:

==== report ====

report(FILE fp, paddr)

Not currently used.

==== init ====

init()

This routine is called once during IOC initialization.

==== init_record ====

init_record(precord)

This routine is optional. If provided, it is called by the record support init_record routine. It should determine MASK if it is needed.

==== get_ioint_info ====

get_ioint_info(int cmd,struct dbCommon *precord,IOSCANPVT *ppvt)

This routine is called by the ioEventScan system each time the record is added or deleted from an I/O event scan list. cmd has the value (0,1) if the record is being (added to, deleted from) an I/O event list. It must be provided for any device type that can use the ioEvent scanner.

==== write_bo ====

write_bo(precord)

This routine must output an new value. It returns the following values:

* 0: Success.
* other: Error.

=== Device Support For Soft Records ===

Two soft device support modules <CODE>Soft Channel</CODE> and <CODE>Raw Soft Channel</CODE> are provided for output records not related to actual hardware devices. The OUT link type must be either a CONSTANT, DB_LINK, or CA_LINK.

==== Soft Channel ====

This module writes the current value of VAL.

If the OUT link type is PV_LINK, then dbCaAddInlink is called by init_record. init_record always returns a value of 2, which means that no conversion will ever be attempted. write_bo calls recGblPutLinkValue to write the current value of VAL. See [[RRM 3-14 Common#Soft Output|Soft Output]] for details.

==== Raw Soft Channel ====

This module is like the previous except that it writes the current value of RVAL.

----

EPICS Record Reference Manual - 19 MAY 1998

RRM 3-14 Binary Output

2009-03-18T16:58:27Z

LewisMuir: /* Output Specification */ Corrected definition of OUT field

[[RRM 3-14|EPICS Record Reference Manual]]

= bo - Binary Output =

The normal use for this record type is to store a simple bit (0 or 1) value to be sent to a Digital Output module. It can also be used to write binary values into other records via database or channel access links. This record can implement both latched and momentary binary outputs depending on how the HIGH field is configured.

== Parameter Fields ==

The binary output's fields fall into the following categories:

* scan parameters
* convert and write parameters
* operator display parameters
* alarm parameters
* run-time parameters

=== Scan Parameters ===

The binary output record has the standard fields for specifying under what circumstances the record will be processed. These fields are listed in [[RRM 3-14 dbCommon#Scan Fields|Scan Fields]]. In addition, [[RRM 3-14 Concepts#Scanning Specification|Scanning Specification]] explains how these fields are used. Note that I/O event scanning is only supported for those card types that interrupt.

=== Desired Output Parameters ===

The binary output record must specify where its desired output originates. The desired output needs to be in engineering units.

The first field that determines where the desired output originates is the output mode select (OSML) field, which can have two possible values: <CODE>closed_loop</CODE> or <CODE>supervisory</CODE>. If <CODE>supervisory</CODE> is specified, the value in the VAL field can be set externally via dbPuts at run-time. If <CODE>closed_loop</CODE> is specified, the VAL field's value is obtained from the address specified in the desired output location (DOL) field which can be either a database link or a channel access link. To achieve continuous control, a database link to a control algorithm record should be entered in the DOL field.

[[RRM 3-14 Concepts#Address Specification|Address Specification]] presents more information on database addresses and links. [[RRM 3-14 Concepts#Scanning Specification|Scanning Specification]] explains the effect of database linkage on scanning.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>DOL<TD>Desired Output Location (Input Link)<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>OMSL<TD>Output Mode Select<TD>[[RRM 3-14 Menu Choices#menuOmsl|menuOmsl]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Convert and Write Parameters ===

These parameters are used to determine where the binary output writes to and how to convert the engineering units to a raw signal. After VAL is set and forced to be either 1 or 0, as the result of either a dbPut or a new value being retrieved from the link in the DOL field, then what happens next depends on which device support routine is used and how the HIGH field is configured.

If the <CODE>Soft Channel</CODE> device support routine is specified, then the device support routine writes the VAL field's value to the address specified in the OUT field. Otherwise, RVAL is the value finally written by the device support routines after being converted.

If VAL is equal to 0, then the record processing routine sets RVAL equal to zero. When VAL is not equal to 0, then RVAL is set equal to the value contained in the MASK field. (MASK is set by the device support routines and is of no concern to the user.) Also when VAL is not 0 and after RVAL is set equal to MASK, the record processing routine checks to see if the HIGH field is greater than 0. If it is, then the routine will process the record again with VAL set to 0 after the number of seconds specified by HIGH. Thus, HIGH implements a momentary output which changes the state of the device back to 0 after ''N'' number of seconds.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>DTYP<TD>Device Type<TD>DEVCHOICE<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD> <TR>
<TD>OUT<TD>Output Link<TD>OUTLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>VAL<TD>Value Field<TD>ENUM<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>RVAL<TD>Raw Data Value<TD>ULONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>HIGH<TD>Seconds to Hold High<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>ZNAM<TD>Zero Name<TD>STRING [20]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>ONAM<TD>One Name<TD>STRING [20]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes
</TABLE>

==== Conversion Parameters ====

The ZNAM field has the string that corresponds to the 0 state, and the ONAM field holds the string that corresponds to the 1 state. These fields, other than being used to tell the operator what each state represents, are used to perform conversions if the value fetched by DOL is a string. If it is, VAL is set to the state correspond to that string. For instance, if the value fetched is the string "Off" and the ZNAM string is "Off," then VAL is set to 0.

After VAL is set, if VAL is equal to 0, then the record processing routine sets RVAL equal to zero. When VAL is not equal to 0, then RVAL is set equal to the value contained in the MASK field. (MASK is set by the device support routines and is of no concern to the user.) Also when VAL is equal to 1 and after RVAL is set equal to MASK, the record processing routine checks to see if the HIGH field is greater than 0. If it is, then the routine process the record again with VAL=0 after the number of seconds specified by HIGH. Thus, HIGH implements a latched output which changes the state of the device or link to 1, then changes it back to 0 after N number of seconds.

<TABLE BORDER="1">
<TD>ZNAM<TD>ASCII string defining state zero<TR>
<TD>ONAM<TD>ASCII string defining state one<TR>
<TD>HIGH<TD>If this value is greater than zero, then whenever VAL is set equal to 1, it is reset to zero after HIGH seconds.
</TABLE>

==== Output Specification ====

The OUT field specifies where the binary output record writes its output. It must specify the address of an I/O card if the record sends its output to hardware, and the DTYP field must contain a the corresponding device support module. Be aware that the address format differs according to the I/O bus used. See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on the format of hardware addresses. You can see a list of the device support modules currently supported at the user's local site by using the <CODE>dbst</CODE> utility in R3.13.

Otherwise, if the record is configured to use the soft device support modules, then it can be either a database link, a channel access link, or a constant. Be aware that nothing will be written when OUT is a constant. See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on the format of database and channel access addresses. Also, see [[#Device Support For Soft Records|Device Support For Soft Records]] in this chapter for more on output to other records.

=== Operator Display Parameters ===

These parameters are used to present meaningful data to the operator. The <CODE>get_enum_str</CODE> record support routine can retrieve the state string corresponding to the VAL's state. So if the value is 1, <CODE>get_enum_str</CODE> will return the string in the ONAM field; and if 0, <CODE>get_enum_str</CODE> will return the ZNAM string.

See [[RRM 3-14 dbCommon#Fields Common to All Record Types|Fields Common to All Record Types]] for more on the record name (NAME) and description (DESC) fields.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>ZNAM<TD>Zero Name<TD>STRING [20]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>ONAM<TD>One Name<TD>STRING [20]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>NAME<TD>Record Name<TD>STRING [29]<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>DESC<TD>Description<TD>STRING [29]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Alarm Parameters ===

These parameters are used to determine the binary output's alarm condition and to determine the severity of that condition. The possible alarm conditions for binary outputs are the SCAN, READ , INVALID, and state alarms. The user can configure the state alarm conditions using these fields.

The possible values for these fields are <CODE>NO_ALARM</CODE>, <CODE>MINOR</CODE>, and <CODE>MAJOR</CODE>. The ZSV holds the severity for the zero state; OSV for the one state. COSV is used to cause an alarm whenever the state changes between the states (0-1, or 1-0) and its severity is configured as MINOR or MAJOR.

See [[RRM 3-14 Common#Invalid Alarm Output Action|Invalid Alarm Output Action]] for more information on the IVOA and IVOV fields. [[RRM 3-14 dbCommon#Alarm Fields|Alarm Fields]] lists other fields related to a alarms that are common to all record types.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>ZSV<TD>Zero Severity<TD>[[RRM 3-14 Menu Choices#menuAlarmSevr|menuAlarmSevr]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>OSV<TD>One Severity<TD>[[RRM 3-14 Menu Choices#menuAlarmSevr|menuAlarmSevr]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>COSV<TD>Change of State Severity<TD>[[RRM 3-14 Menu Choices#menuAlarmSevr|menuAlarmSevr]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>IVOA<TD>Invalid Alarm<TD>[[RRM 3-14 Menu Choices#menuIvoa|menuIvoa]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>IVOV<TD>Invalid Alarm Output Value<TD>USHORT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Run-Time and Simulation Mode Parameters ===

These parameters are used by the run-time code for processing the binary output. They are not configurable using a configuration tool. They represent the current state of the binary output.

ORAW is used to determine if monitors should be triggered for RVAL at the same time they are triggered for VAL.

MASK is given a value by the device support routines and should not concern the user.

The RBV field is also set by device support. It is the actual read back value obtained from the hardware itself or from the associated device driver. The ORBV field is used to decide if monitors should be triggered for RBV at the same time monitors are triggered for changes in VAL.

The LALM field holds the value of the last occurrence of the change of state alarm. It is used to implement the change of state alarm, and thus only has meaning if COSV is MINOR or MAJOR.

The MLST is used by the <CODE>process</CODE> record support routine to determine if archive and value change monitors are invoked. They are if MLST is not equal to VAL.

The WPDT field is a private field for honoring seconds to hold HIGH.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>ORAW<TD>Old Raw Value<TD>ULONG<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>MASK<TD>Hardware Mask<TD>ULONG<TD>No<TD>compute<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>RBV<TD>Readback Value<TD>ULONG<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>ORBV<TD>Old Readback Value<TD>ULONG<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LALM<TD>Last Alarmed Value<TD>USHORT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>MLST<TD>Last Monitored Value<TD>USHORT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>RPVT<TD>Record Private<TD>NOACCESS<TD>No<TD>0<TD>No<TD>No<TD>No<TD>No<TR>
<TD>WDPT<TD>Watchdog Pointer<TD>NOACCESS<TD>No<TD>0<TD>No<TD>No<TD>No<TD>No
</TABLE>

The following fields are used to operate the binary output in the simulation mode. See [[RRM 3-14 Common#Fields Common to Many Record Types|Fields Common to Many Record Types]] for more information on these fields.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>SIOL<TD>Simulation Value Location<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>SVAL<TD>Simulation Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>SIML<TD>Simulation Mode Location<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>SIMM<TD>Simulation Mode<TD>[[RRM 3-14 Menu Choices#menuSimm|menuSimm]]<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>SIMS<TD>Simulation Mode Alarm Severity<TD>[[RRM 3-14 Menu Choices#menuAlarmSevr|menuAlarmSevr]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

== Record Support ==

=== Record Support Routines ===

==== init_record ====

This routine initializes SIMM if SIML is a constant or creates a channel access link if SIML is PV_LINK. If SIOL is PV_LINK a channel access link is created .

This routine next checks to see that device support is available. The routine next checks to see if the device support write routine is defined.

If either device support or the device support write routine does not exist, an error message is issued and processing is terminated.

If DOL is a constant, then VAL is initialized to 1 if its value is nonzero or initialized to 0 if DOL is zero, and UDF is set to FALSE.

If device support includes init_record, it is called. VAL is set using RVAL, and UDF is set to FALSE.

==== process ====

See next section.

==== get_value ====

Fills in the values of struct valueDes so that they refer to VAL.

==== get_enum_str ====

Retrieves ASCII string corresponding to VAL.

==== get_enum_strs ====

Retrieves ASCII strings for ZNAM and ONAM.

==== put_enum_str ====

Checks if string matches ZNAM or ONAM, and if it does, sets VAL.

=== Record Processing ===

Routine process implements the following algorithm:

# Check to see that the appropriate device support module exists. If it doesn't, an error message is issued and processing is terminated with the PACT field still set to TRUE. This ensures that processes will no longer be called for this record. Thus error storms will not occur.
# If PACT is FALSE
#* if DOL is DB_LINK and OMSL is CLOSED_LOOP
#** get value from DOL
#** check for link alarm
#** force VAL to be 0 or 1
#** if MASK is defined
#*** if VAL is 0 set RVAL = 0
#** else set RVAL = MASK
# Check alarms: This routine checks to see if the new VAL causes the alarm status and severity to change. If so, NSEV, NSTA and LALM are set.
# Check severity and write the new value. See [[RRM 3-14 Common#Invalid Alarm Output Action|Invalid Alarm Output Action]] for more information on how INVALID alarms affect output.
# If PACT has been changed to TRUE, the device support write output routine has started but has not completed writing the new value. In this case, the processing routine merely returns, leaving PACT TRUE.
# Check WAIT. If VAL is 1 and WAIT is greater than 0, process again with a VAL=0 after WAIT seconds.
# Check to see if monitors should be invoked.
#* Alarm monitors are invoked if the alarm status or severity has changed.
#* Archive and value change monitors are invoked if MLST is not equal to VAL.
#* Monitors for RVAL and for RBV are checked whenever other monitors are invoked.
#* NSEV and NSTA are reset to 0.
# Scan forward link if necessary, set PACT FALSE, and return.

== Device Support ==

=== Fields Of Interest To Device Support ===

Each binary output record must have an associated set of device support routines. The primary responsibility of the device support routines is to write a new value whenever write_bo is called. The device support routines are primarily interested in the following fields:

<TABLE BORDER="1">
<TH>Name<TH>Summary<TH>Description<TR>
<TD>PACT<TD>Processing Active<TD rowspan=4>See [[RRM 3-14 dbCommon#Fields Common to All Record Types|Fields Common to All Record Types]] for an explanation of these fields.<TR>
<TD>DPVT<TD>Device Private<TR>
<TD>NSEV<TD>New Alarm Severity<TR>
<TD>NSTA<TD>New Alarm Status<TR>
<TD>VAL<TD>Value Field<TD>This field is only of interest to device support routines that do not use MASK and RVAL.<TR>
<TD>OUT<TD>Output Link<TD>This field is used by the device support routines to locate its output.<TR>
<TD>RVAL<TD>Raw Data Value<TD>If MASK is defined then record support sets RVAL=(0,MASK) if VAL is (0, not zero).<TR>
<TD>MASK<TD>Hardware mask.<TD>The device support module must set this field. Not that if VAL is 1, then record processing sets RVAL = MASK.<TR>
<TD>RBV<TD>Read Back Value<TD>This is the actual read back value obtained from the hardware itself or from the associated device driver. It is the responsibility of the device support routine to give this field a value.
</TABLE>

=== Device Support routines ===

Device support consists of the following routines:

==== report ====

report(FILE fp, paddr)

Not currently used.

==== init ====

init()

This routine is called once during IOC initialization.

==== init_record ====

init_record(precord)

This routine is optional. If provided, it is called by the record support init_record routine. It should determine MASK if it is needed.

==== get_ioint_info ====

get_ioint_info(int cmd,struct dbCommon *precord,IOSCANPVT *ppvt)

This routine is called by the ioEventScan system each time the record is added or deleted from an I/O event scan list. cmd has the value (0,1) if the record is being (added to, deleted from) an I/O event list. It must be provided for any device type that can use the ioEvent scanner.

==== write_bo ====

write_bo(precord)

This routine must output an new value. It returns the following values:

* 0: Success.
* other: Error.

=== Device Support For Soft Records ===

Two soft device support modules <CODE>Soft Channel</CODE> and <CODE>Raw Soft Channel</CODE> are provided for output records not related to actual hardware devices. The OUT link type must be either a CONSTANT, DB_LINK, or CA_LINK.

==== Soft Channel ====

This module writes the current value of VAL.

If the OUT link type is PV_LINK, then dbCaAddInlink is called by init_record. init_record always returns a value of 2, which means that no conversion will ever be attempted. write_bo calls recGblPutLinkValue to write the current value of VAL. See [[RRM 3-14 Common#Soft Output|Soft Output]] for details.

==== Raw Soft Channel ====

This module is like the previous except that it writes the current value of RVAL.

----

EPICS Record Reference Manual - 19 MAY 1998

RRM 3-14 Binary Output

2009-02-18T16:26:00Z

LewisMuir: /* Desired Output Parameters */ Fixed typo

[[RRM 3-14|EPICS Record Reference Manual]]

= bo - Binary Output =

The normal use for this record type is to store a simple bit (0 or 1) value to be sent to a Digital Output module. It can also be used to write binary values into other records via database or channel access links. This record can implement both latched and momentary binary outputs depending on how the HIGH field is configured.

== Parameter Fields ==

The binary output's fields fall into the following categories:

* scan parameters
* convert and write parameters
* operator display parameters
* alarm parameters
* run-time parameters

=== Scan Parameters ===

The binary output record has the standard fields for specifying under what circumstances the record will be processed. These fields are listed in [[RRM 3-14 dbCommon#Scan Fields|Scan Fields]]. In addition, [[RRM 3-14 Concepts#Scanning Specification|Scanning Specification]] explains how these fields are used. Note that I/O event scanning is only supported for those card types that interrupt.

=== Desired Output Parameters ===

The binary output record must specify where its desired output originates. The desired output needs to be in engineering units.

The first field that determines where the desired output originates is the output mode select (OSML) field, which can have two possible values: <CODE>closed_loop</CODE> or <CODE>supervisory</CODE>. If <CODE>supervisory</CODE> is specified, the value in the VAL field can be set externally via dbPuts at run-time. If <CODE>closed_loop</CODE> is specified, the VAL field's value is obtained from the address specified in the desired output location (DOL) field which can be either a database link or a channel access link. To achieve continuous control, a database link to a control algorithm record should be entered in the DOL field.

[[RRM 3-14 Concepts#Address Specification|Address Specification]] presents more information on database addresses and links. [[RRM 3-14 Concepts#Scanning Specification|Scanning Specification]] explains the effect of database linkage on scanning.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>DOL<TD>Desired Output Location (Input Link)<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>OMSL<TD>Output Mode Select<TD>[[RRM 3-14 Menu Choices#menuOmsl|menuOmsl]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Convert and Write Parameters ===

These parameters are used to determine where the binary output writes to and how to convert the engineering units to a raw signal. After VAL is set and forced to be either 1 or 0, as the result of either a dbPut or a new value being retrieved from the link in the DOL field, then what happens next depends on which device support routine is used and how the HIGH field is configured.

If the <CODE>Soft Channel</CODE> device support routine is specified, then the device support routine writes the VAL field's value to the address specified in the OUT field. Otherwise, RVAL is the value finally written by the device support routines after being converted.

If VAL is equal to 0, then the record processing routine sets RVAL equal to zero. When VAL is not equal to 0, then RVAL is set equal to the value contained in the MASK field. (MASK is set by the device support routines and is of no concern to the user.) Also when VAL is not 0 and after RVAL is set equal to MASK, the record processing routine checks to see if the HIGH field is greater than 0. If it is, then the routine will process the record again with VAL set to 0 after the number of seconds specified by HIGH. Thus, HIGH implements a momentary output which changes the state of the device back to 0 after ''N'' number of seconds.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>DTYP<TD>Device Type<TD>DEVCHOICE<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD> <TR>
<TD>OUT<TD>Output Link<TD>OUTLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>VAL<TD>Value Field<TD>ENUM<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>RVAL<TD>Raw Data Value<TD>ULONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>HIGH<TD>Seconds to Hold High<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>ZNAM<TD>Zero Name<TD>STRING [20]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>ONAM<TD>One Name<TD>STRING [20]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes
</TABLE>

==== Conversion Parameters ====

The ZNAM field has the string that corresponds to the 0 state, and the ONAM field holds the string that corresponds to the 1 state. These fields, other than being used to tell the operator what each state represents, are used to perform conversions if the value fetched by DOL is a string. If it is, VAL is set to the state correspond to that string. For instance, if the value fetched is the string "Off" and the ZNAM string is "Off," then VAL is set to 0.

After VAL is set, if VAL is equal to 0, then the record processing routine sets RVAL equal to zero. When VAL is not equal to 0, then RVAL is set equal to the value contained in the MASK field. (MASK is set by the device support routines and is of no concern to the user.) Also when VAL is equal to 1 and after RVAL is set equal to MASK, the record processing routine checks to see if the HIGH field is greater than 0. If it is, then the routine process the record again with VAL=0 after the number of seconds specified by HIGH. Thus, HIGH implements a latched output which changes the state of the device or link to 1, then changes it back to 0 after N number of seconds.

<TABLE BORDER="1">
<TD>ZNAM<TD>ASCII string defining state zero<TR>
<TD>ONAM<TD>ASCII string defining state one<TR>
<TD>HIGH<TD>If this value is greater than zero, then whenever VAL is set equal to 1, it is reset to zero after HIGH seconds.
</TABLE>

==== Output Specification ====

The OUT field specifies where the binary output record gets its input. It must specify the address of an I/O card if the record sends its output to hardware, and the DTYP field must contain a the corresponding device support module. Be aware that the address format differs according to the I/O bus used. See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on the format of hardware addresses. You can see a list of the device support modules currently supported at the user's local site by using the <CODE>dbst</CODE> utility in R3.13.

Otherwise, if the record is configured to use the soft device support modules, then it can be either a database link, a channel access link, or a constant. Be aware that nothing will be written when OUT is a constant. See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on the format of database and channel access addresses. Also, see [[#Device Support For Soft Records|Device Support For Soft Records]] in this chapter for more on output to other records.

=== Operator Display Parameters ===

These parameters are used to present meaningful data to the operator. The <CODE>get_enum_str</CODE> record support routine can retrieve the state string corresponding to the VAL's state. So if the value is 1, <CODE>get_enum_str</CODE> will return the string in the ONAM field; and if 0, <CODE>get_enum_str</CODE> will return the ZNAM string.

See [[RRM 3-14 dbCommon#Fields Common to All Record Types|Fields Common to All Record Types]] for more on the record name (NAME) and description (DESC) fields.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>ZNAM<TD>Zero Name<TD>STRING [20]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>ONAM<TD>One Name<TD>STRING [20]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>NAME<TD>Record Name<TD>STRING [29]<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>DESC<TD>Description<TD>STRING [29]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Alarm Parameters ===

These parameters are used to determine the binary output's alarm condition and to determine the severity of that condition. The possible alarm conditions for binary outputs are the SCAN, READ , INVALID, and state alarms. The user can configure the state alarm conditions using these fields.

The possible values for these fields are <CODE>NO_ALARM</CODE>, <CODE>MINOR</CODE>, and <CODE>MAJOR</CODE>. The ZSV holds the severity for the zero state; OSV for the one state. COSV is used to cause an alarm whenever the state changes between the states (0-1, or 1-0) and its severity is configured as MINOR or MAJOR.

See [[RRM 3-14 Common#Invalid Alarm Output Action|Invalid Alarm Output Action]] for more information on the IVOA and IVOV fields. [[RRM 3-14 dbCommon#Alarm Fields|Alarm Fields]] lists other fields related to a alarms that are common to all record types.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>ZSV<TD>Zero Severity<TD>[[RRM 3-14 Menu Choices#menuAlarmSevr|menuAlarmSevr]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>OSV<TD>One Severity<TD>[[RRM 3-14 Menu Choices#menuAlarmSevr|menuAlarmSevr]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>COSV<TD>Change of State Severity<TD>[[RRM 3-14 Menu Choices#menuAlarmSevr|menuAlarmSevr]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>IVOA<TD>Invalid Alarm<TD>[[RRM 3-14 Menu Choices#menuIvoa|menuIvoa]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>IVOV<TD>Invalid Alarm Output Value<TD>USHORT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Run-Time and Simulation Mode Parameters ===

These parameters are used by the run-time code for processing the binary output. They are not configurable using a configuration tool. They represent the current state of the binary output.

ORAW is used to determine if monitors should be triggered for RVAL at the same time they are triggered for VAL.

MASK is given a value by the device support routines and should not concern the user.

The RBV field is also set by device support. It is the actual read back value obtained from the hardware itself or from the associated device driver. The ORBV field is used to decide if monitors should be triggered for RBV at the same time monitors are triggered for changes in VAL.

The LALM field holds the value of the last occurrence of the change of state alarm. It is used to implement the change of state alarm, and thus only has meaning if COSV is MINOR or MAJOR.

The MLST is used by the <CODE>process</CODE> record support routine to determine if archive and value change monitors are invoked. They are if MLST is not equal to VAL.

The WPDT field is a private field for honoring seconds to hold HIGH.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>ORAW<TD>Old Raw Value<TD>ULONG<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>MASK<TD>Hardware Mask<TD>ULONG<TD>No<TD>compute<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>RBV<TD>Readback Value<TD>ULONG<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>ORBV<TD>Old Readback Value<TD>ULONG<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LALM<TD>Last Alarmed Value<TD>USHORT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>MLST<TD>Last Monitored Value<TD>USHORT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>RPVT<TD>Record Private<TD>NOACCESS<TD>No<TD>0<TD>No<TD>No<TD>No<TD>No<TR>
<TD>WDPT<TD>Watchdog Pointer<TD>NOACCESS<TD>No<TD>0<TD>No<TD>No<TD>No<TD>No
</TABLE>

The following fields are used to operate the binary output in the simulation mode. See [[RRM 3-14 Common#Fields Common to Many Record Types|Fields Common to Many Record Types]] for more information on these fields.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>SIOL<TD>Simulation Value Location<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>SVAL<TD>Simulation Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>SIML<TD>Simulation Mode Location<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>SIMM<TD>Simulation Mode<TD>[[RRM 3-14 Menu Choices#menuSimm|menuSimm]]<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>SIMS<TD>Simulation Mode Alarm Severity<TD>[[RRM 3-14 Menu Choices#menuAlarmSevr|menuAlarmSevr]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

== Record Support ==

=== Record Support Routines ===

==== init_record ====

This routine initializes SIMM if SIML is a constant or creates a channel access link if SIML is PV_LINK. If SIOL is PV_LINK a channel access link is created .

This routine next checks to see that device support is available. The routine next checks to see if the device support write routine is defined.

If either device support or the device support write routine does not exist, an error message is issued and processing is terminated.

If DOL is a constant, then VAL is initialized to 1 if its value is nonzero or initialized to 0 if DOL is zero, and UDF is set to FALSE.

If device support includes init_record, it is called. VAL is set using RVAL, and UDF is set to FALSE.

==== process ====

See next section.

==== get_value ====

Fills in the values of struct valueDes so that they refer to VAL.

==== get_enum_str ====

Retrieves ASCII string corresponding to VAL.

==== get_enum_strs ====

Retrieves ASCII strings for ZNAM and ONAM.

==== put_enum_str ====

Checks if string matches ZNAM or ONAM, and if it does, sets VAL.

=== Record Processing ===

Routine process implements the following algorithm:

# Check to see that the appropriate device support module exists. If it doesn't, an error message is issued and processing is terminated with the PACT field still set to TRUE. This ensures that processes will no longer be called for this record. Thus error storms will not occur.
# If PACT is FALSE
#* if DOL is DB_LINK and OMSL is CLOSED_LOOP
#** get value from DOL
#** check for link alarm
#** force VAL to be 0 or 1
#** if MASK is defined
#*** if VAL is 0 set RVAL = 0
#** else set RVAL = MASK
# Check alarms: This routine checks to see if the new VAL causes the alarm status and severity to change. If so, NSEV, NSTA and LALM are set.
# Check severity and write the new value. See [[RRM 3-14 Common#Invalid Alarm Output Action|Invalid Alarm Output Action]] for more information on how INVALID alarms affect output.
# If PACT has been changed to TRUE, the device support write output routine has started but has not completed writing the new value. In this case, the processing routine merely returns, leaving PACT TRUE.
# Check WAIT. If VAL is 1 and WAIT is greater than 0, process again with a VAL=0 after WAIT seconds.
# Check to see if monitors should be invoked.
#* Alarm monitors are invoked if the alarm status or severity has changed.
#* Archive and value change monitors are invoked if MLST is not equal to VAL.
#* Monitors for RVAL and for RBV are checked whenever other monitors are invoked.
#* NSEV and NSTA are reset to 0.
# Scan forward link if necessary, set PACT FALSE, and return.

== Device Support ==

=== Fields Of Interest To Device Support ===

Each binary output record must have an associated set of device support routines. The primary responsibility of the device support routines is to write a new value whenever write_bo is called. The device support routines are primarily interested in the following fields:

<TABLE BORDER="1">
<TH>Name<TH>Summary<TH>Description<TR>
<TD>PACT<TD>Processing Active<TD rowspan=4>See [[RRM 3-14 dbCommon#Fields Common to All Record Types|Fields Common to All Record Types]] for an explanation of these fields.<TR>
<TD>DPVT<TD>Device Private<TR>
<TD>NSEV<TD>New Alarm Severity<TR>
<TD>NSTA<TD>New Alarm Status<TR>
<TD>VAL<TD>Value Field<TD>This field is only of interest to device support routines that do not use MASK and RVAL.<TR>
<TD>OUT<TD>Output Link<TD>This field is used by the device support routines to locate its output.<TR>
<TD>RVAL<TD>Raw Data Value<TD>If MASK is defined then record support sets RVAL=(0,MASK) if VAL is (0, not zero).<TR>
<TD>MASK<TD>Hardware mask.<TD>The device support module must set this field. Not that if VAL is 1, then record processing sets RVAL = MASK.<TR>
<TD>RBV<TD>Read Back Value<TD>This is the actual read back value obtained from the hardware itself or from the associated device driver. It is the responsibility of the device support routine to give this field a value.
</TABLE>

=== Device Support routines ===

Device support consists of the following routines:

==== report ====

report(FILE fp, paddr)

Not currently used.

==== init ====

init()

This routine is called once during IOC initialization.

==== init_record ====

init_record(precord)

This routine is optional. If provided, it is called by the record support init_record routine. It should determine MASK if it is needed.

==== get_ioint_info ====

get_ioint_info(int cmd,struct dbCommon *precord,IOSCANPVT *ppvt)

This routine is called by the ioEventScan system each time the record is added or deleted from an I/O event scan list. cmd has the value (0,1) if the record is being (added to, deleted from) an I/O event list. It must be provided for any device type that can use the ioEvent scanner.

==== write_bo ====

write_bo(precord)

This routine must output an new value. It returns the following values:

* 0: Success.
* other: Error.

=== Device Support For Soft Records ===

Two soft device support modules <CODE>Soft Channel</CODE> and <CODE>Raw Soft Channel</CODE> are provided for output records not related to actual hardware devices. The OUT link type must be either a CONSTANT, DB_LINK, or CA_LINK.

==== Soft Channel ====

This module writes the current value of VAL.

If the OUT link type is PV_LINK, then dbCaAddInlink is called by init_record. init_record always returns a value of 2, which means that no conversion will ever be attempted. write_bo calls recGblPutLinkValue to write the current value of VAL. See [[RRM 3-14 Common#Soft Output|Soft Output]] for details.

==== Raw Soft Channel ====

This module is like the previous except that it writes the current value of RVAL.

----

EPICS Record Reference Manual - 19 MAY 1998

File:RRM 3-14 Compression-2.gif

2009-02-13T19:51:10Z

LewisMuir: RRM Compression Diagram 1.

RRM Compression Diagram 1.

File:RRM 3-14 Compression-1.gif

2009-02-13T19:50:43Z

LewisMuir: RRM Compression Equation 1.

RRM Compression Equation 1.

RRM 3-14 Sequence

2009-01-06T23:09:47Z

LewisMuir: /* Output Parameters */ Fixed typo

[[RRM 3-14|EPICS Record Reference Manual]]

= seq - Sequence =

The Sequence record is used to trigger the processing of up to ten other records and send values to those records. It is similar to the fanout record, except that it will fetch an input value and write an output value instead of simply processing a collection of forward links. It can also specify one of several selection algorithms that determine which values to write. It has no associated device support.

== Parameter Fields ==

The fields fall into the following categories:

* scan parameters
* desired output parameters
* output parameters
* selection algorithm parameters
* delay parameters
* operator display parameters
* run-time parameters

=== Scan Parameters ===

The sequence record has the standard fields for specifying under what circumstances it will be processed. These fields are listed in [[RRM 3-14 dbCommon#Scan Fields|Scan Fields]]. In addition, [[RRM 3-14 Concepts#Scanning Specification|Scanning Specification]] explains how these fields are used.

=== Desired Output Parameters ===

These fields determine where the record retrieves the values it is to write to other records. All of these values are not necessarily used, depending on the selection algorithm.

The sequence record can retrieve up to 10 values from 10 locations. The user specifies the locations in the Desired Output Link fields (DOL1-DOLA), which can be either constants, database links, or channel access links. If a Desired Output Link is a constant, the corresponding value field for that link is initialized to the constant value and ''cannot'' be changed via dbputs. Otherwise, if the Desired Output Link is a database or channel access link, a value is fetched from the link each time the record is processed (provided that the output link is part of the record's selection algorithm). See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on how to specify database links.

The value fetched from the Desired Output Links are stored in the corresponding Desired Output Value fields (DO1-DOA). These fields can be initialized to a constant value, but they cannot be changed via dbPuts.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>DOL1<TD>Desired Output Link 1<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>DOL2<TD>Desired Output Link 2<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>DOL3<TD>Desired Output Link 3<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>DOL4<TD>Desired Output Link 4<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>DOL5<TD>Desired Output Link 5<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>DOL6<TD>Desired Output Link 6<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>DOL7<TD>Desired Output Link 7<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>DOL8<TD>Desired Output Link 8<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>DOL9<TD>Desired Output Link 9<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>DOLA<TD>Desired Output Link 10<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>DO1<TD>Desired Output Value, Link 1<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DO2<TD>Desired Output Value, Link 2<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DO3<TD>Desired Output Value, Link 3<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DO4<TD>Desired Output Value, Link 4<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DO5<TD>Desired Output Value, Link 5<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DO6<TD>Desired Output Value, Link 6<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DO7<TD>Desired Output Value, Link 7<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DO8<TD>Desired Output Value, Link 8<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DO9<TD>Desired Output Value, Link 9<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DOA<TD>Desired Output Value, Link 10 <TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Output Parameters ===

When the record is processed, the desired output values are retrieved for the links in the record's selection algorithm and are written to the corresponding output link (LNK1-LNKA). These output links can be database links or channel access links; they cannot be device addresses. There are ten output links, one for each desired output link. Only those that are defined are used.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>LNK1<TD>Output link 1<TD>OUTLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>LNK2<TD>Output link 2<TD>OUTLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>LNK3<TD>Output link 3<TD>OUTLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>LNK4<TD>Output link 4<TD>OUTLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>LNK5<TD>Output link 5<TD>OUTLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>LNK6<TD>Output link 6<TD>OUTLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>LNK7<TD>Output link 7<TD>OUTLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>LNK8<TD>Output link 8<TD>OUTLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>LNK9<TD>Output link 9<TD>OUTLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>LNKA<TD>Output link 10<TD>OUTLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No
</TABLE>

=== Selection Algorithm Parameters ===

When the sequence record is processed, it uses a selection algorithm similar to that of the selection record to decide which links to process.The select mechanism field (SELM) has four algorithms to choose from: <CODE>All</CODE>, <CODE>Specified</CODE> or <CODE>Mask</CODE>.

The <CODE>All</CODE> algorithm causes the record to process each input and output link each time the record is processed, in order from 1 to 10. So when SELM is <CODE>All</CODE>, the desired output value from DOL1 will fetched and sent to LNK1, then the desired output value from DOL2 will be fetched and sent to the location in LNK2, and so on until the last input and output link DOA and LNKA. (Note that undefined links are not used.) If DOL''x'' is a constant, the current value field is simply used and the desired output link is ignored. The SELN field is not used when <CODE>All</CODE> is the algorithm.

When the <CODE>Specified</CODE> algorithm is chosen, each time the record is processed it gets the integer value in the Link Selection (SELN) field and uses that as the index of the link to process. For instance, if SELN is 4, the desired output value from DO4 will be retrieved and sent to LNK4. If DOL''x'' is a constant, DO''x'' is simply used without the value being fetched from the input link.

When <CODE>Mask</CODE> is chosen, the record uses the individual bits of the SELN field to determine the links to process. When bit 0 of SELN is set, the value from DO1 will be written to the location in LNK1; when bit 1 is set, the valud from DO2 will be written to the location in LNK2 etc. Thus for example if SELN is 3, the record will retrieve the values from DO1 and DO2 and write them to the locations in LNK1 and LNK2, respectively. If SELN is 63, DO1...DO6 will be written to LNK1...LNK6.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>SELM<TD>Select Mechanism<TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>SELN <TD>Link Selection <TD>USHORT<TD>No<TD>1<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>SELL<TD>Link Selection Location <TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No
</TABLE>

=== Delay Parameters ===

The delay parameters consist of 10 fields, one for each I/O link discussed above. These fields can be configured to cause the record to delay processing the link. For instance, if the user gives the DLY1 field a value of 3.0, each time the record is processed at run-time, the record will delay processing the DOL1, DOV1, and LNK1 fields for three seconds. That is, the desired output value will not be fetched and written to the output link until three seconds have lapsed.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>DLY1<TD>Delay time<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DLY2<TD>Delay time<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DLY3<TD>Delay time<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DLY4<TD>Delay time<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DLY5<TD>Delay time<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DLY6<TD>Delay time<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DLY7<TD>Delay time<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DLY8<TD>Delay time<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DLY9<TD>Delay time<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DLYA<TD>Delay time<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Operator Display Parameters ===

These parameters are used to present meaningful data to the operator. The Precision field (PREC) determines the decimal precision for the VAL field when it is displayed. It is used when the <CODE>get_precision</CODE> record routine is called.

See [[RRM 3-14 dbCommon#Fields Common to All Record Types|Fields Common to All Record Types]] for more on the record name (NAME) and description (DESC) fields.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>PREC <TD>Display Precision <TD>SHORT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>NAME<TD>Record Name<TD>STRING [29]<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>DESC<TD>Description<TD>STRING [29]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Alarm Parameters ===

The sequence record has the alarm parameters common to all record types. [[RRM 3-14 dbCommon#Alarm Fields|Alarm Fields]] lists other fields related to a alarms that are common to all record types.

== Record Support ==

=== Record Processing ===

Routine process implements the following algorithm:

# First, PACT is set to TRUE, and the link selection is fetched. Depending on the selection mechanism, the link selection output links are processed in order from LNK1 to LNKA. When LNK''n'' is processed, the corresponding DLY''n'' value is used to generate a delay via watchdog timer.
# After DLY''n'' seconds have expired, the input value is fetched from DO''n'' (if DOL''n'' is constant) or DOL''n'' (if DOL''n'' is a database link or channel access link) and written to LNK''n''.
# When all links are completed, an asynchronous completion call back to dbProcess is made (see the Application Developer's Guide for more information on asynchronous processing.)
# Then UDF is set to FALSE.
# Monitors are checked.
# The forward link is scanned, PACT is set FALSE, and the process routine returns.

For the delay mechanism to operate properly, the record is processed asynchronously. The only time the record will not be processed asynchronously is when there are no non-NULL output links selected (i.e. when it has nothing to do.) The processing of the links is done via callback tasks at the priority set in the PRIO field in dbCommon (see the Application Developer's Guide for more information on call

----

EPICS Record Reference Manual - 19 MAY 1998

RRM 3-14 Sequence

2009-01-06T23:08:53Z

LewisMuir: /* Desired Output Parameters */ Fixed typo

[[RRM 3-14|EPICS Record Reference Manual]]

= seq - Sequence =

The Sequence record is used to trigger the processing of up to ten other records and send values to those records. It is similar to the fanout record, except that it will fetch an input value and write an output value instead of simply processing a collection of forward links. It can also specify one of several selection algorithms that determine which values to write. It has no associated device support.

== Parameter Fields ==

The fields fall into the following categories:

* scan parameters
* desired output parameters
* output parameters
* selection algorithm parameters
* delay parameters
* operator display parameters
* run-time parameters

=== Scan Parameters ===

The sequence record has the standard fields for specifying under what circumstances it will be processed. These fields are listed in [[RRM 3-14 dbCommon#Scan Fields|Scan Fields]]. In addition, [[RRM 3-14 Concepts#Scanning Specification|Scanning Specification]] explains how these fields are used.

=== Desired Output Parameters ===

These fields determine where the record retrieves the values it is to write to other records. All of these values are not necessarily used, depending on the selection algorithm.

The sequence record can retrieve up to 10 values from 10 locations. The user specifies the locations in the Desired Output Link fields (DOL1-DOLA), which can be either constants, database links, or channel access links. If a Desired Output Link is a constant, the corresponding value field for that link is initialized to the constant value and ''cannot'' be changed via dbputs. Otherwise, if the Desired Output Link is a database or channel access link, a value is fetched from the link each time the record is processed (provided that the output link is part of the record's selection algorithm). See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on how to specify database links.

The value fetched from the Desired Output Links are stored in the corresponding Desired Output Value fields (DO1-DOA). These fields can be initialized to a constant value, but they cannot be changed via dbPuts.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>DOL1<TD>Desired Output Link 1<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>DOL2<TD>Desired Output Link 2<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>DOL3<TD>Desired Output Link 3<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>DOL4<TD>Desired Output Link 4<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>DOL5<TD>Desired Output Link 5<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>DOL6<TD>Desired Output Link 6<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>DOL7<TD>Desired Output Link 7<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>DOL8<TD>Desired Output Link 8<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>DOL9<TD>Desired Output Link 9<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>DOLA<TD>Desired Output Link 10<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>DO1<TD>Desired Output Value, Link 1<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DO2<TD>Desired Output Value, Link 2<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DO3<TD>Desired Output Value, Link 3<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DO4<TD>Desired Output Value, Link 4<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DO5<TD>Desired Output Value, Link 5<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DO6<TD>Desired Output Value, Link 6<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DO7<TD>Desired Output Value, Link 7<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DO8<TD>Desired Output Value, Link 8<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DO9<TD>Desired Output Value, Link 9<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DOA<TD>Desired Output Value, Link 10 <TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Output Parameters ===

When the record is processed, the desired output values are retrieved for the links in the record's selection algorithm and are written to the corresponding output link (LNK1-LNKA). These output links can be database links or channel access links; they cannot be device addresses. There are ten output links, one for each desired output link. Only those that are defined are used.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>LNK1<TD>Output link 1<TD>OUTLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>LNK2<TD>Output link 2<TD>OUTLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>LNK3<TD>Output link 3<TD>OUTLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>LNK4<TD>Output link 4<TD>OUTLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>LNK5<TD>Output link 5<TD>OUTLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>LNK6<TD>Output link 6<TD>OUTLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>LNK7<TD>Output link 7<TD>OUTLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>LNK8<TD>Output link 8<TD>OUTLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>LNK9<TD>Output link 9<TD>OUTLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>LNKA<TD>Output link 1<TD>OUTLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No
</TABLE>

=== Selection Algorithm Parameters ===

When the sequence record is processed, it uses a selection algorithm similar to that of the selection record to decide which links to process.The select mechanism field (SELM) has four algorithms to choose from: <CODE>All</CODE>, <CODE>Specified</CODE> or <CODE>Mask</CODE>.

The <CODE>All</CODE> algorithm causes the record to process each input and output link each time the record is processed, in order from 1 to 10. So when SELM is <CODE>All</CODE>, the desired output value from DOL1 will fetched and sent to LNK1, then the desired output value from DOL2 will be fetched and sent to the location in LNK2, and so on until the last input and output link DOA and LNKA. (Note that undefined links are not used.) If DOL''x'' is a constant, the current value field is simply used and the desired output link is ignored. The SELN field is not used when <CODE>All</CODE> is the algorithm.

When the <CODE>Specified</CODE> algorithm is chosen, each time the record is processed it gets the integer value in the Link Selection (SELN) field and uses that as the index of the link to process. For instance, if SELN is 4, the desired output value from DO4 will be retrieved and sent to LNK4. If DOL''x'' is a constant, DO''x'' is simply used without the value being fetched from the input link.

When <CODE>Mask</CODE> is chosen, the record uses the individual bits of the SELN field to determine the links to process. When bit 0 of SELN is set, the value from DO1 will be written to the location in LNK1; when bit 1 is set, the valud from DO2 will be written to the location in LNK2 etc. Thus for example if SELN is 3, the record will retrieve the values from DO1 and DO2 and write them to the locations in LNK1 and LNK2, respectively. If SELN is 63, DO1...DO6 will be written to LNK1...LNK6.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>SELM<TD>Select Mechanism<TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>SELN <TD>Link Selection <TD>USHORT<TD>No<TD>1<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>SELL<TD>Link Selection Location <TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No
</TABLE>

=== Delay Parameters ===

The delay parameters consist of 10 fields, one for each I/O link discussed above. These fields can be configured to cause the record to delay processing the link. For instance, if the user gives the DLY1 field a value of 3.0, each time the record is processed at run-time, the record will delay processing the DOL1, DOV1, and LNK1 fields for three seconds. That is, the desired output value will not be fetched and written to the output link until three seconds have lapsed.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>DLY1<TD>Delay time<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DLY2<TD>Delay time<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DLY3<TD>Delay time<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DLY4<TD>Delay time<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DLY5<TD>Delay time<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DLY6<TD>Delay time<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DLY7<TD>Delay time<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DLY8<TD>Delay time<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DLY9<TD>Delay time<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DLYA<TD>Delay time<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Operator Display Parameters ===

These parameters are used to present meaningful data to the operator. The Precision field (PREC) determines the decimal precision for the VAL field when it is displayed. It is used when the <CODE>get_precision</CODE> record routine is called.

See [[RRM 3-14 dbCommon#Fields Common to All Record Types|Fields Common to All Record Types]] for more on the record name (NAME) and description (DESC) fields.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>PREC <TD>Display Precision <TD>SHORT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>NAME<TD>Record Name<TD>STRING [29]<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>DESC<TD>Description<TD>STRING [29]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Alarm Parameters ===

The sequence record has the alarm parameters common to all record types. [[RRM 3-14 dbCommon#Alarm Fields|Alarm Fields]] lists other fields related to a alarms that are common to all record types.

== Record Support ==

=== Record Processing ===

Routine process implements the following algorithm:

# First, PACT is set to TRUE, and the link selection is fetched. Depending on the selection mechanism, the link selection output links are processed in order from LNK1 to LNKA. When LNK''n'' is processed, the corresponding DLY''n'' value is used to generate a delay via watchdog timer.
# After DLY''n'' seconds have expired, the input value is fetched from DO''n'' (if DOL''n'' is constant) or DOL''n'' (if DOL''n'' is a database link or channel access link) and written to LNK''n''.
# When all links are completed, an asynchronous completion call back to dbProcess is made (see the Application Developer's Guide for more information on asynchronous processing.)
# Then UDF is set to FALSE.
# Monitors are checked.
# The forward link is scanned, PACT is set FALSE, and the process routine returns.

For the delay mechanism to operate properly, the record is processed asynchronously. The only time the record will not be processed asynchronously is when there are no non-NULL output links selected (i.e. when it has nothing to do.) The processing of the links is done via callback tasks at the priority set in the PRIO field in dbCommon (see the Application Developer's Guide for more information on call

----

EPICS Record Reference Manual - 19 MAY 1998

RRM 3-14 Subroutine

2008-09-24T16:22:46Z

LewisMuir: /* Read Parameters */ Corrected typos in summary of INPx fields

[[RRM 3-14|EPICS Record Reference Manual]]

= sub - Subroutine =

The subroutine record is used to call a C initialization routine and a recurring scan routine. There is no device support for this record.

== Parameter Fields ==

The fields fall into several categories:

* scan parameters
* read parameters
* subroutine connection parameters
* operator display parameters
* alarm parameters
* monitor parameters
* run-time parameters.

=== Scan Parameters ===

The subroutine record has the standard fields for specifying under what circumstances it will be processed. These fields are listed in [[RRM 3-14 dbCommon#Scan Fields|Scan Fields]]. In addition, [[RRM 3-14 Concepts#Scanning Specification|Scanning Specification]] explains how these fields are used.

=== Read Parameters ===

The subroutine record has twelve input links (INPA-INPL), each of which has a corresponding value field (A-L). These fields are used to retrieve and store values that can be passed to the subroutine that the record calls.

The input links can be either channel access or database links, or constants. When constants, the corresponding value field for the link is initialized with the constant value and the field's value can be changed at run-time via dbPuts. Otherwise, the values for (A-F) are fetched from the input links when the record is processed. See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on specifying links.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>INPA<TD>Input A<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>INPB<TD>Input B<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>INPC<TD>Input C<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>INPD<TD>Input D<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>INPE<TD>Input E<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>INPF<TD>Input F<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>INPG<TD>Input G<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>INPH<TD>Input H<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>INPI<TD>Input I<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>INPJ<TD>Input J<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>INPK<TD>Input K<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>INPL<TD>Input L<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>A<TD>A Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>B<TD>B Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>C<TD>C Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>D<TD>D Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>E<TD>E Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>F<TD>F Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>G<TD>G Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>H<TD>H Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>I<TD>I Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>J<TD>J Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>K<TD>K Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>L<TD>L Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes
</TABLE>

=== Subroutine Connection ===

These fields are used to connect to the C subroutine. The name of the subroutine should be entered in the SNAM field.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>INAM<TD>Initialization Name <TD>STRING [16]<TD>Yes<TD>Null<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>SNAM<TD>Subroutine Name<TD>STRING [16]<TD>Yes<TD>Null<TD>Yes<TD>No<TD>No<TD>No
</TABLE>

=== Operator Display Parameters ===

These parameters are used to present meaningful data to the operator. They display the value and other parameters of the subroutine either textually or graphically.

EGU is a string of up to 16 characters that could describe any units used by the subroutine record. It is retrieved by the <CODE>get_units</CODE> record support routine.

The HOPR and LOPR fields set the upper and lower display limits for the VAL, A-L, LA-LL, HIHI, LOLO, LOW, and HIGH fields. Both the <CODE>get_graphic_double</CODE> and <CODE>get_control_double</CODE> record support routines retrieve these fields.

The PREC field determines the floating point precision with which to display VAL. It is used whenever the <CODE>get_precision</CODE> record support routine is called.

See [[RRM 3-14 dbCommon#Fields Common to All Record Types|Fields Common to All Record Types]] for more on the record name (NAME) and description (DESC) fields.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>EGU<TD>Engineering Units<TD>STRING [16]<TD>Yes<TD>null<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>HOPR<TD>High Operating Range<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>LOPR<TD>Low Operating Range<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>PREC<TD>Display Precision<TD>SHORT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>NAME<TD>Record Name<TD>STRING [29]<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>DESC<TD>Description<TD>STRING [29]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Alarm Parameters ===

The possible alarm conditions for subroutine records are the SCAN, READ, limit alarms, and an alarm that can be triggered if the subroutine returns a negative value. The SCAN and READ alarms are called by the record or device support routines. The limit alarms are configured by the user in the HIHI, LOLO, HIGH, and LOW fields using numerical values. They apply to the VAL field. For each of these fields, there is a corresponding severity field which can be either NO_ALARM, MINOR, or MAJOR.

The BRSV field is where the user can set the alarm severity in case the subroutine returns a negative value. See [[RRM 3-14 Concepts#Alarm Specification|Alarm Specification]] for a complete explanation of alarms and these fields. [[RRM 3-14 dbCommon#Alarm Fields|Alarm Fields]] lists other fields related to a alarms that are common to all record types.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>HIHI<TD>Hihi Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HIGH<TD>High Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LOW<TD>Low Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LOLO<TD>Lolo Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HHSV<TD>Hihi Alarm Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HSV<TD>High Alarm Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LSV<TD>Low Alarm Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LLSV<TD>Lolo Alarm Severity<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>BRSV<TD>Severity for a subroutine return value less than 0.<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HYST<TD>Alarm Deadband<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Monitor Parameters ===

These parameters are used to determine when to send monitors placed on the VAL field. The appropriate monitors are invoked when VAL differs from the values in the ALST and MLST run-time fields, i.e., when the value of VAL changes by more than the deadband specified in these fields. The ADEL and MDEL fields specify a minimum delta which the change must surpass before the value-change monitors are invoked. If these fields have a value of zero, everytime the value changes, a monitor will be triggered; if they have a value of -1, everytime the record is processed, monitors are triggered. The ADEL field is used by archive monitors and the MDEL field for all other types of monitors. See [[RRM 3-14 Concepts#Monitor Specification|Monitor Specification]] for a complete explanation of monitors and deadbands.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>ADEL<TD>Archive Deadband<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>MDEL<TD>Monitor, i.e. value change, Deadband<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Run-time Parameters ===

These parameters are used by the run-time code for processing the subroutine record. They are not configured using a database configuration tool. They represent the current state of the record. Many of them are used by the record processing routines or the monitors.

VAL should be set by the subroutine. SADR holds the subroutine address and is set by the record processing routine. STYP, the subroutine symbol type, is also set by the record processing routine.

The rest of these fields--LALM, ALST, MLST, and the LA-LL fields--are used to implement the monitors. For example, when LA is not equal to A, the value-change monitors are called for that field.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>VAL<TD>Value Field<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>SADR<TD>Subroutine Address <TD>NOACCESS<TD>No<TD>0<TD>No<TD>No<TD>No<TD> <TR>
<TD>STYP<TD>Subroutine Symbol Type<TD>SHORT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LALM<TD>Last Alarm Monitor Trigger Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>ALST<TD>Last Archiver Monitor Trigger Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>MLST<TD>Last Value Change Monitor Trigger Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LA<TD>Last A Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LB<TD>Last B Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LC<TD>Last C Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LD<TD>Last D Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LE<TD>Last E Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LF<TD>Last F Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LG<TD>Last G Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LH<TD>Last H Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LI<TD>Last I Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LJ<TD>Last J Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LK<TD>Last K Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LL<TD>Last L Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No
</TABLE>

== Record Support ==

=== Record Support Routines ===

==== init_record ====

For each constant input link, the corresponding value field is initialized with the constant value. For each input link that is of type PV_LINK, a channel access link is created.

If an initialization subroutine is defined, it is located and called.

The processing subroutine is located and its address and type stored in SADR and STYP.

==== process ====

See next section.

==== get_value ====

Fills in the values of struct valueDes so that they refer to VAL.

==== get_units ====

Retrieves EGU.

==== get_precision ====

Retrieves PREC when VAL is the field being referenced. Otherwise, calls <CODE>recGblGetPrec()</CODE>.

==== get_graphic_double ====

Sets the upper display and lower display limits for a field. If the field is VAL, A-L, LA-LL, HIHI, HIGH, LOW, or LOLO, the limits are set to HOPR and LOPR, else if the field has upper and lower limits defined they will be used, else the upper and lower maximum values for the field type will be used.

==== get_control_double ====

Sets the upper control and the lower control limits for a field. If the field is VAL, A-L, LA-LL, HIHI, HIGH, LOW, or LOLO, the limits are set to HOPR and LOPR, else if the field has upper and lower limits defined they will be used, else the upper and lower maximum values for the field type will be used.

==== get_alarm_double ====

Sets the following values:

upper_alarm_limit = HIHI
upper_warning_limit = HIGH
lower_warning_limit = LOW
lower_alarm_limit = LOLO

=== Record Processing ===

Routine process implements the following algorithm:

# If PACT is FALSE then fetch all arguments.
# Call the subroutine and check return value.
#* Call subroutine
#* Set PACT TRUE
#* If return value is 1, return
# Check alarms. This routine checks to see if the new VAL causes the alarm status and severity to change. If so, NSEV, NSTA and LALM are set. It also honors the alarm hysteresis factor (HYST). Thus the value must change by more than HYST before the alarm status and severity is lowered.
# Check to see if monitors should be invoked.
#* Alarm monitors are invoked if the alarm status or severity has changed.
#* Archive and value change monitors are invoked if ADEL and MDEL conditions are met.
#* Monitors for A-L are invoked if value has changed.
#* NSEV and NSTA are reset to 0.
# Scan forward link if necessary, set PACT FALSE, and return.

=== Example Synchronous Subroutine ===

This is an example subroutine that merely increments VAL each time process is called.

#include <vxWorks.h>
#include <types.h>
#include <stdioLib.h>
#include <dbDefs.h>
#include <subRecord.h>
#include <dbCommon.h>
#include <recSup.h>

long subInit(struct subRecord *psub)
{
printf("subInit was called\n");
return(0);
}

long subProcess(struct subRecord *psub)
{
psub->val++;
return(0);
}

=== Example Asynchronous Subroutine ===

This example shows an asynchronous subroutine. It uses (actually misuses) fields A and B. Field A is taken as the number of seconds until asynchronous completion. Field B is a flag to decide if messages should be printed. Lets assume A > 0 and B = 1. The following sequence of actions will occcur:

# subProcess is called with pact FALSE. It performs the following steps.
#* Computes, from A, the number of ticks until asynchronous completion should occur.
#* Prints a message stating that it is requesting an asynchronous callback.
#* Calls the vxWorks watchdog start routine.
#* Sets pact TRUE and returns a value of 0. This tells record support to complete without checking alarms, monitors, or the forward link.
# When the time expires, the system wide callback task calls myCallback. myCallback locks the record, calls process, and unlocks the record.
# Process again calls subProcess, but now pact is TRUE. Thus the following is done:
#* VAL is incremented.
#* A completion message is printed.
#* subProcess returns 0. The record processing routine will complete record processing.

#include <vxWorks.h>
#include <types.h>
#include <stdioLib.h>
#include <wdLib.h>
#include <callback.h>
#include <dbDefs.h>
#include <dbAccess.h>
#include <subRecord.h>

/* control block for callback*/
struct callback {
CALLBACK callback;
struct dbCommon *precord;
WDOG_ID wd_id;
};

void myCallback(struct callback *pcallback)
{
struct dbCommon *precord=pcallback->precord;
struct rset *prset=(struct rset *)(precord->rset);
dbScanLock(precord);
(*prset->process)(precord);
dbScanUnlock(precord);
}

long subInit(struct subRecord *psub)
{
struct callback *pcallback;
pcallback = (struct callback *)(calloc(1,sizeof(struct callback)));
psub->dpvt = (void *)pcallback;
callbackSetCallback(myCallback,pcallback);
pcallback->precord = (struct dbCommon *)psub;
pcallback->wd_id = wdCreate();
printf("subInit was called\n");
return 0;
}

long subProcess(struct subRecord *psub)
{
struct callback *pcallback=(struct callback *)(psub->dpvt);
/* sub.inp must be a CONSTANT*/
if (psub->pact) {
psub->val++;
if (psub->b)
printf("%s subProcess Completed\n", psub->name);
return 0;
} else {
int wait_time = (long)(psub->a * vxTicksPerSecond);
if (wait_time <= 0){
if (psub->b)
printf("%s subProcess sync processing\n", psub->name);
psub->pact = TRUE;
return 0;
}
if (psub->b){
callbackSetPriority(psub->prio, pcallback);
printf("%s Starting async processing\n", psub->name);
wdStart(pcallback->wd_id, wait_time, callbackRequest, (int)pcallback);
return 1;
}
}
return 0;
}

----

EPICS Record Reference Manual - 19 MAY 1998

EPICS FAQ

2008-08-28T21:32:35Z

LewisMuir: /* Hardware */ Added "Which target architecture should I use?" section

== General ==
=== What is EPICS? ===
EPICS is a set of software tools and applications which provide a software infrastructure for use in building distributed control systems to operate devices such as Particle Accelerators, Large Experiments and major Telescopes. Such distributed control systems typically comprise tens or even hundreds of computers, networked together to allow communication between them and to provide control and feedback of the various parts of the device from a central control room, or even remotely over the internet.

The term (EPICS) also refers to the collaboration of organizations that are involved in the software's development and use. It was originally written jointly by Los Alamos National Laboratory and Argonne National Laboratory, and is now used by many large scientific facilities throughout the world. Development now occurs cooperatively between these various groups, with much sharing of I/O device support and client applications.

=== Who Uses EPICS? ===

=== How Can I Learn More About EPICS? ===
Many of the sites listed above have tutorials, slides, or overviews of EPICS. It is helpful to peruse several different sites to get a broad exposure of how the facilities use EPICS.

The [http://www.aps.anl.gov/epics/docs/GSWE.php Getting Started With EPICS Lecture Series] presented and recorded at the Advance Photon Source in the Fall of 2004 is probably the most recent and exhaustive series of training presentations. The lectures are available via synchronized streaming video and the Power Point slides are also available for downloading via the above link.

=== Is There a Demo I Can Play With? ===
The most recent published demo application is the Virtual Linac, which is available [http://www.aps.anl.gov/epics/download/examples/index.php here]. Also look at the [http://www.lnl.infn.it/~epics/ LivEPICS CD images] for a bootable system that you can use without having to install anything on a PC.

== Hardware ==
=== What Hardware Platforms Can Be Used With EPICS? ===
The ''Platforms Supported'' sections of [http://www.aps.anl.gov/epics/base/R3-13.php EPICS Base R3.13] and [http://www.aps.anl.gov/epics/base/R3-14/index.php EPICS Base R3.14] provide a list of currently supported host and IOC target platforms for the corresponding EPICS Base release.

=== Can I Port EPICS to My ACME SuperFast CPU? ===
=== What I/O Devices Are Supported? ===
Lots. Most available I/O support is listed in the [http://www.aps.anl.gov/epics/modules/manufacturer.php Supported Hardware Database] but for various reasons that list is never complete, so it's always worth sending a message to [mailto:tech-talk@aps.anl.gov tech-talk] if there's something that you think other sites may be using but don't see listed.

=== Which target architecture should I use? ===
==== VxWorks ====
<table border="1">
<tr>
<th>Hardware</th>
<th>Target Architecture</th>
</tr>
<tr>
<td>Motorola MVME‑162‑532A</td>
<td><tt>vxWorks-68040</tt></td>
</tr>
<tr>
<td>Motorola MVME-2100</td>
<td><tt>vxWorks-ppc603</tt> if has 32 MB of RAM or less; <tt>vxWorks-ppc603_long</tt> if has more than 32 MB of RAM</td>
</tr>
<tr>
<td>Motorola MVME-2700</td>
<td><tt>vxWorks-ppc604</tt> if has 32 MB of RAM or less; <tt>vxWorks-ppc604_long</tt> if has more than 32 MB of RAM</td>
</tr>
<tr>
<td>Motorola MVME-5100</td>
<td><tt>vxWorks-ppc604</tt> if has 32 MB of RAM or less; <tt>vxWorks-ppc604_long</tt> if has more than 32 MB of RAM</td>
</tr>
</table>

== IOC Core Software ==
=== Where Can I Learn About IOC Core? ===

=== What are the relationships between Records, Fields, PVs and Channels? ===
The IOC database manages Records. A Record has Fields, for example an analog input record "fred" has fields such as
* VAL (value)
* EGU (Engineering Units)
* TIME (Timestamp)
* HOPR (High Operator Range)
* LOPR (Low Operator Range)
* STAT (Alarm Status)
* SEVR (Alarm Severity)
* ...
You can use a database (.db) file or the dbgf and dbpf commands to get and set with the fields of a record.

The Channel Access network protocol gives you access to Channels. A Channel has Properties. The Channel "fred" has properties such as
* value
* time stamp
* units
* upper control limit
* lower control limit
* status
* severity, ...
You use the DBR_... request types to read/write the properties of a channel. Although these are called "database request types" DBR_..., they really should be called "channel" or "property" request types.

How do Records map to Channels, and how do Fields of a Record map to the Properties of a Channel? To really understand this, you have to use the force and read the source. The result makes sense in the few but most common cases; it doesn't always make sense in many of the other possible cases.

Our first example makes perfect sense: You have a channel "fred" for an AI record "fred", and ask Channel Access for its value as a DBR_CTRL_DOUBLE. Your channel will provide its properties in a dbr_ctrl_double structure, mapped to the following fields of the record:
: value = VAL
: status = STAT
: severity = SEVR
: precision = PREC
: units = EGU
: upper_ctrl_limit = HOPR
: lower_ctrl_limit = LOPR
: ...
You can also ask for a DBR_TIME_DOUBLE and get the
: value = VAL
: stamp = TIME
: ...
The time stamp is of course the time of the last value update, so it's the time stamp that belongs to the value. This case makes perfect sense.

The next good example is a channel "fred.SCAN", which is of type ENUM and you can get the DBR_CTRL_ENUM properties:
: value = SCAN
: strs = { "Passive", "Event", ..., ".1 second" }
Good, that's the current value as well as corresponding enumeration strings.
But there's also
: status = STAT
: severity = SEVR
Those are status & severity of the "fred" record as a whole. A "NO_ALARM"/"NO_ALARM" or "READ"/"INVALID" pair in there doesn't say anything
about the SCAN field, only about the "fred" record as a whole.

Now attach a channel to "fred.HOPR" and read the DBR_TIME_DOUBLE:
: value = HOPR
: stamp = TIME
You get a time stamp that has nothing to do with the value. It's not the time when HOPR was last updated.

Attach a channel to "fred.PREC" and read a DBR_CTRL_DOUBLE:
: value = PREC
: units = EGU
: status = STAT
: severity = SEVR
: lower_ctrl_limit=-32768
: upper_ctrl_limit=32767
The value and units are OK, but the status & severity are again really properties of the "fred" record as a whole, not of the PREC field which we were asking about. The two control limits also give the range of the 16 bit number that the PREC field holds, even though most values in that range won't make any sense for this field.

So if your channel name is simply a record name, the mapping of record fields to channel properties makes sense. In other cases, you have to look at the source code of the record to figure out what you'll get, and in many cases it's not what you might like.

You also have to understand that Channel Access cannot introspect a record (i.e. iterate over all its fields). There is no DBR_ALL_FIELDS type, only a fixed set of DBR_... requests which are hardcoded to get particular record fields or properties of a field by the record type's code.

== Extensions/Tools ==
=== What Are EPICS Extensions? ===

== The Collaboration ==
=== How Do I Join the Collaboration? ===
There is no formal membership criteria or process. If you begin attending the semi-annual collaboration meetings, submit questions or respond with answers on the tech-talk list-server, or share your EPICS device support or applications with others, you will be warmly welcomed as a contributing member of the collaboration.

=== What Are Some of the Collaboration Activities? ===
Questions, comments, solutions, and other dialogue are routinely exchanged on the EPICS mailing list [http://www.aps.anl.gov/epics/tech-talk/index.php tech-talk]. If a question is worded thoughtfully and with sufficient detail, it is not uncommon to receive an answer (or sometimes several answers) in a few hours. The more precise the question, the more likely you will receive an expedient response.

There are semi-annual EPICS Collaboration Meetings where people give short talks on recent accomplishments, advances, changes, etc. This is a fertile ground for the exchange of ideas with respect to control systems. Agendas and presentations from most past meetings can be found on the [http://www.aps.anl.gov/epics/meetings.php website meetings page].

It is also not uncommon for individuals to visit other labs for short term assistance, training, or advice. This is a very beneficial aspect of the collaboration.

EPICS FAQ

2008-08-28T19:56:24Z

LewisMuir: /* What Hardware Platforms Can Be Used With EPICS? */ Improved last sentence

== General ==
=== What is EPICS? ===
EPICS is a set of software tools and applications which provide a software infrastructure for use in building distributed control systems to operate devices such as Particle Accelerators, Large Experiments and major Telescopes. Such distributed control systems typically comprise tens or even hundreds of computers, networked together to allow communication between them and to provide control and feedback of the various parts of the device from a central control room, or even remotely over the internet.

The term (EPICS) also refers to the collaboration of organizations that are involved in the software's development and use. It was originally written jointly by Los Alamos National Laboratory and Argonne National Laboratory, and is now used by many large scientific facilities throughout the world. Development now occurs cooperatively between these various groups, with much sharing of I/O device support and client applications.

=== Who Uses EPICS? ===

=== How Can I Learn More About EPICS? ===
Many of the sites listed above have tutorials, slides, or overviews of EPICS. It is helpful to peruse several different sites to get a broad exposure of how the facilities use EPICS.

The [http://www.aps.anl.gov/epics/docs/GSWE.php Getting Started With EPICS Lecture Series] presented and recorded at the Advance Photon Source in the Fall of 2004 is probably the most recent and exhaustive series of training presentations. The lectures are available via synchronized streaming video and the Power Point slides are also available for downloading via the above link.

=== Is There a Demo I Can Play With? ===
The most recent published demo application is the Virtual Linac, which is available [http://www.aps.anl.gov/epics/download/examples/index.php here]. Also look at the [http://www.lnl.infn.it/~epics/ LivEPICS CD images] for a bootable system that you can use without having to install anything on a PC.

== Hardware ==
=== What Hardware Platforms Can Be Used With EPICS? ===
The ''Platforms Supported'' sections of [http://www.aps.anl.gov/epics/base/R3-13.php EPICS Base R3.13] and [http://www.aps.anl.gov/epics/base/R3-14/index.php EPICS Base R3.14] provide a list of currently supported host and IOC target platforms for the corresponding EPICS Base release.

=== Can I Port EPICS to My ACME SuperFast CPU? ===
=== What I/O Devices Are Supported? ===
Lots. Most available I/O support is listed in the [http://www.aps.anl.gov/epics/modules/manufacturer.php Supported Hardware Database] but for various reasons that list is never complete, so it's always worth sending a message to [mailto:tech-talk@aps.anl.gov tech-talk] if there's something that you think other sites may be using but don't see listed.

== IOC Core Software ==
=== Where Can I Learn About IOC Core? ===

=== What are the relationships between Records, Fields, PVs and Channels? ===
The IOC database manages Records. A Record has Fields, for example an analog input record "fred" has fields such as
* VAL (value)
* EGU (Engineering Units)
* TIME (Timestamp)
* HOPR (High Operator Range)
* LOPR (Low Operator Range)
* STAT (Alarm Status)
* SEVR (Alarm Severity)
* ...
You can use a database (.db) file or the dbgf and dbpf commands to get and set with the fields of a record.

The Channel Access network protocol gives you access to Channels. A Channel has Properties. The Channel "fred" has properties such as
* value
* time stamp
* units
* upper control limit
* lower control limit
* status
* severity, ...
You use the DBR_... request types to read/write the properties of a channel. Although these are called "database request types" DBR_..., they really should be called "channel" or "property" request types.

How do Records map to Channels, and how do Fields of a Record map to the Properties of a Channel? To really understand this, you have to use the force and read the source. The result makes sense in the few but most common cases; it doesn't always make sense in many of the other possible cases.

Our first example makes perfect sense: You have a channel "fred" for an AI record "fred", and ask Channel Access for its value as a DBR_CTRL_DOUBLE. Your channel will provide its properties in a dbr_ctrl_double structure, mapped to the following fields of the record:
: value = VAL
: status = STAT
: severity = SEVR
: precision = PREC
: units = EGU
: upper_ctrl_limit = HOPR
: lower_ctrl_limit = LOPR
: ...
You can also ask for a DBR_TIME_DOUBLE and get the
: value = VAL
: stamp = TIME
: ...
The time stamp is of course the time of the last value update, so it's the time stamp that belongs to the value. This case makes perfect sense.

The next good example is a channel "fred.SCAN", which is of type ENUM and you can get the DBR_CTRL_ENUM properties:
: value = SCAN
: strs = { "Passive", "Event", ..., ".1 second" }
Good, that's the current value as well as corresponding enumeration strings.
But there's also
: status = STAT
: severity = SEVR
Those are status & severity of the "fred" record as a whole. A "NO_ALARM"/"NO_ALARM" or "READ"/"INVALID" pair in there doesn't say anything
about the SCAN field, only about the "fred" record as a whole.

Now attach a channel to "fred.HOPR" and read the DBR_TIME_DOUBLE:
: value = HOPR
: stamp = TIME
You get a time stamp that has nothing to do with the value. It's not the time when HOPR was last updated.

Attach a channel to "fred.PREC" and read a DBR_CTRL_DOUBLE:
: value = PREC
: units = EGU
: status = STAT
: severity = SEVR
: lower_ctrl_limit=-32768
: upper_ctrl_limit=32767
The value and units are OK, but the status & severity are again really properties of the "fred" record as a whole, not of the PREC field which we were asking about. The two control limits also give the range of the 16 bit number that the PREC field holds, even though most values in that range won't make any sense for this field.

So if your channel name is simply a record name, the mapping of record fields to channel properties makes sense. In other cases, you have to look at the source code of the record to figure out what you'll get, and in many cases it's not what you might like.

You also have to understand that Channel Access cannot introspect a record (i.e. iterate over all its fields). There is no DBR_ALL_FIELDS type, only a fixed set of DBR_... requests which are hardcoded to get particular record fields or properties of a field by the record type's code.

== Extensions/Tools ==
=== What Are EPICS Extensions? ===

== The Collaboration ==
=== How Do I Join the Collaboration? ===
There is no formal membership criteria or process. If you begin attending the semi-annual collaboration meetings, submit questions or respond with answers on the tech-talk list-server, or share your EPICS device support or applications with others, you will be warmly welcomed as a contributing member of the collaboration.

=== What Are Some of the Collaboration Activities? ===
Questions, comments, solutions, and other dialogue are routinely exchanged on the EPICS mailing list [http://www.aps.anl.gov/epics/tech-talk/index.php tech-talk]. If a question is worded thoughtfully and with sufficient detail, it is not uncommon to receive an answer (or sometimes several answers) in a few hours. The more precise the question, the more likely you will receive an expedient response.

There are semi-annual EPICS Collaboration Meetings where people give short talks on recent accomplishments, advances, changes, etc. This is a fertile ground for the exchange of ideas with respect to control systems. Agendas and presentations from most past meetings can be found on the [http://www.aps.anl.gov/epics/meetings.php website meetings page].

It is also not uncommon for individuals to visit other labs for short term assistance, training, or advice. This is a very beneficial aspect of the collaboration.

EPICS FAQ

2008-08-28T19:54:51Z

LewisMuir: /* What Hardware Platforms Can Be Used With EPICS? */ Added pointer to EPICS base R3.13 and R3.14 web pages

== General ==
=== What is EPICS? ===
EPICS is a set of software tools and applications which provide a software infrastructure for use in building distributed control systems to operate devices such as Particle Accelerators, Large Experiments and major Telescopes. Such distributed control systems typically comprise tens or even hundreds of computers, networked together to allow communication between them and to provide control and feedback of the various parts of the device from a central control room, or even remotely over the internet.

The term (EPICS) also refers to the collaboration of organizations that are involved in the software's development and use. It was originally written jointly by Los Alamos National Laboratory and Argonne National Laboratory, and is now used by many large scientific facilities throughout the world. Development now occurs cooperatively between these various groups, with much sharing of I/O device support and client applications.

=== Who Uses EPICS? ===

=== How Can I Learn More About EPICS? ===
Many of the sites listed above have tutorials, slides, or overviews of EPICS. It is helpful to peruse several different sites to get a broad exposure of how the facilities use EPICS.

The [http://www.aps.anl.gov/epics/docs/GSWE.php Getting Started With EPICS Lecture Series] presented and recorded at the Advance Photon Source in the Fall of 2004 is probably the most recent and exhaustive series of training presentations. The lectures are available via synchronized streaming video and the Power Point slides are also available for downloading via the above link.

=== Is There a Demo I Can Play With? ===
The most recent published demo application is the Virtual Linac, which is available [http://www.aps.anl.gov/epics/download/examples/index.php here]. Also look at the [http://www.lnl.infn.it/~epics/ LivEPICS CD images] for a bootable system that you can use without having to install anything on a PC.

== Hardware ==
=== What Hardware Platforms Can Be Used With EPICS? ===
The ''Platforms Supported'' sections of [http://www.aps.anl.gov/epics/base/R3-13.php EPICS Base R3.13] and [http://www.aps.anl.gov/epics/base/R3-14/index.php EPICS Base R3.14] provide a list of currently supported host and IOC target platforms.

=== Can I Port EPICS to My ACME SuperFast CPU? ===
=== What I/O Devices Are Supported? ===
Lots. Most available I/O support is listed in the [http://www.aps.anl.gov/epics/modules/manufacturer.php Supported Hardware Database] but for various reasons that list is never complete, so it's always worth sending a message to [mailto:tech-talk@aps.anl.gov tech-talk] if there's something that you think other sites may be using but don't see listed.

== IOC Core Software ==
=== Where Can I Learn About IOC Core? ===

=== What are the relationships between Records, Fields, PVs and Channels? ===
The IOC database manages Records. A Record has Fields, for example an analog input record "fred" has fields such as
* VAL (value)
* EGU (Engineering Units)
* TIME (Timestamp)
* HOPR (High Operator Range)
* LOPR (Low Operator Range)
* STAT (Alarm Status)
* SEVR (Alarm Severity)
* ...
You can use a database (.db) file or the dbgf and dbpf commands to get and set with the fields of a record.

The Channel Access network protocol gives you access to Channels. A Channel has Properties. The Channel "fred" has properties such as
* value
* time stamp
* units
* upper control limit
* lower control limit
* status
* severity, ...
You use the DBR_... request types to read/write the properties of a channel. Although these are called "database request types" DBR_..., they really should be called "channel" or "property" request types.

How do Records map to Channels, and how do Fields of a Record map to the Properties of a Channel? To really understand this, you have to use the force and read the source. The result makes sense in the few but most common cases; it doesn't always make sense in many of the other possible cases.

Our first example makes perfect sense: You have a channel "fred" for an AI record "fred", and ask Channel Access for its value as a DBR_CTRL_DOUBLE. Your channel will provide its properties in a dbr_ctrl_double structure, mapped to the following fields of the record:
: value = VAL
: status = STAT
: severity = SEVR
: precision = PREC
: units = EGU
: upper_ctrl_limit = HOPR
: lower_ctrl_limit = LOPR
: ...
You can also ask for a DBR_TIME_DOUBLE and get the
: value = VAL
: stamp = TIME
: ...
The time stamp is of course the time of the last value update, so it's the time stamp that belongs to the value. This case makes perfect sense.

The next good example is a channel "fred.SCAN", which is of type ENUM and you can get the DBR_CTRL_ENUM properties:
: value = SCAN
: strs = { "Passive", "Event", ..., ".1 second" }
Good, that's the current value as well as corresponding enumeration strings.
But there's also
: status = STAT
: severity = SEVR
Those are status & severity of the "fred" record as a whole. A "NO_ALARM"/"NO_ALARM" or "READ"/"INVALID" pair in there doesn't say anything
about the SCAN field, only about the "fred" record as a whole.

Now attach a channel to "fred.HOPR" and read the DBR_TIME_DOUBLE:
: value = HOPR
: stamp = TIME
You get a time stamp that has nothing to do with the value. It's not the time when HOPR was last updated.

Attach a channel to "fred.PREC" and read a DBR_CTRL_DOUBLE:
: value = PREC
: units = EGU
: status = STAT
: severity = SEVR
: lower_ctrl_limit=-32768
: upper_ctrl_limit=32767
The value and units are OK, but the status & severity are again really properties of the "fred" record as a whole, not of the PREC field which we were asking about. The two control limits also give the range of the 16 bit number that the PREC field holds, even though most values in that range won't make any sense for this field.

So if your channel name is simply a record name, the mapping of record fields to channel properties makes sense. In other cases, you have to look at the source code of the record to figure out what you'll get, and in many cases it's not what you might like.

You also have to understand that Channel Access cannot introspect a record (i.e. iterate over all its fields). There is no DBR_ALL_FIELDS type, only a fixed set of DBR_... requests which are hardcoded to get particular record fields or properties of a field by the record type's code.

== Extensions/Tools ==
=== What Are EPICS Extensions? ===

== The Collaboration ==
=== How Do I Join the Collaboration? ===
There is no formal membership criteria or process. If you begin attending the semi-annual collaboration meetings, submit questions or respond with answers on the tech-talk list-server, or share your EPICS device support or applications with others, you will be warmly welcomed as a contributing member of the collaboration.

=== What Are Some of the Collaboration Activities? ===
Questions, comments, solutions, and other dialogue are routinely exchanged on the EPICS mailing list [http://www.aps.anl.gov/epics/tech-talk/index.php tech-talk]. If a question is worded thoughtfully and with sufficient detail, it is not uncommon to receive an answer (or sometimes several answers) in a few hours. The more precise the question, the more likely you will receive an expedient response.

There are semi-annual EPICS Collaboration Meetings where people give short talks on recent accomplishments, advances, changes, etc. This is a fertile ground for the exchange of ideas with respect to control systems. Agendas and presentations from most past meetings can be found on the [http://www.aps.anl.gov/epics/meetings.php website meetings page].

It is also not uncommon for individuals to visit other labs for short term assistance, training, or advice. This is a very beneficial aspect of the collaboration.

RRM 3-14 Menu Choices

2008-08-26T14:41:43Z

LewisMuir: /* GBLCHOICE and RECCHOICE Fields */ removed menuArrType; added menuSimm

[[RRM 3-14|EPICS Record Reference Manual]]

= Menu Choices =

== GBLCHOICE and RECCHOICE Fields ==

Some of the fields in EPICS records are of type GBLCHOICE or RECCHOICE, meaning that the value of the field must be one from a menu of specific choices. There are several different menus available and each GBLCHOICE or RECCHOICE field uses one. For instance, the simplest menu is called <CODE>menuYesNo</CODE> and has two possible choices, NO and YES; no other values for a field that uses <CODE>menuYesNo</CODE> are possible--0.5, MAYBE, and NO WAY are not possible choices for the field. In addition, when a menu field is configured to have a certain value, its value string must match exactly one of the possible choices in its menu, including its case. For instance, if a field's type is GBLCHOICE and its menu is <CODE>menuYesNo</CODE>, the choices <CODE>yes</CODE>, <CODE>No</CODE>, and <CODE>Yes</CODE> are not valid choices: they don't match the case of NO or YES.

There are several menus provided as part of the standard EPICS release. Here are their names:

* seqSELM
* selSELM
* menuYesNo
* menuSimm
* menuScan
* menuPriority
* menuOmsl
* menuLinr
* menuIvoa
* menuFtype
* menuConvert
* menuCompress
* menuAlarmStat
* menuAlarmSevr
* fanoutSELM
* compressALG
* aoOIF

A few of these menus are record-specific. For example, <CODE>aoOIF</CODE> is used solely by the OIF field in the analog output record. Any field using one of these menus will be of type RECCHOICE. Most of the above menus, however, are used by many different fields in different records. These are of type GBLCHOICE. For example, the <CODE>menuAlarmSevr</CODE> menu is used by the LLSV field in the analog input record as well as the COSV field in the binary input record, among others.

The above menus and their choices are provided as part of the standard EPICS release; however, developers can add to, delete, or change the choices of each, as well as add new menu types. (See the ''Application Developer's Guide'' for your release for more information on how to add and change existing menus). Thus, the database designer should know that the available menus and their choices may vary from site to site. The designer must be familiar with the menu and menu choices for any fields he/she is configuring. This isn't a problem for most database designers because such tools as VDCT, GDCT, and Capfast allow the designer configuring the database to choose from the specified choices. Nonetheless, there are ways a designer can figure out the available choices for a particular menu and thus for a particular field without using a database configuration tool.

=== Determining the Choices of a GBLCHOICE or RECCHOICE Field ===

==== Peeking at the Database Definition Files ====

The definition for a particular menu can be found by looking at the database definition or <CODE>.dbd</CODE> file for that menu. For instance, the <CODE>menuAlarmSevr.dbd</CODE> file contains the definition for the <CODE>menuAlarmSevr</CODE> menu. In addition, you can see which menu a GBLCHOICE field uses by looking at the <CODE>dbCommonRecord.dbd</CODE> file if the field is common to all record types or by looking at the file that defines that record type if the field is not command to all record types. For example, to see which menu the OIF field uses, one would have to look in the <CODE>aoRecord.dbd</CODE> file which contains the definition for the analog output record, because OIF is particular to the analog output record and is not common to all other record types. RECCHOICE menus are defined in the definition file for the record type in which they are used, usually at the beginning. For example, the field OIF is of type RECCHOICE and uses the <CODE>aoOIF</CODE> menu which is defined at the beginning of <CODE>aoRecord.dbd</CODE>.

=== Standard Menu Definitions ===

Here are the definitions for the menus available as part of the standard EPICS release. The designer should know that the definitions of these menus may be different at his/her site and these are provided merely as a convenience. It's recommended that you use the <CODE>dbst</CODE> utility to view menu choices. Remember that the actual choices appear in quotes.

==== seqSELM ====

choice(seqSELM_All,"All")
choice(seqSELM_Specified,"Specified")
choice(seqSELM_Mask,"Mask")

==== selSELM ====

choice(selSELM_Specified,"Specified")
choice(selSELM_High_Signal,"High Signal")
choice(selSELM_Low_Signal,"Low Signal")
choice(selSELM_Median_Signal,"Median Signal")

==== menuYesNo ====

choice(menuYesNoNO,"NO")
choice(menuYesNoYES,"YES")

==== menuSimm ====

choice(menuSimmNO,"NO")
choice(menuSimmYES,"YES")
choice(menuSimmRAW,"RAW")

==== menuScan ====

choice(menuScanPassive,"Passive")
choice(menuScanEvent,"Event")
choice(menuScanI_O_Intr,"I/O Intr")
choice(menuScan10_second,"10 second")
choice(menuScan5_second,"5 second")
choice(menuScan2_second,"2 second")
choice(menuScan1_second,"1 second")
choice(menuScan_5_second,".5 second")
choice(menuScan_2_second,".2 second")
choice(menuScan_1_second,".1 second")

==== menuPriority ====

choice(menuPriorityLOW,"LOW")
choice(menuPriorityMEDIUM,"MEDIUM")
choice(menuPriorityHIGH,"HIGH")

==== menuOmsl ====

choice(menuOmslsupervisory,"supervisory")
choice(menuOmslclosed_loop,"closed_loop")

==== menuLinr ====

choice(menuLinrNO_CONVERSION,"NO CONVERSION")
choice(menuLinrLINEAR,"LINEAR")

==== menuIvoa ====

choice(menuIvoaContinue_normally,"Continue normally")
choice(menuIvoaDon_t_drive_outputs,"Don't drive outputs")
choice(menuIvoaSet_output_to_IVOV,"Set output to IVOV")

==== menuFtype ====

choice(menuFtypeSTRING,"STRING")
choice(menuFtypeCHAR,"CHAR")
choice(menuFtypeUCHAR,"UCHAR")
choice(menuFtypeSHORT,"SHORT")
choice(menuFtypeUSHORT,"USHORT")
choice(menuFtypeLONG,"LONG")
choice(menuFtypeULONG,"ULONG")
choice(menuFtypeFLOAT,"FLOAT")
choice(menuFtypeDOUBLE,"DOUBLE")
choice(menuFtypeENUM,"ENUM")

==== menuConvert ====

choice(menuConvertNO_CONVERSION,"NO CONVERSION")
choice(menuConvertLINEAR,"LINEAR")
choice(menuConverttypeKdegF,"typeKdegF")
choice(menuConverttypeKdegC,"typeKdegC")
choice(menuConverttypeJdegF,"typeJdegF")
choice(menuConverttypeJdegC,"typeJdegC")
choice(menuConverttypeEdegF,"typeEdegF(ixe only)")
choice(menuConverttypeEdegC,"typeEdegC(ixe only)")
choice(menuConverttypeTdegF,"typeTdegF")
choice(menuConverttypeTdegC,"typeTdegC")
choice(menuConverttypeRdegF,"typeRdegF")
choice(menuConverttypeRdegC,"typeRdegC")
choice(menuConverttypeSdegF,"typeSdegF")
choice(menuConverttypeSdegC,"typeSdegC")

==== menuCompress ====

choice(menuCompressN_to_1_First_Value,"N to 1 First Value")
choice(menuCompressN_to_1_Low_Value,"N to 1 Low Value")
choice(menuCompressN_to_1_High_Value,"N to 1 High Value")
choice(menuCompressN_to_1_Average,"N to 1 Average")

==== menuAlarmStat ====

choice(menuAlarmStat,"NO_ALARM")
choice(menuAlarmStatREAD,"READ")
choice(menuAlarmStatWRITE,"WRITE")
choice(menuAlarmStatHIHI,"HIHI")
choice(menuAlarmStatHIGH,"HIGH")
choice(menuAlarmStatLOLO,"LOLO")
choice(menuAlarmStatLOW,"LOW")
choice(menuAlarmStatSTATE,"STATE")
choice(menuAlarmStatCOS,"COS")
choice(menuAlarmStatCOMM,"COMM")
choice(menuAlarmStatTIMEOUT,"TIMEOUT")
choice(menuAlarmStatHWLIMIT,"HWLIMIT")
choice(menuAlarmStatCALC,"CALC")
choice(menuAlarmStatSCAN,"SCAN")
choice(menuAlarmStatLINK,"LINK")
choice(menuAlarmStatSOFT,"SOFT")
choice(menuAlarmStatBAD_SUB,"BAD_SUB")
choice(menuAlarmStatUDF,"UDF")
choice(menuAlarmStatDISABLE,"DISABLE")
choice(menuAlarmStatSIMM,"SIMM")
choice(menuAlarmStatREAD_ACCESS,"READ_ACCESS")
choice(menuAlarmStatWRITE_ACCESS,"WRITE_ACCESS")

==== menuAlarmSevr ====

choice(menuAlarmSevrNO_ALARM,"NO_ALARM")
choice(menuAlarmSevrMINOR,"MINOR")
choice(menuAlarmSevrMAJOR,"MAJOR")
choice(menuAlarmSevrINVALID,"INVALID")

==== fanoutSELM ====

choice(fanoutSELM_All,"All")
choice(fanoutSELM_Specified,"Specified")
choice(fanoutSELM_Mask,"Mask")

==== compressALG ====

choice(compressALG_N_to_1_Low_Value,"N to 1 Low Value")
choice(compressALG_N_to_1_High_Value,"N to 1 High Value")
choice(compressALG_N_to_1_Average,"N to 1 Average")
choice(compressALG_Average,"Average")
choice(compressALG_Circular_Buffer,"Circular Buffer")

==== aoOIF ====

choice(aoOIF_Full,"Full")
choice(aoOIF_Incremental,"Incremental")

----

EPICS Record Reference Manual - 19 MAY 1998

RRM 3-14 Calcout

2008-05-07T17:27:45Z

LewisMuir: /* Output Parameters */ Fixed IVOV and IVOA mix-up in field table.

[[RRM 3-14|EPICS Record Reference Manual]]

= Calcout - Calculation Output Record =

The Calculation Output or "Calcout" record is similar to the Calc record with the added feature of having outputs (an "output link" and an "output event") which are conditionally executed based on the result of the calculation. This feature allows conditional branching to be implemented within an EPICS database (e.g., process Record_A only if Record_B has a value of 0). The Calcout record is also similar to the Wait record (with additional features) but uses EPICS standard INLINK and OUTLINK fields rather than the DBF_STRING fields used in the Wait record. For new databases, it is recommended that the Calcout record be used instead of the Wait record.

== Parameter Fields ==

The fields in this record fall into these categories:

* scan parameters
* read parameters
* expression parameters
* output parameters
* operator display parameters
* alarm parameters
* monitor parameters
* run-time parameters

=== Scan Parameters ===

The Calcout record has the standard fields for specifying under what circumstances the record will be processed. These fields are listed in [[RRM 3-14 dbCommon#Scan Fields|Scan Fields]]. In addition, [[RRM 3-14 Concepts#Scanning Specification|Scanning Specification]] explains how these fields are used. Since the Calcout record supports no direct interfaces to hardware, it cannot be scanned on I/O interrupt, so its SCAN field cannot be <CODE>I/O Intr</CODE>.

=== Read Parameters ===

The read parameters for the Calcout record consist of 12 input links INPA, INPB, ... INPL. The fields can be database links, channel access links, or constants. If they are links, they must specify another record's field. If they are constants, they will be initialized with the value they are configured with and can be changed via <CODE>dbPuts</CODE>. These fields cannot be hardware addresses. In addition, the Calcout record contains the INAV, INBV, . . . INLV fields which indicate the status of the link fields, for example, whether or not the specified PV was found and a link to it established. See [[#Operator Display Parameters|Operator Display Parameters]] for an explanation of these fields.

See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on how to specify database links.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TR>
<TD>INPA<TD>Input Link A<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPB<TD>Input Link B<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPC<TD>Input Link C<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPD<TD>Input Link D<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPE<TD>Input Link E<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPF<TD>Input Link F<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPG<TD>Input Link G<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPH<TD>Input Link H<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPI<TD>Input Link I<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPJ<TD>Input Link J<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPK<TD>Input Link K<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TR>
<TD>INPL<TD>Input Link L<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A
</TABLE>

=== Expression ===

Like the Calc record, the Calcout record has a CALC field in which the developer can enter an infix expression which the record routine will evaluate when it processes the record. The resulting value is placed in the VAL field. This value can then be used by the OOPT field (see [[#Output Parameters|Output Parameters]]) to determine whether or not to write to the output link or post an output event. It can also be the value that is written to the output link. The CALC expression is actually converted to opcode and stored in Reverse Polish Notation in the RPCL field. It is this expression which is actually used to calculate VAL. The Reverse Polish expression is evaluated more efficiently during run-time than an infix expression. CALC can be changed at run-time, and a special record routine will call a function to convert it to Reverse Polish Notation.

The range of expressions supported by the calculation record are separated into operands, algebraic operators, trigonometric operators, relational operators, logical operators, parentheses and commas, and the conditional '?:' operator. The expression can consist of any of these operators, as well as any of the values from the input links which are the operands.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>CALC<TD>Calculation<TD>STRING[36]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>VAL<TD>Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>RPCL<TD>Reverse Polish<TD>NOACCESS<TD>No<TD>0<TD>No<TD>No<TD>N/A<TD>No
</TABLE> Also, the RNDM unary function can be included as an operand in the expression in order to generate a random number between 0 and 1.

==== Operands ====

The expression can use the values retrieved from the INP''x'' links as operands, though constants can be used as operands too. These values retrieved from the input links are stored in the A-L fields. The values to be used in the expression are simply referenced by the field letter. For instance, the value obtained from the INPA link is stored in the field A, and the value obtained from INPB is stored in field B. The field names can be included in the expression which will operate on their respective values, as in A+B.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>A<TD>Input Value A<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>B<TD>Input Value B<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>C<TD>Input Value C<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>D<TD>Input Value D<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>E<TD>Input Value E<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>F<TD>Input Value F<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>G<TD>Input Value G<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>H<TD>Input Value H<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>I<TD>Input Value I<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>J<TD>Input Value J<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>K<TD>Input Value K<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>L<TD>Input Value L<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes
</TABLE>

==== Algebraic Operators ====

* ABS: Absolute value (unary)
* SQR: Square root (unary)
* MIN: Minimum (binary function)
* MAX: Maximum (binary function)
* CEIL: Ceiling (unary)
* FLOOR: Floor (unary)
* LOG: Log base 10 (unary)
* LOGE: Natural log (unary)
* EXP: Exponential function (unary)
* ^: Exponential (binary)
* ** : Exponential (binary)
* + : Addition (binary)
* - : Subtraction (binary)
* * : Multiplication (binary)
* / : Division (binary)
* % : Modulo (binary)
* NOT: Negate (unary)

==== Trigonometric Operators ====

* SIN: Sine
* SINH: Hyperbolic sine
* ASIN: Arc sine
* COS: Cosine
* COSH: Hyperbolic cosine
* ACOS: Arc cosine
* TAN: Tangent
* TANH: Hyperbolic tangent
* ATAN: Arc tangent

==== Relational Operators ====

* >= : Greater than or equal to
* > : Greater than
* <= : Less than or equal to
* <: Less than
* # : Not equal to
* = : Equal to

==== Logical Operators ====

* && : And
* || : Or
* ! : Not

==== Bitwise Operators ====

* | : Bitwise Or
* & : Bitwise And
* OR : Bitwise Or
* AND: Bitwise And
* XOR: Bitwise Exclusive Or
* ~ : One's Complement
* << : Left shift
* >> : Right shift

==== Parentheses and Comma ====

The open and close parentheses are supported. Nested parenthesis are supported.

The comma is supported when used to separate the arguments of a binary function.

==== Conditional Expression ====

The C language's question mark operator is supported. The format is:

(condition)? True result : False result

=== Example Expressions ===

==== Algebraic ====

A + B + 10

* Result is A + B

==== Relational ====

(A + B) < (C + D)

* Result is 1 if (A+B) < (C+D)
* Result is 0 if (A+B) >= (C+D)

==== Question Mark ====

(A+B)<(C+D)?E:F+L+10

* Result is E if (A+B) < (C+D)
* Result is F+L+10 if (A+B) >= (C+D)

(A+B)<(C+D)?E

* Result is E if (A+B) < (C+D)
* Result is unchanged if (A+B) >= (C+D)

==== Logical ====

A&B

* Causes the following to occur:
** Convert A to integer
** Convert B to integer
** Bit-wise And A and B
** Convert result to floating point

=== Output Parameters ===

These parameters specify and control the output capabilities of the Calcout record. They determine when to write the output, where to write it, and what the output will be. The OUT link specifies the Process Variable to which the result will be written. The OOPT field determines the condition that causes the output link to be written to. It's a menu field that has six choices:

* <CODE>Every Time</CODE> -- write output every time record is processed.
* <CODE>On Change</CODE> -- write output every time VAL changes, i.e., every time the result of the expression changes.
* <CODE>When Zero</CODE> -- when record is processed, write output if VAL is zero.
* <CODE>When Non-zero</CODE> -- when record is processed, write output if VAL is non-zero.
* <CODE>Transition To Zero</CODE> -- when record is processed, write output only if VAL is zero and last value was non-zero.
* <CODE>Transition To Non-zero</CODE> -- when record is processed, write output only if VAL is non-zero and last value was zero.

The DOPT field determines what data is written to the output link when the output is executed. The field is a menu field with two options: <CODE>Use CALC</CODE> or <CODE>Use OCAL</CODE>. If <CODE>Use CALC</CODE> is specified, when the record writes its output it will write the result of the expression in the CALC record, that is, it will write the value of the VAL field. If <CODE>Use OCAL</CODE> is specified, the record will instead write the result of the expression in the OCAL field, which is contained in the OVAL field. The OCAL field is exactly like the CALC field and has the same functionality: it can contain the string representation of an expression which is evaluated at run-time. Thus, if necessary, the record can use the result of the CALC expression to determine if data should be written and can use the result of the OCAL expression as the data to write.

If the OEVT field specifies a non-zero integer and the condition in the OOPT field is met, the record will post a corresponding event. If the ODLY field is non-zero, the record pauses for the specified number of seconds before executing the OUT link or posting the output event. During this waiting period the record is "active" and will not be processed again until the wait is over. The field DLYA is equal to 1 during the delay period. The resolution of the delay entry is 1/60 of a second (it uses the VxWorks <CODE>tickLib</CODE>).

The IVOA field specifies what action to take with the OUT link if the Calcout record enters an INVALID alarm status. The options are <CODE>Continue normally</CODE>, <CODE>Don't drive outputs</CODE>, and <CODE>Set output to IVOV</CODE>. If the IVOA field is <CODE>Set output to IVOV</CODE>, the data entered into the IVOV field is written to the OUT link if the record alarm severity is INVALID.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>OUT<TD>Output Specification<TD>OUTLINK<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>N/A<TD>No<TR>
<TD>OOPT<TD>Output Execute Option<TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DOPT<TD>Output Data Option<TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>OCAL<TD> Output Calculation<TD>STRING[36]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>OVAL<TD>Output Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>OEVT<TD>Event To Issue<TD>SHORT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>ODLY<TD>Output Execution Delay<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>IVOA<TD>Invalid Output Action<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>IVOV<TD>Invalid Output Value<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Operator Display Parameters ===

These parameters are used to present meaningful data to the operator. Some are also meant to represent the status of the record at run-time. An example of an interactive MEDM display screen that displays the status of the Calcout record is located here.

The EGU field contains a string of up to 16 characters which is supplied by the user and which describes the values being operated upon. The string is retrieved whenever the routine <CODE>get_units</CODE> is called. The EGU string is solely for an operator's sake and does not have to be used.

The HOPR and LOPR fields only refer to the limits of the VAL, HIHI, HIGH, LOW, and LOLO fields. PREC controls the precision of the VAL field.

The INAV-INLV fields indicate the status of the link to the PVs specified in the INPA-INPL fields, respectively. The field can have three possible values:

* <CODE>Ext PV NC</CODE> -- the PV wasn't found on this IOC and a Channel Access link hasn't been established.
* <CODE>Ext PV OK</CODE> -- the PV wasn't found on this IOC and a Channel Access link has been established.
* <CODE>Local PV</CODE> -- the PV was found on this IOC.
* <CODE>Constant</CODE> -- the corresponding link field is a constant.

The OUTV field indicates the status of the OUT link. It has the same possible values as the INAV-INLV fields.

The CLCV and OLCV fields indicate the validity of the expression in the CALC and OCAL fields, respectively. If the expression is invalid, the field is set to one.

The DLYA field is set to one during the delay interval specified in ODLY.

See [[RRM 3-14 dbCommon#Fields Common to All Record Types|Fields Common to All Record Types]] for more on the record name (NAME) and description (DESC) fields.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>EGU<TD>Engineering Units<TD>STRING [16]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>PREC<TD>Display Precision<TD>SHORT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>HOPR<TD>High Operating Range<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>LOPR<TD>Low Operating Range<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>INAV<TD>Link Status of INPA<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INBV<TD>Link Status of INPB<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INCV<TD>Link Status of INPC<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INDV<TD>Link Status of INPD<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INEV<TD>Link Status of INPE<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INFV<TD>Link Status of INPF<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INGV<TD>Link Status of INPG<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INHV<TD>Link Status of INPH<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INIV<TD>Link Status of INPI<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INJV<TD>Link Status of INPJ<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INKV<TD>Link Status of INPK<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INLV<TD>Link Status of INPL<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>OUTV<TD>OUT PV Status<TD>RECCHOICE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>CLCV<TD>CALC Valid<TD>LONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>OCLV<TD>OCAL Valid<TD>LONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DLYA<TD>Output Delay Active<TD>USHORT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>NAME<TD>Record Name<TD>STRING [29]<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>DESC<TD>Description<TD>STRING [29]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Alarm Parameters ===

The possible alarm conditions for the Calc record are the SCAN, READ, Calculation, and limit alarms. The SCAN and READ alarms are called by the record support routines. The Calculation alarm is called by the record processing routine when the CALC expression is an invalid one, upon which an error message is generated.

The following alarm parameters which are configured by the user define the limit alarms for the VAL field and the severity corresponding to those conditions.

The HYST field defines an alarm deadband for each limit. See [[RRM 3-14 Concepts#Alarm Specification|Alarm Specification]] for a complete explanation of alarms and these fields. [[RRM 3-14 dbCommon#Alarm Fields|Alarm Fields]] lists other fields related to a alarms that are common to all record types.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>HIHI<TD>Hihi Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HIGH<TD>High Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LOW<TD>Low Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LOLO<TD>Lolo Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HHSV<TD>Severity for a Hihi Alarm<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HSV<TD>Severity for a High Alarm<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LSV<TD>Severity for a Low Alarm<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LLSV<TD>Severity for a Lolo Alarm<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HYST<TD>Alarm Deadband<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Monitor Parameters ===

These parameters are used to determine when to send monitors for the value fields. The monitors are sent when the value field exceeds the last monitored field by the appropriate deadband, the ADEL for archiver monitors and the MDEL field for all other types of monitors. If these fields have a value of zero, every time the value changes, monitors are triggered; if they have a value of -1, every time the record is scanned, monitors are triggered. See [[RRM 3-14 Concepts#Monitor Specification|Monitor Specification]] for a complete explanation of monitors.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>ADEL<TD>Archive Deadband<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>MDEL<TD>Monitor, i.e. value change, Deadband<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Run-time Parameters ===

These fields are not configurable using a configuration too and none are modifiable at run-time. They are used to process the record.

The LALM field is used to implement the hysteresis factor for the alarm limits.

The LA-LL fields are used to decide when to trigger monitors for the corresponding fields. For instance, if LA does not equal the value for A, monitors for A are triggered. The MLST and MLST fields are used in the same manner for the VAL field.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TH>PP<TR>
<TD>LALM<TD>Last Alarmed Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>ALST<TD>Archive Last Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>MLST<TD>Monitor Last Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LA<TD>Previous Input Value for A<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LB<TD>Previous Input Value for A<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LC<TD>Previous Input Value for A<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LD<TD>Previous Input Value for A<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LE<TD>Previous Input Value for A<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LF<TD>Previous Input Value for A<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LG<TD>Previous Input Value for A<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LH<TD>Previous Input Value for A<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LI<TD>Previous Input Value for A<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LJ<TD>Previous Input Value for A<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LK<TD>Previous Input Value for A<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LL<TD>Previous Input Value for A<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No
</TABLE>

== Record Support ==

=== Record Support Routines ===

==== init_record ====

For each constant input link, the corresponding value field is initialized with the constant value if the input link is CONSTANT or a channel access link is created if the input link is PV_LINK.

A routine postfix is called to convert the infix expression in CALC and OCAL to reverse polish notation. The result is stored in RPCL and ORPC, respectively.

==== process ====

See next section.

==== special ====

This is called if CALC or OCAL is changed. special calls postfix.

==== get_value ====

Fills in the values of struct valueDes so that they refer to VAL.

==== get_units ====

Retrieves EGU.

==== get_precision ====

Retrieves PREC.

==== get_graphic_double ====

Sets the upper display and lower display limits for a field. If the field is VAL, HIHI, HIGH, LOW, or LOLO, the limits are set to HOPR and LOPR, else if the field has upper and lower limits defined they will be used, else the upper and lower maximum values for the field type will be used.

==== get_control_double ====

Sets the upper control and the lower control limits for a field. If the field is VAL, HIHI, HIGH, LOW, or LOLO, the limits are set to HOPR and LOPR, else if the field has upper and lower limits defined they will be used, else the upper and lower maximum values for the field type will be used.

==== get_alarm_double ====

Sets the following values:

upper_alarm_limit = HIHI
upper_warning_limit = HIGH
lower_warning_limit = LOW
lower_alarm_limit = LOLO

=== Record Processing ===

==== process() ====

The <CODE>process()</CODE> routine implements the following algorithm:

# Fetch all arguments.
# Call routine calcPerform(), which calculates VAL from the postfix version of the expression given in CALC. If calcPerform() returns success, UDF is set to FALSE.
# Check alarms. This routine checks to see if the new VAL causes the alarm status and severity to change. If so, NSEV, NSTA and LALM are set. It also honors the alarm hysteresis factor (HYST). Thus the value must change by at least HYST before the alarm status and severity changes.
# Determine if the Output Execution Option (OOPT) is met. If it is met, either execute the output link (and output event) immediately (if ODLY = 0), or schedule a callback after the specified interval. See the explanation for the <CODE>execOutput()</CODE> routine below.
# Check to see if monitors should be invoked.
#* Alarm monitors are invoked if the alarm status or severity has changed.
#* Archive and value change monitors are invoked if ADEL and MDEL conditions are met.
#* Monitors for A-L are checked whenever other monitors are invoked.
#* NSEV and NSTA are reset to 0.
# If no output delay was specified, scan forward link if necessary, set PACT FALSE, and return.

==== execOutput() ====

# If DOPT field specifies the use of OCAL, call the routine calcPerform for the postfix version of the expression in OCAL. Otherwise, use VAL.
# If the Alarm Severity is INVALID, follow the option as designated by the field IVOA.
# If the Alarm Severity is not INVALID or IVOA specifies "Continue Normally", put the value of OVAL to the OUT link and post the event in OEVT (if non-zero).
# If an output delay was implemented, process the forward link.

----

EPICS Record Reference Manual - 19 MAY 1998