epics/epics-base
0
0
Fork 0
Code Issues Pull Requests Projects Wiki Activity

Many edits to record reference docs

Browse Source 
Add documentation for aSub from wiki.
Fix incorrect document structures.
Remove inclusion of menu.dbd files.
Fix links to common doc's, remove some links to nowhere.
Adjust podToHtml.pl and the rule that calls it.
This commit is contained in:
Andrew Johnson
2020-05-26 21:49:35 -05:00
parent 1f4e812223
commit dd1b65f32c
34 changed files with 856 additions and 586 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
configure/RULES.Db
View File

@@ -436,7 +436,7 @@ $(COMMON_DIR)/%.html: %.dbd.pod
$(COMMON_DIR)/%.html: %.pod
@$(RM) $(notdir $@)
$(PODTOHTML) -o $(notdir $@) $<
$(PODTOHTML) -s -s -o $(notdir $@) $<
@$(MV) $(notdir $@) $@
$(COMMON_DIR)/%.html: %.pm

539
modules/database/src/std/rec/aSubRecord.dbd.pod
View File

@@ -4,37 +4,53 @@
# Copyright (c) 2002 The Regents of the University of California, as
# Operator of Los Alamos National Laboratory.
# EPICS BASE is distributed subject to a Software License Agreement found
# in file LICENSE that is included with this distribution.
# in file LICENSE that is included with this distribution.
#*************************************************************************
=title Array Subroutine Record (aSub)
...
The aSub record is an advanced variant of the 'sub' (subroutine) record which
has a number of additional features:
=over
=item *
It provides 20 different input and output fields which can hold array or
scalar values.
The types and array capacities of these are user configurable, and they all
have an associated input or output link.
=item *
The name of the C or C++ subroutine to be called when the record processes
can be changed dynamically while the IOC is running.
The name can either be fetched from another record using an input link, or
written directly into the SNAM field.
=item *
The user can choose whether monitor events should be posted for the output
fields.
=item *
The VAL field is set to the return value from the user subroutine, which is
treated as a status value and controls whether the output links will be used
or not. The record can also raise an alarm with a chosen severity if the status
value is non-zero.
=back
=head2 Record-specific Menus
=head3 Menu aSubLFLG
The LFLG field uses this menu to ...
The LFLG menu field controls whether the SUBL link will be read to update
the name of the subroutine to be called when the record processes.
=menu aSubLFLG
=head3 Menu aSubEFLG
The EFLG field uses this menu to ...
=menu aSubEFLG
...
=head2 Parameter Fields
The record-specific fields are described below.
=recordtype aSub
...
=cut
menu(aSubLFLG) {
@@ -42,14 +58,69 @@ menu(aSubLFLG) {
choice(aSubLFLG_READ,"READ")
}
=head3 Menu aSubEFLG
The EFLG menu field indicates whether monitor events should be posted for the
VALA..VALU output value fields.
=menu aSubEFLG
=cut
menu(aSubEFLG) {
choice(aSubEFLG_NEVER,"NEVER")
choice(aSubEFLG_ON_CHANGE,"ON CHANGE")
choice(aSubEFLG_ALWAYS,"ALWAYS")
}
=head2 Parameter Fields
The record-specific fields are described below.
=recordtype aSub
=cut
recordtype(aSub) {
include "dbCommon.dbd"
=head3 Subroutine Fields
The VAL field is set to the value returned by the user subroutine.
The value is treated as an error status value where zero mean success.
The output links OUTA ... OUTU will only be used to forward the associated
output value fields when the subroutine has returned a zero status.
If the return status was non-zero, the record will be put into C<SOFT_ALARM>
state with severity given by the BRSV field.
The INAM field may be used to name a subroutine that will be called once at
IOC initialization time.
LFLG tells the record whether to read or ignore the SUBL link.
If the value is C<READ>, then the name of the subroutine to be called at
process time is read from SUBL.
If the value is C<IGNORE>, the name of the subroutine is that currently held
in SNAM.
A string is read from the SUBL link to fetch the name of the subroutine to
be run during record processing.
SNAM holds the name of the subroutine to be called when the record processes.
The value in this field can be overwritten by the SUBL link if LFLG is set
to C<READ>.
The SADR field is only accessible from C code; it points to the subroutine
to be called.
The CADR field may be set by the user subroutine to point to another function
that will be called immediately before setting the SADR field to some other
routine. This allows the main user subroutine to allocate resources when it is
first called and be able to release them again when they are no longer needed.
=fields VAL, OVAL, INAM, LFLG, SUBL, SNAM, ONAM, SADR, CADR, BRSV
=cut
field(VAL,DBF_LONG) {
prompt("Subr. return value")
asl(ASL0)
@@ -112,12 +183,34 @@ recordtype(aSub) {
interest(1)
menu(menuAlarmSevr)
}
=head3 Operator Display Parameters
The PREC field specifies the number of decimal places with which to display
the values of the value fields A ... U and VALA ... VALU.
Except when it doesn't.
=cut
field(PREC,DBF_SHORT) {
prompt("Display Precision")
promptgroup("80 - Display")
interest(1)
prop(YES)
}
=head3 Output Event Flag
This field tells the record when to post change events on the output fields
VALA ... VALU. If the value is C<NEVER>, events are never posted. If the value
is C<ALWAYS>, events are posted every time the record processes. If the value
is C<ON CHANGE>, events are posted when any element of an array changes value.
This flag controls value, log (archive) and alarm change events.
=fields EFLG
=cut
field(EFLG,DBF_MENU) {
prompt("Output Event Flag")
promptgroup("50 - Output")
@@ -125,6 +218,16 @@ recordtype(aSub) {
menu(aSubEFLG)
initial("1")
}
=head3 Input Link Fields
The input links from where the values of A,...,U are fetched
during record processing.
=fields INPA, INPB, INPC, INPD, INPE, INPF, INPG, INPH, INPI, INPJ, INPK, INPL, INPM, INPN, INPO, INPP, INPQ, INPR, INPS, INPT, INPU
=cut
field(INPA,DBF_INLINK) {
prompt("Input Link A")
promptgroup("41 - Input A-G")
@@ -231,9 +334,10 @@ recordtype(aSub) {
interest(1)
}
=head3 Input Fields
=head3 Input Value Fields
...
Thse fields hold the scalar or array values fetched through the input links
INPA,...,INPU.
=fields A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U
@@ -449,6 +553,16 @@ recordtype(aSub) {
#=write Yes
#=type Set by FTU
}
=head3 Input Value Data Types
Field types of the input value fields.
The choices can be found by following the link to the menuFtype definition.
=fields FTA, FTB, FTC, FTD, FTE, FTF, FTG, FTH, FTI, FTJ, FTK, FTL, FTM, FTN, FTO, FTP, FTQ, FTR, FTS, FTT, FTU
=cut
field(FTA,DBF_MENU) {
prompt("Type of A")
promptgroup("41 - Input A-G")
@@ -617,6 +731,15 @@ recordtype(aSub) {
initial("DOUBLE")
menu(menuFtype)
}
=head3 Input Value Array Capacity
These fields specify how many array elements the input value fields may hold.
=fields NOA, NOB, NOC, NOD, NOE, NOF, NOG, NOH, NOI, NOJ, NOK, NOL, NOM, NON, NOO, NOP, NOQ, NOR, NOS, NOT, NOU
=cut
field(NOA,DBF_ULONG) {
prompt("Max. elements in A")
promptgroup("41 - Input A-G")
@@ -764,6 +887,16 @@ recordtype(aSub) {
interest(1)
initial("1")
}
=head3 Input Value Array Size
These fields specify how many array elements the input value fields currently
contain.
=fields NEA, NEB, NEC, NED, NEE, NEF, NEG, NEH, NEI, NEJ, NEK, NEL, NEM, NEN, NEO, NEP, NEQ, NER, NES, NET, NEU
=cut
field(NEA,DBF_ULONG) {
prompt("Num. elements in A")
special(SPC_NOMOD)
@@ -890,6 +1023,15 @@ recordtype(aSub) {
interest(3)
initial("1")
}
=head3 Output Link Fields
The output links through which the VALA ... VALU field values are sent
during record processing, provided the subroutine returned 0.
=fields OUTA, OUTB, OUTC, OUTD, OUTE, OUTF, OUTG, OUTH, OUTI, OUTJ, OUTK, OUTL, OUTM, OUTN, OUTO, OUTP, OUTQ, OUTR, OUTS, OUTT, OUTU
=cut
field(OUTA,DBF_OUTLINK) {
prompt("Output Link A")
promptgroup("51 - Output A-G")
@@ -996,9 +1138,10 @@ recordtype(aSub) {
interest(1)
}
=head3 Value Fields
=head3 Output Value Fields
...
These fields hold scalar or array data generated by the subroutine which will
be sent through the OUTA ... OUTU links during record processing.
=fields VALA, VALB, VALC, VALD, VALE, VALF, VALG, VALH, VALI, VALJ, VALK, VALL, VALM, VALN, VALO, VALP, VALQ, VALR, VALS, VALT, VALU
@@ -1214,6 +1357,16 @@ recordtype(aSub) {
#=write Yes
#=type Set by FTVU
}
=head3 Old Value Fields
The previous values of the output fields.
These are used to determine when to post events if EFLG is set to C<ON CHANGE>.
=fields VALA, VALB, VALC, VALD, VALE, VALF, VALG, VALH, VALI, VALJ, VALK, VALL, VALM, VALN, VALO, VALP, VALQ, VALR, VALS, VALT, VALU
=cut
field(OVLA,DBF_NOACCESS) {
prompt("Old Output A")
asl(ASL0)
@@ -1361,6 +1514,16 @@ recordtype(aSub) {
interest(4)
extra("void *ovlu")
}
=head3 Output Value Data Types
Field types of the output value fields.
The choices can be found by following a link to the menuFtype definition.
=fields FTVA, FTVB, FTVC, FTVD, FTVE, FTVF, FTVG, FTVH, FTVI, FTVJ, FTVK, FTVL, FTVM, FTVN, FTVO, FTVP, FTVQ, FTVR, FTVS, FTVT, FTVU
=cut
field(FTVA,DBF_MENU) {
prompt("Type of VALA")
promptgroup("51 - Output A-G")
@@ -1529,6 +1692,15 @@ recordtype(aSub) {
initial("DOUBLE")
menu(menuFtype)
}
=head3 Output Value Array Capacity
These fields specify how many array elements the output value fields may hold.
=fields NOVA, NOVB, NOVC, NOVD, NOVE, NOVF, NOVG, NOVH, NOVI, NOVJ, NOVK, NOVL, NOVM, NOVN, NOVO, NOVP, NOVQ, NOVR, NOVS, NOVT, NOVU
=cut
field(NOVA,DBF_ULONG) {
prompt("Max. elements in VALA")
promptgroup("51 - Output A-G")
@@ -1676,6 +1848,16 @@ recordtype(aSub) {
interest(1)
initial("1")
}
=head3 Output Value Array Size
These fields specify how many array elements the output value fields currently
contain.
=fields NEVA, NEVB, NEVC, NEVD, NEVE, NEVF, NEVG, NEVH, NEVI, NEVJ, NEVK, NEVL, NEVM, NEVN, NEVO, NEVP, NEVQ, NEVR, NEVS, NEVT, NEVU
=cut
field(NEVA,DBF_ULONG) {
prompt("Num. elements in VALA")
special(SPC_NOMOD)
@@ -1802,6 +1984,16 @@ recordtype(aSub) {
interest(3)
initial("1")
}
=head3 Old Value Array Size
These fields specify how many array elements the old value fields currently
contain.
=fields ONVA, ONVB, ONVC, ONVD, ONVE, ONVF, ONVG, ONVH, ONVI, ONVJ, ONVK, ONVL, ONVM, ONVN, ONVO, ONVP, ONVQ, ONVR, ONVS, ONVT, ONVU
=cut
field(ONVA,DBF_ULONG) {
prompt("Num. elements in OVLA")
special(SPC_NOMOD)
@@ -1928,4 +2120,305 @@ recordtype(aSub) {
interest(4)
initial("1")
}
=begin html
<br>
<hr>
<br>
=end html
=head2 Record Support Routines
=head3 init_record
long (*init_record)(struct dbCommon *precord, int pass)
This routine is called twice at iocInit. On the first call it does the
following:
=over
=item *
Calloc sufficient space to hold the number of input scalars and/or arrays
defined by the settings of the fields FTA-FTU and NOA-NOU. Initialize fields
NE* to the values of the associated NO* field values.
=item *
Calloc sufficient space to hold the number of output scalars and/or arrays
defined by the settings of the fields FTVA-FTVU and NOVA-NOVU. For the output
fields, also calloc space to hold the previous value of a field. This is
required when the decision is made on whether or not to post events.
=back
On the second call, it does the following:
=over
=item *
Initializes SUBL if it is a constant link.
=item *
Initializes each constant input link.
=item *
If the field INAM is set, look-up the address of the routine and call it.
=item *
If the field LFLG is set to IGNORE and SNAM is defined, look up the address of
the process routine.
=back
=head3 process
long (*process)(struct dbCommon *precord)
This routine implements the following algorithm:
=over
=item *
If PACT is FALSE, perform normal processing
=item *
If PACT is TRUE, perform asynchronous-completion processing
=back
Normal processing:
=over
=item *
Set PACT to TRUE.
=item *
If the field LFLG is set to READ, get the subroutine name from the SUBL link.
If the name is not NULL and it is not the same as the previous subroutine name,
look up the subroutine address. Set the old subroutine name, ONAM, equal to the
current name, SNAM.
=item *
Fetch the values from the input links.
=item *
Set PACT to FALSE
=item *
If all input-link fetches succeeded, call the routine specified by SNAM.
=item *
Set VAL equal to the return value from the routine specified by SNAM.
=item *
If the SNAM routine set PACT to TRUE, then return. In this case, we presume
the routine has arranged that process will be called at some later time for
asynchronous completion.
=item *
Set PACT to TRUE.
=item *
If VAL is zero, write the output values using the output links.
=item *
Get the time of processing and put it into the timestamp field.
=item *
If VAL has changed, post a change-of value and log event for this field.
If EFLG is set to ALWAYS, post change-of-value and log events for every output
field. If EFLG is set to ON CHANGE, post change-of-value and log events for
every output field which has changed. In the case of an array, an event will be
posted if any single element of the array has changed. If EFLG is set to NEVER,
no change-of-value or log events are posted for the output fields.
=item *
Process the record on the end of the forward link, if one exists.
=item *
Set PACT to FALSE.
=back
Asynchronous-completion processing:
=over
=item *
Call the routine specified by SNAM (again).
=item *
Set VAL equal to the return value from the routine specified by SNAM.
=item *
Set PACT to TRUE.
=item *
If VAL is zero, write the output values using the output links.
=item *
Get the time of processing and put it into the timestamp field.
=item *
If VAL has changed, post a change-of value and log event for this field. If
EFLG is set to ALWAYS, post change-of-value and log events for every output
field. If EFLG is set to ON CHANGE, post change-of-value and log events for
every output field which has changed. In the case of an array, an event will
be posted if any single element of the array has changed. If EFLG is set to
NEVER, no change-of-value or log events are posted for the output fields.
=item *
Process the record on the end of the forward link, if one exists.
=item *
Set PACT to FALSE.
=back
=begin html
<br>
<hr>
<br>
=end html
=head2 Use of the aSub Record
The aSub record has input-value fields (A-U) and output-value fields
(VALA-VALU), which are completely independent. The input-value fields have
associated input links (INPA-INPU), and the output-value fields have associated
output links (OUTA-OUTU). Both inputs and outputs have type fields (FTA-FTU,
FTVA-FTVU, which default to 'DOUBLE') and number-of-element fields (NOA-NOU,
NOVA-NOVU, which default to '1'). The output links OUTA-OUTU will only be
processed if the subroutine returns a zero (OK) status value.
=head3 Example database fragment
To use the A field to read an array from some other record, then, you would
need a database fragment that might look something like this:
record(aSub,"my_asub_record") {
field(SNAM,"my_asub_routine")
...
field(FTA, "LONG")
field(NOA, "100")
field(INPA, "myWaveform_1 NPP NMS")
...
}
If you wanted some other record to be able to write to the A field, then you
would delete the input link above. If you wanted the A field to hold a scalar
value, you would either delete the NOA specification, or specify it as "1".
=head3 Example subroutine fragment
The associated subroutine code that uses the A field might look like this:
static long my_asub_routine(aSubRecord *prec) {
long i, *a;
double sum=0;
...
a = (long *)prec->a;
for (i=0; i<prec->noa; i++) {
sum += a[i];
}
...
return 0; /* process output links */
}
Note that the subroutine code must always handle the value fields (A-U,
VALA-VALU) as arrays, even if they contain only a single element.
=head3 Required export code
Aside from your own code, you must export and register your subroutines so the
record can locate them. The simplest way is as follows:
#include <registryFunction.h>
#include <epicsExport.h>
static long my_asub_routine(aSubRecord *prec) {
...
}
epicsRegisterFunction(my_asub_routine);
=head3 Required database-definition code
The .dbd file loaded by the ioc must then contain the following line, which
tells the linker to include your object file in the IOC binary:
function(my_asub_routine)
=head3 Device support, writing to hardware
The aSub record does not call any device support routines. If you want to write
to hardware, you might use your output fields and links to write to some other
record that can write to hardware.
=head3 Dynamically Changing the User Routine called during Record Processing
The aSub record allows the user to dynamically change which routine is called
when the record processes. This can be done in two ways:
=over
=item *
The LFLG field can be set to READ so that the name of the routine is read from
the SUBL link. Thus, whatever is feeding this link can change the name of the
routine before the aSub record is processed. In this case, the record looks in
the symbol table for the symbol name whenever the name of routine fetched from
the link changes.
=item *
The LFLG field can be set to IGNORE. In this case, the routine called during
record processing is that specified in the SNAM field. Under these conditions,
the SNAM field can be changed by a Channel Access write to that field. During
development when trying several versions of the routine, it is not necessary
to reboot the IOC and reload the database. A new routine can be loaded with
the vxWorks ld command, and Channel Access or the dbpf command used to put the
name of the routine into the record's SNAM field. The record will look up the
symbol name in the symbol table whenever the SNAM field gets modified. The
same routine name can even be used as the vxWorks symbol lookup returns the
latest version of the code to have been loaded.
=back
=cut
}

43
modules/database/src/std/rec/aaiRecord.dbd.pod
View File

@@ -18,8 +18,6 @@ storage.
=cut
include "menuFtype.dbd"
menu(aaiPOST) {
choice(aaiPOST_Always,"Always")
choice(aaiPOST_OnChange,"On Change")
@@ -34,10 +32,8 @@ The record-specific fields are described below, grouped by functionality.
=head3 Scan Parameters
The array analog input record has the standard fields for specifying under what
circumstances the record will be processed. These fields are listed in L<Scan
Fields>. In addition, L<Scanning Specification> explains how these fields are
used. Note that I/O event scanning is only supported for those card types that
interrupt.
circumstances the record will be processed.
These fields are described in L<Scan Fields|dbCommonRecord/Scan Fields>.
=head3 Read Parameters
@@ -46,8 +42,7 @@ reads its data. The INP field determines from where the array analog input 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 L<Address Specification> for information on the format
of hardware addresses and database links.
be a hardware address.
=head4 Fields related to waveform reading
@@ -55,14 +50,11 @@ The DTYP field must contain the name of the appropriate device support module.
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.
FTVL specifies the data type of the elements (follow the link in the table below
for a list of the available choices).
=fields DTYP, INP, NELM, FTVL
=head4 Possible data types for FTVL
=menu menuFtype
=head3 Operator Display Parameters
These parameters are used to present meaningful data to the operator. They
@@ -82,8 +74,9 @@ The PREC field determines the floating point precision with which to display the
array values. It is used whenever the C<<< get_precision() >>> record support
routine is called.
See L<Fields Common to All Record Types> for more on the record name (NAME) and
description (DESC) fields.
See L<Fields Common to All Record Types|dbCommonRecord/Operator Display
Parameters> for more on the record name (NAME) and description (DESC) fields.
=fields EGU, HOPR, LOPR, PREC, NAME, DESC
@@ -95,21 +88,21 @@ The array analog input record has the alarm parameters common to all record type
=head3 Monitor Parameters
These parameters are used to determine when to send monitors placed on the VAL
field. The APST and MPST fields are a menu with choices "Always" and "On
Change". The default is "Always", thus monitors will normally be sent every time
the record processes. Selecting "On Change" causes a 32-bit hash of the VAL
field. The APST and MPST fields are a menu with choices C<Always> and C<On
Change>. The default is C<Always>, thus monitors will normally be sent every time
the record processes. Selecting C<On Change> causes a 32-bit hash of the VAL
field buffer to be calculated and compared with the previous hash value every
time the record processes; the monitor will only be sent if the hash is
different, indicating that the buffer has changed. Note that there is a small
chance that two different value buffers might result in the same hash value, so
for critical systems "Always" may be a better choice, even though it re-sends
for critical systems C<Always> may be a better choice, even though it re-sends
duplicate data.
=head4 Record fields related to I<Monitor Parameters>
=fields APST, MPST, HASH
=head4 Menu choices for C<APST> and C<MPST> fields
=head4 Menu aaiPOST
These are the possible choices for the C<APST> and C<MPST> fields:
=menu aaiPOST
@@ -312,7 +305,7 @@ Scan forward link if necessary, set PACT FALSE, and return.
special(SPC_DBADDR)
pp(TRUE)
extra("void * val")
#=type DOUBLE[]
#=type DOUBLE[NELM]
#=read Yes
#=write Yes
}
@@ -434,7 +427,6 @@ Scan forward link if necessary, set PACT FALSE, and return.
prompt("Hash of OnChange data.")
interest(3)
}
}
=head2 Device Support
@@ -485,7 +477,7 @@ C<init_record()> routine.
long get_ioint_info(int cmd, 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
or deleted from an I/O event scan list. C<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.
@@ -521,3 +513,4 @@ in the array.
If the INP link type is constant, then NORD is set to zero.
=cut
}

24
modules/database/src/std/rec/aaoRecord.dbd.pod
View File

@@ -18,8 +18,6 @@ device support to allocate the array storage.
=cut
include "menuFtype.dbd"
menu(aaoPOST) {
choice(aaoPOST_Always,"Always")
choice(aaoPOST_OnChange,"On Change")
@@ -54,14 +52,11 @@ The DTYP field must contain the name of the appropriate device support module. T
values in the array referenced by are written to the location specified in the OUT
field. (If the OUT link is a constant, no data are written.) NELM specifies the
maximum number of elements that the array can hold, while FTVL specifies the data
type of the elements.
type of the elements (follow the link in the table below for a list of the
available choices).
=fields DTYP, OUT, NELM, FTVL
=head4 Possible data types for FTVL
=menu menuFtype
=head3 Operator Display Parameters
These parameters are used to present meaningful data to the operator. They
@@ -81,8 +76,9 @@ The PREC field determines the floating point precision with which to display the
array values. It is used whenever the C<<< get_precision >>> record support
routine is called.
See L<Fields Common to All Record Types> for more on the record name (NAME) and
description (DESC) fields.
See L<Fields Common to All Record Types|dbCommonRecord/Operator Display
Parameters> for more on the record name (NAME) and description (DESC) fields.
=fields EGU, HOPR, LOPR, PREC, NAME, DESC
@@ -109,7 +105,9 @@ duplicate data.
=fields APST, MPST, HASH
=head4 Menu choices for C<APST> and C<MPST> fields
=head4 Menu aaoPOST
These are the choices available for the C<APST> and C<MPST> fields
=menu aaoPOST
@@ -434,7 +432,6 @@ Scan forward link if necessary, set PACT FALSE, and return.
prompt("Hash of OnChange data.")
interest(3)
}
}
=head2 Device Support
@@ -475,7 +472,7 @@ with C<after> set to 1.
=head4 init_record
init_record(dbCommon *precord)
long init_record(dbCommon *precord)
This routine is optional. If provided, it is called by the record support
C<init_record()> routine.
@@ -485,7 +482,7 @@ C<init_record()> routine.
long get_ioint_info(int cmd, 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
or deleted from an I/O event scan list. C<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.
@@ -519,3 +516,4 @@ is written to the link. NORD is set to the number of items in the array.
If the OUT link type is constant, then NORD is set to zero.
=cut
}

41
modules/database/src/std/rec/biRecord.dbd.pod
View File

@@ -23,26 +23,7 @@ value into RVAL just like normal hardware modules.
=head2 Parameter Fields
The binary input's fields fall into the following categories:
=over
=item *
scan Parameters
=item *
read and convert parameters
=item *
operator display parameters
=item *
alarm parameters
=item *
run-time parameters
=back
The record-specific fields are described below, grouped by functionality.
=recordtype bi
@@ -53,12 +34,8 @@ recordtype(bi) {
=head3 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
L<Scan Fields>. In addition, L<Scanning Specification> explains how these
fields are used. Note that I/O event scanning is only supported for those
card types that interrupt.
=fields SCAN
circumstances the record will be processed.
These fields are described in L<Scan Fields|dbCommonRecord/Scan Fields>.
=head3 Read and Convert Parameters
@@ -106,8 +83,8 @@ corresponding to the VAL's state. If the value is 1, C<get_enum_str()> will
return the string in the ONAM field; and if 0, C<get_enum_str()> will return
the ZNAM string.
See L<Fields Common to All Record Types> for more on the record name (NAME)
and description (DESC) fields.
See L<Fields Common to All Record Types|dbCommonRecord/Operator Display
Parameters> for more on the record name (NAME) and description (DESC) fields.
=fields ZNAM, ONAM, NAME, DESC
@@ -126,7 +103,7 @@ 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 L<Alarm Specification> for a complete explanation of the discrete alarm
states. L<Alarm Fields> lists other fields related to alarms that are
states. L<Alarm Fields|dbCommonRecord/Alarm Fields> lists other fields related to alarms that are
common to all record types.
=fields ZSV, OSV, COSV
@@ -160,8 +137,8 @@ is not equal to VAL.
%/* Declare Device Support Entry Table */
%struct biRecord;
%typedef struct bidset {
% dset common; /*init_record returns: (-1,0)=>(failure,success)*/
% long (*read_bi)(struct biRecord *prec);/*(0,2)=> success and convert, don't convert); if convert then raw value stored in rval */
% dset common;
% long (*read_bi)(struct biRecord *prec);
%} bidset;
%#define HAS_bidset
%
@@ -327,7 +304,7 @@ If device support includes C<init_record()>, it is called.
long process(struct dbCommon *precord);
See L<Record Processing> below.
See L</Record Processing> below.
long get_enum_str(const struct dbAddr *paddr, char *pbuffer);

13
modules/database/src/std/rec/boRecord.dbd.pod
View File

@@ -48,7 +48,8 @@ recordtype(bo) {
The binary output record has the standard fields for specifying under what
circumstances the record will be processed. The fields are listed in
L<Scan Fields>. In addition, L<Scanning Specification> explains how these
L<Scan Fields|dbCommonRecord/Scan Fields>. In addition, L<Scanning Specification> explains how these
fields are used. Note that I/O event scanning is only supported for those card
types that interrupt.
@@ -147,8 +148,8 @@ corresponding to the VAL's state. So, if the value is 1, C<get_enum_str()>
will return the string in the ONAM field: and if 0, C<get_enum_str()> will
return the ZNAM string.
See L<Fields Common to All Record Types> for more on the record name (NAME)
and description (DESC) fields.
See L<Fields Common to All Record Types|dbCommonRecord/Operator Display
Parameters> for more on the record name (NAME) and description (DESC) fields.
=fields ZNAM, ONAM, NAME, DESC
@@ -164,8 +165,8 @@ C<MAJOR>. 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
states (0-1, 1-0) and its severity is configured as MINOR or MAJOR.
See L<Invalid Alarm Output Action> for more information on the IVOA and
IVOV fields. L<Alarm Fields> lists other fields related to alarms that are
See L<Invalid Output Action Fields|dbCommonOutput/Invalid Output Action Fields> for more information on the IVOA and
IVOV fields. L<Alarm Fields|dbCommonRecord/Alarm Fields> lists other fields related to alarms that are
common to all record types.
=fields ZSV, OSV, COSV, IVOA, IVOV
@@ -493,7 +494,7 @@ 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.
=item 4.
Check severity and write the new value. See L<Invalid Alarm Output Action>
Check severity and write the new value. See L<Invalid Output Action Fields|dbCommonOutput/Invalid Output Action Fields>
for more information on how INVALID alarms affect output.
=item 5.

42
modules/database/src/std/rec/calcRecord.dbd.pod
View File

@@ -16,32 +16,7 @@ then be used.
=head2 Parameter Fields
The fields in the record fall into the following categories:
=over 1
=item *
scan parameters
=item *
read parameters
=item *
expression parameters
=item *
operator display parameters
=item *
alarm parameters
=item *
monitor parameters
=item *
run-time parameters
=back
The record-specific fields are described below, grouped by functionality.
=recordtype calc
@@ -52,13 +27,8 @@ recordtype(calc) {
=head3 Scan Parameters
The Calc record has the standard fields for specifying under what
circumstances the record will be processed. These fields are listed in
L<Scan Fields>. In addition, L<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 C<I/O Intr>.
=fields SCAN
circumstances the record will be processed.
These fields are listed in L<Scan Fields|dbCommonRecord/Scan Fields>.
=head3 Read Parameters
@@ -466,8 +436,8 @@ 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 L<Fields Common to All Record Types> for more on the record name (NAME)
and description (DESC) fields.
See L<Fields Common to All Record Types|dbCommonRecord/Operator Display
Parameters> for more on the record name (NAME) and description (DESC) fields.
=fields EGU, PREC, HOPR, LOPR, NAME, DESC
@@ -484,7 +454,7 @@ limit alarms for the VAL field and the severity corresponding to those
conditions.
The HYST field defines an alarm deadband for each limit. See L<Alarm Specification>
for a complete explanation of alarms of these fields. L<Alarm Fields>
for a complete explanation of alarms of these fields. L<Alarm Fields|dbCommonRecord/Alarm Fields>
lists other fields related to alarms that are common to all record types.
=fields HIHI, HIGH, LOW, LOLO, HHSV, HSV, LSV, LLSV, HYST

44
modules/database/src/std/rec/calcoutRecord.dbd.pod
View File

@@ -22,35 +22,7 @@ Wait record.
=head2 Parameter Fields
The fields in this record fall into these categories:
=over 1
=item *
scan parameters
=item *
read parameters
=item *
expression parameters
=item *
output parameters
=item *
operator display parameters
=item *
alarm parameters
=item *
monitor parameters
=item *
run-time parameters
=back
The record-specific fields are described below, grouped by functionality.
=recordtype calcout
@@ -80,11 +52,8 @@ recordtype(calcout) {
=head3 Scan Parameters
The Calcout record has the standard fields for specifying under what
circumstances the record will be processed. The fields are listed in
L<Scan Fields>. In addition, L<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 C<I/O Intr>.
circumstances the record will be processed.
These fields are listed in L<Scan Fields|dbCommonRecord/Scan Fields>.
=head3 Read Parameters
@@ -99,9 +68,6 @@ example, whether or not the specified PV was found and a link to it
established. See L<Operator Display Parameters> for an explanation of these
fields.
See L<Address Specification> for information on how to specify database
links.
=fields INPA, INPB, INPC, INPD, INPE, INPF, INPG, INPH, INPI, INPJ, INPK, INPL
=head3 Expression
@@ -607,8 +573,8 @@ is set to one.
The DLYA field is set to one during the delay specified in ODLY.
See L<Fields Common to All Record Types> for more information on the record
name (NAME) and description (DESC) fields.
See L<Fields Common to All Record Types|dbCommonRecord/Operator Display
Parameters> for more on the record name (NAME) and description (DESC) fields.
=fields EGU, PREC, HOPR, LOPR, INAV, INBV, INCV, INDV, INEV, INFV, INGV, INHV, INIV, INJV, INKV, INLV, OUTV, CLCV, OCLV, DLYA, NAME, DESC

13
modules/database/src/std/rec/compressRecord.dbd.pod
View File

@@ -44,8 +44,6 @@ The record-specific fields are described below.
=recordtype compress
...
=cut
menu(compressALG) {
@@ -70,7 +68,8 @@ The record-specific fields are described below, grouped by functionality.
The compression record has the standard fields for specifying under what
circumstances the record will be processed. These fields are listed in
L<Scan Fields>. In addition, L<Scanning Specification>
L<Scan Fields|dbCommonRecord/Scan Fields>. In addition, L<Scanning Specification>
explains how these fields are used. Since the compression record supports no
direct interfaces to hardware, its SCAN field cannot specify C<<< I/O Intr >>>.
@@ -197,14 +196,14 @@ PREC controls the floating-point precision whenever C<<< get_precision >>> is
called, and the field being referenced is the VAL field (i.e., one of the values
contained in the circular buffer).
See L<Fields Common to All Record Types>
for more on the record name (NAME) and description (DESC) fields.
See L<Fields Common to All Record Types|dbCommonRecord/Operator Display
Parameters> for more on the record name (NAME) and description (DESC) fields.
=head3 Alarm Parameters
The compression record has the alarm parameters common to all record types
described in L<Alarm Fields>.
described in L<Alarm Fields|dbCommonRecord/Alarm Fields>.
=head3 Run-time Parameters
@@ -234,7 +233,7 @@ appropriate fields in the record.
long process(struct dbCommon *precord)
See L<Record Processing> below.
See L</"Record Processing"> below.
long special(struct dbAddr *paddr, int after)

40
modules/database/src/std/rec/dfanoutRecord.dbd.pod
View File

@@ -16,32 +16,7 @@ device support.
=head2 Parameter Fields
The fields in this record can be classified into the following categories:
=over
=item *
scan parameters
=item *
desired output parameters
=item *
write parameters
=item *
operator display parameters
=item *
alarm parameters
=item *
monitor parameters
=item *
run-time and simulation mode parameters
=back
The record-specific fields are described below, grouped by functionality.
=recordtype dfanout
@@ -58,11 +33,8 @@ recordtype(dfanout) {
=head3 Scan Parameters
The data fanout record has the standard fields for specifying under what
circumstances it will be processed. These fields are listed in
L<Scan Fields>. In addition, L<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 C<I/O Intr>.
circumstances it will be processed.
These fields are listed in L<Scan Fields|dbCommonRecord/Scan Fields>.
=head3 Desired Output Parameters
@@ -131,8 +103,8 @@ displays. They apply to the VAL, HIHI, HIGH, LOW, and LOLO fields. The
record support routines C<get_graphic_double()> and C<get_control_double()>
retrieve HOPR and LOPR.
See L<Fields Common to All Record Types> for more on the record name (NAME)
and description (DESC) fields.
See L<Fields Common to All Record Types|dbCommonRecord/Operator Display
Parameters> for more on the record name (NAME) and description (DESC) fields.
=fields EGU, HOPR, LOPR, NAME, DESC
@@ -148,7 +120,7 @@ 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 L<Alarm Specification> for a complete explanation of alarms and these
fields. L<Alarm Fields> lists other fields related to alarms that are
fields. L<Alarm Fields|dbCommonRecord/Alarm Fields> lists other fields related to alarms that are
common to all record types.
=fields HIHI, HIGH, LOW, LOLO, HHSV, HSV, LSV, LLSV, HYST

34
modules/database/src/std/rec/eventRecord.dbd.pod
View File

@@ -15,27 +15,7 @@ handler routine for I/O Event-scanned records.
=head2 Parameter Fields
The records in this field fall into the following groups of parameters:
=over
=item *
scan parameters
=item *
read parameters
=item *
event number parameters
=item *
simulation mode parameters
=back
The record-specific fields are described below, grouped by functionality.
=recordtype event
@@ -59,9 +39,8 @@ recordtype(event) {
The event record has the standard fields for specifying under what circumstances
it will be processed. If the SCAN field specifies C<I/O Intr>, then device
support will provide an interrupt handler, posting an event number when an I/O
interrupt occurs. These fields are listed in L<Scan Fields>. In addition,
L<Scanning Specification> explains how the scanning fields work. Note that I/O
event scanning is only supported for those card types that interrupt.
interrupt occurs.
These fields are listed in L<Scan Fields|dbCommonRecord/Scan Fields>.
=head3 Event Number Parameters
@@ -112,8 +91,9 @@ access link. For soft records, the DTYP field should specify C<Soft Channel>.
=head3 Operator Display Parameters
See L<Fields Common to All Record Types> for more on the record name (NAME) and
description (DESC) fields.
See L<Fields Common to All Record Types|dbCommonRecord/Operator Display
Parameters> for more on the record name (NAME) and description (DESC) fields.
=fields NAME, DESC
@@ -276,7 +256,7 @@ C<init_record()> routine.
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
or deleted from an I/O event scan list. C<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.

31
modules/database/src/std/rec/fanoutRecord.dbd.pod
View File

@@ -17,27 +17,11 @@ process. If more than sixteen are needed, one of the forward links in the fanout
record (or its FLNK field) 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 other records.
Data Fanout record can, on the other hand, send data to other records.
=head2 Parameter Fields
The fanout record's fields fall into the following categories:
=over
=item *
scan parameters
=item *
operator display parameters
=item *
run-time parameters.
=back
The record-specific fields are described below, grouped by functionality.
=recordtype fanout
@@ -113,9 +97,7 @@ 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 L<Scan Fields>. In addition,
L<Scanning Specification> explains in more detail how forward links and the
scanning algorithms work.
These fields are listed in L<Scan Fields|dbCommonRecord/Scan Fields>.
=fields SELM, SELN, SELL, OFFS, SHFT, LNK0, LNK1, LNK2, LNK3, LNK4, LNK5, LNK6, LNK7, LNK8, LNK9, LNKA, LNKB, LNKC, LNKD, LNKE, LNKF
@@ -238,15 +220,16 @@ scanning algorithms work.
=head3 Operator Display Parameters
These parameters are used to present meaningful data to the operator. See
L<Fields Common to All Record Types> for more on these fields.
L<Fields Common to All Record Types|dbCommonRecord/Operator Display Parameters>
for more on these fields.
=fields NAME, DESC
=head3 Alarm Parameters
The Fanout record has the alarm parameters common to all record types.
L<Alarm Fields> lists other fields related to a alarms that are common to all
record types.
L<Alarm Fields|dbCommonRecord/Alarm Fields> lists the fields related to
alarms that are common to all record types.
=head3 Run-time Parameters

9
modules/database/src/std/rec/histogramRecord.dbd.pod
View File

@@ -52,16 +52,17 @@ These intervals are determined by dividing the range by NELM:
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 L<Fields Common to All Record Types> for
more on the record name (NAME) and description (DESC) fields.
either textually or graphically. See
L<Fields Common to All Record Types|dbCommonRecord/Operator Display Parameters>
for more on the record name (NAME) and description (DESC) fields.
=fields NAME, DESC
=head3 Alarm Parameters
The Histogram record has the alarm parameters common to all record types.
L<Alarm Fields> lists other fields related to a alarms that are common to all
record types.
L<Alarm Fields|dbCommonRecord/Alarm Fields> lists the fields related to
alarms that are common to all record types.
=head3 Monitor Parameters

5
modules/database/src/std/rec/int64inRecord.dbd.pod
View File

@@ -43,10 +43,7 @@ that comes with Base.
The INP link field contains a database or channel access link or provides
hardware address information that the device support uses to determine where the
input data should come from.
The format for the INP field value depends on the device support layer that is
selected by the DTYP field.
See L<Address Specification|...> for a description of the various hardware
address formats supported.
=head3 Operator Display Parameters

6
modules/database/src/std/rec/int64outRecord.dbd.pod
View File

@@ -74,10 +74,6 @@ that comes with Base.
The OUT link field contains a database or channel access link or provides
hardware address information that the device support uses to determine where the
output data should be sent to.
The format for the OUT field value depends on the device support layer that is
selected by the DTYP field.
See L<Address Specification|...> for a description of the various hardware
address formats supported.
=head3 Operator Display Parameters
@@ -463,7 +459,7 @@ by at least HYST between level alarm status and severity changes.
=item 4.
Check severity and write the new value. See L<Invalid Alarm Output Action>
Check severity and write the new value. See L<Invalid Output Action Fields|dbCommonOutput/Invalid Output Action Fields>
for details on how invalid alarms affect output records.
=item 5.

28
modules/database/src/std/rec/longinRecord.dbd.pod
View File

@@ -28,10 +28,8 @@ The record-specific fields are described below, grouped by functionality.
=head3 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 L<Scan
Fields>. In addition, L<Scanning Specification> explains how these fields are
used. Note that I/O event scanning is only supported for those card types
that interrupt.
circumstances the record will be processed.
These fields are listed in L<Scan Fields|dbCommonRecord/Scan Fields>.
=head3 Read Parameters
@@ -43,9 +41,7 @@ I/O bus used.
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 C<<< Soft Channel >>>
device support module is available for longin records. See L<Address
Specification> for information on the format of hardware addresses and a
database links.
device support module is available for longin records.
=fields VAL, INP, DTYP
@@ -62,8 +58,9 @@ The HOPR and LOPR fields set the upper and lower display limits for the VAL,
HIHI, HIGH, LOW, and LOLO fields. Both the C<<< get_graphic_double >>> and C<<<
get_control_double >>> record support routines retrieve these fields.
See L<Fields Common to All Record Types> for more on the record name (NAME) and
description (DESC) fields.
See L<Fields Common to All Record Types|dbCommonRecord/Operator Display
Parameters> for more on the record name (NAME) and description (DESC) fields.
=fields EGU, HOPR, LOPR, NAME, DESC
@@ -76,10 +73,9 @@ 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 L<Alarm
Specification> for a complete explanation of alarms and these fields. L<Alarm
Fields> lists other fields related to a alarms that are common to all record
types.
HYST field can be used to specify a deadband around each limit.
L<Alarm Fields|dbCommonRecord/Alarm Fields> lists the fields related to
alarms that are common to all record types.
=fields HIHI, HIGH, LOW, LOLO, HHSV, HSV, LSV, LLSV, HYST
@@ -91,7 +87,7 @@ 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 L<Monitor Specification> for a complete explanation of monitors.
monitors.
=fields ADEL, MDEL
@@ -100,7 +96,7 @@ monitors. See L<Monitor Specification> for a complete explanation of monitors.
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
HYST) will monitors be triggered. For instance, only if the difference
between VAL and MLST is greater than MDEL are the monitors triggered for VAL.
=fields LALM, ALST, MLST
@@ -275,7 +271,7 @@ C<init_record()> routine.
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
or deleted from an I/O event scan list. C<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.

41
modules/database/src/std/rec/longoutRecord.dbd.pod
View File

@@ -24,33 +24,13 @@ recordtype(longout) {
=head2 Parameter Fields
The fields in this record fall into the following categories:
=over
=item * L<Scan Parameters>
=item * L<Desired Output Parameters>
=item * L<Write Parameters>
=item * L<Operator Display Parameters>
=item * L<Alarm Parameters>
=item * L<Monitor Parameters>
=item * L<Simulation Mode Parameters>
=back
The record-specific fields are described below, grouped by functionality.
=head3 Scan Parameters
The longout record has the standard fields for specifying under what
circumstances it will be processed. These fields are listed in L<Scan Fields>.
In addition, L<Scanning Specification> explains how these fields are used. Note
that I/O event scanning is only supported for those card types that
interrupt.
circumstances it will be processed.
These fields are listed in L<Scan Fields|dbCommonRecord/Scan Fields>.
=head3 Desired Output Parameters
@@ -141,8 +121,8 @@ The HOPR and LOPR fields set the upper and lower display limits for the VAL,
HIHI, HIGH, LOW, and LOLO fields. Both the C<<< get_graphic_double >>> and C<<<
get_control_double >>> record support routines retrieve these fields.
See L<Fields Common to All Record Types> for more on the record name (NAME) and
description (DESC) fields.
See L<Fields Common to All Record Types|dbCommonRecord/Operator Display
Parameters> for more on the record name (NAME) and description (DESC) fields.
=fields EGU, HOPR, LOPR, NAME, DESC
@@ -195,10 +175,10 @@ 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 L<Alarm Specification> for a complete explanation of alarms and
See L<Alarm Specification> for a complete explanation of alarms and
these fields. For an explanation of the IVOA and IVOV fields, see L<Output
Records>. L<Alarm Fields> lists other fields related to a alarms that are common
to all record types.
Records>. L<Alarm Fields|dbCommonRecord/Alarm Fields> lists the fields related to
alarms that are common to all record types.
=fields HIHI, HIGH, LOW, LOLO, HHSV, HSV, LSV, LLSV, HYST, IVOA, IVOV
@@ -482,7 +462,8 @@ before the alarm status and severity is lowered.
=item 4.
Check severity and write the new value. See L<Invalid Alarm Output Action> for
Check severity and write the new value. See
L<Invalid Output Action Fields|dbCommonOutput/Invalid Output Action Fields> for
information on how INVALID alarms affect output records.
=item 5.
@@ -569,7 +550,7 @@ C<init_record()> routine.
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
or deleted from an I/O event scan list. C<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.

19
modules/database/src/std/rec/lsiRecord.dbd.pod
View File

@@ -24,8 +24,8 @@ recordtype(lsi) {
=head3 Scan Parameters
The long string input record has the standard fields for specifying under what
circumstances it will be processed. These fields are listed in L<Scan Fields>.
In addition, L<Scanning Specification> explains how these fields are used.
circumstances it will be processed.
These fields are listed in L<Scan Fields|dbCommonRecord/Scan Fields>.
=head3 Input Specification
@@ -37,8 +37,6 @@ is processed and placed in the VAL field. The maximum number of characters in
VAL is given by SIZV, and cannot be larger than 65535. In addition, the
appropriate device support module must be entered into the DTYP field.
See L<Address Specification> for information on specifying links.
=fields VAL, OVAL, SIZV, INP, DTYP
=cut
@@ -59,7 +57,7 @@ See L<Address Specification> for information on specifying links.
pp(TRUE)
special(SPC_DBADDR)
extra("char *val")
#=type STRING[SIZV]
#=type STRING or CHAR[SIZV]
#=read Yes
#=write Yes
}
@@ -68,7 +66,7 @@ See L<Address Specification> for information on specifying links.
special(SPC_DBADDR)
interest(3)
extra("char *oval")
#=type STRING[SIZV]
#=type STRING or [SIZV]
#=read Yes
#=write No
}
@@ -119,16 +117,17 @@ APST is used for archiver monitors and MPST for all other type of monitors.
=head3 Operator Display Parameters
See L<Fields Common to All Record Types> for more on the record name (NAME) and
description (DESC) fields.
See L<Fields Common to All Record Types|dbCommonRecord/Operator Display
Parameters> for more on the record name (NAME) and description (DESC) fields.
=fields NAME, DESC
=head3 Alarm Parameters
The long string input record has the alarm parameters common to all record
types. L<Alarm Fields> lists other fields related to a alarms that are common to
all record types.
types. L<Alarm Fields|dbCommonRecord/Alarm Fields> lists the fields related to
alarms that are common to all record types.
=head3 Run-time Parameters

63
modules/database/src/std/rec/lsoRecord.dbd.pod
View File

@@ -19,15 +19,13 @@ The record-specific fields are described below, grouped by functionality.
=cut
include "menuIvoa.dbd"
recordtype(lso) {
=head3 Scan Parameters
The long string output record has the standard fields for specifying under what
circumstances it will be processed. These fields are listed in L<Scan Fields>.
In addition, L<Scanning Specification> explains how these fields are used.
circumstances it will be processed.
These fields are listed in L<Scan Fields|dbCommonRecord/Scan Fields>.
=head3 Desired Output Parameters
@@ -49,8 +47,6 @@ interpreted as a CA link name. If you want to initialize your string output
record, it is therefore best to use the VAL field. Note that if DOL is a
constant, OMSL cannot be C<closed_loop>.
See L<Address Specification> for information on specifying links.
=fields VAL, SIZV, DOL, OMSL
=head3 Output Specification
@@ -59,8 +55,6 @@ The output link specified in the OUT field specifies where the long 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 L<Address Specification> for information on specifying links.
In addition, the appropriate device support module must be entered into the DTYP
field.
@@ -79,30 +73,22 @@ APST is used for archiver monitors and MPST for all other type of monitors.
=head3 Operator Display Parameters
See L<Fields Common to All Record Types> for more on the record name (NAME) and
description (DESC) fields.
See L<Fields Common to All Record Types|dbCommonRecord/Operator Display
Parameters> for more on the record name (NAME) and description (DESC) fields.
=fields NAME, DESC
=head3 Alarm Parameters
The long string input record has the alarm parameters common to all record
types. L<Alarm Fields> lists other fields related to a alarms that are common to
all record types.
The long string input record has the same alarm parameters common to all record
types. L<Alarm Fields|dbCommonRecord/Alarm Fields> lists the fields related to
alarms that are common to all record types.
The IVOA field specifies an action to take when the INVALID alarm is triggered.
There are three possible actions:
=head4 Menu menuIvoa
=menu menuIvoa
When C<<< Set output to IVOV >>>, the value contained in the IVOV field is
written to the output link during an alarm condition. See
L<Invalid Alarm Output Action>
L<Invalid Output Action Fields|dbCommonOutput/Invalid Output Action Fields>
for more information on the IVOA and IVOV fields.
L<Alarm Fields>
lists other fields related to a alarms that are common to all record types.
=fields IVOA, IVOV
@@ -124,12 +110,18 @@ lists other fields related to a alarms that are common to all record types.
pp(TRUE)
special(SPC_DBADDR)
extra("char *val")
#=type STRING or CHAR[SIZV]
#=read Yes
#=write Yes
}
field(OVAL,DBF_NOACCESS) {
prompt("Previous Value")
special(SPC_DBADDR)
interest(3)
extra("char *oval")
#=type STRING or [SIZV]
#=read Yes
#=write No
}
field(SIZV,DBF_USHORT) {
prompt("Size of buffers")
@@ -266,26 +258,23 @@ for more information on simulation mode and its fields.
}
=head2 Device Support Interface
The record requires device support to provide an entry table (dset) which
defines the following members:
The record defines a device support entry table type C<lsodset> in the generated
lsoRecord.h file as follows:
typedef struct {
long number;
long (*report)(int level);
long (*init)(int after);
long (*init_record)(lsoRecord *prec);
long (*get_ioint_info)(int cmd, lsoRecord *prec, IOSCANPVT *piosl);
long (*write_string)(lsoRecord *prec);
typedef struct lsodset {
dset common;
long (*write_string)(struct lsoRecord *prec);
} lsodset;
#define HAS_lsodset
The module must set C<number> to at least 5, and provide a pointer to its
C<write_string()> routine; the other function pointers may be C<NULL> if their
associated functionality is not required for this support layer.
Most device supports also provide an C<init_record()> routine to configure the
record instance and connect it to the hardware or driver support layer.
The support module must set C<common.number> to at least 5, and provide a
pointer to its C<write_string()> routine; the other function pointers may be
C<NULL> if their associated functionality is not required for this support
layer.
Most device supports also provide a C<common.init_record()> routine to configure
the record instance and connect it to the hardware or driver support layer.
=head2 Device Support for Soft Records

30
modules/database/src/std/rec/mbbiDirectRecord.dbd.pod
View File

@@ -31,10 +31,8 @@ The record-specific fields are described below, grouped by functionality.
=head3 Scan Parameters
The mbbiDirect record has the standard fields for specifying under what
circumstances the record will be processed. These fields are listed in L<Scan
Fields>. In addition, L<Scanning Specification> explains how these fields are
used. Note that I/O event scanning is only supported for those card types
that interrupt.
circumstances the record will be processed.
These fields are listed in L<Scan Fields|dbCommonRecord/Scan Fields>.
=head3 Read and Convert Parameters
@@ -42,8 +40,7 @@ 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 L<Address Specification> for
information on the format of hardware addresses.
differs according to the I/O bus used.
Two soft device support modules can be specified in DTYP C<Soft Channel> and
C<<< Raw Soft Channel >>>.
@@ -53,8 +50,7 @@ upon which the normal conversion process is undergone. C<<< Soft Channel >>>
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 L<Address Specification> for
information on how to database links.
run-time via dbPutField or dbPutLink.
For records that don't use C<<< Soft Channel >>> device support, RVAL is used to
determine VAL as follows:
@@ -77,8 +73,9 @@ Each of the fields, B0-BF and B10-B1F, represents one bit of the word.
These parameters are used to present meaningful data to the operator.
See L<Fields Common to All Record Types> for more on the record name (NAME) and
description (DESC) fields.
See L<Fields Common to All Record Types|dbCommonRecord/Operator Display
Parameters> for more on the record name (NAME) and description (DESC) fields.
=fields NAME, DESC
@@ -220,14 +217,13 @@ for more information on simulation mode and its fields.
=head3 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 L<Alarm Specification> for a complete
explanation of Scan and Read alarms. No fields exist for the mbbi direct record
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. No fields exist for the mbbi direct record
to have state alarms.
L<Alarm Fields> lists other fields related to a alarms that are common to all
record types.
L<Alarm Fields|dbCommonRecord/Alarm Fields> lists the fields related to
alarms that are common to all record types.
=cut
@@ -545,7 +541,7 @@ also give SHFT a value.
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 IE<sol>O event scan list. cmd has the value (0,1) if the
or deleted from an IE<sol>O event scan list. C<cmd> has the value (0,1) if the
record is being (added to, deleted from) an IE<sol>O event list. It must be
provided for any device type that can use the ioEvent scanner.

21
modules/database/src/std/rec/mbbiRecord.dbd.pod
View File

@@ -38,10 +38,8 @@ The record-specific fields are described below, grouped by functionality.
=head3 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 L<Scan
Fields>. In addition, L<Scanning Specification> explains how these fields are
used. Note that I/O event scanning is only supported for those card types that
interrupt.
what circumstances it will be processed.
These fields are listed in L<Scan Fields|dbCommonRecord/Scan Fields>.
=head3 Read and Convert Parameters
@@ -49,8 +47,7 @@ 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 L<Address Specification> for
information on the format of hardware addresses.
differs according to the I/O bus used.
Two soft device support modules can be specified in DTYP C<Soft Channel> and
C<<< Raw Soft Channel >>>.
@@ -60,8 +57,7 @@ upon which the normal conversion process is undergone. C<<< Soft Channel >>>
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 L<Address Specification> for
information on the format of database addresses.
at run-time via dbPutField or dbPutLink.
MASK is used by the raw soft channel read routine, and by typical device support
read routines, to select only the desired bits when reading the hardware
@@ -111,8 +107,9 @@ record routines retrieve these strings for the operator. C<<< Get_enum_str >>>
gets the string corresponding to the value set in VAL, and C<<< get_enum_strs
>>> retrieves all the strings.
See L<Fields Common to All Record Types> for more on the record name (NAME) and
description (DESC) fields.
See L<Fields Common to All Record Types|dbCommonRecord/Operator Display
Parameters> for more on the record name (NAME) and description (DESC) fields.
=fields NAME, DESC, ZRST, ONST, TWST, THST, FRST, FVST, SXST, SVST, EIST, NIST, TEST, ELST, TVST, TTST, FTST, FFST
@@ -417,7 +414,7 @@ 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 L<Alarm Specification> for a complete
explanation of discrete alarms and these fields. L<Alarm Fields> lists other
explanation of discrete alarms and these fields. L<Alarm Fields|dbCommonRecord/Alarm Fields> lists other
fields related to a alarms that are common to all record types.
=fields UNSV, COSV, ZRSV, ONSV, TWSV, THSV, FRSV, FVSV, SXSV, SVSV, EISV, NISV, TESV, ELSV, TVSV, TTSV, FTSV, FFSV
@@ -885,7 +882,7 @@ also give SHFT a value.
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
or deleted from an I/O event scan list. C<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.

25
modules/database/src/std/rec/mbboDirectRecord.dbd.pod
View File

@@ -28,10 +28,8 @@ The record-specific fields are described below, grouped by functionality.
=head3 Scan Parameters
The mbboDirect record has the standard fields for specifying under what
circumstances it will be processed. These fields are listed in L<Scan Fields>.
In addition, L<Scanning Specification> explains how these fields are used. Note
that I/O event scanning is only supported for those card types that
interrupt.
circumstances it will be processed.
These fields are listed in L<Scan Fields|dbCommonRecord/Scan Fields>.
=head3 Desired Output Parameters
@@ -45,8 +43,7 @@ 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 C<<< supervisory >>> mode. DOL can also be a constant, in which case VAL
is initialized to the constant value. Note that OMSL cannot be C<<< closed_loop
>>> when DOL is a constant. See L<Address Specification> for information on how
to specify database links.
>>> when DOL is a constant.
VAL is then converted to RVAL in the routine described in the next section.
However, the C<<< Soft Channel >>> device support module for the mbboDirect
@@ -75,15 +72,15 @@ routines--{Soft Channel} or C<<< Raw Soft Channel >>>. The difference between
the two is that C<<< Soft Channel >>> writes the desired output value from VAL
directly to the output link while C<<< Raw Soft Channel >>> writes the value
from RVAL to the output link after it has undergone the conversion described
above. See L<Address Specification> for information on how to specify database
links.
above.
=fields OUT, RVAL, SHFT, B0, B1, B2, B3, B4, B5, B6, B7, B8, B9, BA, BB, BC, BD, BE, BF
=head3 Operator Display Parameters
See L<Fields Common to All Record Types> for more on the record name (NAME) and
description (DESC) fields.
See L<Fields Common to All Record Types|dbCommonRecord/Operator Display
Parameters> for more on the record name (NAME) and description (DESC) fields.
=fields NAME, DESC
@@ -252,9 +249,9 @@ The IVOA field specifies an action to take when the INVALID alarm is triggered.
There are three possible actions: C<<< Continue normally >>>, C<<< Don't drive
outputs >>>, or C<<< Set output to IVOV >>>. When C<<< Set output to IVOV >>> is
specified and a INVALID alarm is triggered, the record will write the value in
the IVOV field to output. See L<Invalid Alarm Output Action> for more
information. L<Alarm Fields> lists other fields related to a alarms that are
common to all record types.
the IVOV field to output. See L<Invalid Output Action Fields|dbCommonOutput/Invalid Output Action Fields> for more
information. L<Alarm Fields|dbCommonRecord/Alarm Fields> lists the fields related to
alarms that are common to all record types.
=fields IVOA, IVOV
@@ -656,7 +653,7 @@ SHFT given a value.
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
or deleted from an I/O event scan list. C<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.

35
modules/database/src/std/rec/mbboRecord.dbd.pod
View File

@@ -28,9 +28,8 @@ The record-specific fields are described below, grouped by functionality.
=head3 Scan Parameters
The mbbo record has the standard fields for specifying under what circumstances
it will be processed. These fields are listed in L<Scan Fields>. In addition,
L<Scanning Specification> explains how these fields are used. Note that I/O
event scanning is only supported for those card types that interrupt.
it will be processed.
These fields are listed in L<Scan Fields|dbCommonRecord/Scan Fields>.
=head3 Desired Output Parameters
@@ -64,8 +63,7 @@ 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 L<Address Specification> for
information on the format of hardware addresses.
differs according to the I/O bus used.
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
@@ -87,8 +85,7 @@ constant, then the DTYP field must specify either one of the two soft device
support modules-- C<<< Soft Channel >>> or C<<< Raw Soft Channel >>>. C<<< Soft
>>> C<<< Channel >>> writes the value of VAL to the output link, without any
conversion, while C<<< Raw Soft Channel >>> writes the value from RVAL after it
has undergone the above conversion. See L<Address Specification> for information
on specifying links.
has undergone the above conversion.
Note also that when a string is retrieved as the desired output, a record
support routine is provided (C<<< put_enum_str() >>>) that will check to see
@@ -108,8 +105,8 @@ C<<< get_enum_strs() >>> record routines retrieve these strings for the
operator. C<<< get_enum_str() >>> gets the string corresponding to the value in
VAL, and C<<< get_enum_strs() >>> retrieves all the strings.
See L<Fields Common to All Record Types> for more on the record name (NAME) and
description (DESC) fields.
See L<Fields Common to All Record Types|dbCommonRecord/Operator Display
Parameters> for more on the record name (NAME) and description (DESC) fields.
=fields NAME, DESC, ZRST, ONST, TWST, THST, FRST, FVST, SXST, SVST, EIST, NIST, TEST, ELST, TVST, TTST, FTST, FFST
@@ -138,10 +135,10 @@ 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 L<Alarm Specification> for a complete explanation of discrete alarms and
these fields. See L<Invalid Alarm Output Action> for an explanation of the IVOA
and IVOV fields. L<Alarm Fields> lists other fields related to a alarms that are
common to all record types.
See L<Invalid Output Action Fields|dbCommonOutput/Invalid Output Action Fields>
for an explanation of the IVOA and IVOV fields.
L<Alarm Fields|dbCommonRecord/Alarm Fields> lists the fields related to
alarms that are common to all record types.
=fields UNSV, COSV, IVOA, IVOV, ZRSV, ONSV, TWSV, THSV, FRSV, FVSV, SXSV, SVSV, EISV, NISV, TESV, ELSV, TVSV, TTSV, FTSV, FFSV
@@ -705,7 +702,6 @@ for more information on simulation mode and its fields.
promptgroup("50 - Output")
interest(2)
}
}
=head2 Record Support
@@ -858,8 +854,10 @@ and severity to change. If so, NSEV, NSTA and LALM are set.
=item 5.
Check severity and write the new value. See L<Simulation Mode> and L<Invalid
Alarm Output Action> for more information.
Check severity and write the new value. See
L<Output Simulation Fields|dbCommonOutput/Output Simulation Fields> and
L<Invalid Output Action Fields|dbCommonOutput/Invalid Output Action Fields> for
more information.
=item 6.
@@ -944,7 +942,7 @@ given a value.
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
or deleted from an I/O event scan list. C<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.
@@ -975,7 +973,7 @@ The C<<< Soft Channel >>> module writes the current value of VAL.
If the OUT link type is PV_LINK, then dbCaAddInlink is called by
C<init_record()>.
write_mbbo calls recGblPutLinkValue to write the current value of VAL. See
C<write_mbbo()> calls C<dbPutLink()> to write the current value of VAL. See
L<Soft Output> for more information.
=head4 Raw Soft Channel
@@ -984,3 +982,4 @@ This module writes RVAL to the location specified in the output link. It returns
a 0.
=cut
}

8
modules/database/src/std/rec/permissiveRecord.dbd.pod
View File

@@ -31,9 +31,7 @@ The record-specific fields are described below, grouped by functionality.
The permissive record has the standard fields for specifying under what
circumstances the record will be processed. These fields are listed in
L<Scan Fields>. In addition, L<Scanning Specification> explains how these
fields are used. Since the permissive record supports no direct interfaces to
hardware, its SCAN field cannot be C<<< I/O Intr >>>.
L<Scan Fields|dbCommonRecord/Scan Fields>.
=head3 Client-server Parameters
@@ -87,8 +85,8 @@ description (DESC) fields.
=head3 Alarm Parameters
The Permissive record has the alarm parameters common to all record types.
L<Alarm Fields> lists other fields related to a alarms that are common to all
record types.
L<Alarm Fields|dbCommonRecord/Alarm Fields> lists the fields related to
alarms that are common to all record types.
=head3 Run-time Parameters

15
modules/database/src/std/rec/printfRecord.dbd.pod
View File

@@ -24,8 +24,8 @@ recordtype(printf) {
=head3 Scan Parameters
The printf record has the standard fields for specifying under what
circumstances it will be processed. These fields are listed in L<Scan Fields>.
In addition, L<Scanning Specification> explains how these fields are used.
circumstances it will be processed.
These fields are listed in L<Scan Fields|dbCommonRecord/Scan Fields>.
=head3 String Generation Parameters
@@ -154,8 +154,6 @@ The output link specified in the OUT field specifies where the printf record is
to write the contents of its VAL field. The link can be a database or channel
access link. If the OUT field is a constant, no output will be written.
See L<Address Specification> for information on specifying links.
In addition, the appropriate device support module must be entered into the DTYP
field.
@@ -163,8 +161,9 @@ field.
=head3 Operator Display Parameters
See L<Fields Common to All Record Types> for more on the record name (NAME) and
description (DESC) fields.
See L<Fields Common to All Record Types|dbCommonRecord/Operator Display
Parameters> for more on the record name (NAME) and description (DESC) fields.
=fields NAME, DESC
@@ -217,8 +216,8 @@ description (DESC) fields.
=head3 Alarm Parameters
The printf record has the alarm parameters common to all record types.
L<Alarm Fields> lists other fields related to a alarms that are common to all
record types.
L<Alarm Fields|dbCommonRecord/Alarm Fields> lists the fields related to
alarms that are common to all record types.
The IVLS field specifies a string which is sent to the OUT link if if input
link data are invalid.

26
modules/database/src/std/rec/selRecord.dbd.pod
View File

@@ -33,9 +33,8 @@ The record-specific fields are described below, grouped by functionality.
=head3 Scan Parameters
The select record has the standard fields for specifying under what
circumstances the record will be processed. These fields are listed in
L<Scan Fields>. In addition, L<Scanning Specification>
explains how these fields work.
circumstances the record will be processed.
These fields are listed in L<Scan Fields|dbCommonRecord/Scan Fields>.
=head3 Read Parameters
@@ -45,8 +44,7 @@ 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 L<Address Specification>
for information on how to specify database links.
value given to it and can be modified via dbPuts.
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,
@@ -80,8 +78,7 @@ 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 L<Address Specification> for information on how to
specify database links.
changed via dbPuts.
The C<<< High Signal >>>, C<<< Low Signal >>>, and C<<< Median Signal >>>
algorithms do not use SELN or NVL. If C<<< High Signal >>> is chosen, VAL is set
@@ -113,8 +110,8 @@ The PREC field determines the floating point precision with which to display
VAL. It is used whenever the C<<< get_precision >>> record support routine is
called.
See L<Fields Common to All Record Types> for more on the record name (NAME)
and description (DESC) fields.
See L<Fields Common to All Record Types|dbCommonRecord/Operator Display
Parameters> for more on the record name (NAME) and description (DESC) fields.
=fields EGU, HOPR, LOPR, PREC, NAME, DESC
@@ -125,9 +122,9 @@ 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 L<Alarm Specification>
for a complete explanation of alarms and these fields. L<Alarm Fields>
lists other fields related to a alarms that are common to all record types.
can be either NO_ALARM, MINOR, or MAJOR.
L<Alarm Fields|dbCommonRecord/Alarm Fields> lists the fields related to
alarms that are common to all record types.
=fields HIHI, HIGH, LOW, LOLO, HHSV, HSV, LSV, LLSV, HYST
@@ -138,8 +135,7 @@ 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. L<Monitor Specification>
gives a complete explanation of alarms and deadbands.
monitors are triggered.
=fields ADEL, MDEL
@@ -183,7 +179,7 @@ is created.
long (*process)(struct dbCommon *precord)
See L<Record Processing>.
See L</"Record Processing">.
=head4 get_units

45
modules/database/src/std/rec/seqRecord.dbd.pod
View File

@@ -35,8 +35,8 @@ The record-specific fields are described below, grouped by functionality.
=head3 Scan Parameters
The sequence record has the standard fields for specifying under what
circumstances it will be processed. These fields are listed in L<Scan Fields>.
In addition, L<Scanning Specification> explains how these fields are used.
circumstances it will be processed.
These fields are listed in L<Scan Fields|dbCommonRecord/Scan Fields>.
=head3 Desired Output Parameters
@@ -48,15 +48,13 @@ The sequence record can retrieve up to 16 values from 16 locations. The user
specifies the locations in the Desired Output Link fields (DOL0-DOLF), 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.
initialized to the constant value.
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 L<Address
Specification> for information on how to specify database links.
value is fetched from the link each time the record is processed.
The value fetched from the Desired Output Links are stored in the corresponding
Desired Output Value fields (DO0-DOF). These fields can be initialized to a
constant value, but they cannot be changed via dbPuts.
constant value, and may subsequently be changed via dbPuts.
=head4 Desired Output Link Fields
@@ -97,19 +95,23 @@ See L<Selection Algorithms Description> below;
B<SELL - Link Selection Location>
This field can be initialized as a CONSTANT or as a LINK to any other record. SELN will fetch its value from this field when the seq record is processed.
Thus, when using I<Mask> or I<Specified> modes, the links that seq will process can be dinamically changed by the record pointed by SELL.
This field can be initialized as a CONSTANT or as a LINK to any other record.
SELN will fetch its value from this field when the seq record is processed.
Thus, when using C<Mask> or C<Specified> modes, the links that seq will
process can be dynamically changed by the record pointed by SELL.
B<SELN - Link Selection>
When B<C<SELM = Specified>> this is the index number of the link that will be processed, used in combination with the C<OFFS> field:
When B<C<SELM = Specified>> this is the index number of the link that will be
processed, used in combination with the C<OFFS> field:
SELN = SELN + OFFS
I<(By default, the OFFS is initalized to ZERO)>
When B<C<SELM = Mask>> this field is the bitmask that will be used to determine which links will be processed by the seq record,
When B<C<SELM = Mask>> this field is the bitmask that will be used to determine
which links will be processed by the seq record,
in combination with the C<SHFT> field:
if (SHFT >= 0)
@@ -121,11 +123,15 @@ I<(By default, the SHFT is initalized to -1)>
=head4 B<Note about SHFT and OFFS fields>
The first versions of seq record had DO, DOL, LNK and DLY fields starting with index ONE (DO1, DOL1, LNK1 and DLY1).
New version of the seq record now supports 16 links, starting by index ZERO (DO0, DOL0, LNK0 and DLY0). The SHFT and OFFS fields
were introduced to keep compatibility of old databases that used seq record with its links indexed from one onwards.
The first versions of seq record had DO, DOL, LNK and DLY fields starting with
index ONE (DO1, DOL1, LNK1 and DLY1).
Since EPICS 7 the seq record now supports 16 links, starting from index ZERO
(DO0, DOL0, LNK0 and DLY0).
The SHFT and OFFS fields were introduced to keep compatibility of old databases
that used seq records with links indexed from one.
B<If one wants to use DO0, DOL0, LNK0, DLY0 fields when SELM = Mask, SHFT field must be set to ZERO>
B<To use the DO0, DOL0, LNK0, DLY0 fields when SELM = Mask, the SHFT field must
be set to ZERO>
=head4 Selection Algorithms Description
@@ -179,16 +185,17 @@ Precision field (PREC) determines the decimal precision for the VAL field when
it is displayed. It is used when the C<<< get_precision >>> record routine is
called.
See L<Fields Common to All Record Types> for more on the record name (NAME) and
description (DESC) fields.
See L<Fields Common to All Record Types|dbCommonRecord/Operator Display
Parameters> for more on the record name (NAME) and description (DESC) fields.
=fields PREC, NAME, DESC
=head3 Alarm Parameters
The sequence record has the alarm parameters common to all record types.
L<Alarm Fields> lists other fields related to a alarms that are common to all
record types.
L<Alarm Fields|dbCommonRecord/Alarm Fields> lists the fields related to
alarms that are common to all record types.
=head2 Record Support

13
modules/database/src/std/rec/stateRecord.dbd.pod
View File

@@ -30,21 +30,22 @@ The record-specific fields are described below, grouped by functionality.
=head3 Scan Parameters
The state record has the standard fields for specifying under what circumstances
it will be processed. These fields are listed in L<Scan Fields>. In addition,
L<Scanning Specification> explains how these fields are used.
it will be processed.
These fields are listed in L<Scan Fields|dbCommonRecord/Scan Fields>.
=head3 Operator Display Parameters
See L<Fields Common to All Record Types> for more on the record name (NAME) and
description (DESC) fields.
See L<Fields Common to All Record Types|dbCommonRecord/Operator Display
Parameters> for more on the record name (NAME) and description (DESC) fields.
=fields NAME, DESC
=head3 Alarm Parameters
The state record has the alarm parameters common to all record types.
L<Alarm Fields> lists other fields related to a alarms that are common to all
record types.
L<Alarm Fields|dbCommonRecord/Alarm Fields> lists the fields related to
alarms that are common to all record types.
=head3 Run-time Parameters

30
modules/database/src/std/rec/stringinRecord.dbd.pod
View File

@@ -54,8 +54,8 @@ The record-specific fields are described below, grouped by functionality.
=head3 Scan Parameters
The string input record has the standard fields for specifying under what
circumstances it will be processed. These fields are listed in L<Scan Fields>.
In addition, L<Scanning Specification> explains how these fields are used.
circumstances it will be processed.
These fields are listed in L<Scan Fields|dbCommonRecord/Scan Fields>.
=head3 Input Specification
@@ -67,8 +67,6 @@ 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 L<Address Specification> for information on specifying links.
=fields VAL, INP, DTYP
=cut
@@ -109,16 +107,17 @@ APST is used for archiver monitors and MPST is for all other type of monitors.
=head3 Operator Display Parameters
See L<Fields Common to All Record Types> for more on the record name (NAME) and
description (DESC) fields.
See L<Fields Common to All Record Types|dbCommonRecord/Operator Display
Parameters> for more on the record name (NAME) and description (DESC) fields.
=fields NAME, DESC
=head3 Alarm Parameters
The string input record has the alarm parameters common to all record types.
L<Alarm Fields> lists other fields related to a alarms that are common to all
record types.
L<Alarm Fields|dbCommonRecord/Alarm Fields> lists the fields related to
alarms that are common to all record types.
=head3 Run-time Parameters
@@ -345,9 +344,13 @@ This routine must provide a new input value. It returns the following values:
=over
=item * 0: Success. A new ASCII string is stored into VAL.
=item *
=item * Other: Error.
0: Success. A new ASCII string is stored into VAL.
=item *
Other: Error.
=back
@@ -355,9 +358,10 @@ This routine must provide a new input value. It returns the following values:
The C<<< Soft Channel >>> module reads a value directly into VAL.
Device support for DTYP C<getenv> is provided for retrieving strings from environment variables.
C<INST_IO> addressing C!!@<environment variable> !!is used on the C<INP> link field to select the
desired environment variable.
Device support for DTYP C<getenv> is provided for retrieving strings from
environment variables.
C<INST_IO> addressing C<<< @<environment variable> >>> is used in the INP
link field to select the desired environment variable.
=cut

47
modules/database/src/std/rec/stringoutRecord.dbd.pod
View File

@@ -16,12 +16,11 @@ characters to other records or software variables.
=cut
include "menuIvoa.dbd"
menu(stringoutPOST) {
choice(stringoutPOST_OnChange,"On Change")
choice(stringoutPOST_Always,"Always")
}
recordtype(stringout) {
include "dbCommon.dbd"
%
@@ -55,10 +54,8 @@ The record-specific fields are described below, grouped by functionality.
=head3 Scan Parameters
The string output record has the standard fields for specifying under what
circumstances it will be processed. These fields are listed in
L<Scan Fields>.
In addition, L<Scanning Specification>
explains how these fields are used.
circumstances it will be processed.
These fields are listed in L<Scan Fields|dbCommonRecord/Scan Fields>.
=head3 Desired Output Parameters
@@ -72,13 +69,11 @@ 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. However, your string constant may be
interpreted as a CA link name, so if you want to initialize your string output
record, it's best to use the VAL field. Note that if DOL is a constant, OMSL
cannot be C<<< closed_loop. >>> See
L<Address Specification>
for information on specifying links.
DOL can also be a constant, in which case VAL will be initialized to the
constant value. However to be interpreted as a constant instead of a CA link
the constant can only be numeric, so string output records are best initialized
by dirctly setting the VAL field. Note that if DOL is a constant, OMSL
cannot be C<<< closed_loop >>>.
=fields VAL, DOL, OMSL
@@ -100,8 +95,7 @@ for information on specifying links.
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 L<Address
Specification> for information on specifying links.
link. If the OUT field is a constant, no output will be written.
In addition, the appropriate device support module must be entered into the DTYP
field.
@@ -150,8 +144,8 @@ 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 L<Fields Common to All Record Types>
for more on the record name (NAME) and description (DESC) fields.
See L<Fields Common to All Record Types|dbCommonRecord/Operator Display
Parameters> for more on the record name (NAME) and description (DESC) fields.
=fields NAME, DESC
@@ -235,18 +229,13 @@ 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:
=head4 Menu menuIvoa
=menu menuIvoa
When C<<< Set output to IVOV >>>, the value contained in the IVOV field is
written to the output link during an alarm condition. See
L<Invalid Alarm Output Action>
L<Invalid Output Action Fields|dbCommonOutput/Invalid Output Action Fields>
for more information on the IVOA and IVOV fields.
L<Alarm Fields>
lists other fields related to a alarms that are common to all record types.
L<Alarm Fields|dbCommonRecord/Alarm Fields> lists the fields related to
alarms that are common to all record types.
=fields IVOA, IVOV
@@ -291,7 +280,7 @@ If device support includes C<init_record()>, it is called.
long (*process)(struct dbCommon *precord)
See L<Record Processing>.
See L</Record Processing>.
=head3 Record Processing
@@ -315,8 +304,8 @@ If the return status of recGblGetLinkValue is zero then UDF is set to FALSE.
=item 3.
Check severity and write the new value. See
L<Simulation Mode>
and L<Invalid Alarm Output Action>
L<Simulation Mode> and
L<Invalid Output Action Fields|dbCommonOutput/Invalid Output Action Fields>
for details on how the simulation mode and the INVALID alarm conditions affect output.
=item 4.

19
modules/database/src/std/rec/subArrayRecord.dbd.pod
View File

@@ -36,17 +36,14 @@ The record-specific fields are described below, grouped by functionality.
=head3 Scan Parameters
The subArray record has the standard fields for specifying under what
circumstances the record will be processed. These fields are listed in
L<Scan Fields>.
In addition, L<Scanning Specification> explains how these fields are used.
circumstances the record will be processed.
These fields are listed in L<Scan Fields|dbCommonRecord/Scan Fields>.
=head3 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
L<Address Specification>
for information on specifying links.
be a channel access link, in addition to a database link.
In addition, the DTYP field must specify a device support module. Currently, the
only device support module is C<Soft Channel>.
@@ -94,16 +91,16 @@ The PREC field determines the floating point precision with which to display
VAL. It is used whenever the C<get_precision()> record support routine is
called.
See L<Fields Common to All Record Types>
for more on the record name (NAME) and description (DESC) fields.
See L<Fields Common to All Record Types|dbCommonRecord/Operator Display
Parameters> for more on the record name (NAME) and description (DESC) fields.
=fields EGU, HOPR, LOPR, PREC, NAME, DESC
=head3 Alarm Parameters
The subarray record has the alarm parameters common to all record types.
L<Alarm Fields> lists other fields related to a alarms that are common to all
record types.
L<Alarm Fields|dbCommonRecord/Alarm Fields> lists the fields related to
alarms that are common to all record types.
=head3 Run-time Parameters
@@ -144,7 +141,7 @@ C<init_record()>, it is called.
long (*process)(struct dbCommon *precord)
See L<Record Processing>.
See L</"Record Processing">.
=head4 cvt_dbaddr

30
modules/database/src/std/rec/subRecord.dbd.pod
View File

@@ -25,9 +25,8 @@ The record-specific fields are described below, grouped by functionality.
=head3 Scan Parameters
The subroutine record has the standard fields for specifying under what
circumstances it will be processed. These fields are listed in
L<Scan Fields>. In addition, L<Scanning Specification>
explains how these fields are used.
circumstances it will be processed.
These fields are described in L<Scan Fields|dbCommonRecord/Scan Fields>.
=head3 Read Parameters
@@ -39,7 +38,7 @@ 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 L<Address Specification> for information on specifying links.
is processed.
=fields INPA, INPB, INPC, INPD, INPE, INPF, INPG, INPH, INPI, INPJ, INPK, INPL, A, B, C, D, E, F, G, H, I, J, K, L
@@ -69,8 +68,8 @@ The PREC field determines the floating point precision with which to display
VAL. It is used whenever the C<<< get_precision >>> record support routine is
called.
See L<Fields Common to All Record Types>
for more on the record name (NAME) and description (DESC) fields.
See L<Fields Common to All Record Types|dbCommonRecord/Operator Display
Parameters> for more on the record name (NAME) and description (DESC) fields.
=fields EGU, HOPR, LOPR, PREC, NAME, DESC
@@ -85,9 +84,10 @@ 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 L<Alarm Specification>
for a complete explanation of alarms and these fields. L<Alarm Fields>
lists other fields related to a alarms that are common to all record types.
subroutine returns a negative value.
L<Alarm Fields|dbCommonRecord/Alarm Fields> lists the fields related to
alarms that are common to all record types.
=fields HIHI, HIGH, LOW, LOLO, HHSV, HSV, LSV, LLSV, BRSV, HYST
@@ -101,8 +101,7 @@ 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 L<Monitor Specification>
for a complete explanation of monitors and deadbands.
and the MDEL field for all other types of monitors.
=fields ADEL, MDEL
@@ -142,7 +141,7 @@ The processing subroutine is located and its address stored in SADR.
long (*process)(struct dbCommon *precord)
See L<Record Processing>.
See L</"Record Processing">.
=head4 get_units
@@ -218,7 +217,12 @@ If return value is 1, return
=item 3.
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 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.
=item 4.

51
modules/database/src/std/rec/waveformRecord.dbd.pod
View File

@@ -17,8 +17,6 @@ types.
=cut
include "menuFtype.dbd"
menu(waveformPOST) {
choice(waveformPOST_Always,"Always")
choice(waveformPOST_OnChange,"On Change")
@@ -33,10 +31,8 @@ The record-specific fields are described below, grouped by functionality.
=head3 Scan Parameters
The waveform record has the standard fields for specifying under what
circumstances the record will be processed. These fields are listed in L<Scan
Fields>. In addition, L<Scanning Specification> explains how these fields are
used. Note that I/O event scanning is only supported for those card types that
interrupt.
circumstances the record will be processed.
These fields are listed in L<Scan Fields|dbCommonRecord/Scan Fields>.
=head3 Read Parameters
@@ -45,9 +41,7 @@ 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 L<Address
Specification> for information on the format of hardware addresses and database
links.
Otherwise, the INP field must be a hardware address.
=head4 Fields related to waveform reading
@@ -57,12 +51,11 @@ The DTYP field must contain the name of the appropriate device support module.
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.
FTVL specifies the data type of the elements (follow the link in the table
above for a list of the available choices).
=head4 Possible data types for FTVL
=menu menuFtype
The RARM field used to cause some device types to re-arm when it was set to 1,
but we don't know of any such devices any more.
=head3 Operator Display Parameters
@@ -85,34 +78,36 @@ The PREC field determines the floating point precision with which to display the
array values. It is used whenever the C<<< get_precision >>> record support
routine is called.
See L<Fields Common to All Record Types> for more on the record name (NAME) and
description (DESC) fields.
See L<Fields Common to All Record Types|dbCommonRecord/Operator Display
Parameters> for more on the record name (NAME) and description (DESC) fields.
=head3 Alarm Parameters
The waveform record has the alarm parameters common to all record types. L<Alarm
Fields> lists other fields related to a alarms that are common to all record
types.
The waveform record has the alarm parameters common to all record types.
L<Alarm Fields|dbCommonRecord/Alarm Fields> lists the fields related to
alarms that are common to all record types.
=head3 Monitor Parameters
These parameters are used to determine when to send monitors placed on the VAL
field. The APST and MPST fields are a menu with choices "Always" and "On
Change". The default is "Always", thus monitors will normally be sent every time
the record processes. Selecting "On Change" causes a 32-bit hash of the VAL
field.
The APST and MPST fields are a menu with choices C<Always> and C<On Change>.
The default is C<Always>, thus monitors will normally be sent every time
the record processes.
Selecting C<On Change> causes a 32-bit hash of the VAL
field buffer to be calculated and compared with the previous hash value every
time the record processes; the monitor will only be sent if the hash is
different, indicating that the buffer has changed. Note that there is a small
chance that two different value buffers might result in the same hash value, so
for critical systems "Always" may be a better choice, even though it re-sends
for critical systems C<Always> may be a better choice, even though it re-sends
duplicate data.
=head4 Record fields related to I<Monitor Parameters>
=fields APST, MPST, HASH
=head4 Menu choices for C<APST> and C<MPST> fields
=head4 Menu waveformPOST
This menu defines the possible choices for C<APST> and C<MPST> fields:
=menu waveformPOST
@@ -179,7 +174,7 @@ If device support includes C<init_record()>, it is called.
static long process(waveformRecord *prec)
See L</"Record Processing"> section below.
See L</Record Processing> section below.
=head4 cvt_dbaddr
@@ -347,7 +342,7 @@ C<init_record()> routine.
long get_ioint_info(int cmd, 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
or deleted from an I/O event scan list. C<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.

10
src/tools/podToHtml.pl
View File

@@ -16,8 +16,7 @@ use warnings;
use FindBin qw($Bin);
use lib ("$Bin/../../lib/perl", $Bin);
use Getopt::Std;
$Getopt::Std::STANDARD_HELP_VERSION = 1;
use EPICS::Getopts;
use EPICS::PodHtml;
@@ -52,9 +51,10 @@ Help, display this document as text.
=item B<-s>
Indicates that the first component of the input file path is not part of the
Indicates that one leading component of the input file path is not part of the
final installation path, thus should be removed before calculating the relative
path to the style-sheet file.
path to the style-sheet file. This flag may be repeated as many times as needed
to remove multiple leading components from the path to the style sheet.
=item B<-o> file.html
@@ -87,7 +87,7 @@ if (!$opt_o) {
}
# Calculate path to style.css file
shift @inpath if $opt_s; # Remove leading ..
shift @inpath while $opt_s--; # Remove leading ..
my $root = '../' x scalar @inpath;
open my $out, '>', $opt_o or