EPICSWIKI - User contributions [en]

RRM 3-14 Waveform

2008-04-18T20:08:33Z

KazimierzGofron:

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

= Waveform =

The waveform record type is used to interface waveform digitizers. The record stores its data in arrays. The array can contain any of the supported data types.

== Parameter Fields ==

The waveform's fields fall into the following categories:

* scan parameters
* read parameters
* operator display parameters
* run-time parameters

=== Scan Parameters ===

The waveform 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 Parameters ===

These fields are configurable by the user to specify how and from where the record reads its data. How the INP field is configured determines where the waveform gets its input. It can be a hardware address, a channel access or database link, or a constant. Only in records that use soft device support can the INP field be a channel access link, a database link, or a constant. Otherwise, the INP field must be a hardware address. See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on the format of hardware addresses and database links.

The DTYP field must contain the name of the appropriate device support module. 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 (R3.13).

The values retrieved from the input link are placed in an array referenced by VAL. (If the INP link is a constant, elements can be placed in the array via dbPuts.) NELM specifies the number of elements that the array will hold, while FTVL specifies the data type of the elements.

The RARM field causes the device to re-arm when this field is set to 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>INP<TD>Input Link <TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>NELM<TD>Number of Elements in array <TD>ULONG<TD>Yes<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>FTVL<TD> Field Type of Value<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>RARM<TD> Rearm<TD>SHORT<TD>Yes<TD>0<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 waveform either textually or graphically.

EGU is a string of up to 16 characters describing the units that the waveform 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 array elements referenced by the VAL field. 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 the array values. 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 waveform 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 parameters are used by the run-time code for processing the waveform. They are not configured using a configuration tool. Only the VAL field is modifiable at run-time.

VAL references the array where the waveform stores its data. The BPTR field holds the address of the array.

The NORD field holds a counter of the number of elements that have been read into the array. It is reset to 0 when the device is rearmed. The BUSY field indicates if the device is armed but has not yet been digitized.

<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>See FTVL<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>BPTR<TD>Buffer Pointer <TD>NOACCESS<TD>No<TD>0<TD>No<TD>No<TD>No<TD>No<TR>
<TD>NORD <TD>Number of Elements Read <TD>ULONG<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>BUSY<TD>Busy<TD>SHORT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No
</TABLE>

The following fields are used to operate the waveform in the simulation mode. See [[RRM 3-14 Common#Simulation Mode|Simulation Mode]] 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 ====

Using NELM and FTVL space for the array is allocated. The array address is stored in the 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. VAL 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 the array.

==== cvt_dbaddr ====

This is called by dbNameToAddr. It makes the dbAddr structure refer to the actual buffer holding the result.

==== get_array_info ====

Obtains values from the array referenced by VAL.

==== put_array_info ====

Writes values into the array referenced by VAL.

==== get_units ====

Retrieves EGU.

==== get_prec ====

Retrieves PREC if field is VAL field. Otherwise, calls <CODE>recGblGetPrec()</CODE>.

==== get_graphic_double ====

Sets the upper display and lower display limits for a field. If the field is VAL 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 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_graphic_double ====

Sets the following values:

upper_disp_limit = HOPR
lower_disp_limit = LOPR

==== get_control_double ====

Sets the following values

upper_ctrl_limit = HOPR
lower_ctrl_limit = LOPR

=== 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.
# Call device support read routine.
# If PACT has been changed to TRUE, the device support read 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 always 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 waveform record must have an associated set of device support routines. The primary responsibility of the device support routines is to obtain a new array value whenever read_wf 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>INP<TD>Input Link<TD>This field is used by the device support routines to locate its input.<TR>
<TD>RATE<TD>Sampling Rate<TD>Some device support modules may find this useful.<TR>
<TD>PTSS<TD>Pre-trigger Samples<TD>Some device support modules may find this useful.<TR>
<TD>NELM<TD>Number Of Elements In Array<TD> <TR>
<TD>FTVL<TD>Field Type Of Value<TD>This is DBF_STRING, ... , DBF_ENUM. The device support routine should check that this is correctly defined.<TR>
<TD>RARM<TD>Rearm<TD>When set to 1, the device will be rearmed. The device support routine should reset it to 0 when done.<TR>
<TD>BPTR<TD>Holds Address of Array<TD> <TR>
<TD>NORD<TD>Number of Elements Read<TD>Device support must set this value when it completes.<TR>
<TD>BUSY<TD>Is device busy?<TD> 
</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_wf ====

read_wf(precord)

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

* 0: Success.
* Other: Error.

=== Device Support For Soft Records ===

The <CODE>Soft Channel</CODE> device support module is provided to read values from other records and store them in arrays. If INP is a constant link, then read_wf does nothing. In this case, the record can be used to hold arrays written via dbPuts. If INP is a database or channel access link, the new array value is read from the link. NORD is set.

This module places a value directly in VAL.

If the INP link type is constant, then NORD is set to zero. If the INP link type is PV_LINK, then dbCaAddInlink is called by init_record.

read_wf calls recGblGetLinkValue which performs the following steps:

If the INP link type is CONSTANT recGblGetLinkValue does nothing.

If the INP link type is DB_LINK, then dbGetLink is called to obtain a new input value. If dbGetLink returns an error, a LINK_ALARM with a severity of INVALID_ALARM is raised.

If the INP link type is CA_LINK, then dbCaGetLink is called to obtain a new input value. If dbCaGetLink returns an error, a LINK_ALARM with a severity of INVALID_ALARM is raised.

NORD is set to the number of values returned and read_wf returns.

----

EPICS Record Reference Manual - 19 MAY 1998

RRM 3-14 Wait

2008-04-18T20:07:52Z

KazimierzGofron:

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

= Wait =

: Ned D. Arnold
: Advanced Photon Source
: Argonne National Laboratory

This chapter describes the capabilities and use of the Wait record. The Wait record was developed primarily to provide "reassignable" link fields that could be changed during run time. A unique library was developed to provide this feature. Since all EPICS standard link fields are "reassignable" in R3.13 and above, the Wait record and its associated library are somewhat obsolete. For new designs, it is recommended that the ''Calcout'' record be used, which provides the same function as the Wait record (plus more) while using the standard EPICS links.

The Wait record is derived from the Calc record with the following additional features:

* reassignable PV links
* an output link
* a desired output link
* an output event number to post
* and several options as to when it will execute the output link and event posting.

The Wait record also has the capability to process as a result of an input changing (via CA monitors), and it can be used to do ''conditional'' processing within the database. Its name is derived from the original requirement that initiated its development -- "I want to wait until all the motors have stopped and then trigger the detector."

== Parameter Fields ==

The fields fall into the following categories:

* scan parameters
* read parameters
* expression-related parameters
* desired output parameters
* write parameters
* operator parameters
* monitor parameters
* run-time and simulation mode parameters

=== Scan Parameters ===

The wait record has the standard fields for specifying under what circumstances the record will be processed. In addition to the standard scan mechanisms available to all records (periodic, passive, event, etc.), the wait record can be specified to process as a result of one of its input values changing (using Channel Access monitors). This offers immediate response to an input change (rather than waiting for the next periodic scan) while minimizing record processing that is not required. The scan mechanism choice <CODE>I/O Intr</CODE> will enable this feature. For the current EPICS release, an additional module, <CODE>caMonitor.o</CODE>, must be compiled and loaded with the wait record support to provide this feature.

: <B>Note: Because of the event driven nature of this feature, it is quite easy to configure a database that results in an infinite loop which uses all available CPU time. If the wait record is set to process as a result of a channel changing and the processing of the wait record causes the channel to change again, an infinite loop will result. The symptom will be a loss of all channel access connections (lower priority tasks) even though the shell responds normally. Using the <CODE>spy</CODE> vxWorks utility will confirm the predicament by showing 0% free CPU time.</B>

[[RRM 3-14 Concepts#Scanning Specification|Scanning Specification]] explains how the rest of these fields are used. They are listed in [[RRM 3-14 dbCommon#Scan Fields|Scan Fields]].

=== Read Parameters ===

Like the Calc record, the read parameters for the Wait record consist of 12 input links--INAN, INBN, ... INLN. The fields can be database links or constants. If they are links, they must specify another record's field in the same IOC. If they are constants, the corresponding value field for the link (A-L) will be initialized with the constant's value and can be changed via dbPuts. The Wait record does not support direct links to hardware.

Unlike the Calc record, these input links can be modified during run time. These are ASCII fields which have a special processing routine attached to them. When changed, the routine is called. The record will use the new link the next time the record is processed.

A consequence of reassignable links is that one cannot force the processing of any specified records prior to retrieving the data from them (i.e. there is no .PP flag). This should be considered when designing a database using the Wait record.

In this initial version, the ''reassignable'' links do not support channel access connections external to the IOC. Until this feature is added, the specified Process Variables must reside on the same IOC.

See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on specifying links and constants.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TR>
<TD>INAN<TD>Input Link A Name<TD>STRING[40]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>INBN<TD>Input Link B Name<TD>STRING[40]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>INCN<TD>Input Link C Name<TD>STRING[40]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>INDN<TD>Input Link D Name<TD>STRING[40]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>INEN<TD>Input Link E Name<TD>STRING[40]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>INFN<TD>Input Link F Name<TD>STRING[40]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>INGN<TD>Input Link G Name<TD>STRING[40]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>INHN<TD>Input Link H Name<TD>STRING[40]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>ININ<TD>Input Link I Name<TD>STRING[40]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>INJN<TD>Input Link J Name<TD>STRING[40]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>INKN<TD>Input Link K Name<TD>STRING[40]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>INLN<TD>Input Link L Name<TD>STRING[40]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes
</TABLE>

=== Expression-related Parameters ===

The expression related fields of the Wait record are identical to that of the Calc record. The two main fields are the CALC and RPCL fields. The CALC field contains the infix expression which the record routine will use when it processes the record. The user enters an expression in this field. The resulting value of the expression is placed in the VAL field The write parameters of the record can write this value if configured to.

The CALC field is actually converted to opcode and stored as a reverse polish expression, or postfix expression, in the RPCL field. It is this expression which is actually used to calculate VAL. CALC can be changed at run-time, and the special record routine calls a function to convert it to the postfix expression. One difference between the Calc record and the Wait record is that the Wait record contains a flag field (CLCV) that indicates if the expression is a valid one. It will be true (non-zero) if the expression is invalid, in which case an error message is generated.

The reverse polish calculation is evaluated most efficiently during run-time. The range of expressions supported by the calculation record are separated into operands, algebraic operations, trigonometric operations, relational operations, logical operations, parentheses and commas, and the question mark operator.

<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 can use the values retrieved from the INP''x'' links as operands, these values being 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 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. In addition, the RNDM unary function can be included as an operand 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<TR>
<TD>A<TD>Input Values A<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TR>
<TD>B<TD>Input Values B<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TR>
<TD>C<TD>Input Values C<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TR>
<TD>D<TD>Input Values D<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TR>
<TD>E<TD>Input Values E<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TR>
<TD>F<TD>Input Values E<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TR>
<TD>G<TD>Input Values G<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TR>
<TD>H<TD>Input Values H<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TR>
<TD>I<TD>Input Values I<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TR>
<TD>J<TD>Input Values J<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TR>
<TD>K<TD>Input Values K<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TR>
<TD>L<TD>Input Values L<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<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 parentheses are supported.

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

==== Conditional Expression ====

The "C" 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

=== Desired Output Parameters ===

Using the choices in the Data Output field (DOPT) explained in the next section, the Wait record can be configured to write as its output the result of its calculation (the value in VAL) or it can be configured to write a desired output value, fetched from an input link. The desired output fields for the Wait record are similar to the desired output parameters of other output records.

In the desired output location (DOLN) field, the user specifies a link from which the record will retrieve the value that it writes (if the DOPT field specifies DOLD). The value is retrieved and placed in the desired output location data field (DOLD). If DOLN specifies no link, a flag field indicates that the DOLN field is invalid. When the DOLN field is invalid, the value of DOLD can be set via dbPuts at run-time.

<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>DOLN <TD>Desired Output Location<TD>STRING [40]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DOLD<TD>Desired Output Location Data <TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No
</TABLE>

=== Write Parameters ===

The Wait record can write either the result of its calculation (VAL) or the value retrieved by the DOLN field. If the user specifies <CODE>Use VAL</CODE> in the Data Option (DOPT) field, then the value in VAL will be written. If the user specifies <CODE>Use DOL</CODE>, the value retrieved from the DOLN link and contained in the DOLD field will be written. The DOPT field can be changed during run-time.

The Output Link Name (OUTN) specifies where the record is to write the output value.

The Wait record does not have to write its output every time the record processes. This allows "downstream" processing of records to be done conditionally. The record has ''output execution'' options which can be specified in the OOPT field. These options are as follows.

* <CODE>Every Time</CODE>: Outputs are executed every time the record processes.
* <CODE>On Change</CODE>: Outputs are executed if the result of the calculation (VAL) is different than the previous time the record was processed.
* <CODE>When Zero</CODE>: Outputs are executed if the result of the calculation is zero.
* <CODE>When Non-zero</CODE>: Outputs are executed if the result of the calculation is not zero.
* <CODE>Transition To Zero</CODE>: Outputs are executed if the result of the calculation is zero and the previous value was not zero.
* <CODE>Transition To Non-zero</CODE>: Outputs are executed if the result of the calculation is not zero and the previous value was zero.
The Wait record can also post an event. If a non-zero value is entered into the OEVT (Output Event) field, the record will "post an event" (using the entered number as the event number) whenever the output link is executed. This is a way of initiating several other records to process as a result of a calculation.

<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>OOPT<TD>Output Option<TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>OUTN <TD>Output Link Name <TD>STRING [40]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DOPT<TD>Data Option<TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>OEVT<TD> Output Event <TD>USHORT<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. They display the value and other parameters of the Wait record either textually or graphically.

The HOPR and LOPR fields set the upper and lower display limits for the VAL field. The <CODE>get_graphic_double</CODE> retrieves 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>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 wait 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.

=== Monitor Parameters ===

These parameters are delta values that implement a deadband on the value-change monitors for the VAL field. Monitors are sent when the value field exceeds the last monitored field (MLST, for instance) 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 processed, monitors are triggered. The ADEL field is used for 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.

<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 Wait record. They are not configurable. They represent the current state of the record. The record support routines use some of them to process the record or to implement monitors.

The OVAL field is used to implement monitors on the VAL field. If VAL differs from OVAL (taking into account the deadband) then monitors for VAL are triggered.

The LA-LL fields are used to implement monitors for the A-L field, the fields which hold the values retrieved from the input links. They hold the values retrieved from INPA-INPL the last time the record was processed. For instance, when A, the current value retrieved from INPA, does not equal LA, the last value retrieved, then monitors for A are triggered.

The DOLV and CLCV are flag fields. The DOLV flag is used to indicate if the process variable specified in the Desired Output Location (DOLN) field is a valid name. If it is not, the desired output value is not retrieved from DOLN. The CLCV flag is used to indicate if the Wait record's CALC expression is a mathematically valid one.

The CBST field contains a pointer to a record private structure. It is not of concern to the user.

<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>CBST<TD>Callback Structure<TD>NOACCESS<TD>No<TD>Null<TD>No<TD>No<TD>No<TD>No<TR>
<TD>OVAL<TD>Old Value <TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DOLA <TD>Desired Output Location Address<TD>NOACCESS<TD>No<TD>Null<TD>No<TD>No<TD>No<TD>No<TR>
<TD>DOLV<TD>Desired Output Location Valid<TD>LONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<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>CLCV <TD>Calculation String Valid<TD>LONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>LA<TD>Previous Input<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>LB<TD>Previous Input<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>LC<TD>Previous Input<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>LD<TD>Previous Input<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>LE<TD>Previous Input<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>LF<TD>Previous Input<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>LG<TD>Previous Input<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>LH<TD>Previous Input<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>LI<TD>Previous Input<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>LJ<TD>Previous Input<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>LK<TD>Previous Input<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>LL<TD>Previous Input<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

----

EPICS Record Reference Manual - 19 MAY 1998

RRM 3-14 Transform

2008-04-18T20:07:03Z

KazimierzGofron:

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

= Transform Record =

The Transform record combines features of the Calcout and Seq records, with
16 sets of the following fields:

* input link
* input-link status
* value (from input link or from calc expression)
* calc expression
* calc-expression status
* output link
* output-link status
* comment

For concreteness, here is the first set of fields:

INPA - link from which value for A will be read
IAV - status of INPA
A - value
CLCA - expression whose value might be written to A
CAV - validity of expression CLCA
OUTA - link to which A will be written
OAV - status of OUTA
CMTA - comment (description)

The value fields A-P are "process-passive", which means that writing to one of them from
a CA client, or via a "CA" link, will cause the record to process, if its scan state is "Passive".
If the input link associated with a value field is not blank and is not an initialization constant, then
writes to that value field are not permitted.

An expression is evaluated only if the associated value field has not been modified (either by a <i>put</i> from
some external agent, or as the result of input-link execution) since the last time the record processed.

== Background ==
The Transform record was originally intended to perform the sequences of conditional calculations required to implement bidirectional coordinate transformations.

Example: You have defined two records containing values we'll call "L" and "R" (the left and right edges of a slit, say). Sometimes the user wants to control L and R individually, and sometimes he wants to control a combination of L and R--say (L-R) and (L+R)/2, the width and center of the slit system. You can implement a bidirectional coordinate transformation with the following expressions (where position values are assumed to increase as we go from left to right):

<table border = "1">
<th>field<th>expression<th>comment
<tr> <td>A <td>C-D/2 <td>position of left edge of slit
<tr> <td>B <td>C+D/2 <td>position of right edge of slit
<tr> <td>C <td>(A+B)/2 <td>position of center of slit
<tr> <td>D <td>B-A <td>width of slit
</table>

Now, if a user command moves the left side of the slit (A changes) and causes the record to process, A will not be recalculated because it's value is new, the right side of the slit will remain still (B is unnecessarily recalculated from old values of C and D), the position of the slit center (C) will change as expected, and the slit width (D) will change as expected. Thus, all four fields will contain consistent information about the two degrees of freedom controlled by the record, and effectively we have two actual devices and two virtual devices.

We don't care which two fields (out of A..D) correspond to actual motion-control devices, and two channel-access clients that make different assumptions about how a slit should be implemented can control this slit without modification. With an additional, similar transform record driven from the readback fields of the actual motion-control devices, we can calculate readback values for the virtual devices as well.

We could have accomplished nearly the same effect with six CALC records and some FANOUTs, but two of the drive fields (A,B,C,D) would always be inconsistent with their readbacks.

== Parameter Fields ==

The fields in this record fall into these categories:

* scan parameters
* read parameters
* expression parameters
* output parameters
* operator display parameters
* alarm parameters

=== Scan Parameters ===

The Transform 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 Transform 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 Transform record consist of 16 input links INPA, INPB, ... INPP. 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, associated value fields will be initialized with the constants. These fields cannot be hardware addresses. In addition, the Transform record contains the IAV, IBV, . . . IPV fields which indicate the states 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>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>INPP<TD>Input Link P<TD>INLINK<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes
</TABLE>

=== Expression Parameters ===

Like the Calcout record, the Transform record has fields in which the developer or user can enter an infix
expression to be evaluated when the record is processed. There are, in fact, 16 such fields, each of which
is a member of its own (<i>inputlink</i>, <i>value</i>, <i>expression</i>, <i>outputlink</i>) group. For
each group, if <i>inputlink</i> is not blank and is not simply a constant initializer, then <i>expression</i> may be evaluated when
the record processes, and the result will be placed in <i>value</i>.

Transform-record expressions are very similar to Calcout-record expression described elsewhere in this
manual. Instead of the standard EPICS calc engine (which does not permit an expression
to reference more than 12 input fields), Transform-record expressions are handled by the sCalcout (string calculation and output) record's engine. The differences, between these engines, that matter for
transform-record 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. (EPICS 3.14-compatible version only.)</font>
* <font color="blue">The binary operators '>&' (larger of the operands) and '<&' (smaller) are supported. (EPICS 3.14-compatible version only.)</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'.)
* The values of the variables A...P used in expressions may be the results of previously evaluated expressions.

=== Output Parameters ===

The Transform record has 16 output links, executed in order from OUTA to OUTP. Unlike the Calcout record,
these links are not conditional; they execute every time the record processes.

<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 Specification<TD>OUTLINK<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>N/A<TD>No<TR>
<TD>OUTB<TD>Output Specification<TD>OUTLINK<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>N/A<TD>No<TR>
<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TR>
<TD>OUTP<TD>Output Specification<TD>OUTLINK<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>N/A<TD>No<TR>

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

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. This field is not very useful, because it's unlikely to pertain to all 16 value fields.

The IAV-IPV fields indicate the states of the links INPA-INPP. These fields 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 OAV-OPV fields indicate the states of the OUTA-OUTP links. They have the same possible values as the IAV-ILV fields.

The CAV-CPV fields indicate the validity of the expressions in the CLCA-CLCP fields, respectively. If an expression is invalid, its status field is set to one.

The IVLA field specifies how the record should behave if any of its input links references a record that is in alarm. There are two possibilities:

* "Ignore Error" - Use whatever value was gotten from the link, and proceed as if there had not been any error indication.
* "Do Nothing" - Stop after all input values have been retrieved: do not evaluate expressions, and do not execute output or forward links.

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>IAV<TD>Link Status of INPA<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>IBV<TD>Link Status of INPB<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TR>
<TD>IPV<TD>Link Status of INPP<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>OAV<TD>Link Status of OUTA<TD>RECCHOICE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>OBV<TD>Link Status of OUTB<TD>RECCHOICE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TR>
<TD>OPV<TD>Link Status of OUTP<TD>RECCHOICE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>CAV<TD>CLCA Valid<TD>LONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>CBV<TD>CLCB Valid<TD>LONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TR>
<TD>CPV<TD>CLCP Valid<TD>LONG<TD>No<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 Transform record has no record-type-specific alarm fields.
See [[RRM 3-14 dbCommon#Alarm Fields|Alarm Fields]] for the list of alarm fields common to all record types.

== Record Support ==

=== Record Support Routines ===

==== init_record ====

For each constant input link, the corresponding value field is initialized with the constant.

A routine sCalcPostfix is called to convert the infix expression in CLCA-CLCV to postfix notation. The results are stored in RPCA-RPCP.

==== process ====

See next section.

==== special ====

This is called if any of the fields A-P, CLCA-CLCP, INPA-INPP, OUTA-OUTP 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_precision ====

Retrieves PREC.

=== Record Processing ===

==== process() ====

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

# Fetch values from all valid input links.
# For each value field <b>x</b>, in order from A to P: if the value has not been written to since the last time the record processed, call sCalcPerform(), which evaluates the expression specified in CLC<b>x</b> and stores the result in <b>x</b>.
# Post all fields the record has changed.
# Execute all valid output links, in order from OUTA to OUTP.
# Execute the forward link, set PACT FALSE, and return.

== Availability ==

The Transform record is not included with EPICS base. An EPICS 3.13-compatible version of this record is available as part of the [http://www.aps.anl.gov/aod/bcda/synApps/std/std.html std] module, which is part of the [http://www.aps.anl.gov/aod/bcda/synApps synApps] package of EPICS-based synchrotron-beamline software.
----

EPICS Record Reference Manual - 7 JUNE 2006

RRM 3-14 Timer

2008-04-18T20:06:24Z

KazimierzGofron:

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

= Timer =

The timer record is provided as a means for configuring timing outputs. These records will drive an output that may be used to latch data into analog inputs or waveform digitizers.

== Parameter Fields ==

The fields for the timer record fall into the following categories:

* scan parameters
* setup parameters
* write and convert parameters
* operator display parameters
* event generation parameters
* run-time parameters

=== Scan Parameters ===

The timer record has the standard fields for specifying under what circumstances it will be processed. In addition, the VAL field is provided in the timer record to force record processing when written to. The other 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.

<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>SHORT<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes
</TABLE>

=== Setup Parameters ===

The timer record has fields needed to initialize a motor. The trigger source (TRSC) field is usually configured to come in from an external signal. This is configured in the record by setting TSRC to <CODE>external</CODE>, the only other choice being <CODE>internal</CODE>. The pre-trigger state field (PSRC) is the state of the timing channel when it is not fired. The timing channel usually goes high when the timing pulse is present. In such a case the pre-trigger state is low.

<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>TSRC<TD>Clock Source <TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>PTST <TD>Pre-Trigger State <TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes
</TABLE>

=== Write and Convert Parameters ===

The delays and outputs are specified in the time units (TIMU), which has four choices based on seconds: <CODE>Milliseconds</CODE>, <CODE>Microseconds</CODE>, <CODE>Nanoseconds</CODE>, <CODE>and Picoseconds</CODE>.

There are delays and pulse widths for five timing pulses per channel. The pulse width for each should be specified in the OPW1-OPW5 fields, in the units chosen in the TIMU field. The delay width for each trigger is specified in the DUT1-DUT5 fields. The delay width is the time in between pulses. These fields are converted to seconds by the run-time code before being used.

The value of the trigger delay field (TRDL) fetched from the trigger origin (TORG) field is added to the delay for each of these five signals. The TORG and TRDL work like the desired output parameters of other output records. TORG can be a channel access or database link, or a constant. If TORG is a constant, TRDL is initialized to the constant value and can be changed at run-time via dbPuts. Using the TORG field one can set up timing chains which are relative to other timing signals. See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on how to specify database links.

The desired output is sent to the address contained in the output link (OUT). The DTYP field must contain the name of a valid device support module. 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 (R3.13).

<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>TORG<TD>Trigger Delay Origin (input link)<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>TRDL<TD>Trigger Delay <TD>FLOAT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>TIMU <TD>Timer Units<TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DTYP<TD>Device Type<TD>DEVCHOICE<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>OUT <TD>Output Link<TD>OUTLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>DUT1<TD>Delay Width for trigger 1<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>OPW1<TD>Pulse width for Trigger 1<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>DUT2<TD>Delay Width for Trigger 2<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>OPW2<TD>Pulse Width for Trigger 2<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>DUT3<TD>Delay Width for Trigger 3<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>OPW3<TD>Pulse Width for Trigger 3<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>DUT4<TD>Delay Width for Trigger 4<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>OPW4<TD>Pulse Width for Trigger 4<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>DUT5<TD>Delay Width for Trigger 5<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>OPW5<TD>Pulse Width for Trigger 5<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes
</TABLE>

=== Operator Display Parameters ===

The PDLY field displays the delay from source to input, which is the time is takes for the timing signal to get from its output to the trigger. It is not used by the run-time code, but characterizes the timing signals for the operator's knowledge.

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>PDLY<TD>Delay Source to Input<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 timer 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.

=== Event Generation Parameters ===

The timing event (TEVT) field is used to generate internal events for processing records on an event. It should be an integer representing an event number.

<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>TEVT<TD>Event Number To Be Posted On Trigger. <TD>SHORT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes
</TABLE>

=== Run-time Parameters ===

These parameters are used by the run-time code for processing the timing channel. They are not configured using a configuration tool. They represent the current state of the timing channel.

The T1DL-T5DL and T1WD-T5WD fields are where the record stores the user-configured delay widths and pulse widths for the five triggers (DUT1-DUT5 and OPW1-OPW5) after it has converted them to seconds.

The T1TD-T5TD and T1LD-T5LD fields hold the trailing and leading trigger delays for each trigger. These fields are calculated by the record as follows:

T''n''LD = DUT''n'' + TRDL
T''n''TD = T''n''LD + OPW''n''

where ''n'' represents the trigger number.

<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>T1DL<TD>Delay Width for Trigger 1<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>T1WD<TD>Pulse Width for Trigger 1<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>T2DL<TD>Delay Width for Trigger 2<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>T2WD<TD>Pulse Width for Trigger 2<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>T3DL<TD>Delay Width for Trigger 3<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>T3WD<TD>Pulse Width for Trigger 3<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>T4DL<TD>Delay Width or Trigger 4<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>T4WD<TD>Pulse Width for Trigger 4<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>T5DL<TD>Delay width for Trigger 5<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>T5WD<TD>Pulse Width for Trigger 5<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>T1TD<TD>Trigger 1 Trailing Delay<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>T1LD<TD>Trigger 1 Leading Delay<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>T2TD<TD>Trigger 2 Trailing Delay <TD>FLOAT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>T2LD<TD>Trigger 2 Leading Delay<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>T3TD<TD>Trigger 3 Trailing Delay<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>T3LD<TD>Trigger 3 Leading Delay<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>T4TD<TD>Trigger 4 Trailing Delay<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>T4LD<TD>Trigger 4 Leading Delay<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>T5TD<TD>Trigger 5 Trailing Delay<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>T5LD<TD>Trigger 5 Leading Delay<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>TDIS<TD>Timing Pulse Disable<TD>SHORT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>MAIN<TD>Maintain on Reboot <TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>1<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>RDT1<TD>Reboot Delay of 1 <TD>FLOAT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>RDW1<TD>Reboot Width of 1 <TD>FLOAT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

----

EPICS Record Reference Manual - 19 MAY 1998

RRM 3-14 Subroutine

2008-04-18T20:05:45Z

KazimierzGofron:

[[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 F<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>INPJ<TD>Input H<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>Value for A<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

RRM 3-14 SubArray

2008-04-18T20:04:58Z

KazimierzGofron:

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

= subArray =

The normal use for the subArray record type is to obtain sub-arrays from waveform records. Setting either the number of elements (NELM) or index (INDX) fields causes the record to be processed anew so that applications in which the length and position of a sub-array in a waveform record vary dynamically can be implemented using standard EPICS operator interface tools.

The first element of the sub-array, that at location INDX in the referenced waveform record, can be displayed as a scalar, or the entire subarray (of length NELM) can be displayed in the same way as a waveform record. If there are fewer than NELM elements in the referenced waveform after the INDX, only the number of elements actually available are returned, and the number of elements read field (NORD) is set to reflect this. This record type does not support writing new values into waveform records.

== Parameter Fields ==

The subArray's fields fall into the following categories:

* scan parameters
* read parameters
* array parameters
* operator display parameters
* run-time parameters

=== Scan Parameters ===

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

=== Read Parameters ===

The subArray's input link (INP) should be configured to reference the Waveform record. It should specify the VAL field of a Waveform record. The INP field can be a channel access link, in addition to a database link. See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on specifying links.

In addition, the DTYP field must specify a device support module. Currently, the only device support module is <CODE>Soft Channel</CODE>.

<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> <TD>N/A<TD>No<TR>
<TD>DTYP<TD>Device Type<TD>DEVCHOICE<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD>No
</TABLE>

=== Array Parameters ===

These parameters determine the number of array elements (the array length) and the data type of those elements. The Field Type of Value (FTVL) field determines the data type of the array.

The user specifies the maximum number of elements allowed in the subarray in the MALM field. Generally, the number should be equal to the number of elements of the Waveform array (found in the Waveform's NELM field). The MALM field is used to allocate memory. The subArray's Number of Elements (NELM) field is where the user specifies the actual number of elements that the subArray will contain. It should of course be no greater than MALM; if it is, the record processing routine sets it equal to MALM.

The INDX field determines the offset of the subArray record's array in relation to the Waveform's. For instance, if INDX is 2, then the subArray will read NELM elements starting with the third element of the Waveform's array. Thus, it equals the index number of the Waveform's array.

The actual sub-array is referenced by 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>FTVL<TD>Field Type of Value<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>VAL<TD>Value Field<TD>(See FTVL)<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>MALM<TD>Maximum Number of Elements In Sub-array<TD>ULONG<TD>Yes<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>NELM<TD>Number of Elements In Sub-array<TD>ULONG<TD>Yes<TD>1<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>INDX<TD>Index Into Referenced Array <TD>ULONG<TD>Yes<TD>0<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 subarray record either textually or graphically.

EGU is a string of up to 16 characters describing the engineering units (if any) of the values which the subArray holds. 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 sub-array elements. 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 subarray 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 not configurable by the user. They are used for the record's internal processing or to represent the current state of the record.

The NORD field holds a counter of the number of elements read into the array. It can be less than NELM even after the array is full if NELM exceeds the number of existing elements in the referenced array, i.e., the Waveform's array.

BPTR contains a pointer to the record's array.

<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>NORD <TD>Number of Elements Read<TD>LONG<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>BPTR<TD>Buffer Pointer<TD>NOACCESS<TD>No<TD>null<TD>Yes<TD>No<TD>No<TD>No
</TABLE>

== Record Support ==

=== Record Support Routines ===

==== init_record ====

Using MALM and FTVL, space for the array is allocated. The array address is stored in BPTR. This routine 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 the sub-array.

==== cvt_dbaddr ====

This is called by dbNameToAddr. It makes the dbAddr structure refer to the actual buffer holding the result.

==== get_array_info ====

Retrieves NELM.

==== put_array_info ====

Sets NORD.

==== get_graphic_double ====

For the elements in the array, this routine routines HOPR and LOPR. For the INDX field, this routine returns MALM - 1 and 0. For NELM, it returns MALM and 1. For other fields, it calls <CODE>recGblGetGraphicDouble()</CODE>.

==== get_control_double ====

For array elements, this routine retrieves HOPR and LOPR. Otherwise, <CODE>recGblGetControlDouble()</CODE> is called.

==== get_units ====

Retrieves EGU.

==== get_prec ====

Retrieves PREC.

=== 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.
# Sanity check NELM and INDX. If NELM is greater than MALM it is set to MALM. If INDX is greater than or equal to MALM it is set to MALM-1.
# Call device support read routine. This routine is expected to place the desired sub-array at the beginning of the buffer and set NORD to the number of elements of the sub-array that were read.
# If PACT has been changed to TRUE, the device support read routine has started but has not completed writing the new value. In this case, the processing routine merely returns, leaving PACT TRUE. Otherwise, process sets PACT TRUE at this time. This asynchronous processing logic is not currently used but has been left in place.
# 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 always 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 ===

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>INP<TD>Input Link<TD>This field is used by the device support routines to locate its input.<TR>
<TD>FTVL<TD>Field Type of Value<TD>This is DBF_STRING, ... ,DBF_ENUM. The device support routine should check that this is correctly defined.<TR>
<TD>MALM<TD>Maximum Number Of Elements in Sub-array<TD>Number of elements that will fit in the array the record allocates. Device support must never return more elements than this.<TR>
<TD>NELM<TD>Number Sub-array Elements<TD>Number of elements in desired sub-array.<TR>
<TD>INDX<TD>Index Into Referenced Array<TD>Index of beginning of desired sub-array in source array.<TR>
<TD>BPTR<TD>Buffer Pointer<TD>Address of array device support must copy the source array into.<TR>
<TD>NORD<TD>Number Of Elements Read<TD>Device support must set this value when it completes.
</TABLE>

=== Device Support Routines ===

Device support consists of the following routines:

==== report ====

report(FILE fp, paddr)

not currently used.

==== init ====

init()

Not currently used.

==== init_record ====

init_record(precord)

This routine is called by the record support init_record routine.

==== read_sa ====

read_sa(precord)

Enough of the source waveform is read into BPTR, from the beginning of the source, to include the requested sub-array. The sub-array is then copied to the beginning of the buffer. NORD is set to indicate how many elements of the sub-array were acquired.

=== Device Support For Soft Records ===

Only the device support module <CODE>Soft Channel</CODE> is currently provided. The INP link type must be either DB_LINK or CA_LINK.

==== Soft Channel ====

INP is expected to point to a waveform record.

----

EPICS Record Reference Manual - 19 MAY 1998

RRM 3-14 String Output

2008-04-18T20:02:48Z

KazimierzGofron:

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

= stringout -- String Output =

The stringout record is used to write an arbitrary ASCII string of up to 40 characters to other records or software variables.

== Parameter Fields ==

The fields fall into the following categories:

* scan parameters
* desired output parameters
* write parameters
* operator display parameters
* run-time parameters

=== Scan Parameters ===

The string output 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 ===

The string output record must specify from where it gets its desired output string. The first field that determines where the desired output originates is the output mode select (OSML) field, which can have two possible value: <CODE>closed_loop</CODE> or <CODE>supervisory</CODE>. If <CODE>supervisory</CODE> is specified, DOL is ignored, the current value of VAL is written, and the VAL can be changed 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 field (DOL) which can be either a database link or a channel access link.

DOL can also be a constant in addition to a link, in which case VAL is initialized to the constant value. Note that if DOL is a constant, OMSL cannot be <CODE>closed_loop.</CODE> 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>VAL<TD> Value Field <TD>STRING [40]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>Yes<TD>Yes<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
</TABLE>

=== Write Parameters ===

The output link specified in the OUT field specifies where the string output record is to write its string. The link can be a database or channel access link. If the OUT field is a constant, no output will be written. See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on specifying links.

In addition, the appropriate device support module must be entered into the DTYP field. All string output records must specify a device support module. 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 (R3.13).

<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>No
</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 string output either textually or graphically.

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>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 string output record are the SCAN, READ, and INVALID alarms. The severity of the first two is always MAJOR and not configurable.

The IVOA field specifies an action to take when the INVALID alarm is triggered. There are three possible actions: <CODE>Continue normally</CODE>, <CODE>Don't drive outputs</CODE>, and <CODE>Set output to IVOV</CODE>. When <CODE>Set output to IVOV</CODE>, the value contained in the IVOV field is written to the output link during an alarm condition. 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>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>

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

The old value field (OVAL) of the string input is used to implement value change monitors for VAL. If VAL is not equal to OVAL, then monitors are triggered.

<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>Output Value<TD>STRING [40]<TD>No<TD>Null<TD>Yes<TD>No<TD>No<TD>No
</TABLE>

The following fields are used to operate the string output in the simulation mode. See [[RRM 3-14 Common#Simulation Mode|Simulation Mode]] 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>STRING [40]<TD>No<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<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 ===

Three record support routines are provided: init_record, process, and get_value.

==== 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 the type double constant, if non-zero, is converted to a string and stored into VAL 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.

=== 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#Soft Output|Soft Output]]. If the return status of recGblGetLinkValue is zero then UDF is set to FALSE.
# 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 details on how the simulation mode and the INVALID alarm conditions 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 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 OVAL is not equal to VAL.
#* 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 stringout 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_stringout 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 Field<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<TD>This is the field written by the device support routines.<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:

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

==== write_stringout ====

write_stringout(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> device support module writes the current value of VAL.

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

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

----

EPICS Record Reference Manual - 19 MAY 1998

RRM 3-14 String Input

2008-04-18T20:01:34Z

KazimierzGofron:

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

= stringin - String Input =

The string input record retrieves an arbitrary ASCII string of up to 40 characters. Several device support routines are available, all of which are soft device support for retrieving values from other records or other software components.

== Parameter Fields ==

The fields fall into the following categories.

* scan parameters
* read parameters
* operator display parameters
* run-time and simulation mode parameters

=== Scan Parameters ===

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

=== Read Parameters ===

The INP field determines where the string input record gets its string. It can be a database or channel access link, or a constant. If constant, the VAL field is initialized with the constant and can be changed via dbPuts. Otherwise, the string is read from the specified location each time the record is processed and placed in the VAL field. The maximum number of characters that the string in VAL can be is 40. In addition, the appropriate device support module must be entered into the DTYP field.

See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on specifying links. 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 (R3.13).

<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<TD>STRING [40]<TD>Yes<TD>Null<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>DTYP<TD>Device Type<TD>DEVCHOICE<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD>No
</TABLE>

=== Operator Display Parameters ===

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>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 string input 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 and Simulation Mode Parameters ===

The old value field (OVAL) of the string input is used to implement value change monitors for VAL. If VAL is not equal to OVAL, then monitors are triggered.

<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>Output Value<TD>STRING<TD>No<TD>Null<TD>Yes<TD>No<TD>No<TD>No
</TABLE>

The following fields are used to operate the string input in the simulation mode. See [[RRM 3-14 Common#Simulation Mode|Simulation Mode]] for more information on 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>STRING [40]<TD>No<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<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 ===

Three record support routines are provided: init_record, process, and get_value.

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

=== 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#Simulation Mode|Simulation Mode]] for more information on simulation mode fields and how they affect input.
# 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.
# TIME is set to tslocaltime
# 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 OVAL is not equal to VAL.
#* 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 stringin input record must have an associated set of device support routines. The primary responsibility of the device support routines is to obtain a new ASCII string value whenever read_stringin 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=3>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>VAL<TD>Value<TD>This field is set by the device support routines.<TR>
<TD>INP<TD>Input Link.<TD>This field is used by the device support routines to locate its input.
</TABLE>

=== Device Support Routines ===

Device support consists of the following routines:

==== report ====

report(FILE fp, paddr)

Not currently used.

==== init ====

init()

==== 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_stringin ====

read_stringin(precord)

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

* 0: Success. A new ASCII string is stored into VAL.
* Other: Error.

=== Device Support For Soft Records ===

The <CODE>Soft Channel</CODE> module places a value directly in VAL.

If the INP link type is constant, the double constant, if non-zero, is converted to a string and stored into VAL by init_record, and UDF is set to FALSE. If the INP link type is PV_LINK, then dbCaAddInlink is called by init_record.

read_stringin 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_stringin sets UDF to FALSE. The status of recGblGetLinkValue is returned.

----

EPICS Record Reference Manual - 19 MAY 1998

RRM 3-14 Stepper Motor

2008-04-18T20:00:24Z

KazimierzGofron:

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

= steppermotor - Stepper Motor =

The stepper motor record controls and monitors stepper motors. The stepper motor can be controlled in either ''position'' mode or ''velocity'' mode. Position mode moves a device to a position. Velocity mode causes the motor to revolve continuously.

The record is set up assuming that the same stepper motor will not be used in both velocity and position mode. The fields for the stepper motor record fall into the following categories:

* scan parameters
* setup parameters
* desired output parameters
* output and readback parameters
* operator display parameters
* alarm parameters
* monitor parameters
run-time parameters.

=== Scan Parameters ===

The stepper motor record has the standard fields for specifying under what circumstances the record will be processed. A motor record that is scanned periodically or on event will compare its actual position to the desired position and will attempt to achieve its position. It will only make a certain number of attempts; the number of attempts is specified in the retry (RTRY) field. A passive motor will not go through the retry logic.

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.

=== Setup Parameters ===

The set-up parameters determine how the stepper motor is initialized and how it operates at run-time.

The MODE field has two choices: <CODE>Velocity</CODE> or <CODE>Position</CODE>.

The VELO field determines the velocity that the stepper motor will run at when in the velocity mode. In position mode, it determines the pulses per second to move when it moves to a new position.

The ACCL field determines the acceleration of the motor by specifying a number of seconds. In velocity mode, the stepper motor will accelerate at the rate needed to reach the operating velocity in the number of seconds specified in ACCL. In positional mode, ACCL determines the seconds the stepper motor will take to reach the specified velocity, and the number of seconds it will take to come to a stop at the new position.

The MRES field specifies the number of pulses per revolution for the stepper motor, while ERES specifies the encoder pulses per revolution.

The DIST field's value determines the distance which the stepper motor moves for each pulse in engineering units.

The RTRY field specifies the number of attempts the record will make to reach the desired position each time it's processed, and the RDBD field specifies a deadband for this processing. Thus, when the motor is moving in a positive direction, no retries will be attempted unless the readback value is greater than VAL added to the value in the RDBD field. If the motor is moving in the negative direction, no retries will be attempted unless the readback value is less than VAL added to the value in the RDBD field:

; if direction positive and RBV > (VAL + RDBD)
: attempt to correct position <EM>RTRY</EM> times
; if direction negative and RBV < (VAL + RDBD)
: attempt to correct position <EM>RTRY</EM> times

The initialization algorithm (IALG) field has three algorithms to choose from: <CODE>No Initialization</CODE>, <CODE>Move to the Positive Limit</CODE>,<CODE> </CODE>and<CODE> Move to the Negative Limit</CODE>. The IVAL field determines the value of VAL at initialization; i.e., VAL is initialized to the value in IVAL when IALG is either Move to Positive or Move to Negative.

<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>ACCL<TD> Seconds to Reach Velocity<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>VELO<TD> Velocity in Pulses per Second<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DIST<TD> Distance in Engineering Units of 1 Pulse<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>IVAL<TD> Initial Value<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>MODE<TD> Mode--Position/Velocity<TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>IALG<TD>Initialization Algorithm<TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>RTRY<TD>Number Of Retries Before Failure<TD>SHORT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>RDBD<TD>Retry Deadband<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>MRES<TD>Motor Pulses per Revolution<TD>USHORT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>ERES<TD>Encoder Pulses per Revolution<TD>USHORT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Desired Output Parameters ===

The stepper motor record specifies where the desired output originates in the DOL field. The desired output needs to be in engineering units. If the output is controlled by the operator or a sequence program, nothing should be entered in the DOL field.

The desired output link (DOL) and operation mode select (OMSL) fields work as they do for output records. If OMSL is <CODE>closed_loop</CODE>, the desired output (VAL) is fetched from the DOL link, which can be a database or channel access link. If <CODE>supervisory</CODE>, VAL can be changed via dbPuts. DOL can be a constant, in which case VAL is initialized to the constant. If DOL is a constant, OMSL cannot specify <CODE>closed_loop</CODE>. See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on specifying links.

VAL indicates the position of the stepper motor in position mode; in velocity mode, it indicates the current velocity. When the desired output is retrieved and placed in VAL, it is forced to be within the drive limits configured in the DRVH and DRVL fields. The DRVH and DRVL fields must be given values by the user. Note: If nothing is entered in the DRVH and DRVL fields, the motor will not move. The <CODE>get_control_double()</CODE> record support routine returns the values in these fields when it is called.

<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 <TD>FLOAT<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<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
</TABLE>

=== Output and Readback Parameters ===

In the OUT output link field, the user must enter the address of the I/O card of the device, and in the DTYP field, the user must enter the name of the appropriate stepper motor 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 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.

The RDBL field can contain the address of an encoder or an external device, such as an LDVT, or it can specify the motor position field (MPOS) or the encoder position field (EPOS) in the same record. In the case of an external readback, the value would be read through an analog input record and linked to this record through this field. The value retrieved from this field is placed into the RBV 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>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>RDBL<TD>Read Back Location (an input link)<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>RBV<TD>Read Back Value <TD>FLOAT<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No
</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 stepper motor either textually or graphically.

EGU is a string of up to 16 characters describing the engineering units of VAL. 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, LOLO, MPOS, EPOS, RBV, and LVAL fields. Only the <CODE>get_graphic_double</CODE> record support routine retrieves 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 the VAL and LVAL fields. 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> <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 stepper motor records are the SCAN, READ, and limit alarms. The SCAN and READ alarms are called by the record or device support routines and are always of MAJOR severity.

The limit alarms are configured by the user in the HIHI, LOLO, HIGH, and LOW fields using numerical values. The conditions apply to the VAL and RBV fields of the stepper motor record. For each of these fields, there is a corresponding severity field which can specify either NO ALARM, MINOR, or MAJOR. The user can specify a deadband around these limits in the HYST or hysteresis field. See [[RRM 3-14 Concepts#Alarm Specification|Alarm Specification]] for a complete explanation of analog 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 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 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.

<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 by the user before run-time, but most of them can be modified after initialization.

The STHM field will set the current position of the motor to its home or zero position when this field is set to 1 via a dbPut. Its value is automatically reset to 0 after the command is accepted.

Setting the STOP field to 1 will cause the motor to stop moving. Its value is also reset to 0 after the command is accepted.

The DMOV field is a flag which indicates if the motor is done moving and all retries are complete. It is significant only while the record is in POSITION mode. It will be 1 if TRUE and 0 if FALSE.

The RVAL field contains the value which is actually written to output after it is forced in the drive limits.

The RBV and RRBV fields contain the value retrieved from the readback location link (RDBL).

The MOVN field indicates whether the motor is currently moving. It will contain a 1 if moving or a 0 if not moving. The DIR field indicates which direction the record is moving--a 0 means clockwise and a 1 means counter clockwise.

The CW and CCW fields contain the values for the clockwise and counterclockwise limit switches, respectively. The MCW and MCCW fields will be 1 if the limit has been reached or 0 if not.

The CVEL field indicates whether the motor is at constant velocity. If so, the value of this field is 1.

The RCNT field will indicate the current number of retries that have been attempted.

The POSM field will contain a 1 if the motor is moving in a positive direction and a 0 if otherwise.

The MISS field holds the error after the first attempt has been made to change the stepper motor's position, the error being the difference between VAL and RBV, the readback value. If monitors are present, the value is posted.

The EPOS field holds the value obtained from encoder readback. The MPOS holds the readback value of the motor positions.

The MLST and ALST fields are used to implement monitors on the VAL field. If the difference between one of these fields and the VAL field exceeds the appropriate deadband (MDEL, for instance) monitors are triggered.

The LVEL, LACC, and LVAL fields contain the last values set for the VELO, ACCL, and VAL fields respectively. They are used to determine when the velocity and acceleration should be recalculated.

The CMOD or current mode fields indicates which mode, position or velocity, the record is using.

<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>STHM<TD>Set Home<TD>SHORT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>STOP<TD>Stop<TD>SHORT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>DMOV<TD>Done Moving to Value<TD>SHORT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>RVAL<TD> Raw Data Value <TD>LONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>RRBV<TD>Raw Read Back Value<TD>LONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>INIT<TD>Initialize<TD>SHORT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>MOVN <TD>Moving Status<TD>SHORT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DIR<TD>Current Direction<TD>SHORT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>MCW<TD>Motor Clockwise Limit Switch Value<TD>SHORT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>MCCW<TD>Motor Counter Clockwise Limit Switch Value<TD>SHORT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>CW <TD>Clockwise Limit<TD>SHORT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>CCW<TD>Counter Clockwise Limit<TD>SHORT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>CVEL<TD>Constant Velocity<TD>SHORT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>RCNT<TD>Current Retry Count<TD>SHORT<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>POSM<TD> Positive Motion<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>Yes<TD>No<TR>
<TD>MISS<TD>First Attempt Error <TD>FLOAT<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>EPOS <TD>Encoder Read Back Position <TD>FLOAT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>MPOS<TD> Motor Position <TD>FLOAT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>ALST<TD>Archive Last Value <TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>MLST<TD>Monitor Last Value<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LVEL<TD>Last Velocity Set<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>LACC<TD>Last Acceleration Set<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>LVAL<TD> Last Value <TD>SHORT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>CMOD<TD>Current Mode <TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

== Record Support ==

=== Record Support Routines ===

==== init_record ====

This routine checks to see that device support is available. The routine next checks to see if the device support <CODE>sm_command</CODE> 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 device support includes <CODE>init_record</CODE>, it is called.

If DOL is a constant, then VAL is initialized with its value and UDF is set to FALSE. If DOL is a PV_LINK then a channel access link is created.

init_sm is then called.

==== init_sm ====

The init_sm routine initializes the stepper motor according to its configuration.

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

==== get_graphic_double ====

Sets the upper display and lower display limits for a field. If the field is VAL, LVAL, MPOS, RBV, EPOS, 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, LVAL, MPOS, RBV, EPOS, HIHI, HIGH, LOW, or LOLO, the limits are set to DRVH and DRVL. 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 ===

Description not available.

== Device Support ==

At the present time, device support is intimately connected to record support. The compumotor 1830 and the OMS 6 axis controllers are supported.

----

EPICS Record Reference Manual - 19 MAY 1998

RRM 3-14 State

2008-04-18T19:59:42Z

KazimierzGofron:

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

= State =

The state record is a means for a state program to communicate with the operator interface. Its only function is to provide a place in the database through which the state program can inform the operator interface of its state by storing an arbitrary ASCII string in its VAL field.

== Parameter Fields ==

The state record fields fall into the following categories:

* scan parameters
* operator display parameters
* other parameters

=== Scan Parameters ===

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

=== Operator Display Parameters ===

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>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 state 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 parameters are used by the application code to convey the state of the program to the operator interface. The VAL field holds the string retrieved from the state program. The OVAL is used to implement monitors for the VAL field. When the string in OVAL differs from the one in VAL, monitors are triggered. They represent the current state of the sequence program.

<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>STRING [20]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>OVAL<TD>Old Value<TD>STRING [20]<TD>No<TD>Null<TD>Yes<TD>No<TD> <TD> 
</TABLE>

== Record Support ==

=== Record Support Routines ===

Two record support routines are provided:

==== process ====

process triggers monitors on VAL when it changes and scans the forward link if necessary.

==== get_value ====

get_value fills in struct valueDes so that it refers to VAL.

----

EPICS Record Reference Manual - 19 MAY 1998

RRM 3-14 Sequence

2008-04-18T19:58:40Z

KazimierzGofron:

[[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 71<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 Select

2008-04-18T19:51:45Z

KazimierzGofron:

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

= sel - Select =

The select record computes a value based on input obtained from up to 12 locations. The selection algorithm can be one of the following: <CODE>Specified</CODE>, <CODE>High Signal</CODE>, <CODE>Low Signal</CODE>, <CODE>Median Signal</CODE>. Each input can be a constant, a database link, or a channel access link.

== Parameter Fields ==

The fields in this record fall into several categories:

* scan parameters
* read parameters
* select parameters
* operator display parameters
* alarm parameters
* monitor parameters
* run-time parameters

=== Scan Parameters ===

The select 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 work.

=== Read Parameters ===

The INPA-L links determine where the selection record retrieves the values from which it is to select or compute its final value. The INPA-L links are input links configured by the user to be either constants, channel access links, or database links. If channel access or database links, a value is retrieved for each link and placed in the corresponding value field, A-L. If any input link is a constant, the value field for that link will be initialized with the constant value given to it and can be modified via dbPuts. See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on how to specify database links.

Any links not defined are ignored by the selection record and its algorithm. An undefined link is any constant link whose value is 0. At initialization time, the corresponding value links for such fields are set equal to le30, which means MISSING. The value field of an undefined link can be changed at run-time from the MISSING value to another value in order to define the link and its field. Note that all undefined links must be recognized as such if the selection algorithm is to work as expected.

<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>Input A Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>B<TD>Input B Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>C<TD>Input C Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>D<TD>Input D Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>E<TD>Input E Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>F<TD>Input F Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>G<TD>Input G Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>H<TD>Input H Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>I<TD>Input I Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>J<TD>Input J Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>K<TD>Input K Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes<TR>
<TD>L<TD>Input L Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TD>Yes
</TABLE>

=== Select Parameters ===

The selection algorithm is determined by three fields configurable by the user: the select mechanism (SELM) field, the select number (SELN) field, and the index value location (NVL) field.

The SELM field has four choices, i.e., four algorithms: <CODE>Specified</CODE>, <CODE>High Signal</CODE>, <CODE>Low Signal</CODE>, and <CODE>Median Signal</CODE>. The selection record's VAL field is determined differently for each algorithm. For <CODE>Specified</CODE>, the VAL field is set equal to the value field (A, B, C, D, E, F, G, H, I, J, K, or L) specified by the SELN field. The SELN field contains a number from 0-11 which corresponds to the value field to be used (0 means use A; 1 means use B, etc.). How the NVL field is configured determines, in turn, SELN's value. NVL is an input link from which a value for SELN can be retrieved, Like most other input links NVL can be a constant, or a channel access or database link. If NVL is a link, SELN is retrieved from the location in NVL. If a constant, SELN is initialized to the value given to the constant and can be changed via dbPuts. See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on how to specify database links.

The <CODE>High Signal</CODE>, <CODE>Low Signal</CODE>, and <CODE>Median Signal</CODE> algorithms do not use SELN or NVL. If <CODE>High Signal</CODE> is chosen, VAL is set equal to the highest value out of all the defined value fields (A-F). If <CODE>Low Signal</CODE> is chosen, VAL is set equal to lowest value of all the defined fields (A-F). And if <CODE>Median Signal</CODE> is chosen, VAL is set equal to the median value of the defined value fields (A-F). (Note that these algorithms select from the value fields; they do not select from the value field index. For instance, <CODE>Low Signal</CODE> will not select the A field's value unless the value itself is the lowest of all the defined values.)

<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>Select Number<TD>USHORT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>NVL<TD>Index Value Location, an input link<TD>INLINK<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 select record either textually or graphically.

EGU is a string of up to 16 characters describing the units that the selection record manipulates. 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.

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> <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 select records are the SCAN, READ, and limit alarms. 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 specify conditions for the VAL field. 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. [[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 fields are configurable by the user. They are used as deadbands for the archiver and monitor calls for the VAL field. Unless, VAL changes by more than the value specified by each, then the respective monitors will not be called. If these fields have a value of zero, everytime the VAL changes, monitors are triggered; if they have a value of -1, everytime the record is processed, monitors are triggered. [[RRM 3-14 Concepts#Monitor Specification|Monitor Specification]] gives a complete explanation of alarms 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 selection record. They are not configurable prior to run-time, nor are they modifiable at run-time. They represent the current state of the record. The record support routines use some of them for more efficient processing.

The VAL field is the result of the selection record's processing. It can be accessed in the normal way by another record or through database access, but is not modifiable except by the record itself. The LALM, ALST, and the MLST are used to implement the HYST, ADEL, and MDEL hysteresis factors for the alarms, archiver, and monitors, respectively.

The LA-LL fields are used to implement the monitors for each of the value fields, A-F. They represent previous input values. For example, unless LA is not equal to A, no monitor is invoked for A.

<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>No<TD>Yes<TD>No<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>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 ====

IF NVL is a constant, SELN is set to its value. If NVL is a PV_LINK a channel access link is created.

For each constant input link, the corresponding value field is initialized with the constant value (or 1e30 if the constant has the value 0).

For each input link that is of type PV_LINK, a channel access link is created.

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

==== 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:

# If NVL is a database or channel access link, SELN is obtained from NVL. Fetch all values if database or channel access links. If SELM is SELECTED, then only the selected link is fetched.
# Implement the appropriate selection algorithm. For SELECT_HIGH, SELECT_LOW, and SELECT_MEDIAN, input fields are ignored if they are undefined. If 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 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 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 Scan

2008-04-18T19:50:57Z

KazimierzGofron:

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

= scan =

: Ned D. Arnold
: Advanced Photon Source
: Argonne National Laboratory

== Introduction ==

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

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

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

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

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

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

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

=== A Simple Single Dimensional Scan ===

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

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

<H5 ID="Figure_1">Figure 1: Typical Database Support for a SCAN</H5>

[[Image:RRM 3-14 Scan-1.gif|Figure 1]]

=== Two Dimensional Scanning ===

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

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

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

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

<H5 ID="Figure_2">Figure 2: A Two Dimensional Scan</H5>

[[Image:RRM 3-14 Scan-2.gif|Figure 2]]

== Parameter Fields ==

=== Scan Parameters ===

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

==== Positioner Parameters ====

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

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

<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>P1SM<TD>Positioner 1 Step Mode<TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>P2SM<TD>Positioner 2 Step Mod<TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>P3SM<TD>Positioner 3 Step Mode<TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>P4SM<TD>Positioner 4 Step Mode<TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

==== Linear Mode Parameters ====

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

<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>NPTS<TD>Number of Points <TD>SHORT<TD>Yes<TD>100<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>MPTS<TD>Maximum Number of Points<TD>SHORT<TD>Yes<TD>100<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>P1SP<TD>Positioner 1 Starting Point<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>P2SP<TD>Positioner 2 Starting Point<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>P3SP<TD>Positioner 3 Starting Point<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>P4SP<TD>Positioner 4 Starting Point<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>P1EP<TD>Positioner 1 Ending Point<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>P2EP<TD>Positioner 2 Ending Point<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>P3EP<TD>Positioner 3 Ending Point<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>P4EP<TD>Positioner 4 Ending Point<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>P1CP<TD>Positioner 1 Center Point<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>P2CP<TD>Positioner 2 Center Point<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>P3CP<TD>Positioner 3 Center Point<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>P4CP<TD>Positioner 4 Center Point<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>P1WD<TD>Positioner 1 Width<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>P2WD<TD>Positioner 2 Width<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>P3WD<TD>Positioner 3 Width<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>P4WD<TD>Positioner 4 Width<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>P1SI<TD>Positioner 1 Step Increment<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>P2SI<TD>Positioner 2 Step Increment<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>P3SI<TD>Positioner 3 Step Increment<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>P4SI<TD>Positioner 4 Step Increment<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No
</TABLE>

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

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

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

<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>FPTS<TD>Freeze Flag for NPTS<TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>1<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>FFO<TD>Freeze Flag Override<TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>P''n''FS<TD>Positioner ''n'' Freeze Flag for P''n''SP<TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>1<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>P''n''FE<TD>Positioner ''n'' Freeze Flag for P''n''EP<TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>P''n''FI<TD>Positioner ''n'' Freeze Flag for P''n''SI<TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>1<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>P''n''FC<TD>Positioner ''n'' Freeze Flag for P''n''CP<TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>P''n''FW<TD>Positioner ''n'' Freeze Flag for P''n''WD<TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

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

==== Lookup Mode Parameters ====

For those positioners using the linear mode, each desired position value (contained in the P''n''DV fields) is placed in the arrays referenced by the P''n''PA fields that are used for the lookup mode. Therefore, after the scan is complete, these arrays will always contain the sequence of positions to which the controller was commanded by the linear algorithm. For look-up mode, the user provides the values for the P''n''PA arrays prior to run-time. These arrays will contain no useful data if on-the-fly mode is 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>P1PA<TD>Positioner 1 Position Array<TD>FLOAT[ ]<TD>No<TD>Null<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>P2PA<TD>Positioner 2 Position Array<TD>FLOAT[ ]<TD>No<TD>Null<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>P3PA<TD>Positioner 3 Position Array<TD>FLOAT[ ]<TD>No<TD>Null<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>P4PA<TD>Positioner 4 Position Array<TD>FLOAT[ ]<TD>No<TD>Null<TD>Yes<TD>Yes<TD>Yes<TD>No
</TABLE>

==== Position Verification, Readback Process Variable, and Delta Parameters ====

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

<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>R1PV<TD>Readback 1 Process Variable <TD>STRING [40]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>R2PV<TD>Readback 2 Process Variable <TD>STRING [40]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>R3PV<TD>Readback 3 Process Variable <TD>STRING [40]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>R4PV<TD>Readback 4 Process Variable <TD>STRING [40]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>R1DL<TD>Readback 1 Delta <TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>R2DL<TD>Readback 2 Delta <TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>R3DL<TD>Readback 3 Delta <TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>R4DL<TD>Readback 4 Delta <TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

==== Detector Trigger Process Variables and Desired Command ====

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

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

<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>T1PV<TD>Detector Trigger 1 Process Variable <TD>STRING [40]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>T2PV<TD>Detector Trigger 2 Process Variable <TD>STRING [40]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>T1CD<TD>Trigger 1 Command<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>T2CD<TD> Trigger 2 Command<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Data Acquisition Parameters ===

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

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

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

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

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

<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>D1PV<TD>Data 1 Process Variable <TD>STRING [40]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>D2PV<TD>Data 2 Process Variable <TD>STRING [40]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>D3PV<TD>Data 3 Process Variable <TD>STRING [40]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>D4PV<TD>Data 4 Process Variable <TD>STRING [40]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>EXSC<TD>Execute Scan Flag<TD>SHORT<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>D1DA<TD>Detector 1 Data Array<TD>FLOAT[ ]<TD>No<TD>Null<TD>Yes<TD>No<TD>Yes<TD>No<TR>
<TD>D2DA<TD>Detector 2 Data Array<TD>FLOAT[ ]<TD>No<TD>Null<TD>Yes<TD>No<TD>Yes<TD>No<TR>
<TD>D3DA<TD>Detector 3 Data Array<TD>FLOAT[ ]<TD>No<TD>Null<TD>Yes<TD>No<TD>Yes<TD>No<TR>
<TD>D4DA<TD>Detector 4 Data Array<TD>FLOAT[ ]<TD>No<TD>Null<TD>Yes<TD>No<TD>Yes<TD>No
</TABLE>

=== Operator Display Parameters ===

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

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

* An Engineering Units Field (P1EU-P4EU, D1EU-D4EU), which has a string that is given to it by the user.
* A Precision Field (P1PR-P4PR, D1PR-D4PR), which holds an integer that controls the decimal precision that the corresponding field is displayed with. For instance, P1PR controls the decimal precision for positioner 1 array elements.
See [[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>P1EU<TD>Positioner 1 Eng. Units<TD>STRING [16]<TD>Yes<TD>16<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>P1HR<TD>Pos. 1 High Range<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>P1LR<TD>Pos. 1 Low Range<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>P1PR<TD>Pos. 1 Precision<TD>SHORT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>P2EU<TD>Pos. 2 Eng Units<TD>STRING [16]<TD>Yes<TD>16<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>P2HR<TD>Pos. 2 High Range<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>P2LR<TD>Pos. 2 Low Range<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>P2PR<TD>Pos. 2 Precision<TD>SHORT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>P3EU<TD>Pos. 3 Eng Units<TD>STRING [16]<TD>Yes<TD>16<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>P3HR<TD>Pos. 3 High Range<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>P3LR<TD>Pos. 3 Low Range<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>P3PR<TD>Pos. 3 Precision<TD>SHORT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>P4EU<TD>Pos. 4 Eng Units<TD>STRING [16]<TD>Yes<TD>16<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>P4HR<TD>Pos. 4 High Range<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>P4LR<TD>Pos. 4 Low Range<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>P4PR<TD>Pos. 4 Precision<TD>SHORT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>D1EU<TD>Detector 1 Eng. Units<TD>STRING [16]<TD>Yes<TD>16<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>D1HR<TD>Det. 1 High Range<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>D1LR<TD>Det. 1 Low Range<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>D1PR<TD>Det. 1 Precision<TD>SHORT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>D2EU<TD>Det. 2 Eng. Units<TD>STRING [16]<TD>Yes<TD>16<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>D2HR<TD>Det. 2 High Range<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>D2LR<TD>Det. 2 Low Range<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>D2PR<TD>Det. 2 Precision<TD>SHORT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>D3EU<TD>Det. 3 Eng. Units<TD>STRING [16]<TD>Yes<TD>16<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>D3HR<TD>Det. 3 High Range<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>D3LR<TD>Det. 3 Low Range<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>D3PR<TD>Det. 3 Precision<TD>SHORT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>D4EU<TD>Det. 4 Eng. Units<TD>STRING [16]<TD>Yes<TD>16<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>D4HR<TD>Det. 4 High Range<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>D4LR<TD>Det. 4 Low Range<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>D4PR<TD>Det. 4 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>

=== Run-time Parameters ===

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

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

The VAL field is not used.

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

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

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

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

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

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

<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>VERS<TD>Code Version<TD>FLOAT<TD>No<TD>1.0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>VAL<TD>Value Field <TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>SMSG<TD>State Message <TD>STRING [40]<TD>No<TD>Null<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>CMND<TD>Command Field<TD>ENUM<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>ALRT<TD>Alert Field <TD>UCHAR<TD>No<TD>0<TD>Yes<TD>No<TD>Yes<TD>No<TR>
<TD>RPVT<TD>Record Private <TD>NOACCESS<TD>No<TD>Null<TD>No<TD>No<TD>No<TD>No<TR>
<TD>PXSC<TD>Previous Execute Scan<TD>UCHAR<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>CPT<TD>Current Point<TD>SHORT<TD>No<TD>0<TD>Yes<TD>No<TD>Yes*<TD>No<TR>
<TD>PCPT<TD>Previous Current Point <TD>SHORT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>TOLP<TD>Time of Last Posting <TD>ULONG<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>P1NV<TD>Pos. 1 Name Valid<TD>LONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>P2NV<TD>Pos. 2 Name Valid<TD>LONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>P3NV<TD>Pos. 3 Name Valid<TD>LONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>P4NV<TD>Pos. 4 Name Valid<TD>LONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>R1NV<TD>Readback 1 Name Valid<TD>LONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>R2NV<TD>Rbk. 2 Name Valid<TD>LONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>R3NV<TD>Rbk. 3 Name Valid<TD>LONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>R4NV<TD>Rbk. 4 Name Valid<TD>LONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>T1NV<TD>Trigger 1 Name Valid<TD>LONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>T2NV<TD>Trigger 2 Name Valid<TD>LONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>D1NV<TD>Data 1 Name Valid<TD>LONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>D2NV<TD>Data 2 Name Valid<TD>LONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>D3NV<TD>Data 3 Name Valid<TD>LONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>D4NV<TD>Data 4 Name Valid<TD>LONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>P1DV<TD>Pos. 1 Desired Value<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>Yes*<TD>No<TR>
<TD>P1LV<TD>Pos. 1 Last Value<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>R1CV<TD>Readback 1 Current Value<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>Yes*<TD>No<TR>
<TD>R1LV<TD>Readback 1 Last Value<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>P2DV<TD>Pos. 2 Desired Value<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>Yes*<TD>No<TR>
<TD>P2LV<TD>Pos. 2 Last Value<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>R2CV<TD>Readback 4 Current Value<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>Yes*<TD>No<TR>
<TD>R2LV<TD>Readback 2 Last Value<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>P3DV<TD>Pos. 3 Desired Value<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>Yes*<TD>No<TR>
<TD>P3LV<TD>Pos. 3 Last Value<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>R3CV<TD>Readback 4 Current Value<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>Yes*<TD>No<TR>
<TD>R3LV<TD>Readback 3 Last Value<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>P4DV<TD>Pos. 4 Desired Value<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>Yes*<TD>No<TR>
<TD>P4LV<TD>Pos. 4 Last Value<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>R4CV<TD>Readback 4 Current Value<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>Yes*<TD>No<TR>
<TD>R4LV<TD>Readback 4 Last Value<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>D1CV<TD>Detector 1 Current Value<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>Yes*<TD>No<TR>
<TD>D1LV<TD>Detector 1 Last Value<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>D2CV<TD>Detector 2 Current Value<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>Yes*<TD>No<TR>
<TD>D2LV<TD>Detector 2 Last Value<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>D3CV<TD>Detector 3 Current Value<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>Yes*<TD>No<TR>
<TD>D3LV<TD>Detector 3 Last Value<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>D4CV<TD>Detector 4 Current Value<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>Yes*<TD>No<TR>
<TD>D4LV<TD>Detector 4 Last Value<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>P1DB<TD>Pos. 1 dbAddr<TD>NOACCESS<TD>No<TD>Null<TD>No<TD>No<TD>No<TD>No<TR>
<TD>P2DB<TD>Pos. 2 dbAddr<TD>NOACCESS<TD>No<TD>Null<TD>No<TD>No<TD>No<TD>No<TR>
<TD>P3DB<TD>Pos. 3 dbAddr<TD>NOACCESS<TD>No<TD>Null<TD>No<TD>No<TD>No<TD>No<TR>
<TD>P4DB<TD>Pos. 4 dbAddr<TD>NOACCESS<TD>No<TD>Null<TD>No<TD>No<TD>No<TD>No<TR>
<TD>R1DB<TD>Readback 1 dbAddr<TD>NOACCESS<TD>No<TD>Null<TD>No<TD>No<TD>No<TD>No<TR>
<TD>R2DB<TD>Readback 2 dbAddr<TD>NOACCESS<TD>No<TD>Null<TD>No<TD>No<TD>No<TD>No<TR>
<TD>R3DB<TD>Readback 3 dbAddr<TD>NOACCESS<TD>No<TD>Null<TD>No<TD>No<TD>No<TD>No<TR>
<TD>R4DB<TD>Readback 4 dbAddr<TD>NOACCESS<TD>No<TD>Null<TD>No<TD>No<TD>No<TD>No<TR>
<TD>T1DB<TD>Trigger 1 dbAddr<TD>NOACCESS<TD>No<TD>Null<TD>No<TD>No<TD>No<TD>No<TR>
<TD>T2DB<TD>Trigger 2 dbAddr<TD>NOACCESS<TD>No<TD>Null<TD>No<TD>No<TD>No<TD>No<TR>
<TD>D1DB<TD>Detector 1 dbAddr<TD>NOACCESS<TD>No<TD>Null<TD>No<TD>No<TD>No<TD>No<TR>
<TD>D2DB<TD>Detector 2 dbAddr<TD>NOACCESS<TD>No<TD>Null<TD>No<TD>No<TD>No<TD>No<TR>
<TD>D3DB<TD>Detector 3 dbAddr<TD>NOACCESS<TD>No<TD>Null<TD>No<TD>No<TD>No<TD>No<TR>
<TD>D4DB<TD>Detector 4 dbAddr<TD>NOACCESS<TD>No<TD>Null<TD>No<TD>No<TD>No<TD>No
</TABLE>

----

EPICS Record Reference Manual - 19 MAY 1998

RRM 3-14 String Calcout

2008-04-18T19:50:14Z

KazimierzGofron:

[[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>IVOV</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>IVOA</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 Pulse Train

2008-04-18T19:49:21Z

KazimierzGofron:

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

= pulseTrain =

The normal use for the pulseTrain record type is to generate a pulse train for output.

== Parameter Fields ==

The fields fall into the following categories:

* scan parameters
* trigger parameters
* pulse parameters
* output parameters
* operator display parameters
* run-time parameters

=== Scan Parameters ===

The pulseTrain record has the standard fields for specifying under what circumstances the 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.

=== Trigger Parameters ===

These fields determine the source of the trigger for each train. At least the gate type (GTYP) field must be configured by the user. It can be either <CODE>Hardware</CODE> or <CODE>Software</CODE>. If <CODE>Hardware</CODE>, then the triggers are device dependent, and the HGV field determines gating control, HGV being device dependent.

If the user configures GTYP to be software, then the soft gate value (SGV) field provides gating control. This field has the same possible values as HGV, <CODE>Active</CODE> and <CODE>Inactive</CODE>, triggering a pulse when <CODE>Active</CODE>, or not triggering a pule when <CODE>Inactive</CODE>. The SGV value can be retrieved from the location specified in the Soft Gate Location (SGL) field, which must be a database link.

The CEDG, CTYP, ECS, and ECR field may not have significance for all device support modules. For the modules they apply to, they control the timing of pulses. The CEDG field determines whether clock timing occurs on the rising edge or falling edge of a signal. It has two choices: <CODE>Rising Edge</CODE> or <CODE>Falling Edge</CODE>. The CTYP field determines whether the timing is controlled externally or internally and has two choices: <CODE>Internal</CODE> and <CODE>External</CODE>. The ECS and ECR fields have significance only if CTYP specifies <CODE>External</CODE>.

<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>GTYP<TD>Gate Type <TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>HGV <TD>Hardware Gate Value<TD>SHORT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>SGL<TD>Soft Gate Location (Input Link)<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>SGV<TD>Soft Gate Value <TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>CTYP<TD> Clock Type <TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>CEDG<TD>Clock Signal Edge<TD>RECCHOICE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>ECS<TD>External Clock Source<TD>SHORT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>ECR<TD>External Clock Rate, in Hz<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Pulse Parameters ===

These parameters characterize the pulse train. The pulse train is characterized by the time duration of the entire train, which the user specifies in the Period (PER) field, and the percentage of that time when the signal is high, which the user specifies in the Duty Cycle (DCY) field. In the UNIT field, the user must specify the units of time which the time period is in. This field can be either <CODE>Seconds</CODE>, <CODE>Milliseconds</CODE>, <CODE>Microseconds</CODE>, <CODE>Nanoseconds</CODE>, or <CODE>Picoseconds</CODE>.

<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>UNIT<TD>Units of time<TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD> PER<TD>Period, in UNITs <TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>DCY<TD>Duty Cycle, percent <TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No
</TABLE>

=== Output Parameters ===

The OUT field contains the location where the pulse train record sends the actual pulse. If the pulseTrain uses hardware device support, it must specify the address of the I/O card, and the DTYP field must specify the appropriate 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 dbst utility in R3.13.

For records that use soft device support, OUT can be a constant, a database link or a channel access link, though if it's a constant, no output will be written. 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<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>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 pulse train either textually or graphically. The operating range fields (HOPR and LOPR) for the pulse train record apply to the VAL, PER, or OPER fields. They are retrieved when the <CODE>get_graphic_double</CODE> and <CODE>get_control_double</CODE> record support routines are called for that field. The PREC field is used when the <CODE>get_precision</CODE> record routine is called. It is used only for the value in 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>HOPR <TD>High Operating Range<TD>FLOAT<TD>Yes<TD>4.3e+9<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 pulse train 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 ===

The record uses these fields for processing and to implement monitors. The VAL field is not used.

The Old Period (OPER), Old Duty Cycle (ODCY), and Old Soft Gate Value (OSGV) fields are used to implement monitors for the PER, DCY, and SGV fields, respectively. When the current value doesn't equal the old value, 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>OPER<TD>Old Period, in UNITS<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>Yes<TD>Yes<TR>
<TD>ODCY<TD>Old Duty Cycle, percent<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>Yes<TD>Yes<TR>
<TD>OSGV<TD>Old Soft Gate Value<TD>SHORT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>VAL<TD>Value <TD>SHORT<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>LLOW<TD>Low Logic Level <TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

== Record Support ==

=== Record Support Routines ===

==== init_record ====

This routine first checks that device support is available. If SGL is a constant then HGV is initialized with its value or a channel access link is created if SGL type is PV_LINK.

Device support is then checked to see if write_pt is defined.

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_precision ====

Retrieves PREC.

==== get_graphic_double ====

Sets the upper display and lower display limits for a field. If the field is VAL, PER, or OPER 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 or PER 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.

=== 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 SGL is DB_LINK and GTYP is Software, get SGV from SGL. If SGV has changed, save the duty cycle DCY value, call the write_pt routine with duty cycle =0, reset the duty cycle to the saved value, and set alarms if return status not zero. Then set the old soft gate value OSGV to SGV.
# Call write_pt routine. If device support set PACT to TRUE, then return.
# Set UDF to FALSE.
# 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 on PER and DCY are invoked if values have changed.
#* 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 record must have an associated set of device support routines. The primary responsibility of the device support routines is to issue commands to the output device. The device support routines are primarily interested in the following fields:

<TABLE BORDER="1"><TH>Name<TH>Summary<TH>Description<TR>
<TD>UNIT<TD>Units of time<TD>This field will be used to identify the time units used for time fields.<TR>
<TD>OUT<TD>Output Link<TD>This field is used by the device support routines to locate its output.<TR>
<TD>PER<TD>Period, in UNITs<TD>Device support must use PER for pulse period.<TR>
<TD>DCY<TD>Duty Cycle, percent<TD>Device support must use DCY for the percent of time the signal is high.<TR>
<TD>LLOW<TD>Low Logic Level<TD>Device support must use to determine logic low level.<TR>
<TD>CEDG<TD>Clock Signal Edge<TD>This field is used by the device support routines to force counting on leading or falling edge of signal.<TR>
<TD>GTYP<TD>Gate Type <TD rowspan=2>Device support is responsible for using IGV to determine gating control if GTYP is internal, or SGV if GTYP is external.<TR>
<TD>SGV<TD>Soft Gate Value<TR>
<TD>CTYP<TD>Clock Type <TD rowspan=3>If CTYP is external, device support is responsible for using ECR for the clock rate and if CTYP is internal, ECS is the clock source.<TR>
<TD>ECS<TD>External Cocksurely<TR>
<TD>ECR<TD>External Clock Rate, in Hz
</TABLE>

=== Device Support Routines ===

Device support consists of the following routines:

==== report ====

report()

This routine is optional. If provided, it prints a report of all device modules.

==== 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_pt ====

write_pt(precord)

This routine issues commands to the output device. It returns the following values:

* 0: Success.
* Other: Error.

==== Soft Device Support ====

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

----

EPICS Record Reference Manual - 19 MAY 1998

RRM 3-14 Pulse Delay

2008-04-18T19:41:23Z

KazimierzGofron:

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

= pulseDelay =

The normal use for the pulseDelay record type is to generate pulses to be written to a device.

== Parameter Fields ==

The fields fall into the following categories:

* scan parameters
* trigger parameters
* pulse parameters
* output parameters
* operator display parameters
* run-time parameters

=== Scan Parameters ===

The pulse delay 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.

=== Trigger Parameters ===

These fields determine the source for the pulse triggers. Since the pulse delay record is a kind of output record, these fields resemble the desired output parameters of, for example, the analog output record.

The trigger type (TTYP) field determines whether the pulse trigger comes from an external or internal source. Or, differently put, from a hardware source or from a soft trigger source. When TTYP is set to <CODE>Hardware</CODE>, the HTS field becomes the trigger source for the record. The hard device support sets the HTS. When hardware is chosen, the OUT output link must specify a hardware address, and the DTYP field must specify the appropriate device support module.

When software is specified in the TTYP field, the record uses the SGV field to generate pulses. The SGV field generates a pulse when its value is <CODE>Active</CODE>, and generates no pulse when <CODE>Inactive</CODE>. It's value can be manipulated by dbPuts at run-time, or else a value for STV can be retrieved from the soft trigger location (STL) field, an input link which must be a database link if STV is used.

The GATE field can either enable or disable the generation of pulses. When GATE is 0, no pulses are triggered. When GATE is 1, pulses are triggered according to the record's configuration. A value for GATE can be read from the GLNK field, an input link which can be a constant, database link, or a channel access link. When a constant, GATE is initialized to the constant value. Otherwise, a value for GATE is fetched from the location specified in GLNK each time the record is processed.

The CEDG, CTYP, ECS, and ECR field may not have significance for all device support modules. For the modules they apply to, they control the timing of pulses. The CEDG field determines whether clock timing occurs on the rising edge or falling edge of a signal. It has two choices: <CODE>Rising Edge</CODE> or <CODE>Falling Edge</CODE>. The CTYP field determines whether the timing is controlled externally or internally and has two choices: <CODE>Internal</CODE> and <CODE>External</CODE>. The ECS and ECR fields have significance only if CTYP specifies <CODE>External</CODE>.

<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>TTYP<TD>Trigger Type (hardware/Software) <TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>HTS <TD>Hardware Trigger <TD>ENUM<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>STL<TD>Soft Trigger Location (input link)<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>STV<TD> Soft Trigger Value <TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>GATE <TD>Gate for enable/disable of Pulse Generation<TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>1<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>GLNK<TD>Gate Location<TD>INLINK<TD>Yes<TD>0<TD>Yes<TD>No<TD>N/A<TD>No<TR>
<TD>CTYP<TD>Clock Type<TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>CEDG<TD>Clock Signal Edge <TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>ECS <TD>External Clock Source<TD>SHORT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>ECR<TD>External Clock Rate, in Hz<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Pulse Parameters ===

These fields determine the characteristics of the pulse that is generated by the record. The pulse delay (DLY) field is the most important of these fields. In it, the user specifies the time delay, from the trigger edge until the generation of the pulse. In the time units (UNIT) field, the user specifies the units of time that the delay should be in. The UNIT field can specify <CODE>Seconds</CODE>, <CODE>Milliseconds</CODE>, <CODE>Microseconds</CODE>, <CODE>Nanoseconds</CODE>, or <CODE>Picoseconds</CODE>.

The user specifies the time duration of the pulse in the pulse width (WIDE) field, which also uses the UNIT field for its time units.

<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>UNIT<TD>Time units <TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DLY<TD>Pulse Delay, in UNITS of time<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>WIDE<TD>Pulse Width, in UNITS of time<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes
</TABLE>

=== Operator Display Parameters ===

These parameters are used to display the delay value (DLY)and other parameters of the pulse delay either textually or graphically.

The HOPR and LOPR fields set the upper and lower display limits for the VAL, DLY, ODLY, WIDE, and OWID 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 DLY only. 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>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> <TR>
<TD>DESC<TD>Description<TD>STRING [29]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Alarm Parameters ===

The pulse delay 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 by the record for processing and to implement monitors for some of the pulse fields.

The old delay (ODLY) and old width (OWID) fields are used to implement monitors for the DLY and WIDE fields, respectively. If, for instance, the current value of the DLY field differs from the value held in ODLY, monitors are triggered for the DLY field.

The PFLD indicates which of the following fields have changes since the record was last processed: DLY, WIDE, STV, GATE, or HTS. Some devices use PFLD so that adjustments can be made when any of these fields are changed.

The VAl field indicates whether a pulse has been generated since the last time the record was processed. It is <CODE>ACTIVE</CODE> if YES, <CODE>INACTIVE</CODE> if NO.

<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>ODLY<TD> Old Delay<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>OWID<TD>Old Width<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>PFLD <TD>Processing Field<TD>USHORT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>VAL<TD>Value <TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>LLOW<TD>Low Logic Level<TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

== Record Support ==

=== Record Support Routines ===

==== init_record ====

This routine first checks that device support is available. Device support is then checked to see if write_pd is defined.

Next this routine initializes STV with the value of STL if STL type is CONSTANT link or creates a channel access link if STL type is PV_LINK.

GATE is likewise initialized if GLNK is CONSTANT or PV_LINK.

If device support includes init_record, it is called.

==== process ====

See next section.

==== special ====

Sets the PFLD field to indicate if write to DLY, STV, GATE or HTS field caused processing of the record.

==== get_value ====

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

==== get_precision ====

Retrieves PREC.

==== get_graphic_double ====

Sets the upper display and lower display limits for a field. If the field is VAL, DLY, ODLY, WIDE or OWID 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, DLY, ODLY, WIDE or OWID 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.

=== 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.
# The values for STV and GATE are then fetched.
# Call write_pd routine.
# PFLD is reset to zero.
# If device support set PACT to TRUE, then return.
# Set UDF to FALSE.
# 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 on DLY and WIDE are invoked if values have changed.
#* 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 record must have an associated set of device support routines. The primary responsibility of the device support routines is to issue commands to the output device. The device support routines are primarily interested in the following fields:

<TABLE BORDER="1">
<TH>Name<TH>Summary<TH>Description<TR>
<TD>OUT<TD>Output Link<TD>This field is used by the device support routines to locate its output.<TR>
<TD>WIDE<TD>Pulse Width<TD>Device support must use WIDE for pulse width<TR>
<TD>DLY<TD>Pulse Delay<TD>Device support must use DLY for the delay after trigger edge until beginning of pulse.<TR>
<TD>LLOW<TD>Low Logic Level<TD>Device support must use to determine logic low level.<TR>
<TD>UNIT<TD>Time Units<TD>All values that refer to time measure will be in this time unit.<TR>
<TD>VAL<TD>Value<TD>This field will contain a 1 if a trigger occurred since the last time the record was processed if the device supports it.<TR>
<TD>PFLD<TD>Processing Field<TD>This field is used by some devices to indicate if the record was scanned to adjust certain fields such as delay or trigger source. If the device has a destructive read, then changes to these types of fields could write to the device instead of a read and a write.<TR>
<TD>TTYP<TD>Trigger Type<TD>This field is used by the device support routines to force triggering on leading or falling edge of signal if the specified device supports it.<TR>
<TD>HTS<TD>Hardware Trigger Source<TD>This field will be used to set the hardware trigger source if the device supports it.<TR>
<TD>STV<TD>Soft Trigger Source<TD>This field will be used for software to trigger an output delayed pulse if the device supports it.<TR>
<TD>CEDG<TD>Clock Signal Edge<TD>This field is used by the device support routines to force clock timing on leading or falling edge of signal.<TR>
<TD>CTYP<TD>Clock Type<TD rowspan=3>If CTYP is external, device support is responsible for using ECR for the clock rate and if CTYP is internal, ECS is the clock source.<TR>
<TD>ECS<TD>External Clock Source<TR>
<TD>ECR<TD>External Clock Rate
</TABLE>

=== Device Support Routines ===

Device support consists of the following routines:

==== report ====

report()

This routine is optional. If provided, it prints a report of all device modules.

==== 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_pd ====

write_pd(precord)

This routine issues commands to the output device.

----

EPICS Record Reference Manual - 19 MAY 1998

RRM 3-14 Pulse Counter

2008-04-18T19:40:44Z

KazimierzGofron:

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

= pulseCounter =

The normal use for the pulseCounter record type is to record counts and write them to a device.

== Parameter Fields ==

The fields fall into the following categories:

* scan parameters
* setup parameters
* write parameters
* operator display parameters
* run-time parameters

=== Scan Parameters ===

The pulse counter 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.

=== Setup Parameters ===

These parameters control the characteristics of the counter pulse. Normally, the user only needs to configure the gate type (GTYP) field. This field has two choices, <CODE>Hardware</CODE> or <CODE>Software</CODE>. If hardware is chosen, then the HGV field controls gating. The device support routine should set the HGV field.

If GTYP is configured as software, then gating control is determined by the soft gate location (SGL) and soft gate value (SGV) fields. SGL must be a database link; SGV is read from that link. SGV can have two possible values, <CODE>Active</CODE> or <CODE>Inactive</CODE>. <CODE>Active</CODE> causes the command routine (see below section on run-time parameters) to start counting, while <CODE>Inactive</CODE> causes it to stop counting. See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on how to specify database links.

The device support routines should also set the counter size (CSIZ), counter edge (CNTE), and count source (CNTS) fields. Nevertheless, these fields can be configured using a configuration tool. CSIZ can be 16 bit or 32 bit. With 32 bit, two counters are used. The CNTE field determines whether counting occurs on the rising or falling edge of the source signal. It's choices are <CODE>Rising Edge</CODE> or <CODE>Falling Edge</CODE>. The CNTS determines the count source during setup.

Once again, most of these fields are set by the device support routines.

<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>GTYP<TD>Gate Type <TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>SGL <TD>Soft Gate Location (Input Link) <TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>SGV<TD>Soft Gate Value <TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>HGV<TD>Hardware Gate Value<TD>SHORT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>CSIZ<TD>Counter Size<TD>[[RRM 3-14 Menu Choices|RECCHOICE]] <TD>Yes<TD>1<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>CNTE <TD> Count Edge<TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>CNTS <TD> Count Source<TD>SHORT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Write Parameters ===

The output link (OUT) specifies where the pulse counter write its output, i.e., the current, recorded value of the counter (VAL). If the record writes its a value to a device, the OUT output link must specify the address of the I/O card, and the DTYP field must contain the name of the appropriate 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 dbst utility in R3.13.

If the record uses soft device support, then it can be a database or channel access link, or a constant. If it's a constant, no output can be written.

<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>No
</TABLE>

=== Operator Display Parameters ===

These parameters are used to present meaningful data to the operator. The display the value and other parameters of the pulse counter either textually or graphically. The operating range fields (HOPR and LOPR) for the pulse counter record apply only to the VAL field. They are retrieved when the <CODE>get_graphic_double</CODE> and <CODE>get_control_double</CODE> record support routines are 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>HOPR <TD>High Operating Range<TD>FLOAT<TD>Yes<TD>4.3e+9<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 pulse counter 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 parameters are used by the record itself and the device support routines. They are not configurable prior to run-time, and only the CMD and VAL fields are modifiable by a user at run-time.

The CMD field controls the command routines that control the counter. It has five commands:

; <B><CODE>Read</CODE></B>
: Read the current value of the counter
; <B><CODE>Clear</CODE></B>
: Stop and clear the counter, i.e., reset it to zero. Since the Stop command is also invoked, the Start command must be issued to start the counter after this command is invoked.
; <B><CODE>Start</CODE></B>
: Start counting
; <B><CODE>Stop</CODE></B>
: Stop counting. This does not reset the counter.
; <B><CODE>Setup</CODE></B>
: Do not begin counting until Start command is issued.

The VAL field holds the current number of recorded pulses. It is normally set by the read command.

The record support routines and device support routines sometimes use the SCMD field to temporarily store the currently active CMD, after which they change the current, active command in the CMD field. When they are done, they will set the command back to the saved command.

The OSGV field is used to implement monitors for the SGV 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>CMD <TD>Command <TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>SCMD<TD>Save Command<TD>USHORT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>CPTR <TD>Callback <TD>ULONG<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>VAL<TD>Counter Value <TD>ULONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>OSGV <TD>Old Soft Gate Value <TD>SHORT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No
</TABLE>

== Record Support ==

=== Record Support Routines ===

==== init_record ====

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

If SGL is a constant and GTYP is software, then SGV is initialized with its value. If SGL type is PV_LINK a channel access link is created.

Device support is then checked to see if cmd_pc is defined.

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_graphic_double ====

Sets the upper display and lower display limits for a field. If the field is VAL 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 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.

=== Record Processing ===

The 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 SGL is DB_LINK and GTYP is Software, get SGV from SGL. If SGV has changed, save the CMD value, call the command routine with START if SGV =0 or with STOP if SGV is 1, reset the command to the saved value, and set alarms if return status not zero. If the device is not done (PACT TRUE), then issue a callback request for this record to process and return
# If CMD is not READ, call command routine and set CMD to READ. If the device is not done (PACT TRUE), then issue a callback request for this record to process again and return.
# Call command routine. If device support set PACT to TRUE, then return.
# 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 on CMD are invoked if values have changed.
#* 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 record must have an associated set of device support routines. The primary responsibility of the device support routines is to issue commands to the output device. The device support routines are primarily interested in the following fields:

<TABLE BORDER="1">
<TH>Name<TH>Summary<TH>Description<TR>
<TD>CSIZ <TD>Counter size<TD>This will determine to a 16 bit or 32 bit count is to be used. With 32 bit, two counters are used.<TR>
<TD>CMD <TD>Command <TD>The device support routine is responsible for processing the commands READ, CLEAR, START, STOP, and SETUP.<TR>
<TD>GTYP,IGV<TD>Gate Type <TD>If GTYP is internal, device support is responsible for using IGV to determine gating control.<TR>
<TD>CNTE <TD>Count Edge <TD>This field is used by the device support routines to force counting on leading or falling edge of signal.<TR>
<TD>CNTS<TD> Count Source <TD> Device support must use CNTS to set count source during setup.
</TABLE>

=== Device Support Routines ===

Device support consists of the following routines:

==== report ====

report()

This routine is optional. If provided, it prints a report of all device modules.

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

==== cmd_pc ====

cmd_pc(precord)

This routine issues commands to the output device. It returns the following values:

* 0: Success.
* Other: Error.

----

EPICS Record Reference Manual - 19 MAY 1998

RRM 3-14 PID Control

2008-04-18T19:39:11Z

KazimierzGofron:

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

= PID Control =

The PID record is used to maintain a setpoint that affects the output according to the difference between a controlled value and the setpoint. The record reads the controlled value and the setpoint when the record is processed, and then the PID expression computes the result, which is stored in a field (DM) that can be accessed via another record, usually an analog output record.

There are three terms of the PID expression: the proportional, the integral, and the derivative. Using the gain that exists for each of these terms, the user can weight each contribution according to the characteristics of the controlled variable.

== Parameter Fields ==

The fields in this record fall into several categories:

* scan parameters
* controlled variable
* setpoint parameters
* expression parameters
* operator display parameters
* alarm parameters
* monitor parameters
* run-time parameters

=== Scan Parameters ===

The PID record has the standard fields for specifying under what circumstances it will be processed. Note, however, that the integral and derivative parts of the algorithm are affected by the SCAN field, i.e., the scanning algorithm. For Passive, I/O Interrupt, and Event, or a period of 0.1 seconds, the interval is set to 1. For periods of 0.2, 0.5, 1, and 2 seconds, the interval is set to 2, 3, 4, and 5.

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.

The minimum delta time field (MDT) is a processing field particular to the PID record. It can be configured by the user or modified at run-time. It contains a floating point value which represents the minimum amount of time between record processing. If the amount of time between the last time the record was processed an the current time is less than MDT, than the record is not processed. If MDT is left at its default value (0), the minimum delta will be equal to one clock tick.

<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>MDT<TD>Minimum Delta Time<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Controlled Variable Parameters ===

The control variable link field (CVL) is used to obtain the value of the controlled process variable, i.e., the value read into the CVAL field. The link must be a database link. If it is not a database link a MAJOR alarm is triggered when the record is processed. 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<TH>PP<TR>
<TD>CVL<TD>Controlled Value Location (an input link)<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>CVAL<TD>Value of controlled variable<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>YesNo<TD>No<TD>No
</TABLE>

=== Setpoint Parameters ===

The setpoint mode select (SMSL) and the setpoint location (STPL) fields determine where the setpoint value is obtained, which is held in the VAL field. The SMSL and STPL fields work just like the OMSL and DOL fields found in many output records (analog output, binary output, etc.).

The SMSL field has two choices: <CODE>supervisory</CODE> and <CODE>closed_loop</CODE>. When <CODE>supervisory</CODE>, the setpoint, i.e., VAL, can be set via database access. When <CODE>closed_loop</CODE>, the setpoint value is retrieved from the link specified in STPL, which must be a database link. See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on how to specify database links. STML can also be a constant in which case VAL is set equal to the constant value when the record is initialized.

<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>STPL<TD>Setpoint Location (an input link)<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>SMSL<TD>Setpoint 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>Setpoint value<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes
</TABLE>

=== Expression Parameters ===

The discrete form of the PID expression is as follows:

<TABLE>
<TD ROWSPAN=3>M(n) = KP × E(n) + KI × SUMi ( E(i) × dT(n) ) + KD × (
<TD>E(n) - E(n-1)
<TD ROWSPAN=3>) + Mr
<TR>
<TD ALIGN=CENTER>-----------------
<TR>
<TD ALIGN=CENTER>dT(n)
</TABLE>

where

: M(n) = value of manipulated variable at ''n''th instant.
: KP, KI, and KD = Proportional, Integral, Derivative gains set by the user
: E(n) = Error at ''n''th sampling instant
: SUMi = Sum from i=0 to i=n
: dT(n) = Time difference between ''n-1''th instance and ''n''th instance
: Mr = Midrange adjustment

Taking the first difference between instances yields the following equation:

<TABLE>
<TD ROWSPAN=3>delM(n) = KP × (E(n) - E(n-1)) + KI × E(i) × dT(n) + KD × (
<TD>E(n) - E(n-1)
<TD ROWSPAN=3>) - (
<TD>E(n) - E(n-1)
<TD ROWSPAN=3>)
<TR>
<TD ALIGN=CENTER>-----------------
<TD ALIGN=CENTER>-----------------
<TR>
<TD ALIGN=CENTER>dT(n)
<TD ALIGN=CENTER>dT(n-1)
</TABLE>

The terms KP, KI, and KD are the only terms configured by the user. These terms represent the gain for the proportional (KP), integral (KI) and the derivative (KD). A field exists for each of these terms (the KP, KI, and KD fields). KP should be configured according to the characteristics of the controlled variable; KI should be set equal to the number of times that the integral contribution repeats the proportional contribution; and KD should equal the number of minutes until the derivative contribution repeats the proportional contribution.

The PID record calculates the other terms of the expression:

; <B>E(n)</B>
: Error at ''n''th sampling instant, where the Error equals the setpoint minus the value of the controlled variable (VAL - CVAL).
; <B>delM(n)</B>
: This is the end result of the PID expression -- the change in the manipulated value. The DM field holds this value.
; <B>dT(n)</B>
: This is the time difference between n and n-1, between current and last samplings.

The final result of the expression <CODE>delM(n)</CODE> and the other parts of the expression are held in several different run-time fields, which are not configurable prior to run-time, nor modifiable at run-time, but can be accessed so that their values can be used. See [[#Run-time Parameters|Run-time Parameters]] in this chapter for more information on those 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>KP<TD>Proportional Gain<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>KI<TD>Integral Gain, in repeats per minute.<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>KD<TD>Derivative Gain, in repeats per minute<TD>FLOAT<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. They display the setpoint (VAL), the controlled variable (CVAL), the change in manipulated value (DM), and other fields of the PID, either textually or graphically.

EGU is a string of up to 16 characters describing the units of PID's manipulated values measures. It is retrieved by the <CODE>get_units</CODE> record support routine. It must be configured by the user if at all.

The HOPR and LOPR fields set the upper and lower display limits for the VAL, HIHI, HIGH, LOW, LOLO, VAL, and CVAL fields.

The PREC field determines the floating point precision with which to display VAL and CVAL. 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 PID are the SCAN alarm, limit alarms, and an alarm that is triggered when CVL is not a database link. The SCAN and "CVL" alarms are called by the record routines and are always of MAJOR severity.

The limit alarms trigger alarms on the VAL field. They 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. See [[RRM 3-14 Concepts#Alarm Specification|Alarm Specification]] for a complete explanation of alarms and 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>HIHI<TD>Hihi Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LOLO<TD>High Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HIGH<TD>Low Alarm Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LOW<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>LLSV<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>HSV<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>LSV<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>[[RRM 3-14 dbCommon#Alarm Fields|Alarm Fields]] lists other fields related to a alarms that are common to all record types.

=== Monitor Parameters ===

These parameters are used to determine when to send monitors placed on the VAL field. These fields contain values configured by the user. The monitors are sent when the VAL field exceeds the last monitored field (MLST, ALST, and LALM) by the appropriate delta. Otherwise, value change monitors are not called. 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 the delta used for archive monitors, and the MDEL field is the delta for all other types of monitors.

The ODEL field specifies the hysteresis factor for the DM field, the field which holds the manipulated value. Unless the current value of DM is greater than the amount which the user specifies in this field, no monitors will be invoked. If zero, anytime DM is greater than zero, a monitor is triggered. If -1, each time the record is processed, a monitor is triggered. Note that when monitors are called for DM, they are also called for the following fields which comprise the PID expression: P, I, D, CT, DT, ERR, and DERR.

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<TR>
<TD>ODEL<TD>Output deadband<TD>FLOAT<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 PID. They are not configurable prior to run-time. They represent the current state of the PID and/or the terms of the PID expression. Many of them are used to process the PID record more efficiently.

The DM field contains the change in manipulated value, the result of the PID expression (delM(n)). It is an increment which will usually be accessed by the desired output link (DOL) of an analog output record. Since its value represents an increment, the OIF field of the analog output record should be set to <CODE>Incremental</CODE>. There is no output field with which the PID record can itself send output.

The P, I, D, CT, DT, ERR, and DERR fields are used to calculate the PID expression. They are not configurable prior to, nor modifiable during, run-time, but may be of interest when fine tuning the gains of each contribution (KP, KI, KD). The following lists the fields as they relate to the expression:

; <B>ERR</B>
: E(n). Error at current sampling (VAL-CVAL).
; <B>DERR</B>
: E(n) - E(n-1). Difference between current error and error at last sampling.
; <B>P</B>
: This field corresponds to <CODE>KP * DERR</CODE>
; <B>I</B>
: This field corresponds to <CODE>E(n) * dTn * KI</CODE>
; <B>D</B>
: This field corresponds to <CODE>Kp * Kd * (err/dt(n) - derr/dt(n-1))</CODE>

The LALM, ALST, and MLST fields are used by record processing to implement the monitors for this record. These fields hold the values for the VAL field from the last time the record was processed. When the record is processed again the difference between these fields and current value of VAL exceeds the appropriate delta (MDEL for instance), then the appropriate monitors are triggered.

<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>DM<TD>Change in Manipulated Value<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>Yes<TD>No<TR>
<TD>ODM<TD>Old DM. <TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>Yes<TD>No<TR>
<TD>P<TD>Proportional contribution to DM.<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>Yes<TD>No<TR>
<TD>I<TD>Integral contribution to DM.<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>Yes<TD>No<TR>
<TD>D<TD>Derivative contribution to DM.<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>Yes<TD>No<TR>
<TD>CT<TD>Clock ticks when previous process occurred.<TD>ULONG<TD>No<TD>0<TD>Yes<TD>No<TD>Yes<TD>No<TR>
<TD>DT<TD>Time difference in seconds between processing steps.<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>Yes<TD>No<TR>
<TD>ERR<TD>Current error (VAL - CVAL).<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>Yes<TD>No<TR>
<TD>DERR<TD>Delta Error<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>Yes<TD>No<TR>
<TD>LALM<TD>Value when last monitors for alarm were triggered<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>ALST<TD>Value when last monitors for archiver were triggered<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>MLST<TD>Value when last monitors for value changes were triggered<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No
</TABLE>

== Record Support ==

=== Record Support Routines ===

==== init_record ====

If STPL is a constant link, initialize VAL with it's value and set UDF to false.

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

==== get_graphic_double ====

Sets the following values:

upper_disp_limit = hopr
lower_disp_limit = lopr

==== get_control_double ====

Sets the following values

upper_ctrl_limit = hopr
lower_ctrl_limit = lopr

==== 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 CVL is not a database link a major alarm is declared and the algorithm completes.
# The current value of CVAL is obtained from CVL.
# If STPL is a database link and SMSL is CLOSED_LOOP then VAL is obtained from STPL and UDF is set to false.
# The time difference since the last time step is calculated. If it is less than MDT or if no ticks have occurred since the last time the algorithm was executed, process just completes without raising any alarms, checking monitors, or scanning the forward link.
# The new values of P, I, D, OUT, CT, DT, ERR, and DERR are computed.
# 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. It also honors the alarm hysteresis factor (HYST). Thus the value must change by at least HYST before the alarm status and severity changes.
# Checks to see if monitors should be invoked:
#* Alarm Monitors are invoked if ADEL and MDEL conditions are met.
#* Archive and value change monitors are invoked if ODEL conditions are met. If monitors are triggered from DM, they are also triggered for P, I, D, CT, DT, E

----

EPICS Record Reference Manual - 19 MAY 1998

RRM 3-14 Permissive

2008-04-18T19:38:14Z

KazimierzGofron:

[[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 the 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 Multi-Bit Binary Output Direct

2008-04-18T19:37:24Z

KazimierzGofron:

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

= mbboDirect - Multi-Bit Binary Output Direct =

: Johnny Tang, Matthew Bickley, and Chip Watson
: Continuous Electron Beam Accelerator Facility
: Southeastern Universities Research Association

The mbboDirect record performs the opposite function to that of the mbbiDirect record. It accumulates bits (in the fields B0 - BF) as unsigned characters, and converts them to a word which is then written out to hardware. If a bit field is non-zero, it is interpreted as a binary 1. On the other hand, if it is zero, it is interpreted as a binary 0.

== Parameter Fields ==

The mbboDirect record's 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 mbboDirect 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 mbboDirect record, like all output records, must specify where its output originates. The output mode select field (OMSL) 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 DOL field is ignored and the current value of VAL is used. The desired output can be written into the VAL field via dpPuts at run-time when the record is in <CODE>supervisory</CODE> mode. DOL can also be a constant, in which case VAL is initialized to the constant value. Note that OMSL cannot be <CODE>closed_loop</CODE> when DOL is a constant. See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on how to specify database links.

VAL is then converted to RVAL in the routine described in the next section. However, the <CODE>Soft Channel</CODE> device support module for the mbboDirect record writes 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 ===

For records that are to write values to hardware devices, the OUT output link 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 dbst utility in R3.13.

If the mbboDirect record does not use the <CODE>Soft Channel</CODE> device support module, then VAL is converted to RVAL, and RVAL is the actual 16-bit word sent out. RVAL is set equal to VAL and then shifted left by the number of bits specified in the SHFT field (the SHFT value is set by device support and is not configurable by the user). RVAL is then sent out to the location specified in the OUT field.

For mbboDirect records that specify a database link, a channel access link, or a constant, the DTYP field must specify either one of two soft device support routines--<CODE>Soft Channel</CODE> or <CODE>Raw Soft Channel</CODE>. The difference between the two is that <CODE>Soft Channel</CODE> writes the desired output value from VAL directly to the output link while <CODE>Raw Soft Channel</CODE> writes the value from RVAL to the output link after it has undergone the conversion described above. 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<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>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>B0<TD>Bit 0 Value<TD>UCHAR<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>B1<TD>Bit 1 Value<TD>UCHAR<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>B2<TD>Bit 2 Value<TD>UCHAR<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>B3<TD>Bit 3 Value<TD>UCHAR<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>B4<TD>Bit 4 Value<TD>UCHAR<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>B5<TD>Bit 5 Value<TD>UCHAR<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>B6<TD>Bit 6 Value<TD>UCHAR<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>B7<TD>Bit 7 Value<TD>UCHAR<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>B8<TD>Bit 8 Value<TD>UCHAR<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>B9<TD>Bit 9 Value<TD>UCHAR<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>BA<TD>Bit 10 Value<TD>UCHAR<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>BB<TD>Bit 12 Value<TD>UCHAR<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>BC<TD>Bit 13 Value<TD>UCHAR<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>BD<TD>Bit 14 Value<TD>UCHAR<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>BE<TD>Bit 15 Value<TD>UCHAR<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>BF<TD>Bit 16 Value<TD>UCHAR<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes
</TABLE>

=== Operator Display Parameters ===

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>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 mbboDirect records are the SCAN, READ, and INVALID alarms. The SCAN and READ alarms are not configurable by the user since they are always of MAJOR severity. See [[RRM 3-14 Concepts#Alarm Specification|Alarm Specification]] for a complete explanation of Scan and Read alarms.

The IVOA field specifies an action to take when the INVALID alarm is triggered. There are three possible actions: <CODE>Continue normally</CODE>, <CODE>Don't drive outputs</CODE>, or <CODE>Set output to IVOV</CODE>. When <CODE>Set output to IVOV</CODE> is specified and a INVALID alarm is triggered, the record will write the value in the IVOV field to output. See [[RRM 3-14 Common#Invalid Alarm Output Action|Invalid Alarm Output Action]] for more information. [[RRM 3-14 dbCommon#Alarm Fields|Alarm Fields]] lists other fields related to a alarms that are common to all record types.

No fields exist for this record to have state alarms.

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

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

These parameters are used by the run-time code for processing the mbbo Direct record.

MASK is used by device support routine to read the hardware register. Record support sets low order NOBT bits. 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.

<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>No<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 mbboDirect record in the simulation mode. See [[RRM 3-14 Common#Simulation Mode|Simulation Mode]] 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.

==== get_value ====

Fills in the values of struct valueDes so that they refer to 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
#** Set PACT to FALSE
# Convert
#* If PACT is FALSE, compute RVAL
#** Set RVAL = VAL
#** Shift RVAL left SHFT bits
#* Status=write_mbboDirect
# 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 mbboDirect 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_mbboDirect 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>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_mbboDirect ====

write_mbboDirect(precord)

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

* 0: Success.
* Other: Error.

=== Device Support For Soft Records ===

This <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_mbboDirect calls recGblPutLinkValue to write the current value of VAL.

See [[RRM 3-14 Common#Soft Output|Soft Output]].

----

EPICS Record Reference Manual - 19 MAY 1998

RRM 3-14 Multi-Bit Binary Output

2008-04-18T19:36:40Z

KazimierzGofron:

[[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 Direct

2008-04-18T19:35:49Z

KazimierzGofron:

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

= mbbiDirect - Multi-Bit Binary Input Direct =

: Johnny Tang, Matthew Bickley, and Chip Watson
: Continuous Electron Beam Accelerator Facility
: Southeastern Universities Research Association

The mbbiDirect record retrieves a sixteen-bit hardware value and converts it to an array of sixteen unsigned characters, each representing a bit of the word. These fields (B0-B9, BA-BF) are set to 1 if a bit is set, and 0 if not.

This record's operation is similar to that of the multi-bit binary input record, and it has many fields in common with it. This record also has two available soft device support modules--<CODE>Soft Channel</CODE> and <CODE>Raw Soft Channel</CODE>.

== Parameter Fields ==

The fields fall into the following categories:

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

=== Scan fields ===

The mbbiDirect 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 fields ===

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 mbbiDirect 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 INP value but can be changed at run-time via dbPutField or dbPutLink. See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on how to database links.

For records that don't use <CODE>Soft Channel</CODE> device support, 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.
# VAL is set equal to rval.

Each of the fields, B0-BF, represents one bit of the word.

<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>B0<TD>Bit 0 Value<TD>UCHAR<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>B1<TD>Bit 1 Value<TD>UCHAR<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>B2<TD>Bit 2 Value<TD>UCHAR<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>B3<TD>Bit 3 Value<TD>UCHAR<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>B4<TD>Bit 4 Value<TD>UCHAR<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>B5<TD>Bit 5 Value<TD>UCHAR<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>B6<TD>Bit 6 Value<TD>UCHAR<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>B7<TD>Bit 7 Value<TD>UCHAR<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>B8<TD>Bit 8 Value<TD>UCHAR<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>B9<TD>Bit 9 Value<TD>UCHAR<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>BA<TD>Bit 10 Value<TD>UCHAR<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>BB<TD>Bit 12 Value<TD>UCHAR<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>BC<TD>Bit 13 Value<TD>UCHAR<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>BD<TD>Bit 14 Value<TD>UCHAR<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>BE<TD>Bit 15 Value<TD>UCHAR<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>BF<TD>Bit 16 Value<TD>UCHAR<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes
</TABLE>

=== Operator Display Parameters ===

These parameters are used to present meaningful data to the operator.

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>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 multi-bit binary input direct records are the SCAN and READ alarms. These alarms are not configurable by the user since they are always of MAJOR severity. See [[RRM 3-14 Concepts#Alarm Specification|Alarm Specification]] for a complete explanation of Scan and Read alarms. No fields exist for the mbbi direct record to have state alarms.

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

=== Run-time and Simulation Mode Fields ===

These parameters are used by the run-time code for processing the mbbi direct record. They are not configurable prior to run-time.

MASK is used by device support routine to read hardware register. Record support sets low order NOBT bits in MASK. 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.

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

refresh_bits is then called to refresh all the bit fields based on a hardware value.

==== process ====

See next section.

==== get_value ====

Fills in the values of struct valueDes so that they refer to 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#Output Records|Output Records]] for 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_mbbiDirect
#* PACT = TRUE
#* TIME = tsLocalTime
#* If status is 0, then determine VAL
#** Set rval = RVAL
#** Shift rval right SHFT bits
#** Set VAL = RVAL
#** If status is 1, return(0)
#* If status is 2, set status = 0
# 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_mbbiDirect 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 ioEvent scanner.

==== read_mbbiDirect ====

read_mbbiDirect(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 and SHFT.
* 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 direct records not related to actual hardware devices. The INP link type must be either CONSTANT, DB_LINK, or CA_LINK.

==== Soft Channel ====

For this module, read_mbbiDirect 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_mbbiDirect calls recGblGetLinkValue to read the current value of VAL.

See [[RRM 3-14 Common#Input Records|Input Records]] for a further explanation.

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_mbbiDirect 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 Multi-Bit Binary Input

2008-04-18T19:34:59Z

KazimierzGofron:

[[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 Long Output

2008-04-18T19:33:46Z

KazimierzGofron:

[[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 data fanout 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>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. 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 Input

2008-04-18T19:32:48Z

KazimierzGofron:

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

= longin - Long Input =

The normal use for the long input record or "longin" record is to retrieve a long integer value of up to 32 bits. Device support routines are provided to support direct interfaces to hardware. In addition, the <CODE>Soft Channel</CODE> device module is provided to obtain input via database or channel access links or via dbPutField or dbPutLink requests.

== Parameter Fields ==

The fields in this record fall into the following categories:

* scan parameters
* read parameters
* operator display parameters
* alarm parameters
* run-time and simulation mode parameters

=== Scan Parameters ===

The long 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 Parameters ===

The device support routines use the INP field to obtain the record's input. 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. 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 INP can be a constant, a database link, or a channel access link. The value is read directly into VAL. The <CODE>Soft Channel</CODE> device support module is available for longin records. See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on the format of hardware addresses and a database 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>VAL<TD>Value Field<TD>LONG<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>DTYP<TD>Device Type<TD>DEVCHOICE<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD> 
</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 long input either textually or graphically.

EGU is a string of up to 16 characters describing the units that the long input 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>LONG<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>LOPR<TD>Low Operating Range<TD>LONG<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 long inputs are the SCAN, READ, and limit alarms. 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. For each of these fields, there is a corresponding severity field which can be either NO_ALARM, MINOR, or MAJOR. The HYST field can be used to specify a deadband around 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>LONG<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HIGH<TD>High Alarm Limit<TD>LONG<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LOW<TD>Low Alarm Limit<TD>LONG<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LOLO<TD>Lolo Alarm Limit<TD>LONG<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>LONG<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 (see the next section) by the appropriate 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 scanned, 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.

<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>LONG<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>MDEL<TD>Monitor, i.e. value change, Deadband<TD>LONG<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>LONG<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>ALST<TD>Last Archiver Monitor Trigger Value<TD>LONG<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>MLST<TD>Last Value Change Monitor Trigger Value<TD>LONG<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No
</TABLE>

The following fields are used to operate the long input 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>LONG<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.

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.
# 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.
# 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.
#* 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 input record must have an associated set of device support routines. The primary responsibility of the device support routines is to obtain a new input value whenever read_longin 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>VAL<TD>Value Field<TD>This field is set by device support routines.<TR>
<TD>INP<TD>Input Link<TD>This field is used by the device support routines to locate its input.
</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_longin ====

read_longin(precord)

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

* 0: Success. A new value is placed in VAL.
* Other: Error.

=== Device Support For Soft Records ===

The <CODE>Soft Channel</CODE> device support module places a value directly in VAL.

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

<CODE>read_longin</CODE> calls recGblGetLinkValue to read the current value of VAL. See [[RRM 3-14 Common#Soft Input|Soft Input]] for more information

If the return status of <CODE>recGblGetLinkValue</CODE> is zero then read_longin sets UDF to FALSE. read_longin returns the status of <CODE>recGblGetLinkValue</CODE>.

----

EPICS Record Reference Manual - 19 MAY 1998

RRM 3-14 Histogram

2008-04-18T19:16:03Z

KazimierzGofron:

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

= Histogram =

The histogram record is used to store frequency counts of a signal into an array of arbitrary length. The user can configure the range of the signal value that the array will store. Anything outside this range will be ignored.

== Parameter Fields ==

The fields in this record fall into the following categories:

* scan parameters
* read parameters
* operator display parameters
* monitor parameters
* run-time and simulation mode parameters

=== Scanning Parameters ===

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

=== Read Parameters ===

The SVL is the input link where the record reads its value. It can be a constant, a database link, or a channel access link. If SVL is a database or channel access link, then SGNL is read from SVL. If SVL is a constant, then SGNL is initialized with the constant value but can be changed via dbPuts. The <CODE>Soft Channel</CODE> device support module can be specified in the DTYP field. For a list of other device support modules currently supported at the user's local site, use the <CODE>dbst</CODE> utility in R3.13.

The ULIM and LLIM fields determine the usable range of signal values. Any value of SGNL below LLIM or above ULIM is outside the range and will not be stored in the array. In the NELM field the user must specify the array size, e.g., the number of array elements. Each element in the NELM field holds the counts for an interval of the range of signal counts, the range specified by ULIM and LLIM. These intervals are determined by dividing the range by NELM:

(ULIM - LLIM) / NELM.

<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>SVL<TD>Signal Value Location (an input link)<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>SGNL<TD>Signal Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>DTYP<TD>Device Type<TD>DEVCHOICE<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD> <TR>
<TD>NELM<TD>Number of elements in array<TD>USHORT<TD>Yes<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>ULIM<TD>Upper Signal Limit<TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>LLIM<TD>Lower Signal Limit<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. These fields are used to display the value and other parameters of the histogram either textually or graphically. 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>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 Histogram 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.

=== Monitor Parameters ===

The MDEL field implements the monitor count deadband. Only when MCNT is greater than the value given to MDEL are monitors triggered, MCNT being the number of counts since the last time the record was processed. If MDEL is -1, everytime the record is processed, a monitor is triggered regardless.

If SDEL is greater than 0, it causes a callback routine to be called. The number specified in SDEL is the callback routines interval. The callback routine is called every SDEL seconds. The callback routine posts an event if MCNT is greater than 0.

<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>MDEL<TD>Monitor Delta<TD>SHORT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>SDEL<TD>Monitor Seconds Deadband<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD>No
</TABLE>

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

These parameters are used by the run-time code for processing the histogram. They are not configurable by the user prior to run-time. They represent the current state of the record. Many of them are used to process the histogram more efficiently.

The BPTR field contains a pointer to the unsigned long array of frequency values. The VAL field references this array as well. However, the BPTR field is not accessible at run-time.

The MCNT field keeps counts the number of signal counts since the last monitor was invoked.

The WDOG field contains a pointer to the callback control structure and is of no interest to the user.

The collections controls field (CMD) is a menu field with five choices: <CODE>Read</CODE>, <CODE>Clear</CODE>, <CODE>Start</CODE>, <CODE>Stop</CODE>, and <CODE>Setup</CODE>. When <CODE>Read</CODE>, the record retrieves its values and adds them to the signal array. This command will first clear the signal counts which have already been read when it is first invoked. The <CODE>Clear</CODE> command erases the signal counts, setting the elements in the array back to zero. Afterwards, the field is set back to <CODE>Read</CODE>. The <CODE>Start</CODE> command simply causes the record to read signal values into the array. Unlike <CODE>Read</CODE>, it doesn't clear the array first. The <CODE>Stop</CODE> command disables the reading of signal values into the array. The <CODE>Setup</CODE> command waits until the <CODE>start</CODE> or <CODE>read</CODE> command has been issued to start counting.

The CSTA or collections status field implements the CMD field choices by enabling or disabling the reading of values into the histogram array. While FALSE, no signals are added to the array. While TRUE, signals are read and added to the array. The field is initialized to TRUE. The <CODE>Stop</CODE> command is the only command that sets CSTA to FALSE. On the other hand, the <CODE>Start</CODE> command is the only command that sets it to TRUE. Thus, <CODE>Start</CODE> must be invoked after each <CODE>Stop</CODE> command in order to enable counting; invoking <CODE>Read</CODE> will not enable signal counting after <CODE>Stop</CODE> has been invoked.

A typical use of these fields would be to initialize the CMD field to <CODE>Read</CODE> (it is initialized to this command by default), to use the <CODE>Stop</CODE> command to disable counting when necessary, after which the <CODE>Start</CODE> command can be invoked to re-start the signal count.

The WDTH field is a private field that holds the signal width of the array elements. For instance, if the LLIM was configured to be 4.0 and ULIM was configured to be 12.0 and the NELM was set to 4, then the WDTH for each array would be 2. Thus, it is (ULIM - LLIM) / NELM.

<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>BPTR<TD>Buffer Pointer<TD>NOACCESS<TD>No<TD>0<TD>No<TD>No<TD>No<TD>No<TR>
<TD>VAL<TD>Value Field<TD>See BPTR<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>MCNT<TD>Monitor Counts<TD>SHORT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>WDOG<TD>Watchdog Callback<TD>NOACCESS<TD>No<TD>0<TD>No<TD>No<TD>No<TD>No<TR>
<TD>CMD<TD>Collections Control<TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>CSTA<TD>Collections Status<TD>SHORT<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>WDTH<TD>Element Width<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No
</TABLE>

The following fields are used to operate the histogram record in 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 ====

Using NELM, space for the unsigned long array is allocated and the width WDTH of the array is calculated.

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 and a device support read routine are available. If device support includes init_record, it is called.

==== process ====

See next section.

==== special ====

Special is invoked whenever the fields CMD, SGNL, ULIM, or LLIM are changed.

If SGNL is changed, add_count is called.

If ULIM or LLIM are changed, WDTH is recalculated and clear_histogram is called.

If CMD is less or equal to 1, clear_histogram is called and CMD is reset to 0. If CMD is 2, CSTA is set to TRUE and CMD is reset to 0. If CMD is 3, CSTA is set to FALSE and CMD is reset to 0.

clear_histogram zeros out the histogram array. add_count increments the frequency in the histogram array.

==== get_value ====

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

==== cvt_dbaddr ====

This is called by dbNameToAddr. It makes the dbAddr structure refer to the actual buffer holding the array.

==== get_array_info ====

Obtains values from the array referenced by VAL.

==== put_array_info ====

Writes values into the array referenced by 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 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 writing the new value. In this case, the processing routine merely returns, leaving PACT TRUE.
# Add count to histogram array.
# 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 MDEL conditions are met. NSEV and NSTA are reset to 0.
# Scan forward link if necessary, set PACT and INIT to FALSE, and return.

== Device Support ==

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

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>SVL<TD>Signal Value<TD rowspan=2>The device support module retrieves a value from SGNL for SVL<TR>
<TD>SGNL<TD>Signal Value Location
</TABLE>

=== Device Support Routines ===

Device support consists of the following routines:

==== init_record ====

init_record(precord)

This routine is called by the record support init_record routine. It makes sure that SGNL is a CONSTANT, PV_LINK, DB_LINK, or CA_LINK. It also retrieves a value for SVL from SGNL. If SGNL is none of the above, an error is generated.

==== read_histogram ====

read_histogram(*precord)

This routine is called by the record support routines. It retrieves a value for SVL from SGNL.

=== Device Support For Soft Records ===

Only the device support module <CODE>Soft Channel</CODE> is currently provided, though other device support modules may be provided at the user's site.

==== Soft Channel ====

The <CODE>Soft Channel</CODE> device support routine retrieves a value from SGNL. SGNL must be CONSTANT, PV_LINK, DB_LINK, or CA_LINK.

----

EPICS Record Reference Manual - 19 MAY 1998

RRM 3-14 Fanout

2008-04-18T19:14:29Z

KazimierzGofron:

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

= Fanout =

The fanout record uses several forward processing links to force multiple passive records to scan. When more than one record needs to be scanned as the result of a record being processed, the forward link of that record can specify a fanout record. The fanout record can specify up to six other records to process. When more than six are needed, one of the links in the fanout record can point to another fanout record.

<B>NOTE: Fanout records only propagate processing, not data. The dfanout or data fanout record can, on the other hand, send data to up to eight other records.</B>

== Parameter Fields ==

The fanout record's fields fall into the following categories:

* scan parameters
* operator display parameters
* run-time parameters.

=== Scan Parameters ===

The forward link fields of the fanout record (LINK1-LINK6) specify records to be scanned. The records to be processed must specify <CODE>Passive</CODE> in their SCAN fields; otherwise the forward link to it will not cause it to process. Also when specifying database links for the fanout record, the user needs only to specify the record name. As no value is being sent or retrieved, the field name is optional.

The SELM, SELN, and SELL fields specify the order of processing for the forward links. The select mechanism field (SELM) has three choices--<CODE>All</CODE>, <CODE>Specified</CODE>, or <CODE>Mask</CODE>. How these affect which links to process and in which order is as follows:

; <B>All</B>
: Links are processed in numerical order--LNK1, LNK2, etc.
; <B>Specified</B>
: SELN is used as the specifier of which link to process. For instance, if SELN=1, then LNK1 will be processed.
; <B>Mask</B>
: The individual bits in SELN are used to select which links to process as follows:
:* If bit 0 of SELN is set, LNK1 is processed.
:* If bit 1 of SELN is set, LNK2 is processed.
:* If bit 2 of SELN is set, LNK3 is processed, etc.

SELN reads its value from SELL. SELL can be a constant, a database link, or a channel access link. If a constant, SELN is initialized with the constant value and can be changed via dbPuts. For database/channel access links, SELN is retrieved from SELL each time the record is processed and can also be changed via dbPuts.

The Fanout record also has the standard scanning fields common to all records. These fields are listed in [[RRM 3-14 dbCommon#Scan Fields|Scan Fields]]. In addition, [[RRM 3-14 Concepts#Scanning Specification|Scanning Specification]] explains in more detail how forward links and the scanning algorithms work.

<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> Forward Links<TD>FWDLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>LNK2<TD> Forward Links<TD>FWDLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>LNK3<TD> Forward Links<TD>FWDLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>LNK4<TD> Forward Links<TD>FWDLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>LNK5<TD> Forward Links<TD>FWDLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>LNK6<TD> Forward Links<TD>FWDLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<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 Algorithm<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>

=== Operator Display Parameters ===

These parameters are used to present meaningful data to the operator. See [[RRM 3-14 dbCommon#Fields Common to All Record Types|Fields Common to All Record Types]] for more 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>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 Fanout 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 ===

The VAL field is used only so that dbNameAddr succeeds when no field name is specified. Otherwise, it has no significance.

<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>LONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes
</TABLE>

== Record Support ==

=== Record Support Routines ===

==== init_record ====

This routine initializes SELN with the value of SELL, if SELL type is CONSTANT link, or creates a channel access link if SELL type is PV_LINK.

==== process ====

See next section.

=== Record Processing ===

Routine process implements the following algorithm:

# PACT is set to TRUE.
# The link selection SELN is fetched.
# Depending on the selection mechanism, the link selection forward links are processed. and UDF is set to FALSE.
# Check to see if monitors should be invoked:
#* Alarm monitors are invoked if the alarm status or severity has changed.
#* 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 Event

2008-04-18T19:13:47Z

KazimierzGofron:

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

= Event =

The normal use for this record type is to post an event and/or process a forward link. Device support for this record can provide a hardware interrupt handler routine for I/O Event-scanned records.

== Parameter Fields ==

The records in this field fall into the following groups of parameters:

* scan parameters
* read parameters
* event number parameters
* simulation mode parameters

=== Scan Parameters ===

The event record has the standard fields for specifying under what circumstances it will be processed. If the SCAN field specifies <CODE>I/O Intr</CODE>, then device support will provide an interrupt handler, posting an event number when an I/O interrupt occurs. 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 the scanning fields work. Note that I/O event scanning is only supported for those card types that interrupt.

=== Input Specification ===

The device support routines use the address in this record to obtain input. For records that provide an interrupt handler, the INP field should specify the address of the I/O card, and the DTYP field should specify a valid device support module. Be aware that the address format differs according to the card type used. See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on the format of hardware addresses and specifying links. You 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 INP field can be a constant, a database link, or a channel access link. For soft records, the DTYP field should specify <CODE>Soft Channel</CODE>.

<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> 
</TABLE>

=== Event Number Parameters ===

The VAL field contains the event number read by the device support routines. It is this number which is posted. For records that use <CODE>Soft Channe</CODE>l device support, it can be configured before run-time or set 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>VAL<TD>Event Number to Post<TD>USHORT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No
</TABLE>

=== Operator Display Parameters ===

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

=== Simulation Mode Parameters ===

The following fields are used to operate the event 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 a 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.

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.

=== Record Processing ===

Routine process implements the following algorithm:

# 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.
# If VAL > 0, post event number VAL.
# Check to see if monitors should be invoked. Alarm monitors are invoked if the alarm status or severity has changed 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 record must have an associated set of device support routines. 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>INP<TD>Input Link<TD>This field is used by the device support routines to locate its input.<TR>
<TD>PRIO<TD>Priority<TD>This value must be used by the device support interrupt handler to set the scheduling priority for processing this record.
</TABLE>

=== Device Support Routines ===

Device support consists of the following routines:

==== report ====

report(FILE fp, interest)

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_event ====

read_event(precord)

This routine returns the following values:

* 0: Success.
* Other: Error.

=== Device Support For Soft Records ===

The <CODE>Soft Channel</CODE> device support module is available. The INP link type must be either CONSTANT, DB_LINK, or CA_LINK.

If the INP link type is CONSTANT, then the constant value is stored into VAL by init_record, and UDF is set to FALSE. If the INP link type is PV_LINK, then dbCaAddInlink is called by init_record.

<CODE>read_event</CODE> calls recGblGetLinkValue to read the current value of VAL. See [[RRM 3-14 Common#Input Records|Input Records]] for details on soft input.

----

EPICS Record Reference Manual - 19 MAY 1998

RRM 3-14 Data Fanout

2008-04-18T19:12:58Z

KazimierzGofron:

[[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 CPID Control

2008-04-18T19:12:11Z

KazimierzGofron:

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

= CPID Control =

The CPID record, like the PID record, is used for making error corrections on output values in order to maintain a specified setpoint. In the CPID record, the setpoint must be retrieved from another database record. When the record is processed, it reads the controlled value and the setpoint, and then computes the error correction. Unlike the PID record, the CPID record can write this value because it has its own output link.

Another important difference is that unlike the PID record, the CPID record has four different modes: normal mode, sequencer mode, local mode, and manual mode. The normal mode causes the CPID record to function in the same way as the PID record does. The other modes significantly change how the CPID record functions. All these modes are explained in this chapter.

When in normal mode, the CPID record performs the same equation as the PID record. This equation consists of three parts: the proportional, the integral, and the derivative. Using the gain that exists for each of these terms, the user can weight each contribution according to the response of the process being controlled.

== Parameter Fields ==

The fields in this record fall into several categories:

* scan parameters
* controlled variable and setpoint parameters
* output, readback, and mode parameters
* expression parameters
* operator display parameters
* alarm parameters
* monitor parameters
* run-time parameters

=== Scan Parameters ===

The CPID 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 CPID record supports no direct interfaces to hardware, it cannot be scanned on I/O interrupt, i.e., its SCAN field cannot specify <CODE>I/O Intr</CODE>.

However, the CPID record contains an additional field that affects its processing while in normal mode. The minimum delta time field (MDT) is a scanning field particular to the CPID record and PID records. It can be configured by the user or modified at run-time. It contains a floating point value which represents the minimum amount of time between record processing so that if the amount of time between the last time the record was processed and the current time is less than MDT, then DM and the output value (OVAL) are set to 0. If MDT is left at its default value (0), the minimum delta will be equal to one clock tick.

<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>MDT<TD>Minimum Delta Time<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Controlled Variable and Setpoint Parameters ===

The control variable location field (CVL) is used to obtain the value of the controlled process variable, the value read into the CVAL field. The link must be a database link. If it is not a database link an INVALID alarm is triggered when the record is processed. See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on specifying links.

The setpoint value is set in the VAL field. Unlike the PID record, the setpoint value cannot be read from other records, but must be set via dbPuts. It is set equal to CVAL, the value retrieved from the CVL link, when the record is initialized.

<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>CVL<TD>Controlled value location (an input link)<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>VAL<TD>Setpoint value<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes
</TABLE>

=== Expression Parameters ===

The PID expression calculated by the CPID record in Normal mode is the same as the PID record's expression. The discrete from of the PID expression is as follows:

<TABLE>
<TD ROWSPAN=3>M(n) = KP × E(n) + KI × SUMi ( E(i) × dT(n) ) + KD × (
<TD>E(n) - E(n-1)
<TD ROWSPAN=3>) + Mr
<TR>
<TD ALIGN=CENTER>-----------------
<TR>
<TD ALIGN=CENTER>dT(n)
</TABLE>

where

: M(n) = value of manipulated variable at ''n''th instant.
: KP, KI, and KD = Proportional, Integral, Derivative gains set by the user
: E(n) = Error at ''n''th sampling instant
: SUMi = Sum from i=0 to i=n
: dT(n) = Time difference between ''n-1''th instance and ''n''th instance
: Mr = Midrange adjustment

Taking the first difference between instances yields the following equation:

<TABLE>
<TD ROWSPAN=3>delM(n) = KP × (E(n) - E(n-1)) + KI × E(i) × dT(n) + KD × (
<TD>E(n) - E(n-1)
<TD ROWSPAN=3>) - (
<TD>E(n) - E(n-1)
<TD ROWSPAN=3>)
<TR>
<TD ALIGN=CENTER>-----------------
<TD ALIGN=CENTER>-----------------
<TR>
<TD ALIGN=CENTER>dT(n)
<TD ALIGN=CENTER>dT(n-1)
</TABLE>

The terms KP, KI, and KD are the only terms configured by the user. These terms represent the gain for the proportional (KP), integral (KI), and the derivative (KD). A field exists for each of these terms (the KP, KI, and KD fields). KP should be configured according to the characteristics of the controlled variable; KI should be set equal to the number of times that the integral contribution repeats the proportional contribution; and KD should equal the number of minutes until the derivative contribution repeats the proportional contribution.

The PID record calculates the other terms of the expression:

; <B>E(n)</B>
: Error at ''n''th sampling instant, where the Error equals the setpoint minus the value of the controlled variable (VAL - CVAL).
; <B>delM(n)</B>
: This is the end result of the PID expression -- the change in the manipulated value. The DM field holds this value.
; <B>dT(n)</B>
: This is the time difference between n and n-1, between current and last samplings.

The final result of the expression <CODE>delM(n)</CODE> and the other parts of the expression are held in several different run-time fields, which are not configurable prior to run-time, nor modifiable at run-time, but can be accessed so that their values can be used.

When in Normal Mode, the DM field contains the change in manipulated value, i.e., the result of the PID expression delM(n). For other modes, the value is different, but is always an increment which can be accessed by the desired output link (DOL) of an analog output record. Since its value represents an increment, the OIF field of the analog output record should be set to <CODE>Incremental</CODE>. Note that the final result to be written may not be the same as the final result of the equation; that is, DM, the result of the equation, may not equal OVAL, the output value, depending on the mode.

The P, I, D, CT, DT, ERR, and DERR fields are used to calculate the PID expression. They are not configurable prior to, nor modifiable during, run-time, but may be of interest when fine tuning the gains of each contribution (KP, KI, KD). The following lists the fields as they relate to the expression:

; <B>ERR</B>
: E(n). Error at current sampling (VAL-CVAL).
; <B>DERR</B>
: E(n) - E(n-1). Difference between current error and error at last sampling.
; <B>P</B>
: This field corresponds to <CODE>KP * DERR</CODE>
; <B>I</B>
: This field corresponds to <CODE>E(n) * dTn * KI</CODE>
; <B>D</B>
: This field corresponds to <CODE>Kp * Kd * (err/dt(n) - derr/dt(n-1))</CODE>

<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>KP<TD>Proportional Gain<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>KI<TD>Integral Gain, in repeats per minute.<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>KD<TD>Derivative Gain, in repeats per minute<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DM<TD>Change in Manipulated Value<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>Yes<TD>No<TR>
<TD>P<TD>Proportional contribution to DM.<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>Yes<TD>No<TR>
<TD>I<TD>Integral contribution to DM.<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>Yes<TD>No<TR>
<TD>D<TD>Derivative contribution to DM.<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>Yes<TD>No<TR>
<TD>CT<TD>Clock ticks when previous process occurred.<TD>ULONG<TD>No<TD>0<TD>Yes<TD>No<TD>Yes<TD>No<TR>
<TD>DT<TD>Time difference in seconds between processing steps.<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>Yes<TD>No<TR>
<TD>ERR<TD>Current error (VAL - CVAL).<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>Yes<TD>No<TR>
<TD>DERR<TD>Delta Error<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>Yes<TD>No
</TABLE>

=== Output, Readback, and Mode Parameters ===

Unlike the PID record, the CPID record has an output link so that it can write its output. The value written is the value of the OVAL field. How record processing determines this value depends on, among other things, the current mode and the limits.

Firstly, the record has two output modes, CHANGE and POSITION, set by the OMOD field. If OMOD is (0,1), then the output mode will be (CHANGE, POSITION). The OMOD field cannot be modified at run-time, so it must be configured to be either CHANGE or POSITION. It is initialized to CHANGE by default.

When CHANGE, the record sets OVAL equal to DM, the result of the PID expression. DM being itself an increment, OVAL is an incremental value in the CHANGE mode. If the record is in POSITION mode, OVAL is an absolute value obtained by adding OVAL to DM. In this case, OVAL will be the last value of OVAL when it was written unless it was changed by database access.

if CHANGE
OVAL = DM
if POSITION
OVAL = OVAL + DM

After OVAL is adjusted in case it violates the value limits explained below, DM is set equal to OVAL when in CHANGE mode. When in position mode, after any adjustments, DM is set equal to OVAL - MLST, MLST being the value of OVAL the last time the record was processed. This way, DM is always an increment, adjusted to be within the value limits.

Secondly, there are four different modes on top of the output mode: Normal, Sequencer, Manual, and Local.

# In Normal mode, OVAL is computed as explained above. DM is also computed as usual.
# In Sequencer mode, the CPID record computes OVAL as SVAL - ORBV when in CHANGE mode, and sets OVAL equal to SVAL in the POSITION mode. DM is computed as SVAL - ORBV in CHANGE mode and OVAL - SVAL in POSITION mode. The sequencer program should determine the value of SVAL while in Sequencer mode.
# In Manual mode, the CPID record computes OVAL as MVAL - ORBV when in CHANGE mode, and sets OVAL equal to MVAL when in POSITION mode. DM is set equal to MVAL - ORBV in CHANGE mode and OVAL - MVAL in POSITION mode. MVAL is determined by the operator at run-time, via dbPuts.
# In Local mode, the CPID record sets OVAL equal to 0 when the output mode is CHANGE and ORBV when the output mode is POSITION. The Local mode was implemented to support the setting of the output by a local hardware control.

The MMOD, SMOD, and LOC field determine which of these four modes the CPID record is in. The MMOD and SMOD fields are set via database access (by the operator or the sequencer). The LOC field must specify a database link if the record is to be placed into Local mode. If the MMOD field is true (has a value other than 0), then the mode is Manual. If the SMOD field is true, then the mode is Sequencer. If the LOC field is a database link and the value retrieved from it is 0, then the mode is Local. The default mode is the normal mode so that if none of the above conditions exist, the mode is normal. An order of precedence exists so that the mode can be determined when more than one of the above conditions is true. The order of precedence is Local mode, Manual mode, Sequencer, then Normal mode, so that if the MMOD and SMOD fields are true and the value retrieved from the LOC field ''is not 0'' (i.e., local mode is not requested), then the mode is Sequencer.

Note: DM is calculated even for modes other than Normal. This prevents the DT change in time contribution from "winding up" when the mode is other than Normal.

Finally, MAX, MIN, DMAX, and DMIN fields are used to specify limits for the output value. The MAX and MIN fields limit the value of OVAL, whereas the DMAX and DMIN fields limit the value of DM. How these fields do this for the different modes is somewhat complex. See [[#Record Processing|Record Processing]] in this chapter for a further explanation of how these fields work.

<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>ORBL<TD>Output Readback Location<TD>INLINK<TD>Yes<TD> <TD>No<TD>No<TD>No<TD>No<TR>
<TD>OMOD<TD>Output Mode<TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>ORBV<TD>Output Readback Value<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>MAX<TD>Maximum Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>MIN<TD>Minimum Limit<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DMAX<TD>Maximum Change<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DMIN<TD>Minimum Change<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>LOC<TD>Local Mode Switch<TD>INLINK<TD>Yes<TD> <TD> <TD>No<TD>No<TD>No<TR>
<TD>MMOD<TD>Manual Mode Request<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>SMOD<TD>Sequencer Mode Request<TD>[[RRM 3-14 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>MVAL<TD>Manual Value<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>SVAL<TD>Sequencer Value<TD>FLOAT<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. These fields are used to display the setpoint (VAL), the controlled variable (CVAL), the change in manipulated value (DM), and other fields of the PID, either textually or graphically.

EGU is a string of up to 16 characters describing the units of PID's manipulated values measures. It is retrieved by the <CODE>get_units</CODE> record support routine. It must be configured by the user if at all.

The HOPR and LOPR fields set the upper and lower display limits for the VAL, HIHI, HIGH, LOW, LOLO, VAL, P, I, D, and CVAL fields.

The PREC field determines the floating point precision with which to display VAL and CVAL. 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<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<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD> <TR>
<TD>DESC<TD>Description<TD>STRING<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Alarm Parameters ===

The possible alarm conditions for PID are the SCAN alarm, limit alarms, and an INVALID alarm that is triggered when CVL is not a database link. The SCAN and INVALID alarms are called by the record routines and are always of MAJOR severity.

The limit alarms trigger alarms on the VAL field. They 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. 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 deadbands configured by the user which determine when to send monitors on the DM field. If the value of DM is greater than ADEL, archive monitors for the OVAL, CT, and DM fields are sent. Additionally, if the record is in Normal mode, monitors for P, I, D, ERR, DERR, and DT are sent. MDEL is used the same way as ADEL for all other types of monitors.

The ODEL field is not implemented in the PID record.

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<TR>
<TD>ODEL<TD>Output deadband for DM<TD>FLOAT<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 PID. They are not configurable prior to run-time. They represent the current state of the PID and/or the terms of the PID expression. Many of them are used to process the PID record more efficiently.

The CVAL field is the controlled variable value retrieved from the CVL link.

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

The ALST field holds the last value for OVAL, but has no other function for the record.

The MLST field holds the last value for the OVAL field. It is used to calculate a value for DM when the record is in the POSITION mode. After any other calculations, DM is set equal to OVAL - MLST. Thus, even in POSTION mode, DM always holds a relative value, the difference between DM and the value of OVAL from the last time the record was processed.

The PMOD field indicates the current mode of the record:

* 0 Normal Mode
* 1 Manual Mode
* 2 Sequencer Mode
* 3 Local Control Mode

The last mode field (LMOD) implements monitors for PMOD. If PMOD is not equal to LMOD, monitors are posted for the PMOD 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>CVAL<TD>Value of controlled variable<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>No<TD>No<TR>
<TD>OVAL<TD>Output Value<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>ODM<TD>Old DM. <TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>Yes<TD>No<TR>
<TD>LALM<TD>Value from when last monitors for alarm were triggered<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>ALST<TD>Value when last monitors for archiver were triggered<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>MLST<TD>Value when last monitors for value changes were triggered<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LOVL<TD>Last Readback Value<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>PMOD<TD>Current Mode<TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD> <TD>No<TD>Yes<TD>No<TR>
<TD>LMOD<TD>Last Mode<TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>yes<TD>No<TD>No<TD>No<TR>
<TD>ODM<TD>Old DM Value<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No
</TABLE>

== Record Support ==

=== Record Support Routines ===

==== init_record ====

Set UDF to false. Return 0.

==== 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 if field is CVAL or VAL. Otherwise, calls <B>recGblGetPrec()</B>.

==== get_graphic_double ====

Sets the following values if field is VAL, HIHI, HIGH, LOW, LOLO, P, I, D, or CVAL:

upper_disp_limit = hopr
lower_disp_limit = lopr

==== get_control_double ====

Sets the following values if field is VAL, HIHI, HIGH, LOW, LOLO, P, I, D, or CVAL:

upper_ctrl_limit = hopr
lower_ctrl_limit = lopr

==== 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:

# Set PACT to TRUE.
# If CVL is not a database link an INVALID alarm is declared, PACT is set to FALSE, and the routine returns (0).
# The current value of CVAL is obtained from CVL.
# If ORBL is a database link, the current value of ORBV is obtained.
# Determine the mode:
#* mode = normal
#* if SMOD true
#** mode = Sequencer mode
#* if MMOD true
#** mode = Manual mode
#* if value retrieved from LOC is 0
#** mode = Local Mode
# Compute time difference between current and last processing; that is , compute DT.
# Set DM = 0.
# If Mode is Normal and DT < MDT, calculate DM using PID expression.
# If Mode is Normal and OMOD is CHANGE:
#* if (ORBV + DM) is less than MAX
#** set OVAL = MAX - ORBV
#* else if (ORBV + DM) < MIN
#** set OVAL = MIN - ORBV
#* else set OVAL = DM
# If Mode is Normal and OMOD is POSITION and OVAL > MAX:
#* if (OVAL - MAX) > DMAX
#** set OVAL = OVAL - DMAX
#* if (OVAL - MAX) >= DMIN
#** set OVAL = MAX
# If Mode is Normal and OMOD is POSITION and OVAL < MIN.
#* if (MIN - OVAL) > DMAX
#** Set OVAL = OVAL + DMAX
#* if ( MIN - OVAL) >= DMIN
#** set OVAL = MIN
# If Mode is Manual and OMOD is CHANGE
#* set DM and OVAL to MVAL - ORBV.
# If Mode is Manual and OMOD is POSITION
#* set DM and OVAL to MVAL - ORBV.
# if Mode is Local Control and OMOD is CHANGE
#* set OVAL equal to 0.
# If Mode is Local Control and OMOD is POSITION
#* set OVAL equal to ORBV.
# If Mode is Sequencer and OMOD is CHANGE
#* set DM and OVAL to SVAL - ORBV
# If Mode is Sequencer and OMOD is POSITION
#* set DM and OVAL to SVAL.
# If OMOD is CHANGE
#* set DM equal to OVAL.
# If OMOD is POSITION
#* set DM equal to OVAL - MLST.
# Write OVAL to output location.
# Check alarms and post if any.
# Check monitors and post if any.
# Process FLNK.
# Set PACT equal to FALSE and return 0.

== Device Support ==

The CPID record has no associated device support.

----

EPICS Record Reference Manual - 19 MAY 1998

RRM 3-14 Compression

2008-04-18T19:11:05Z

KazimierzGofron:

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

= compress - Compression =

The data compression record is used to collect and compress data from arrays. When the INP field references a data array field, it immediately compresses the entire array into an element of an array using one of several algorithms, overwriting the previous element. If the INP field obtains its value from a scalar-value field, the compression record will collect a new sample each time the record is processed and add it to the compressed data array as a circular buffer.

The INP link can also specify a constant; however, if this is the case, the compression algorithms are ignored, and the record support routines merely return after checking the FLNK field.

== Parameter Fields ==

The data compression fields fall into the following categories:

* scan parameters
* read parameters
* operator display parameters
* run-time parameters

=== Scanning Parameters ===

The compression 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 compression record supports no direct interfaces to hardware, its SCAN field cannot specify <CODE>I/O Intr</CODE>.

=== Read Parameters and Algorithm Parameters ===

These fields determine what channel to read and how to compress the data. The user specifies the algorithm to be used in the ALG field. There are five possible algorithms which can be specified as follows:

* <CODE>Circular Buffer</CODE>
* <CODE>Average</CODE>
* <CODE>N to 1 Low Value</CODE>
* <CODE>N to 1 High Value</CODE>
* <CODE>N to 1 Average</CODE>

These algorithms are explained in one of the sections below.

The RES field can be accessed at run time to cause the algorithm to reset itself.

<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>RES<TD>Reset<TD>SHORT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>ALG<TD>Algorithm<TD>[[RRM 3-14 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>NSAM<TD>Number in Sample<TD>ULONG<TD>Yes<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>N<TD>Number<TD>ULONG<TD>Yes<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>ILIL<TD>Initial Low Interest Value<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>IHIL<TD>Initial High Interest Value<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

==== Input Specification ====

The input specification should be a database or channel access link. Though INP can be a constant, the data compression algorithms are supported only when INP is a database link. See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on specifying links.

==== Algorithms and Related Fields ====

As stated above, the ALG field specifies which algorithm to be performed on the data. The rest of the fields--NSAM, N, ILIL, IHIL, and OFF--are used in the compressions, though N is not used in the <CODE>Circular Buffer</CODE> algorithm and ILIL, IHIL, and OFF are used neither in the <CODE>Circular Buffer</CODE> algorithm nor in the <CODE>Average</CODE> algorithm.

The <CODE>Circular Buffer</CODE> algorithm keeps a circular buffer of length NSAM. Each time the record is processed, it gets the data referenced by INP and puts it into the circular buffer referenced by VAL. Note that when INP refers to a scalar, VAL is just a time ordered circular buffer of values obtained from INP.

<CODE>Average</CODE> takes an average of all the elements of the array obtained from INP; that is, the entire array referenced by INP is retrieved, and the average of the elements is placed in the next element of the circular buffer. The retrieved array is truncated to be of length NSAM. N successive arrays are averaged and placed in the circular buffer. Thus, VAL[0] holds the average of the first sampling of INP, VAL[1] holds the average of the next sampling of INP, and so on. The following shows the equation:

[[Image:RRM 3-14 Compression-1.gif]]

If <CODE>N to 1 Low Value</CODE>, <CODE>N to 1 High Value</CODE>, or <CODE>N to 1 Average</CODE> are chosen, then VAL is a circular buffer of NSAM samples. The actual algorithm depends on whether INP references a scalar or an array. If INP refers to a scalar, then N successive time ordered samples of INP are taken. After the Nth sample is obtained a new value, determined by the algorithm (LOW, HIGH, or AVE), is written to the circular buffer referenced by VAL. If LOW, the lowest value is written; if HIGH, the highest value of all the samples is written; and if AVE, the average of all the samples are written.

If INP refers to an array, then the following applies:

; <CODE>N to 1 Low Value</CODE>
: Compress N to 1 samples, keeping the lowest value
; <CODE>N to 1 High Value</CODE>
: Compress N to 1 samples, keeping the highest value
; <CODE>N to 1 Average</CODE>
: Compress N to 1 samples, taking the average

The compression record keeps (NSAM) data samples.

The N field determines the number of fields to compress into 1.

Thus, if NSAM was 3, and N was also equal to 3, then the algorithms would work as in the following diagram:

[[Image:RRM 3-14 Compression-2.gif]]

OFF number of samples are ignored at the beginning of the array being compressed. IHIL and ILIL are used as initial value filters when compressing arrays; that is, the compression does not begin until a value is found that is either greater than IHIL or less than ILIL

RES resets the algorithm before the maximum number of samples are reached.

=== Operator Display Parameters ===

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

The HOPR and LOPR fields only specify the range for VAL, HIHI, HIGH, LOLO and LOW fields.

PREC controls the floating-point precision whenever <CODE>get_precision</CODE> is called, and the field being referenced is the VAL field (i.e., one of the values contained in the circular buffer).

The EGU field should be given a string that describes the value of VAL, but is used whenever the <CODE>get_units</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> <TR>
<TD>DESC<TD>Description<TD>STRING [29]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Alarm Parameters ===

The compression 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 parameters are used by the run-time code for processing the data compression algorithm. They are not configurable by the user, though some are accessible at run-time. They can represent the current state of the waveform or of the record whose field is referenced by the INP field.

NUSE holds the number of elements currently stored in VAL.

BPTR is a pointer that refers to the buffer referenced by VAL.

The SPTR field pointer to an array that is used for array averages.

WPTR is used by the dbGetlinks routines.

<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>NUSE<TD>Number Used<TD>ULONG<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>BPTR<TD>Buffer Pointer<TD>NOACCESS<TD>No<TD>0<TD>No<TD>No<TD>No<TD> <TR>
<TD>SPTR<TD>Summing Buffer Pointer<TD>NOACCESS<TD>No<TD>0<TD>No<TD>No<TD>No<TD> <TR>
<TD>WPTR<TD>Work Buffer Pointer<TD>NOACCESS<TD>No<TD>0<TD>No<TD>No<TD>No<TD> <TR>
<TD>CVB<TD>Compress Value Buffer<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>INX<TD>Current Index of Circular Buffer<TD>ULONG<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No
</TABLE>

== Record Support ==

=== Record Support Routines ===

==== init_record ====

Space for all necessary arrays is allocated. The addresses are stored in the appropriate fields in the record.

==== process ====

See next section.

==== special ====

This routine is called when RSET is set. It performs a reset.

==== get_value ====

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

==== cvt_dbaddr ====

This is called by dbNameToAddr. It makes the dbAddr structure refer to the actual buffer holding the result.

==== get_array_info ====

Obtains values from the circular buffer referenced by VAL.

==== put_array_info ====

Writes values into the circular buffer referenced by 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, 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, 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.

=== Record Processing ===

Routine process implements the following algorithm:

# If INP is not a database link, check monitors and the forward link and return.
# Get the current data referenced by INP.
# Perform the appropriate algorithm:
#* Average: Read N successive instances of INP and perform an element by element average. Until N instances have been obtained it just return without checking monitors or the forward link. When N instances have been obtained complete the algorithm, store the result in the VAL array, check monitors and the forward link, and return.
#* Circular Buffer: Write the values obtained from INP into the VAL array as a circular buffer, check monitors and the forward link, and return.
#* N to 1 xxx and INP refers to a scalar: Obtain N successive values from INP and apply the NTO1xxx algorithm to these values. Until N values are obtained monitors and forward links are not checked. When N successive values have been obtained, complete the algorithm, check monitors and the forward link, and return.
#* N to 1 xxx and INP refers to an array: The ILIL and IHIL are honored if ILIL < IHIL. The input array is divided into subarrays of length N. The specified N to 1 xxx compression algorithm is applied to each sub-array and the result stored in the array referenced by VAL. The monitors and forward link are checked.
# If success, set UDF to FALSE.
# Check to see if monitors should be invoked:
#* Alarm monitors are invoked if the alarm status or severity has changed.
#* 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 Calcout

2008-04-18T19:10:22Z

KazimierzGofron:

[[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>IVOV<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>IVOA<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

RRM 3-14 Calculation

2008-04-18T19:09:10Z

KazimierzGofron:

[[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 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, 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 Binary Output

2008-04-18T19:08:06Z

KazimierzGofron:

[[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|GBLCHOICE]]<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|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>OSV<TD>One 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<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<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|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 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 Input

2008-04-18T19:06:35Z

KazimierzGofron:

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

RRM 3-14 Archive

2008-04-18T19:05:01Z

KazimierzGofron:

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

= The Archive Record =

The Archive record was developed to provide a way to store the values of a PV for use by an EPICS archiving client. A client that archives the states of one or more PVs typically uses Channel Access to establish monitors on a channel, or the client retrieves a PV's values directly using get requests, the client usually running on a different host than the host which is running the database. In the case that the network fails or the client or client's host crashes, then the Archive record provides a way to store values for the PV being archived within the IOC. In addition, the Archive record stores the time stamp for the value as well as the status and severity of the PV. The Archive record can then "flush" the stored values and time stamps out to the client the next time the record processes.

Each time the Archive record processes, it reads a value from the address specified by its input link (the INP field) and decides whether or not to store it in an array. Whether the Archive record stores the value depends on the configuration of the STIM, AVAR, RVAR, and PCAB fields. If the record decides to archive the value, the value will be written into the CVAL field, and then stored in an array of data structures, each structure having members for the value, time stamp, and status and severity. The value of the sample is also stored in another array. The seconds and nanoseconds parts of the time stamp for the value are also stored in separate arrays. Writing directly to the CVAL field will cause the record to process. The size of the arrays used by the Archive record is determined by the value of the NVAL field, which should be configured beforehand.

Each time the record is processed, it will determine if monitors should be posted for the Archive records arrays. That is, it will decide if the array of values and the time arrays should be flushed to the client. The Archive record flushes the arrays when the record is full, half-full, and when the number of seconds since the last flush exceeds the number of seconds specified in the FTIM field. FTIM should be configured before run-time.

== Parameter Fields ==

The record's fields fall into the following categories:

* scan parameters
* read parameters
* archive and monitor parameters
* operator display parameters
* run-time and simulation mode parameters

=== Scan Parameters ===

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

=== Read Parameters ===

The INP field determines where the Archive record gets its input. It can be a database or channel access link, or a constant. Each time the record is processed, it reads the value from the specified address and writes it into the RVAL field. If constant, the RVAL field is initialized with the constant and can be changed via <CODE>dbPuts</CODE>. The Archive record does not support device input.

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>RVAL<TD>Raw Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>INP<TD>Input Link<TD>INLINK<TD>Yes<TD>Null<TD>Yes<TD>No<TD>N/A<TD>No
</TABLE>

=== Archive and Monitor Parameters ===

These configurable parameters are the core of the archive record and basically determine how it operates at run-time. The STIM, AVAR, RVAR, and PCAB fields determine whether or not the record will archive the value read into the RVAL field. If the time since the last value archived is greater than the number of seconds specified in the STIM field, the value read into RVAL will be archived. Otherwise, the record will then use the PCAB, and RVAR or AVAR fields to determine whether or not to save the value. The PCAB field is a menu-type field that has seven choices:

* absolute
* relative
* abs && rel
* abs || rel
* on change
* allways
* never

If the PCAB field specifies <CODE>absolute</CODE>, when the record reads in a value to RVAL it will archive the value only if the difference between RVAL and the last value archived is greater than the value specified in the AVAR field. The difference between the RVAL and the last archived value is calculated as an absolute value. If the PCAB field specifies <CODE>relative</CODE>, the record will archive the value in RVAL only if the difference between RVAL and the last archived value is greater than ''n''% of the last value archived, where ''n'' is the value specified in the RVAR field. The difference between RVAL and the last archived value is calculated as an absolute value. Thus, if PCAB specifies <CODE>relative</CODE> and the RVAR specifies 10%, and if the last archived value was 100.0, then if the current value is less than 90 or greater than 110, then that means the value has changed by more than 10% and the value will be archived.

If the PCAB field specifies <CODE>abs && rel</CODE>, then the record will archive the value in RVAL only if both the above absolute and relative conditions are true. If the PCAB field specifies <CODE>abs || rel</CODE>, then the value will be archived if either condition holds true. If <CODE>on change</CODE> is specified, then the record will archive the value if it has changed from the last value archived; if <CODE>allways</CODE>, the record will archive the value in RVAL every time the record processes; and if <CODE>never</CODE>, the record will never archive the value.

If a value is to be archived, it is written into the CVAL field.

When the archive record archives a value, it archives the value, a time stamp for the value, as well as the status and severity of the PV's value. This information is collectively called a sample. The record keeps track of each sample with a data structure. An array of these data structures is allocated when the record is initialized. The size of this array is configured by the developer/user in the NVAL field. It's the responsibility of the configurer to make sure NVAL specifies an array of the appropriate size. In addition to an array to hold the samples, three more arrays are allocated of size NVAL: the first holds the value part of each sample; the second holds the time of each sample, where the time is the number of seconds past the epoch of the sample; the third holds the nanoseconds part of the sample's time stamp. Although these arrays are not directly accessible at run-time through read or write operations, the record posts the latter three arrays using monitors.

The record posts the above three arrays--an array with the sample's values, an array with the seconds part of the sample's time stamp, and an array with the nanoseconds part of the time stamp--when the difference between the current time and the last time the values were posted exceeds the number of seconds specified in the FTIM field. In addition, the arrays are posted when the arrays are full and half-full. Of course, these conditions are only checked when the record processes

The MASK field changes the above algorithm somewhat. It was intended to enable a special digital reading of any input. It's an unsigned integer field which, if non-zero, changes the algorithm of the record in the following way. Firstly, if the MASK field is set to true, the following conversion is performed on RVAL: its value is typecast to an unsigned integer, RVAL being read as floating-point number. Then this integer is ANDed (&) with the value in MASK. In deciding to archive this integer, if the interval specified in STIM has been exceeded, the value is archived, just as when MASK is zero. However, if STIM hasn't been exceed, if MASK is true, the PCAB field is ignored, and the record simply checks to see if the converted value is not equal to the last value archived. If it isn't, the value is archived.

<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>STIM<TD>Save Time in Secnds<TD>ULONG<TD>Yes<TD>900<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>PCAB<TD>Percent or Absolute<TD>RECCHOICE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>AVAR<TD>Absolute Difference<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>RVAR<TD>Percent Difference<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>CVAL<TD>Current Value<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>NVAL<TD>Number of Values<TD>ULONG<TD>Yes<TD>100<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>FTIM<TD>Flush Time in Sec<TD>ULONG<TD>Yes<TD>900<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>MASK<TD>Bit Mask<TD>USHORT<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD>No</TABLE>

=== Operator Display Parameters ===

These fields are used to give meaning to the record's data for the operator's sake. The HOPR and LOPR fields indicate the upper and lower limits for the CVAL and LVAL fields. In addition, the HOPR and LOPR fields determine the control limits for these fields. The PREC field determines the displayed precision for the CVAL, AVAR, and LVAL fields. The EGU field indicates the engineering units for the VAL, CVAL, AVAR, and LVAL fields.

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>NAME<TD>Record Name<TD>STRING [29]<TD>Yes<TD>Null<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<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>Precision<TD>SHORT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>EGU<TD>Engineering Units<TD>STRING[16]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No</TABLE>

=== Run-time Parameters ===

These parameters are all used for the record's internal processing or to access the record's data, except for the RES field which can be written to at run-time to reset the record. The ARCH, VALS, TIMS, and NSCS are all array fields of size NVAL. Their arrays contain the archived data. The ARCH field points to an array of data structures, each of which contains the value of the PV, the time stamp when the value was taken, and the status and severity of the PV when the value was taken. The VALS field points to an array containing only the value part of each sample; the TIMS field points to an array containing only the seconds part of the time stamp of each sample, while the NSCS field points to an array containing only the nanoseconds part of each sample. Each array is of the size specified in the NVAL field. None of these array fields are directly accessible at run-time. However, the VALS and TIMS arrays are accessible through the VAL and TIM fields.

The FLSH field is an internal flag that indicates whether or not the VALS, TIMS, and NSCS fields are to be flushed when monitors are posted.

When the user changes the RES field to a non-zero value at run-time, the NUSE and CCNT fields are set equal to zero. In addition, the TIMS and NSCS pointers are set to NULL. RES is then set back to zero.

The LVAL field contains the last value archived. The LTIM field contains the time in seconds at which the last value was archived. The CCNT keeps track of the array index. When a sample is archived, it's values and time stamps are written into the CCNT index of the appropriate arrays. The NUSE field keeps track of the number of samples that have been archived, while the NUSB field keeps track of the number of samples that have been written into the current buffers/arrays. For example, if data for five samples has been written into the ARCH, VALS, TIMS, and NSCS fields, then NUSB will be five. The FTOF field is used as an offset when comparing the LTIM field with the current time. It will usually have the value of one.

<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>ARCH<TD>Archive Array<TD>NOACCESS<TD>No<TD>NA<TD>No<TD>No<TD>No<TD>No<TR>
<TD>VALS<TD>Values Array<TD>NOACCESS<TD>No<TD>NA<TD>No<TD>No<TD>Yes<TD>No<TR>
<TD>TIMS<TD>Times Array Seconds<TD>NOACCESS<TD>No<TD>NA<TD>No<TD>No<TD>Yes<TD>No<TR>
<TD>NSCS<TD>Times Array Nanoseconds<TD>NOACCESS<TD>No<TD>NA<TD>No<TD>No<TD>Yes<TD>No<TR>
<TD>VAL<TD>Array Value<TD>NOACCESS<TD>No<TD>NA<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>TIM<TD>Array Times Seconds<TD>NOACCESS<TD>No<TD>NA<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>NSC<TD>Array Times Nanoseconds<TD>NOACCESS<TD>No<TD>NA<TD>No<TD>No<TD>No<TD>No<TR>
<TD>FLSH<TD>Flush Flag<TD>ULONG<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>RES<TD>Reset<TD>SHORT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>LVAL<TD>Last Value Stored<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LTIM<TD>Last Time Monitored<TD>ULONG<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>CCNT<TD>Current Buffer Counter<TD>ULONG<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>NUSE<TD>Number Used<TD>ULONG<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>NUSB<TD>Number Used in Buffer<TD>ULONG<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>FTOF<TD>Flush Time Offset<TD>ULONG<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No</TABLE>

----

EPICS Record Reference Manual - 19 MAY 1998

RRM 3-14 Analog Output

2008-04-18T19:04:17Z

KazimierzGofron:

[[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 can 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>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>OIF<TD>Out Full or Incremental<TD>RECCHOICE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DRVH<TD>Drive High<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>DRVL<TD>Drive Low<TD>FLOAT<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>FLOAT<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>CVTCHOICE<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>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>EGUL<TD>Engineering Units Low<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>AOFF<TD>Adjustment Offset<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>ASLO<TD>Adjustment Slope<TD>FLOAT<TD>Yes<TD>1<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>ESLO<TD>Slope for Linear Conversions<TD>DOUBLE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>EOFF<TD>Offset for Linear Conversions<TD>DOUBLE<TD>No<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 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. They are used to calculate the value ESLO, and are thus only significant for records that use linear conversions. 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. Used if LINR specifies LINEAR.<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, then X = (OVAL - EOFF) / ESLO, else if LINR==NO_CONVERSION, then X = OVAL, else X is obtained via breakpoint table.

: 2. X = X * ASLO + AOFF

: 3. RVAL = round(X) - ROFF

Since RVAL is now defined, the last step is to set UDF to FALSE.

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>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 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>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>GBLCHOICE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HSV<TD>High Alarm Severity<TD>GBLCHOICE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LSV<TD>Low Alarm Severity<TD>GBLCHOICE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LLSV<TD>Lolo Alarm Severity<TD>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>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 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>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 ===

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, EGUL or ROFF is modified. To support linear conversion, EOFF and ESLO must be set accordingly.

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.

----

EPICS Record Reference Manual - 19 MAY 1998

RRM 3-14 Analog Input

2008-04-18T19:02:47Z

KazimierzGofron:

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

= ai - Analog Input =

The normal use for this record type is to obtain an analog value from hardware and then convert it to engineering units. Most device support modules obtain values from hardware. The record supports alarm limits, conversion to engineering units, smoothing, and graphics and control limits.

Two soft device modules <CODE>Soft Channel</CODE> and <CODE>Raw Soft Channel</CODE> are provided to obtain input via database or channel access links or via dbPutField or dbPutLink requests. The first module reads values directly into VAL. The second reads values into RVAL. These values are then converted just like raw values obtained from hardware device support modules. If soft device support with a constant INP link is chosen, then the VAL field can be modified via dbPuts.

== Parameter Fields ==

The fields fall into the following groups of parameters:

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

=== Scanning Parameters ===

The analog 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 ===

These parameters determine where the record gets its input and how it converts the raw signal to engineering units. For records that obtain input from devices or that use the Raw Soft Channel device support, the device support routines will return the value of this device into the RVAL field. Unless the LINR conversion field specifies NO CONVERSION, the proper conversion algorithm will be performed and the resulting value will be placed in the VAL field.

A further explanation of these fields follows.

<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>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>LINR<TD>Type of Conversion<TD>CVTCHOICE<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>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>EGUL<TD>Engineering Units Low<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>AOFF<TD>Adjustment Offset<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>ASLO<TD>Adjustment Slope<TD>FLOAT<TD>Yes<TD>1<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>ESLO<TD>Slope for Linear Conversions<TD>DOUBLE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>EOFF<TD>Offset for Linear Conversions<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>SMOO<TD>Smoothing Factor<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

==== Input Specification ====

As stated in the introduction to this chapter, what is entered in the INP field of the analog input record determines its run-time behavior. For an analog record that obtains its value from hardware, the address of the I/O card must appear in the INP field, and the name of the device support module must appear in the device type field (DTYP). 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 dbst utility in R3.13.

The INP field can also specify a constant value, a channel access link, or a database link. When configured with a constant value, the record's VAL field is initialized with the value given to the field and the VAL field can be changed using dbPuts. See [[RRM 3-14 Concepts#Address Specification|Address Specification]] for information on database and channel access links.

When INP is a constant, a database link, or a channel access link either one of two soft device support modules, Raw Soft Channel or Soft Channel, must be specified in DTYP field. See [[#Device Support For Soft Records|Device Support For Soft Records]] in this chapter for more on how these device support modules work.

==== Conversion Related Fields ====

The LINR field determines if a conversion is performed and which conversion algorithm is used to convert the raw value (RVAL). No conversions are performed if the Soft Channel device support module is used. For other records that use other device support modules, the LINR field determines what adjustments or conversions are made on the raw value. The LINR field specifies either LINEAR, NO CONVERSION, or the name of a breakpoint table, such as typeKdegC. LINEAR specifies a linear conversion; NO CONVERSION, no conversion at all; and a breakpoint table, a breakpoint conversion. Note that the EGUF, EGUL, EOFF, and ESLO fields are not used when a breakpoint table or NO CONVERSION is specified.

<TABLE BORDER="1">
<TD>EGUF<TD rowspan=2>The user must calculate these fields when configuring the database. They are used to calculate the EOFF and ESLO, and are thus only significant for records that use linear conversions. 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. Used if LINR specifies LINEAR.<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>
<TD>SMOO<TD>A value between 1 and 0 specified by the user, with 0 meaning no smoothing and 1 meaning ultimate smoothing (in fact, the data value will never change). See [[RRM 3-14 Concepts#Conversion Specification|Conversion Specification]] for more information on what this field does. It is used for all records but <CODE>Soft Channel</CODE> records.
</TABLE>

The record processing routine performs the following algorithm for all records except those that use the Soft Channel device support routine. Be aware that step 3 is performed only when the record specifies LINEAR:

: 1. Val= RVAL + ROFF

: 2. Val = Val * ASLO + AOFF

If the conversion algorithm is LINEAR, the raw value is converted via the equation:

: 3. val = val * ESLO + EOFF

If the conversion is via a breakpoint table, the new value is obtained.

The next step is to apply the following smoothing algorithm:

: 4. if SMOO is 0 or INIT is True, VAL = val

: 5. else VAL = val * (1 - SMOO) + Previous_value * SMOO

Since VAL is now defined, the last step is to set UDF to FALSE.

For a complete explanation on conversion parameters, see [[RRM 3-14 Concepts#Conversion Specification|Conversion Specification]]. To see how Raw Soft Channel device support uses these parameters, see [[#Device Support For Soft Records|Device Support For Soft Records]] in this chapter.

=== Operator Display Parameters ===

These parameters are used to present meaningful data to the operator. They display the value and other parameters of the analog input either textually or graphically. EGU is a string of up to 16 characters describing the units that the analog input 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, HIHI, HIGH, LOW, and LOLO fields. Both the get_graphic_double and get_control_double record support routines retrieve these fields.

The PREC field determines the floating point precision with which to display VAL. 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>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> <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 state for analog inputs are the SCAN, READ, and limit alarms. 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. 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. [[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>LOLO<TD>Lolo 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>HHSV<TD>Hihi Alarm Severity<TD>GBLCHOICE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LLSV<TD>Lolo Alarm Severity<TD>GBLCHOICE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>HSV<TD>High Alarm Severity<TD>GBLCHOICE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>LSV<TD>Low Alarm Severity<TD>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 appropriate 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 scanned, 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.

<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 input. They are not configurable by the user, but many can be modified after initialization. They represent the current state of the analog input. Many of them are used to process the analog input more efficiently.

The ORAW field is used to decide if monitors should be triggered for RVAL when monitors are triggered for VAL. The LALM, MLST, and ALST fields are used to implement the hysteresis factors for monitors on the VAL field.

The PBRK field contains a pointer to the breakpoint table specified in the LINR field (if any). The LBRK field indicates the name of the last breakpoint table used (if any).

<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>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
</TABLE>

The following fields are used to operate the analog 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 ===

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, all of which are used for the monitor parameters.

==== 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_ai() routine is defined. If either does not exist, an error message is issued and processing is terminated.

INIT is then set to TRUE.

If device support includes init_record, it is called.

==== process ====

See next section.

==== special ====

The only special processing for analog input records is SPC_LINCONV. which is invoked whenever any 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 the structure 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.
# 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 writing the new value. In this case, the processing routine merely returns, leaving PACT TRUE.
# PACT is then set to TRUE, TIME is set to tslocaltime and the return status value of readValue is checked. convert is called only if status is 0. If status is 2, then convert is not called, but status is reset to 0.
# Perform conversion if necessary: After conversions (if any), 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 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 are checked whenever other monitors are invoked.
#* NSEV and NSTA are reset to 0.
# Scan forward link if necessary, set PACT and INIT to FALSE, and return.

== Device Support ==

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

Each analog 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 analog input value whenever read_ai 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<TD>This field is used by device support only if it obtains a value already converted to engineering units. See RVAL below.<TR>
<TD>INP<TD>Input Link<TD>This field is used by the device support routines to locate its input.<TR>
<TD>EGUF<TD>Engineering Units Full<TD rowspan=2>These fields are used to calculate ESLO and EOFF. 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>It is the responsibility of the device support routine to give this field a value. If the device support routine obtains a value already in engineering units, it should place the value in VAL and return a value of 2.
</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_ai ====

read_ai(precord)

This routine must provide a new input 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 read_ai.

Because PACT is still TRUE read_ai knows that this is a request to retrieve the data obtained by the previous call. When finished, read_ai should set PACT to FALSE and return one the following values:

: 0: Success. A new raw value is placed in RVAL. convert will be called.

: 2: Success, but don't call convert. This is useful if read_ai obtains a value already converted to engineering units or in the event a hardware failure is detected.

: Other: Error.

==== special_linconv ====

special_linconv(precord,after)

This routine is called whenever any of the fields LINR, EGUF, EGUL or ROFF is modified. To support linear conversion, EOFF and ESLO must be set accordingly.

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 ADC 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 input records not related to actual hardware devices. The INP link type must be either CONSTANT, DB_LINK or CA_LINK.

==== Soft Channel ====

This module places a value directly in VAL. read_ai always returns a value of 2, which means that no conversion will ever be attempted.

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

read_ai 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_ai sets UDF to FALSE. The status of recGblGetLinkValue is returned.

If soft support is chosen, the following fields become meaningless: LINR, EGUF, EGUL, EOFF, ESLO, ROFF, AOFF, ASLO, and SMOO. The read_ai routine always returns a value of 2 which means don't convert.

==== Raw Soft Channel ====

This module is like the previous except that it places its value in RVAL and read_ai returns a value of 0. Thus the record processing routine will convert the raw value in the normal way.

If raw soft support is chosen, the fields EGUF and EGUL become meaningless. ESLO and EOFF always have their default values of 1 and 0.

----

EPICS Record Reference Manual - 19 MAY 1998

RRM 3-14 Waveform

2008-04-18T18:51:15Z

KazimierzGofron:

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

= Waveform =

The waveform record type is used to interface waveform digitizers. The record stores its data in arrays. The array can contain any of the supported data types.

== Parameter Fields ==

The waveform's fields fall into the following categories:

* scan parameters
* read parameters
* operator display parameters
* run-time parameters

=== Scan Parameters ===

The waveform record has the standard fields for specifying under what circumstances the record will be processed. These fields are listed in [[RRM 3-13 dbCommon#Scan Fields|Scan Fields]]. In addition, [[RRM 3-13 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 Parameters ===

These fields are configurable by the user to specify how and from where the record reads its data. How the INP field is configured determines where the waveform gets its input. It can be a hardware address, a channel access or database link, or a constant. Only in records that use soft device support can the INP field be a channel access link, a database link, or a constant. Otherwise, the INP field must be a hardware address. See [[RRM 3-13 Concepts#Address Specification|Address Specification]] for information on the format of hardware addresses and database links.

The DTYP field must contain the name of the appropriate device support module. 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 (R3.13).

The values retrieved from the input link are placed in an array referenced by VAL. (If the INP link is a constant, elements can be placed in the array via dbPuts.) NELM specifies the number of elements that the array will hold, while FTVL specifies the data type of the elements.

The RARM field causes the device to re-arm when this field is set to 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>INP<TD>Input Link <TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>NELM<TD>Number of Elements in array <TD>ULONG<TD>Yes<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>FTVL<TD> Field Type of Value<TD>[[RRM 3-13 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>RARM<TD> Rearm<TD>SHORT<TD>Yes<TD>0<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 waveform either textually or graphically.

EGU is a string of up to 16 characters describing the units that the waveform 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 array elements referenced by the VAL field. 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 the array values. It is used whenever the <CODE>get_precision</CODE> record support routine is called.

See [[RRM 3-13 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 waveform record has the alarm parameters common to all record types. [[RRM 3-13 dbCommon#Alarm Fields|Alarm Fields]] lists other fields related to a alarms that are common to all record types.

=== Run-time Parameters ===

These parameters are used by the run-time code for processing the waveform. They are not configured using a configuration tool. Only the VAL field is modifiable at run-time.

VAL references the array where the waveform stores its data. The BPTR field holds the address of the array.

The NORD field holds a counter of the number of elements that have been read into the array. It is reset to 0 when the device is rearmed. The BUSY field indicates if the device is armed but has not yet been digitized.

<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>See FTVL<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>BPTR<TD>Buffer Pointer <TD>NOACCESS<TD>No<TD>0<TD>No<TD>No<TD>No<TD>No<TR>
<TD>NORD <TD>Number of Elements Read <TD>ULONG<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>BUSY<TD>Busy<TD>SHORT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No
</TABLE>

The following fields are used to operate the waveform in the simulation mode. See [[RRM 3-13 Common#Simulation Mode|Simulation Mode]] 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-13 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-13 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

== Record Support ==

=== Record Support Routines ===

==== init_record ====

Using NELM and FTVL space for the array is allocated. The array address is stored in the 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. VAL 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 the array.

==== cvt_dbaddr ====

This is called by dbNameToAddr. It makes the dbAddr structure refer to the actual buffer holding the result.

==== get_array_info ====

Obtains values from the array referenced by VAL.

==== put_array_info ====

Writes values into the array referenced by VAL.

==== get_units ====

Retrieves EGU.

==== get_prec ====

Retrieves PREC if field is VAL field. Otherwise, calls <CODE>recGblGetPrec()</CODE>.

==== get_graphic_double ====

Sets the upper display and lower display limits for a field. If the field is VAL 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 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_graphic_double ====

Sets the following values:

upper_disp_limit = HOPR
lower_disp_limit = LOPR

==== get_control_double ====

Sets the following values

upper_ctrl_limit = HOPR
lower_ctrl_limit = LOPR

=== 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.
# Call device support read routine.
# If PACT has been changed to TRUE, the device support read 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 always 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 waveform record must have an associated set of device support routines. The primary responsibility of the device support routines is to obtain a new array value whenever read_wf 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-13 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>INP<TD>Input Link<TD>This field is used by the device support routines to locate its input.<TR>
<TD>RATE<TD>Sampling Rate<TD>Some device support modules may find this useful.<TR>
<TD>PTSS<TD>Pre-trigger Samples<TD>Some device support modules may find this useful.<TR>
<TD>NELM<TD>Number Of Elements In Array<TD> <TR>
<TD>FTVL<TD>Field Type Of Value<TD>This is DBF_STRING, ... , DBF_ENUM. The device support routine should check that this is correctly defined.<TR>
<TD>RARM<TD>Rearm<TD>When set to 1, the device will be rearmed. The device support routine should reset it to 0 when done.<TR>
<TD>BPTR<TD>Holds Address of Array<TD> <TR>
<TD>NORD<TD>Number of Elements Read<TD>Device support must set this value when it completes.<TR>
<TD>BUSY<TD>Is device busy?<TD> 
</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_wf ====

read_wf(precord)

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

* 0: Success.
* Other: Error.

=== Device Support For Soft Records ===

The <CODE>Soft Channel</CODE> device support module is provided to read values from other records and store them in arrays. If INP is a constant link, then read_wf does nothing. In this case, the record can be used to hold arrays written via dbPuts. If INP is a database or channel access link, the new array value is read from the link. NORD is set.

This module places a value directly in VAL.

If the INP link type is constant, then NORD is set to zero. If the INP link type is PV_LINK, then dbCaAddInlink is called by init_record.

read_wf calls recGblGetLinkValue which performs the following steps:

If the INP link type is CONSTANT recGblGetLinkValue does nothing.

If the INP link type is DB_LINK, then dbGetLink is called to obtain a new input value. If dbGetLink returns an error, a LINK_ALARM with a severity of INVALID_ALARM is raised.

If the INP link type is CA_LINK, then dbCaGetLink is called to obtain a new input value. If dbCaGetLink returns an error, a LINK_ALARM with a severity of INVALID_ALARM is raised.

NORD is set to the number of values returned and read_wf returns.

----

EPICS Record Reference Manual - 19 MAY 1998

RRM 3-14 Wait

2008-04-18T18:50:36Z

KazimierzGofron:

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

= Wait =

: Ned D. Arnold
: Advanced Photon Source
: Argonne National Laboratory

This chapter describes the capabilities and use of the Wait record. The Wait record was developed primarily to provide "reassignable" link fields that could be changed during run time. A unique library was developed to provide this feature. Since all EPICS standard link fields are "reassignable" in R3.13 and above, the Wait record and its associated library are somewhat obsolete. For new designs, it is recommended that the ''Calcout'' record be used, which provides the same function as the Wait record (plus more) while using the standard EPICS links.

The Wait record is derived from the Calc record with the following additional features:

* reassignable PV links
* an output link
* a desired output link
* an output event number to post
* and several options as to when it will execute the output link and event posting.

The Wait record also has the capability to process as a result of an input changing (via CA monitors), and it can be used to do ''conditional'' processing within the database. Its name is derived from the original requirement that initiated its development -- "I want to wait until all the motors have stopped and then trigger the detector."

== Parameter Fields ==

The fields fall into the following categories:

* scan parameters
* read parameters
* expression-related parameters
* desired output parameters
* write parameters
* operator parameters
* monitor parameters
* run-time and simulation mode parameters

=== Scan Parameters ===

The wait record has the standard fields for specifying under what circumstances the record will be processed. In addition to the standard scan mechanisms available to all records (periodic, passive, event, etc.), the wait record can be specified to process as a result of one of its input values changing (using Channel Access monitors). This offers immediate response to an input change (rather than waiting for the next periodic scan) while minimizing record processing that is not required. The scan mechanism choice <CODE>I/O Intr</CODE> will enable this feature. For the current EPICS release, an additional module, <CODE>caMonitor.o</CODE>, must be compiled and loaded with the wait record support to provide this feature.

: <B>Note: Because of the event driven nature of this feature, it is quite easy to configure a database that results in an infinite loop which uses all available CPU time. If the wait record is set to process as a result of a channel changing and the processing of the wait record causes the channel to change again, an infinite loop will result. The symptom will be a loss of all channel access connections (lower priority tasks) even though the shell responds normally. Using the <CODE>spy</CODE> vxWorks utility will confirm the predicament by showing 0% free CPU time.</B>

[[RRM 3-13 Concepts#Scanning Specification|Scanning Specification]] explains how the rest of these fields are used. They are listed in [[RRM 3-13 dbCommon#Scan Fields|Scan Fields]].

=== Read Parameters ===

Like the Calc record, the read parameters for the Wait record consist of 12 input links--INAN, INBN, ... INLN. The fields can be database links or constants. If they are links, they must specify another record's field in the same IOC. If they are constants, the corresponding value field for the link (A-L) will be initialized with the constant's value and can be changed via dbPuts. The Wait record does not support direct links to hardware.

Unlike the Calc record, these input links can be modified during run time. These are ASCII fields which have a special processing routine attached to them. When changed, the routine is called. The record will use the new link the next time the record is processed.

A consequence of reassignable links is that one cannot force the processing of any specified records prior to retrieving the data from them (i.e. there is no .PP flag). This should be considered when designing a database using the Wait record.

In this initial version, the ''reassignable'' links do not support channel access connections external to the IOC. Until this feature is added, the specified Process Variables must reside on the same IOC.

See [[RRM 3-13 Concepts#Address Specification|Address Specification]] for information on specifying links and constants.

<TABLE BORDER="1">
<TH>Field<TH>Summary<TH>Type<TH>DCT<TH>Initial<TH>Access<TH>Modify<TH>Rec Proc Monitor<TR>
<TD>INAN<TD>Input Link A Name<TD>STRING[40]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>INBN<TD>Input Link B Name<TD>STRING[40]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>INCN<TD>Input Link C Name<TD>STRING[40]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>INDN<TD>Input Link D Name<TD>STRING[40]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>INEN<TD>Input Link E Name<TD>STRING[40]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>INFN<TD>Input Link F Name<TD>STRING[40]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>INGN<TD>Input Link G Name<TD>STRING[40]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>INHN<TD>Input Link H Name<TD>STRING[40]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>ININ<TD>Input Link I Name<TD>STRING[40]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>INJN<TD>Input Link J Name<TD>STRING[40]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>INKN<TD>Input Link K Name<TD>STRING[40]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>INLN<TD>Input Link L Name<TD>STRING[40]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes
</TABLE>

=== Expression-related Parameters ===

The expression related fields of the Wait record are identical to that of the Calc record. The two main fields are the CALC and RPCL fields. The CALC field contains the infix expression which the record routine will use when it processes the record. The user enters an expression in this field. The resulting value of the expression is placed in the VAL field The write parameters of the record can write this value if configured to.

The CALC field is actually converted to opcode and stored as a reverse polish expression, or postfix expression, in the RPCL field. It is this expression which is actually used to calculate VAL. CALC can be changed at run-time, and the special record routine calls a function to convert it to the postfix expression. One difference between the Calc record and the Wait record is that the Wait record contains a flag field (CLCV) that indicates if the expression is a valid one. It will be true (non-zero) if the expression is invalid, in which case an error message is generated.

The reverse polish calculation is evaluated most efficiently during run-time. The range of expressions supported by the calculation record are separated into operands, algebraic operations, trigonometric operations, relational operations, logical operations, parentheses and commas, and the question mark operator.

<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 can use the values retrieved from the INP''x'' links as operands, these values being 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 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. In addition, the RNDM unary function can be included as an operand 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<TR>
<TD>A<TD>Input Values A<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TR>
<TD>B<TD>Input Values B<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TR>
<TD>C<TD>Input Values C<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TR>
<TD>D<TD>Input Values D<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TR>
<TD>E<TD>Input Values E<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TR>
<TD>F<TD>Input Values E<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TR>
<TD>G<TD>Input Values G<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TR>
<TD>H<TD>Input Values H<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TR>
<TD>I<TD>Input Values I<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TR>
<TD>J<TD>Input Values J<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TR>
<TD>K<TD>Input Values K<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<TD>Yes<TR>
<TD>L<TD>Input Values L<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes/No<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 parentheses are supported.

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

==== Conditional Expression ====

The "C" 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

=== Desired Output Parameters ===

Using the choices in the Data Output field (DOPT) explained in the next section, the Wait record can be configured to write as its output the result of its calculation (the value in VAL) or it can be configured to write a desired output value, fetched from an input link. The desired output fields for the Wait record are similar to the desired output parameters of other output records.

In the desired output location (DOLN) field, the user specifies a link from which the record will retrieve the value that it writes (if the DOPT field specifies DOLD). The value is retrieved and placed in the desired output location data field (DOLD). If DOLN specifies no link, a flag field indicates that the DOLN field is invalid. When the DOLN field is invalid, the value of DOLD can be set via dbPuts at run-time.

<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>DOLN <TD>Desired Output Location<TD>STRING [40]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DOLD<TD>Desired Output Location Data <TD>DOUBLE<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No
</TABLE>

=== Write Parameters ===

The Wait record can write either the result of its calculation (VAL) or the value retrieved by the DOLN field. If the user specifies <CODE>Use VAL</CODE> in the Data Option (DOPT) field, then the value in VAL will be written. If the user specifies <CODE>Use DOL</CODE>, the value retrieved from the DOLN link and contained in the DOLD field will be written. The DOPT field can be changed during run-time.

The Output Link Name (OUTN) specifies where the record is to write the output value.

The Wait record does not have to write its output every time the record processes. This allows "downstream" processing of records to be done conditionally. The record has ''output execution'' options which can be specified in the OOPT field. These options are as follows.

* <CODE>Every Time</CODE>: Outputs are executed every time the record processes.
* <CODE>On Change</CODE>: Outputs are executed if the result of the calculation (VAL) is different than the previous time the record was processed.
* <CODE>When Zero</CODE>: Outputs are executed if the result of the calculation is zero.
* <CODE>When Non-zero</CODE>: Outputs are executed if the result of the calculation is not zero.
* <CODE>Transition To Zero</CODE>: Outputs are executed if the result of the calculation is zero and the previous value was not zero.
* <CODE>Transition To Non-zero</CODE>: Outputs are executed if the result of the calculation is not zero and the previous value was zero.
The Wait record can also post an event. If a non-zero value is entered into the OEVT (Output Event) field, the record will "post an event" (using the entered number as the event number) whenever the output link is executed. This is a way of initiating several other records to process as a result of a calculation.

<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>OOPT<TD>Output Option<TD>[[RRM 3-13 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>OUTN <TD>Output Link Name <TD>STRING [40]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DOPT<TD>Data Option<TD>[[RRM 3-13 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>OEVT<TD> Output Event <TD>USHORT<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. They display the value and other parameters of the Wait record either textually or graphically.

The HOPR and LOPR fields set the upper and lower display limits for the VAL field. The <CODE>get_graphic_double</CODE> retrieves 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-13 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>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 wait record has the alarm parameters common to all record types. [[RRM 3-13 dbCommon#Alarm Fields|Alarm Fields]] lists other fields related to a alarms that are common to all record types.

=== Monitor Parameters ===

These parameters are delta values that implement a deadband on the value-change monitors for the VAL field. Monitors are sent when the value field exceeds the last monitored field (MLST, for instance) 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 processed, monitors are triggered. The ADEL field is used for archive monitors and the MDEL field for all other types of monitors. See [[RRM 3-13 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 parameters are used by the run-time code for processing the Wait record. They are not configurable. They represent the current state of the record. The record support routines use some of them to process the record or to implement monitors.

The OVAL field is used to implement monitors on the VAL field. If VAL differs from OVAL (taking into account the deadband) then monitors for VAL are triggered.

The LA-LL fields are used to implement monitors for the A-L field, the fields which hold the values retrieved from the input links. They hold the values retrieved from INPA-INPL the last time the record was processed. For instance, when A, the current value retrieved from INPA, does not equal LA, the last value retrieved, then monitors for A are triggered.

The DOLV and CLCV are flag fields. The DOLV flag is used to indicate if the process variable specified in the Desired Output Location (DOLN) field is a valid name. If it is not, the desired output value is not retrieved from DOLN. The CLCV flag is used to indicate if the Wait record's CALC expression is a mathematically valid one.

The CBST field contains a pointer to a record private structure. It is not of concern to the user.

<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>CBST<TD>Callback Structure<TD>NOACCESS<TD>No<TD>Null<TD>No<TD>No<TD>No<TD>No<TR>
<TD>OVAL<TD>Old Value <TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DOLA <TD>Desired Output Location Address<TD>NOACCESS<TD>No<TD>Null<TD>No<TD>No<TD>No<TD>No<TR>
<TD>DOLV<TD>Desired Output Location Valid<TD>LONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<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>CLCV <TD>Calculation String Valid<TD>LONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>LA<TD>Previous Input<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>LB<TD>Previous Input<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>LC<TD>Previous Input<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>LD<TD>Previous Input<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>LE<TD>Previous Input<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>LF<TD>Previous Input<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>LG<TD>Previous Input<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>LH<TD>Previous Input<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>LI<TD>Previous Input<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>LJ<TD>Previous Input<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>LK<TD>Previous Input<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>LL<TD>Previous Input<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

----

EPICS Record Reference Manual - 19 MAY 1998

RRM 3-14 Transform

2008-04-18T18:49:28Z

KazimierzGofron:

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

= Transform Record =

The Transform record combines features of the Calcout and Seq records, with
16 sets of the following fields:

* input link
* input-link status
* value (from input link or from calc expression)
* calc expression
* calc-expression status
* output link
* output-link status
* comment

For concreteness, here is the first set of fields:

INPA - link from which value for A will be read
IAV - status of INPA
A - value
CLCA - expression whose value might be written to A
CAV - validity of expression CLCA
OUTA - link to which A will be written
OAV - status of OUTA
CMTA - comment (description)

The value fields A-P are "process-passive", which means that writing to one of them from
a CA client, or via a "CA" link, will cause the record to process, if its scan state is "Passive".
If the input link associated with a value field is not blank and is not an initialization constant, then
writes to that value field are not permitted.

An expression is evaluated only if the associated value field has not been modified (either by a <i>put</i> from
some external agent, or as the result of input-link execution) since the last time the record processed.

== Background ==
The Transform record was originally intended to perform the sequences of conditional calculations required to implement bidirectional coordinate transformations.

Example: You have defined two records containing values we'll call "L" and "R" (the left and right edges of a slit, say). Sometimes the user wants to control L and R individually, and sometimes he wants to control a combination of L and R--say (L-R) and (L+R)/2, the width and center of the slit system. You can implement a bidirectional coordinate transformation with the following expressions (where position values are assumed to increase as we go from left to right):

<table border = "1">
<th>field<th>expression<th>comment
<tr> <td>A <td>C-D/2 <td>position of left edge of slit
<tr> <td>B <td>C+D/2 <td>position of right edge of slit
<tr> <td>C <td>(A+B)/2 <td>position of center of slit
<tr> <td>D <td>B-A <td>width of slit
</table>

Now, if a user command moves the left side of the slit (A changes) and causes the record to process, A will not be recalculated because it's value is new, the right side of the slit will remain still (B is unnecessarily recalculated from old values of C and D), the position of the slit center (C) will change as expected, and the slit width (D) will change as expected. Thus, all four fields will contain consistent information about the two degrees of freedom controlled by the record, and effectively we have two actual devices and two virtual devices.

We don't care which two fields (out of A..D) correspond to actual motion-control devices, and two channel-access clients that make different assumptions about how a slit should be implemented can control this slit without modification. With an additional, similar transform record driven from the readback fields of the actual motion-control devices, we can calculate readback values for the virtual devices as well.

We could have accomplished nearly the same effect with six CALC records and some FANOUTs, but two of the drive fields (A,B,C,D) would always be inconsistent with their readbacks.

== Parameter Fields ==

The fields in this record fall into these categories:

* scan parameters
* read parameters
* expression parameters
* output parameters
* operator display parameters
* alarm parameters

=== Scan Parameters ===

The Transform record has the standard fields for specifying under what circumstances the record will be processed. These fields are listed in [[RRM 3-13 dbCommon#Scan Fields|Scan Fields]]. In addition, [[RRM 3-13 Concepts#Scanning Specification|Scanning Specification]] explains how these fields are used. Since the Transform 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 Transform record consist of 16 input links INPA, INPB, ... INPP. 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, associated value fields will be initialized with the constants. These fields cannot be hardware addresses. In addition, the Transform record contains the IAV, IBV, . . . IPV fields which indicate the states 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-13 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>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>INPP<TD>Input Link P<TD>INLINK<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes
</TABLE>

=== Expression Parameters ===

Like the Calcout record, the Transform record has fields in which the developer or user can enter an infix
expression to be evaluated when the record is processed. There are, in fact, 16 such fields, each of which
is a member of its own (<i>inputlink</i>, <i>value</i>, <i>expression</i>, <i>outputlink</i>) group. For
each group, if <i>inputlink</i> is not blank and is not simply a constant initializer, then <i>expression</i> may be evaluated when
the record processes, and the result will be placed in <i>value</i>.

Transform-record expressions are very similar to Calcout-record expression described elsewhere in this
manual. Instead of the standard EPICS calc engine (which does not permit an expression
to reference more than 12 input fields), Transform-record expressions are handled by the sCalcout (string calculation and output) record's engine. The differences, between these engines, that matter for
transform-record 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. (EPICS 3.14-compatible version only.)</font>
* <font color="blue">The binary operators '>&' (larger of the operands) and '<&' (smaller) are supported. (EPICS 3.14-compatible version only.)</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'.)
* The values of the variables A...P used in expressions may be the results of previously evaluated expressions.

=== Output Parameters ===

The Transform record has 16 output links, executed in order from OUTA to OUTP. Unlike the Calcout record,
these links are not conditional; they execute every time the record processes.

<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 Specification<TD>OUTLINK<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>N/A<TD>No<TR>
<TD>OUTB<TD>Output Specification<TD>OUTLINK<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>N/A<TD>No<TR>
<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TR>
<TD>OUTP<TD>Output Specification<TD>OUTLINK<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>N/A<TD>No<TR>

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

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. This field is not very useful, because it's unlikely to pertain to all 16 value fields.

The IAV-IPV fields indicate the states of the links INPA-INPP. These fields 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 OAV-OPV fields indicate the states of the OUTA-OUTP links. They have the same possible values as the IAV-ILV fields.

The CAV-CPV fields indicate the validity of the expressions in the CLCA-CLCP fields, respectively. If an expression is invalid, its status field is set to one.

The IVLA field specifies how the record should behave if any of its input links references a record that is in alarm. There are two possibilities:

* "Ignore Error" - Use whatever value was gotten from the link, and proceed as if there had not been any error indication.
* "Do Nothing" - Stop after all input values have been retrieved: do not evaluate expressions, and do not execute output or forward links.

See [[RRM 3-13 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>IAV<TD>Link Status of INPA<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>IBV<TD>Link Status of INPB<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TR>
<TD>IPV<TD>Link Status of INPP<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>OAV<TD>Link Status of OUTA<TD>RECCHOICE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>OBV<TD>Link Status of OUTB<TD>RECCHOICE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TR>
<TD>OPV<TD>Link Status of OUTP<TD>RECCHOICE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>CAV<TD>CLCA Valid<TD>LONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>CBV<TD>CLCB Valid<TD>LONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TR>
<TD>CPV<TD>CLCP Valid<TD>LONG<TD>No<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 Transform record has no record-type-specific alarm fields.
See [[RRM 3-13 dbCommon#Alarm Fields|Alarm Fields]] for the list of alarm fields common to all record types.

== Record Support ==

=== Record Support Routines ===

==== init_record ====

For each constant input link, the corresponding value field is initialized with the constant.

A routine sCalcPostfix is called to convert the infix expression in CLCA-CLCV to postfix notation. The results are stored in RPCA-RPCP.

==== process ====

See next section.

==== special ====

This is called if any of the fields A-P, CLCA-CLCP, INPA-INPP, OUTA-OUTP 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_precision ====

Retrieves PREC.

=== Record Processing ===

==== process() ====

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

# Fetch values from all valid input links.
# For each value field <b>x</b>, in order from A to P: if the value has not been written to since the last time the record processed, call sCalcPerform(), which evaluates the expression specified in CLC<b>x</b> and stores the result in <b>x</b>.
# Post all fields the record has changed.
# Execute all valid output links, in order from OUTA to OUTP.
# Execute the forward link, set PACT FALSE, and return.

== Availability ==

The Transform record is not included with EPICS base. An EPICS 3.13-compatible version of this record is available as part of the [http://www.aps.anl.gov/aod/bcda/synApps/std/std.html std] module, which is part of the [http://www.aps.anl.gov/aod/bcda/synApps synApps] package of EPICS-based synchrotron-beamline software.
----

EPICS Record Reference Manual - 7 JUNE 2006

RRM 3-14 Transform

2008-04-18T18:48:48Z

KazimierzGofron:

= Transform Record =

The Transform record combines features of the Calcout and Seq records, with
16 sets of the following fields:

* input link
* input-link status
* value (from input link or from calc expression)
* calc expression
* calc-expression status
* output link
* output-link status
* comment

For concreteness, here is the first set of fields:

INPA - link from which value for A will be read
IAV - status of INPA
A - value
CLCA - expression whose value might be written to A
CAV - validity of expression CLCA
OUTA - link to which A will be written
OAV - status of OUTA
CMTA - comment (description)

The value fields A-P are "process-passive", which means that writing to one of them from
a CA client, or via a "CA" link, will cause the record to process, if its scan state is "Passive".
If the input link associated with a value field is not blank and is not an initialization constant, then
writes to that value field are not permitted.

An expression is evaluated only if the associated value field has not been modified (either by a <i>put</i> from
some external agent, or as the result of input-link execution) since the last time the record processed.

== Background ==
The Transform record was originally intended to perform the sequences of conditional calculations required to implement bidirectional coordinate transformations.

Example: You have defined two records containing values we'll call "L" and "R" (the left and right edges of a slit, say). Sometimes the user wants to control L and R individually, and sometimes he wants to control a combination of L and R--say (L-R) and (L+R)/2, the width and center of the slit system. You can implement a bidirectional coordinate transformation with the following expressions (where position values are assumed to increase as we go from left to right):

<table border = "1">
<th>field<th>expression<th>comment
<tr> <td>A <td>C-D/2 <td>position of left edge of slit
<tr> <td>B <td>C+D/2 <td>position of right edge of slit
<tr> <td>C <td>(A+B)/2 <td>position of center of slit
<tr> <td>D <td>B-A <td>width of slit
</table>

Now, if a user command moves the left side of the slit (A changes) and causes the record to process, A will not be recalculated because it's value is new, the right side of the slit will remain still (B is unnecessarily recalculated from old values of C and D), the position of the slit center (C) will change as expected, and the slit width (D) will change as expected. Thus, all four fields will contain consistent information about the two degrees of freedom controlled by the record, and effectively we have two actual devices and two virtual devices.

We don't care which two fields (out of A..D) correspond to actual motion-control devices, and two channel-access clients that make different assumptions about how a slit should be implemented can control this slit without modification. With an additional, similar transform record driven from the readback fields of the actual motion-control devices, we can calculate readback values for the virtual devices as well.

We could have accomplished nearly the same effect with six CALC records and some FANOUTs, but two of the drive fields (A,B,C,D) would always be inconsistent with their readbacks.

== Parameter Fields ==

The fields in this record fall into these categories:

* scan parameters
* read parameters
* expression parameters
* output parameters
* operator display parameters
* alarm parameters

=== Scan Parameters ===

The Transform record has the standard fields for specifying under what circumstances the record will be processed. These fields are listed in [[RRM 3-13 dbCommon#Scan Fields|Scan Fields]]. In addition, [[RRM 3-13 Concepts#Scanning Specification|Scanning Specification]] explains how these fields are used. Since the Transform 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 Transform record consist of 16 input links INPA, INPB, ... INPP. 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, associated value fields will be initialized with the constants. These fields cannot be hardware addresses. In addition, the Transform record contains the IAV, IBV, . . . IPV fields which indicate the states 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-13 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>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>INPP<TD>Input Link P<TD>INLINK<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>Yes
</TABLE>

=== Expression Parameters ===

Like the Calcout record, the Transform record has fields in which the developer or user can enter an infix
expression to be evaluated when the record is processed. There are, in fact, 16 such fields, each of which
is a member of its own (<i>inputlink</i>, <i>value</i>, <i>expression</i>, <i>outputlink</i>) group. For
each group, if <i>inputlink</i> is not blank and is not simply a constant initializer, then <i>expression</i> may be evaluated when
the record processes, and the result will be placed in <i>value</i>.

Transform-record expressions are very similar to Calcout-record expression described elsewhere in this
manual. Instead of the standard EPICS calc engine (which does not permit an expression
to reference more than 12 input fields), Transform-record expressions are handled by the sCalcout (string calculation and output) record's engine. The differences, between these engines, that matter for
transform-record 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. (EPICS 3.14-compatible version only.)</font>
* <font color="blue">The binary operators '>&' (larger of the operands) and '<&' (smaller) are supported. (EPICS 3.14-compatible version only.)</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'.)
* The values of the variables A...P used in expressions may be the results of previously evaluated expressions.

=== Output Parameters ===

The Transform record has 16 output links, executed in order from OUTA to OUTP. Unlike the Calcout record,
these links are not conditional; they execute every time the record processes.

<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 Specification<TD>OUTLINK<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>N/A<TD>No<TR>
<TD>OUTB<TD>Output Specification<TD>OUTLINK<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>N/A<TD>No<TR>
<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TR>
<TD>OUTP<TD>Output Specification<TD>OUTLINK<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>N/A<TD>No<TR>

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

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. This field is not very useful, because it's unlikely to pertain to all 16 value fields.

The IAV-IPV fields indicate the states of the links INPA-INPP. These fields 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 OAV-OPV fields indicate the states of the OUTA-OUTP links. They have the same possible values as the IAV-ILV fields.

The CAV-CPV fields indicate the validity of the expressions in the CLCA-CLCP fields, respectively. If an expression is invalid, its status field is set to one.

The IVLA field specifies how the record should behave if any of its input links references a record that is in alarm. There are two possibilities:

* "Ignore Error" - Use whatever value was gotten from the link, and proceed as if there had not been any error indication.
* "Do Nothing" - Stop after all input values have been retrieved: do not evaluate expressions, and do not execute output or forward links.

See [[RRM 3-13 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>IAV<TD>Link Status of INPA<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>IBV<TD>Link Status of INPB<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TR>
<TD>IPV<TD>Link Status of INPP<TD>RECCHOICE<TD>No<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>OAV<TD>Link Status of OUTA<TD>RECCHOICE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>OBV<TD>Link Status of OUTB<TD>RECCHOICE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TR>
<TD>OPV<TD>Link Status of OUTP<TD>RECCHOICE<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>CAV<TD>CLCA Valid<TD>LONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>CBV<TD>CLCB Valid<TD>LONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TD>...<TR>
<TD>CPV<TD>CLCP Valid<TD>LONG<TD>No<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 Transform record has no record-type-specific alarm fields.
See [[RRM 3-13 dbCommon#Alarm Fields|Alarm Fields]] for the list of alarm fields common to all record types.

== Record Support ==

=== Record Support Routines ===

==== init_record ====

For each constant input link, the corresponding value field is initialized with the constant.

A routine sCalcPostfix is called to convert the infix expression in CLCA-CLCV to postfix notation. The results are stored in RPCA-RPCP.

==== process ====

See next section.

==== special ====

This is called if any of the fields A-P, CLCA-CLCP, INPA-INPP, OUTA-OUTP 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_precision ====

Retrieves PREC.

=== Record Processing ===

==== process() ====

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

# Fetch values from all valid input links.
# For each value field <b>x</b>, in order from A to P: if the value has not been written to since the last time the record processed, call sCalcPerform(), which evaluates the expression specified in CLC<b>x</b> and stores the result in <b>x</b>.
# Post all fields the record has changed.
# Execute all valid output links, in order from OUTA to OUTP.
# Execute the forward link, set PACT FALSE, and return.

== Availability ==

The Transform record is not included with EPICS base. An EPICS 3.13-compatible version of this record is available as part of the [http://www.aps.anl.gov/aod/bcda/synApps/std/std.html std] module, which is part of the [http://www.aps.anl.gov/aod/bcda/synApps synApps] package of EPICS-based synchrotron-beamline software.
----

EPICS Record Reference Manual - 7 JUNE 2006

RRM 3-14 Timer

2008-04-18T18:48:09Z

KazimierzGofron:

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

= Timer =

The timer record is provided as a means for configuring timing outputs. These records will drive an output that may be used to latch data into analog inputs or waveform digitizers.

== Parameter Fields ==

The fields for the timer record fall into the following categories:

* scan parameters
* setup parameters
* write and convert parameters
* operator display parameters
* event generation parameters
* run-time parameters

=== Scan Parameters ===

The timer record has the standard fields for specifying under what circumstances it will be processed. In addition, the VAL field is provided in the timer record to force record processing when written to. The other fields are listed in [[RRM 3-13 dbCommon#Scan Fields|Scan Fields]]. In addition, [[RRM 3-13 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.

<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>SHORT<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes
</TABLE>

=== Setup Parameters ===

The timer record has fields needed to initialize a motor. The trigger source (TRSC) field is usually configured to come in from an external signal. This is configured in the record by setting TSRC to <CODE>external</CODE>, the only other choice being <CODE>internal</CODE>. The pre-trigger state field (PSRC) is the state of the timing channel when it is not fired. The timing channel usually goes high when the timing pulse is present. In such a case the pre-trigger state is low.

<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>TSRC<TD>Clock Source <TD>[[RRM 3-13 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>PTST <TD>Pre-Trigger State <TD>[[RRM 3-13 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes
</TABLE>

=== Write and Convert Parameters ===

The delays and outputs are specified in the time units (TIMU), which has four choices based on seconds: <CODE>Milliseconds</CODE>, <CODE>Microseconds</CODE>, <CODE>Nanoseconds</CODE>, <CODE>and Picoseconds</CODE>.

There are delays and pulse widths for five timing pulses per channel. The pulse width for each should be specified in the OPW1-OPW5 fields, in the units chosen in the TIMU field. The delay width for each trigger is specified in the DUT1-DUT5 fields. The delay width is the time in between pulses. These fields are converted to seconds by the run-time code before being used.

The value of the trigger delay field (TRDL) fetched from the trigger origin (TORG) field is added to the delay for each of these five signals. The TORG and TRDL work like the desired output parameters of other output records. TORG can be a channel access or database link, or a constant. If TORG is a constant, TRDL is initialized to the constant value and can be changed at run-time via dbPuts. Using the TORG field one can set up timing chains which are relative to other timing signals. See [[RRM 3-13 Concepts#Address Specification|Address Specification]] for information on how to specify database links.

The desired output is sent to the address contained in the output link (OUT). The DTYP field must contain the name of a valid device support module. 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 (R3.13).

<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>TORG<TD>Trigger Delay Origin (input link)<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>TRDL<TD>Trigger Delay <TD>FLOAT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>TIMU <TD>Timer Units<TD>[[RRM 3-13 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DTYP<TD>Device Type<TD>DEVCHOICE<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>OUT <TD>Output Link<TD>OUTLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>DUT1<TD>Delay Width for trigger 1<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>OPW1<TD>Pulse width for Trigger 1<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>DUT2<TD>Delay Width for Trigger 2<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>OPW2<TD>Pulse Width for Trigger 2<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>DUT3<TD>Delay Width for Trigger 3<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>OPW3<TD>Pulse Width for Trigger 3<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>DUT4<TD>Delay Width for Trigger 4<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>OPW4<TD>Pulse Width for Trigger 4<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>DUT5<TD>Delay Width for Trigger 5<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>OPW5<TD>Pulse Width for Trigger 5<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes
</TABLE>

=== Operator Display Parameters ===

The PDLY field displays the delay from source to input, which is the time is takes for the timing signal to get from its output to the trigger. It is not used by the run-time code, but characterizes the timing signals for the operator's knowledge.

See [[RRM 3-13 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>PDLY<TD>Delay Source to Input<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 timer record has the alarm parameters common to all record types. [[RRM 3-13 dbCommon#Alarm Fields|Alarm Fields]] lists other fields related to a alarms that are common to all record types.

=== Event Generation Parameters ===

The timing event (TEVT) field is used to generate internal events for processing records on an event. It should be an integer representing an event number.

<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>TEVT<TD>Event Number To Be Posted On Trigger. <TD>SHORT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes
</TABLE>

=== Run-time Parameters ===

These parameters are used by the run-time code for processing the timing channel. They are not configured using a configuration tool. They represent the current state of the timing channel.

The T1DL-T5DL and T1WD-T5WD fields are where the record stores the user-configured delay widths and pulse widths for the five triggers (DUT1-DUT5 and OPW1-OPW5) after it has converted them to seconds.

The T1TD-T5TD and T1LD-T5LD fields hold the trailing and leading trigger delays for each trigger. These fields are calculated by the record as follows:

T''n''LD = DUT''n'' + TRDL
T''n''TD = T''n''LD + OPW''n''

where ''n'' represents the trigger number.

<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>T1DL<TD>Delay Width for Trigger 1<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>T1WD<TD>Pulse Width for Trigger 1<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>T2DL<TD>Delay Width for Trigger 2<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>T2WD<TD>Pulse Width for Trigger 2<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>T3DL<TD>Delay Width for Trigger 3<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>T3WD<TD>Pulse Width for Trigger 3<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>T4DL<TD>Delay Width or Trigger 4<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>T4WD<TD>Pulse Width for Trigger 4<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>T5DL<TD>Delay width for Trigger 5<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>T5WD<TD>Pulse Width for Trigger 5<TD>DOUBLE<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>T1TD<TD>Trigger 1 Trailing Delay<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>T1LD<TD>Trigger 1 Leading Delay<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>T2TD<TD>Trigger 2 Trailing Delay <TD>FLOAT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>T2LD<TD>Trigger 2 Leading Delay<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>T3TD<TD>Trigger 3 Trailing Delay<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>T3LD<TD>Trigger 3 Leading Delay<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>T4TD<TD>Trigger 4 Trailing Delay<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>T4LD<TD>Trigger 4 Leading Delay<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>T5TD<TD>Trigger 5 Trailing Delay<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>T5LD<TD>Trigger 5 Leading Delay<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>TDIS<TD>Timing Pulse Disable<TD>SHORT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>MAIN<TD>Maintain on Reboot <TD>[[RRM 3-13 Menu Choices|GBLCHOICE]]<TD>Yes<TD>1<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>RDT1<TD>Reboot Delay of 1 <TD>FLOAT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>RDW1<TD>Reboot Width of 1 <TD>FLOAT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

----

EPICS Record Reference Manual - 19 MAY 1998

RRM 3-14 Subroutine

2008-04-18T18:47:38Z

KazimierzGofron:

[[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-13 dbCommon#Scan Fields|Scan Fields]]. In addition, [[RRM 3-13 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-13 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 F<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>INPJ<TD>Input H<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>Value for A<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-13 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-13 Concepts#Alarm Specification|Alarm Specification]] for a complete explanation of alarms and these fields. [[RRM 3-13 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-13 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-13 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-13 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-13 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-13 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-13 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 SubArray

2008-04-18T18:47:07Z

KazimierzGofron:

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

= subArray =

The normal use for the subArray record type is to obtain sub-arrays from waveform records. Setting either the number of elements (NELM) or index (INDX) fields causes the record to be processed anew so that applications in which the length and position of a sub-array in a waveform record vary dynamically can be implemented using standard EPICS operator interface tools.

The first element of the sub-array, that at location INDX in the referenced waveform record, can be displayed as a scalar, or the entire subarray (of length NELM) can be displayed in the same way as a waveform record. If there are fewer than NELM elements in the referenced waveform after the INDX, only the number of elements actually available are returned, and the number of elements read field (NORD) is set to reflect this. This record type does not support writing new values into waveform records.

== Parameter Fields ==

The subArray's fields fall into the following categories:

* scan parameters
* read parameters
* array parameters
* operator display parameters
* run-time parameters

=== Scan Parameters ===

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

=== Read Parameters ===

The subArray's input link (INP) should be configured to reference the Waveform record. It should specify the VAL field of a Waveform record. The INP field can be a channel access link, in addition to a database link. See [[RRM 3-13 Concepts#Address Specification|Address Specification]] for information on specifying links.

In addition, the DTYP field must specify a device support module. Currently, the only device support module is <CODE>Soft Channel</CODE>.

<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> <TD>N/A<TD>No<TR>
<TD>DTYP<TD>Device Type<TD>DEVCHOICE<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD>No
</TABLE>

=== Array Parameters ===

These parameters determine the number of array elements (the array length) and the data type of those elements. The Field Type of Value (FTVL) field determines the data type of the array.

The user specifies the maximum number of elements allowed in the subarray in the MALM field. Generally, the number should be equal to the number of elements of the Waveform array (found in the Waveform's NELM field). The MALM field is used to allocate memory. The subArray's Number of Elements (NELM) field is where the user specifies the actual number of elements that the subArray will contain. It should of course be no greater than MALM; if it is, the record processing routine sets it equal to MALM.

The INDX field determines the offset of the subArray record's array in relation to the Waveform's. For instance, if INDX is 2, then the subArray will read NELM elements starting with the third element of the Waveform's array. Thus, it equals the index number of the Waveform's array.

The actual sub-array is referenced by 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>FTVL<TD>Field Type of Value<TD>[[RRM 3-13 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>VAL<TD>Value Field<TD>(See FTVL)<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>MALM<TD>Maximum Number of Elements In Sub-array<TD>ULONG<TD>Yes<TD>1<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>NELM<TD>Number of Elements In Sub-array<TD>ULONG<TD>Yes<TD>1<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>INDX<TD>Index Into Referenced Array <TD>ULONG<TD>Yes<TD>0<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 subarray record either textually or graphically.

EGU is a string of up to 16 characters describing the engineering units (if any) of the values which the subArray holds. 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 sub-array elements. 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-13 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 subarray record has the alarm parameters common to all record types. [[RRM 3-13 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 not configurable by the user. They are used for the record's internal processing or to represent the current state of the record.

The NORD field holds a counter of the number of elements read into the array. It can be less than NELM even after the array is full if NELM exceeds the number of existing elements in the referenced array, i.e., the Waveform's array.

BPTR contains a pointer to the record's array.

<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>NORD <TD>Number of Elements Read<TD>LONG<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>BPTR<TD>Buffer Pointer<TD>NOACCESS<TD>No<TD>null<TD>Yes<TD>No<TD>No<TD>No
</TABLE>

== Record Support ==

=== Record Support Routines ===

==== init_record ====

Using MALM and FTVL, space for the array is allocated. The array address is stored in BPTR. This routine 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 the sub-array.

==== cvt_dbaddr ====

This is called by dbNameToAddr. It makes the dbAddr structure refer to the actual buffer holding the result.

==== get_array_info ====

Retrieves NELM.

==== put_array_info ====

Sets NORD.

==== get_graphic_double ====

For the elements in the array, this routine routines HOPR and LOPR. For the INDX field, this routine returns MALM - 1 and 0. For NELM, it returns MALM and 1. For other fields, it calls <CODE>recGblGetGraphicDouble()</CODE>.

==== get_control_double ====

For array elements, this routine retrieves HOPR and LOPR. Otherwise, <CODE>recGblGetControlDouble()</CODE> is called.

==== get_units ====

Retrieves EGU.

==== get_prec ====

Retrieves PREC.

=== 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.
# Sanity check NELM and INDX. If NELM is greater than MALM it is set to MALM. If INDX is greater than or equal to MALM it is set to MALM-1.
# Call device support read routine. This routine is expected to place the desired sub-array at the beginning of the buffer and set NORD to the number of elements of the sub-array that were read.
# If PACT has been changed to TRUE, the device support read routine has started but has not completed writing the new value. In this case, the processing routine merely returns, leaving PACT TRUE. Otherwise, process sets PACT TRUE at this time. This asynchronous processing logic is not currently used but has been left in place.
# 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 always 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 ===

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-13 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>INP<TD>Input Link<TD>This field is used by the device support routines to locate its input.<TR>
<TD>FTVL<TD>Field Type of Value<TD>This is DBF_STRING, ... ,DBF_ENUM. The device support routine should check that this is correctly defined.<TR>
<TD>MALM<TD>Maximum Number Of Elements in Sub-array<TD>Number of elements that will fit in the array the record allocates. Device support must never return more elements than this.<TR>
<TD>NELM<TD>Number Sub-array Elements<TD>Number of elements in desired sub-array.<TR>
<TD>INDX<TD>Index Into Referenced Array<TD>Index of beginning of desired sub-array in source array.<TR>
<TD>BPTR<TD>Buffer Pointer<TD>Address of array device support must copy the source array into.<TR>
<TD>NORD<TD>Number Of Elements Read<TD>Device support must set this value when it completes.
</TABLE>

=== Device Support Routines ===

Device support consists of the following routines:

==== report ====

report(FILE fp, paddr)

not currently used.

==== init ====

init()

Not currently used.

==== init_record ====

init_record(precord)

This routine is called by the record support init_record routine.

==== read_sa ====

read_sa(precord)

Enough of the source waveform is read into BPTR, from the beginning of the source, to include the requested sub-array. The sub-array is then copied to the beginning of the buffer. NORD is set to indicate how many elements of the sub-array were acquired.

=== Device Support For Soft Records ===

Only the device support module <CODE>Soft Channel</CODE> is currently provided. The INP link type must be either DB_LINK or CA_LINK.

==== Soft Channel ====

INP is expected to point to a waveform record.

----

EPICS Record Reference Manual - 19 MAY 1998

RRM 3-14 String Output

2008-04-18T18:46:35Z

KazimierzGofron:

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

= stringout -- String Output =

The stringout record is used to write an arbitrary ASCII string of up to 40 characters to other records or software variables.

== Parameter Fields ==

The fields fall into the following categories:

* scan parameters
* desired output parameters
* write parameters
* operator display parameters
* run-time parameters

=== Scan Parameters ===

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

=== Desired Output Parameters ===

The string output record must specify from where it gets its desired output string. The first field that determines where the desired output originates is the output mode select (OSML) field, which can have two possible value: <CODE>closed_loop</CODE> or <CODE>supervisory</CODE>. If <CODE>supervisory</CODE> is specified, DOL is ignored, the current value of VAL is written, and the VAL can be changed 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 field (DOL) which can be either a database link or a channel access link.

DOL can also be a constant in addition to a link, in which case VAL is initialized to the constant value. Note that if DOL is a constant, OMSL cannot be <CODE>closed_loop.</CODE> See [[RRM 3-13 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>VAL<TD> Value Field <TD>STRING [40]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>Yes<TD>Yes<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-13 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Write Parameters ===

The output link specified in the OUT field specifies where the string output record is to write its string. The link can be a database or channel access link. If the OUT field is a constant, no output will be written. See [[RRM 3-13 Concepts#Address Specification|Address Specification]] for information on specifying links.

In addition, the appropriate device support module must be entered into the DTYP field. All string output records must specify a device support module. 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 (R3.13).

<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>No
</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 string output either textually or graphically.

See [[RRM 3-13 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>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 string output record are the SCAN, READ, and INVALID alarms. The severity of the first two is always MAJOR and not configurable.

The IVOA field specifies an action to take when the INVALID alarm is triggered. There are three possible actions: <CODE>Continue normally</CODE>, <CODE>Don't drive outputs</CODE>, and <CODE>Set output to IVOV</CODE>. When <CODE>Set output to IVOV</CODE>, the value contained in the IVOV field is written to the output link during an alarm condition. See [[RRM 3-13 Common#Invalid Alarm Output Action|Invalid Alarm Output Action]] for more information on the IVOA and IVOV fields. [[RRM 3-13 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>IVOA<TD>Invalid Alarm Output Action<TD>[[RRM 3-13 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>

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

The old value field (OVAL) of the string input is used to implement value change monitors for VAL. If VAL is not equal to OVAL, then monitors are triggered.

<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>Output Value<TD>STRING [40]<TD>No<TD>Null<TD>Yes<TD>No<TD>No<TD>No
</TABLE>

The following fields are used to operate the string output in the simulation mode. See [[RRM 3-13 Common#Simulation Mode|Simulation Mode]] 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>STRING [40]<TD>No<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<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-13 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-13 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

== Record Support ==

=== Record Support Routines ===

Three record support routines are provided: init_record, process, and get_value.

==== 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 the type double constant, if non-zero, is converted to a string and stored into VAL 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.

=== 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-13 Common#Soft Output|Soft Output]]. If the return status of recGblGetLinkValue is zero then UDF is set to FALSE.
# Check severity and write the new value. See [[RRM 3-13 Common#Simulation Mode|Simulation Mode]] and [[RRM 3-13 Common#Invalid Alarm Output Action|Invalid Alarm Output Action]] for details on how the simulation mode and the INVALID alarm conditions 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 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 OVAL is not equal to VAL.
#* 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 stringout 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_stringout 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 Field<TD rowspan=4>See [[RRM 3-13 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<TD>This is the field written by the device support routines.<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:

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

==== write_stringout ====

write_stringout(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> device support module writes the current value of VAL.

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

write_so calls recGblPutLinkValue to write the current value of VAL. See [[RRM 3-13 Common#Soft Output|Soft Output]].

----

EPICS Record Reference Manual - 19 MAY 1998

RRM 3-14 String Input

2008-04-18T18:46:01Z

KazimierzGofron:

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

= stringin - String Input =

The string input record retrieves an arbitrary ASCII string of up to 40 characters. Several device support routines are available, all of which are soft device support for retrieving values from other records or other software components.

== Parameter Fields ==

The fields fall into the following categories.

* scan parameters
* read parameters
* operator display parameters
* run-time and simulation mode parameters

=== Scan Parameters ===

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

=== Read Parameters ===

The INP field determines where the string input record gets its string. It can be a database or channel access link, or a constant. If constant, the VAL field is initialized with the constant and can be changed via dbPuts. Otherwise, the string is read from the specified location each time the record is processed and placed in the VAL field. The maximum number of characters that the string in VAL can be is 40. In addition, the appropriate device support module must be entered into the DTYP field.

See [[RRM 3-13 Concepts#Address Specification|Address Specification]] for information on specifying links. 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 (R3.13).

<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<TD>STRING [40]<TD>Yes<TD>Null<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>DTYP<TD>Device Type<TD>DEVCHOICE<TD>Yes<TD>0<TD>Yes<TD>No<TD>No<TD>No
</TABLE>

=== Operator Display Parameters ===

See [[RRM 3-13 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>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 string input record has the alarm parameters common to all record types. [[RRM 3-13 dbCommon#Alarm Fields|Alarm Fields]] lists other fields related to a alarms that are common to all record types.

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

The old value field (OVAL) of the string input is used to implement value change monitors for VAL. If VAL is not equal to OVAL, then monitors are triggered.

<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>Output Value<TD>STRING<TD>No<TD>Null<TD>Yes<TD>No<TD>No<TD>No
</TABLE>

The following fields are used to operate the string input in the simulation mode. See [[RRM 3-13 Common#Simulation Mode|Simulation Mode]] for more information on 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>STRING [40]<TD>No<TD>Null<TD>Yes<TD>Yes<TD>No<TD>Yes<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-13 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-13 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

== Record Support ==

=== Record Support Routines ===

Three record support routines are provided: init_record, process, and get_value.

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

=== 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-13 Common#Simulation Mode|Simulation Mode]] for more information on simulation mode fields and how they affect input.
# 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.
# TIME is set to tslocaltime
# 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 OVAL is not equal to VAL.
#* 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 stringin input record must have an associated set of device support routines. The primary responsibility of the device support routines is to obtain a new ASCII string value whenever read_stringin 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=3>See [[RRM 3-13 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>VAL<TD>Value<TD>This field is set by the device support routines.<TR>
<TD>INP<TD>Input Link.<TD>This field is used by the device support routines to locate its input.
</TABLE>

=== Device Support Routines ===

Device support consists of the following routines:

==== report ====

report(FILE fp, paddr)

Not currently used.

==== init ====

init()

==== 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_stringin ====

read_stringin(precord)

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

* 0: Success. A new ASCII string is stored into VAL.
* Other: Error.

=== Device Support For Soft Records ===

The <CODE>Soft Channel</CODE> module places a value directly in VAL.

If the INP link type is constant, the double constant, if non-zero, is converted to a string and stored into VAL by init_record, and UDF is set to FALSE. If the INP link type is PV_LINK, then dbCaAddInlink is called by init_record.

read_stringin calls recGblGetLinkValue to read the current value of VAL. See [[RRM 3-13 Common#Soft Input|Soft Input]].

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

----

EPICS Record Reference Manual - 19 MAY 1998

RRM 3-14 Stepper Motor

2008-04-18T18:45:24Z

KazimierzGofron:

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

= steppermotor - Stepper Motor =

The stepper motor record controls and monitors stepper motors. The stepper motor can be controlled in either ''position'' mode or ''velocity'' mode. Position mode moves a device to a position. Velocity mode causes the motor to revolve continuously.

The record is set up assuming that the same stepper motor will not be used in both velocity and position mode. The fields for the stepper motor record fall into the following categories:

* scan parameters
* setup parameters
* desired output parameters
* output and readback parameters
* operator display parameters
* alarm parameters
* monitor parameters
run-time parameters.

=== Scan Parameters ===

The stepper motor record has the standard fields for specifying under what circumstances the record will be processed. A motor record that is scanned periodically or on event will compare its actual position to the desired position and will attempt to achieve its position. It will only make a certain number of attempts; the number of attempts is specified in the retry (RTRY) field. A passive motor will not go through the retry logic.

These fields are listed in [[RRM 3-13 dbCommon#Scan Fields|Scan Fields]]. In addition, [[RRM 3-13 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.

=== Setup Parameters ===

The set-up parameters determine how the stepper motor is initialized and how it operates at run-time.

The MODE field has two choices: <CODE>Velocity</CODE> or <CODE>Position</CODE>.

The VELO field determines the velocity that the stepper motor will run at when in the velocity mode. In position mode, it determines the pulses per second to move when it moves to a new position.

The ACCL field determines the acceleration of the motor by specifying a number of seconds. In velocity mode, the stepper motor will accelerate at the rate needed to reach the operating velocity in the number of seconds specified in ACCL. In positional mode, ACCL determines the seconds the stepper motor will take to reach the specified velocity, and the number of seconds it will take to come to a stop at the new position.

The MRES field specifies the number of pulses per revolution for the stepper motor, while ERES specifies the encoder pulses per revolution.

The DIST field's value determines the distance which the stepper motor moves for each pulse in engineering units.

The RTRY field specifies the number of attempts the record will make to reach the desired position each time it's processed, and the RDBD field specifies a deadband for this processing. Thus, when the motor is moving in a positive direction, no retries will be attempted unless the readback value is greater than VAL added to the value in the RDBD field. If the motor is moving in the negative direction, no retries will be attempted unless the readback value is less than VAL added to the value in the RDBD field:

; if direction positive and RBV > (VAL + RDBD)
: attempt to correct position <EM>RTRY</EM> times
; if direction negative and RBV < (VAL + RDBD)
: attempt to correct position <EM>RTRY</EM> times

The initialization algorithm (IALG) field has three algorithms to choose from: <CODE>No Initialization</CODE>, <CODE>Move to the Positive Limit</CODE>,<CODE> </CODE>and<CODE> Move to the Negative Limit</CODE>. The IVAL field determines the value of VAL at initialization; i.e., VAL is initialized to the value in IVAL when IALG is either Move to Positive or Move to Negative.

<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>ACCL<TD> Seconds to Reach Velocity<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>VELO<TD> Velocity in Pulses per Second<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DIST<TD> Distance in Engineering Units of 1 Pulse<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>IVAL<TD> Initial Value<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>MODE<TD> Mode--Position/Velocity<TD>[[RRM 3-13 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>IALG<TD>Initialization Algorithm<TD>[[RRM 3-13 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>RTRY<TD>Number Of Retries Before Failure<TD>SHORT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>RDBD<TD>Retry Deadband<TD>FLOAT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>MRES<TD>Motor Pulses per Revolution<TD>USHORT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>ERES<TD>Encoder Pulses per Revolution<TD>USHORT<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Desired Output Parameters ===

The stepper motor record specifies where the desired output originates in the DOL field. The desired output needs to be in engineering units. If the output is controlled by the operator or a sequence program, nothing should be entered in the DOL field.

The desired output link (DOL) and operation mode select (OMSL) fields work as they do for output records. If OMSL is <CODE>closed_loop</CODE>, the desired output (VAL) is fetched from the DOL link, which can be a database or channel access link. If <CODE>supervisory</CODE>, VAL can be changed via dbPuts. DOL can be a constant, in which case VAL is initialized to the constant. If DOL is a constant, OMSL cannot specify <CODE>closed_loop</CODE>. See [[RRM 3-13 Concepts#Address Specification|Address Specification]] for information on specifying links.

VAL indicates the position of the stepper motor in position mode; in velocity mode, it indicates the current velocity. When the desired output is retrieved and placed in VAL, it is forced to be within the drive limits configured in the DRVH and DRVL fields. The DRVH and DRVL fields must be given values by the user. Note: If nothing is entered in the DRVH and DRVL fields, the motor will not move. The <CODE>get_control_double()</CODE> record support routine returns the values in these fields when it is called.

<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 <TD>FLOAT<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<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-13 Menu Choices|GBLCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

=== Output and Readback Parameters ===

In the OUT output link field, the user must enter the address of the I/O card of the device, and in the DTYP field, the user must enter the name of the appropriate stepper motor device support module. Be aware that the address format differs according to the I/O bus used. See [[RRM 3-13 Concepts#Address Specification|Address Specification]] for information on 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.

The RDBL field can contain the address of an encoder or an external device, such as an LDVT, or it can specify the motor position field (MPOS) or the encoder position field (EPOS) in the same record. In the case of an external readback, the value would be read through an analog input record and linked to this record through this field. The value retrieved from this field is placed into the RBV 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>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>RDBL<TD>Read Back Location (an input link)<TD>INLINK<TD>Yes<TD>0<TD>No<TD>No<TD>N/A<TD>No<TR>
<TD>RBV<TD>Read Back Value <TD>FLOAT<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No
</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 stepper motor either textually or graphically.

EGU is a string of up to 16 characters describing the engineering units of VAL. 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, LOLO, MPOS, EPOS, RBV, and LVAL fields. Only the <CODE>get_graphic_double</CODE> record support routine retrieves 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 the VAL and LVAL fields. It is used whenever the <CODE>get_precision</CODE> record support routine is called.

See [[RRM 3-13 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> <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 stepper motor records are the SCAN, READ, and limit alarms. The SCAN and READ alarms are called by the record or device support routines and are always of MAJOR severity.

The limit alarms are configured by the user in the HIHI, LOLO, HIGH, and LOW fields using numerical values. The conditions apply to the VAL and RBV fields of the stepper motor record. For each of these fields, there is a corresponding severity field which can specify either NO ALARM, MINOR, or MAJOR. The user can specify a deadband around these limits in the HYST or hysteresis field. See [[RRM 3-13 Concepts#Alarm Specification|Alarm Specification]] for a complete explanation of analog alarms and these fields. [[RRM 3-13 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-13 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-13 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-13 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-13 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 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 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-13 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 by the user before run-time, but most of them can be modified after initialization.

The STHM field will set the current position of the motor to its home or zero position when this field is set to 1 via a dbPut. Its value is automatically reset to 0 after the command is accepted.

Setting the STOP field to 1 will cause the motor to stop moving. Its value is also reset to 0 after the command is accepted.

The DMOV field is a flag which indicates if the motor is done moving and all retries are complete. It is significant only while the record is in POSITION mode. It will be 1 if TRUE and 0 if FALSE.

The RVAL field contains the value which is actually written to output after it is forced in the drive limits.

The RBV and RRBV fields contain the value retrieved from the readback location link (RDBL).

The MOVN field indicates whether the motor is currently moving. It will contain a 1 if moving or a 0 if not moving. The DIR field indicates which direction the record is moving--a 0 means clockwise and a 1 means counter clockwise.

The CW and CCW fields contain the values for the clockwise and counterclockwise limit switches, respectively. The MCW and MCCW fields will be 1 if the limit has been reached or 0 if not.

The CVEL field indicates whether the motor is at constant velocity. If so, the value of this field is 1.

The RCNT field will indicate the current number of retries that have been attempted.

The POSM field will contain a 1 if the motor is moving in a positive direction and a 0 if otherwise.

The MISS field holds the error after the first attempt has been made to change the stepper motor's position, the error being the difference between VAL and RBV, the readback value. If monitors are present, the value is posted.

The EPOS field holds the value obtained from encoder readback. The MPOS holds the readback value of the motor positions.

The MLST and ALST fields are used to implement monitors on the VAL field. If the difference between one of these fields and the VAL field exceeds the appropriate deadband (MDEL, for instance) monitors are triggered.

The LVEL, LACC, and LVAL fields contain the last values set for the VELO, ACCL, and VAL fields respectively. They are used to determine when the velocity and acceleration should be recalculated.

The CMOD or current mode fields indicates which mode, position or velocity, the record is using.

<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>STHM<TD>Set Home<TD>SHORT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>STOP<TD>Stop<TD>SHORT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>DMOV<TD>Done Moving to Value<TD>SHORT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>RVAL<TD> Raw Data Value <TD>LONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>RRBV<TD>Raw Read Back Value<TD>LONG<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>INIT<TD>Initialize<TD>SHORT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>MOVN <TD>Moving Status<TD>SHORT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>DIR<TD>Current Direction<TD>SHORT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>MCW<TD>Motor Clockwise Limit Switch Value<TD>SHORT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>MCCW<TD>Motor Counter Clockwise Limit Switch Value<TD>SHORT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>CW <TD>Clockwise Limit<TD>SHORT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>CCW<TD>Counter Clockwise Limit<TD>SHORT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>Yes<TR>
<TD>CVEL<TD>Constant Velocity<TD>SHORT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>RCNT<TD>Current Retry Count<TD>SHORT<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>POSM<TD> Positive Motion<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>Yes<TD>No<TR>
<TD>MISS<TD>First Attempt Error <TD>FLOAT<TD>No<TD>0<TD>Yes<TD>Yes<TD>Yes<TD>No<TR>
<TD>EPOS <TD>Encoder Read Back Position <TD>FLOAT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>MPOS<TD> Motor Position <TD>FLOAT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>ALST<TD>Archive Last Value <TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>MLST<TD>Monitor Last Value<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>No<TD>No<TD>No<TR>
<TD>LVEL<TD>Last Velocity Set<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>LACC<TD>Last Acceleration Set<TD>FLOAT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>LVAL<TD> Last Value <TD>SHORT<TD>No<TD>0<TD>Yes<TD>Yes<TD>No<TD>No<TR>
<TD>CMOD<TD>Current Mode <TD>[[RRM 3-13 Menu Choices|RECCHOICE]]<TD>Yes<TD>0<TD>Yes<TD>Yes<TD>No<TD>No
</TABLE>

== Record Support ==

=== Record Support Routines ===

==== init_record ====

This routine checks to see that device support is available. The routine next checks to see if the device support <CODE>sm_command</CODE> 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 device support includes <CODE>init_record</CODE>, it is called.

If DOL is a constant, then VAL is initialized with its value and UDF is set to FALSE. If DOL is a PV_LINK then a channel access link is created.

init_sm is then called.

==== init_sm ====

The init_sm routine initializes the stepper motor according to its configuration.

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

==== get_graphic_double ====

Sets the upper display and lower display limits for a field. If the field is VAL, LVAL, MPOS, RBV, EPOS, 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, LVAL, MPOS, RBV, EPOS, HIHI, HIGH, LOW, or LOLO, the limits are set to DRVH and DRVL. 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 ===

Description not available.

== Device Support ==

At the present time, device support is intimately connected to record support. The compumotor 1830 and the OMS 6 axis controllers are supported.

----

EPICS Record Reference Manual - 19 MAY 1998

RRM 3-14 State

2008-04-18T18:44:49Z

KazimierzGofron:

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

= State =

The state record is a means for a state program to communicate with the operator interface. Its only function is to provide a place in the database through which the state program can inform the operator interface of its state by storing an arbitrary ASCII string in its VAL field.

== Parameter Fields ==

The state record fields fall into the following categories:

* scan parameters
* operator display parameters
* other parameters

=== Scan Parameters ===

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

=== Operator Display Parameters ===

See [[RRM 3-13 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>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 state record has the alarm parameters common to all record types. [[RRM 3-13 dbCommon#Alarm Fields|Alarm Fields]] lists other fields related to a alarms that are common to all record types.

=== Run-time Parameters ===

These parameters are used by the application code to convey the state of the program to the operator interface. The VAL field holds the string retrieved from the state program. The OVAL is used to implement monitors for the VAL field. When the string in OVAL differs from the one in VAL, monitors are triggered. They represent the current state of the sequence program.

<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>STRING [20]<TD>Yes<TD>Null<TD>Yes<TD>Yes<TD>Yes<TD>Yes<TR>
<TD>OVAL<TD>Old Value<TD>STRING [20]<TD>No<TD>Null<TD>Yes<TD>No<TD> <TD> 
</TABLE>

== Record Support ==

=== Record Support Routines ===

Two record support routines are provided:

==== process ====

process triggers monitors on VAL when it changes and scans the forward link if necessary.

==== get_value ====

get_value fills in struct valueDes so that it refers to VAL.

----

EPICS Record Reference Manual - 19 MAY 1998

RRM 3-14 Sequence

2008-04-18T18:44:17Z

KazimierzGofron:

[[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-13 dbCommon#Scan Fields|Scan Fields]]. In addition, [[RRM 3-13 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-13 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 71<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-13 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-13 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-13 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