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

Merge branch '7.0' into add-simm-to-ao-records

Browse Source
This commit is contained in:
Ralph Lange
2022-05-11 10:47:12 -07:00
committed by GitHub
parent 0bcffb56bb cbae8d37b3
commit 4fc549234c
337 changed files with 4510 additions and 4034 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
modules/database/src/std/dev/devBoSoft.c
View File

@@ -43,7 +43,7 @@ static long init_record(dbCommon *pcommon)
{
long status=0;
/* dont convert */
/* don't convert */
status=2;
return status;

1
modules/database/src/std/dev/devSiSoftCallback.c
View File

@@ -108,6 +108,7 @@ static long add_record(dbCommon *pcommon)
recGblRecordError(status, (void *)prec,
"devSiSoftCallback (add_record) linked record not found");
free(pdevPvt);
return status;
}

6
modules/database/src/std/filters/dbnd.c
View File

@@ -20,7 +20,7 @@
#include <chfPlugin.h>
#include <recGbl.h>
#include <epicsExit.h>
#include <db_field_log.h>
#include <dbAccess.h>
#include <epicsExport.h>
typedef struct myStruct {
@@ -81,8 +81,8 @@ static db_field_log* filter(void* pvt, dbChannel *chan, db_field_log *pfl) {
status = dbFastGetConvertRoutine[pfl->field_type][DBR_DOUBLE]
(localAddr.pfield, (void*) &val, &localAddr);
if (!status) {
send = 0;
recGblCheckDeadband(&my->last, val, my->hyst, &send, 1);
send = pfl->mask & ~(DBE_VALUE|DBE_LOG);
recGblCheckDeadband(&my->last, val, my->hyst, &send, pfl->mask & (DBE_VALUE|DBE_LOG));
if (send && my->mode == 1) {
my->hyst = val * my->cval/100.;
}

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

@@ -736,6 +736,10 @@ The choices can be found by following the link to the menuFtype definition.
These fields specify how many array elements the input value fields may hold.
Note that access to the C<NOT> field from C code must use the field name in
upper case, e.g. C<< prec->NOT >> since the lower-case C<not> is a reserved
word in C++ and cannot be used as an identifier.
=fields NOA, NOB, NOC, NOD, NOE, NOF, NOG, NOH, NOI, NOJ, NOK, NOL, NOM, NON, NOO, NOP, NOQ, NOR, NOS, NOT, NOU
=cut

4
modules/database/src/std/rec/aaoRecord.c
View File

@@ -162,7 +162,7 @@ static long process(struct dbCommon *pcommon)
prec->udf = FALSE;
/* Update the timestamp before writing output values so it
* will be uptodate if any downstream records fetch it via TSEL */
* will be up to date if any downstream records fetch it via TSEL */
recGblGetTimeStampSimm(prec, prec->simm, NULL);
}
@@ -357,7 +357,7 @@ static long writeValue(aaoRecord *prec)
case menuYesNoYES: {
recGblSetSevr(prec, SIMM_ALARM, prec->sims);
if (prec->pact || (prec->sdly < 0.)) {
/* Device suport is responsible for buffer
/* Device support is responsible for buffer
which might be write-only so we may not be
allowed to call dbPutLink on it.
Maybe also device support has an advanced

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

@@ -32,9 +32,10 @@ The record-specific fields are described below, grouped by functionality.
=head3 Scan Parameters
The array analog output 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. I/O event scanning is only available when supported by device support.
circumstances the record will be processed.
These fields are described in L<Scan Fields|dbCommonRecord/Scan Fields>.
=fields SCAN, PHAS, EVNT, PRIO, PINI
=head3 Write Parameters
@@ -43,8 +44,9 @@ writes its data. The OUT field determines where the array analog output writes i
output. 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 OUT field be a
channel access link, a database link, or a constant. Otherwise, the OUT 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. See L<Address
Specification|https://docs.epics-controls.org/en/latest/guides/EPICS_Process_Database_Concepts.html#address-specification>
for information on the format of hardware addresses and database links.
=head4 Fields related to array writing

2
modules/database/src/std/rec/aiRecord.c
View File

@@ -43,7 +43,7 @@
#undef GEN_SIZE_OFFSET
#include "epicsExport.h"
/* Hysterisis for alarm filtering: 1-1/e */
/* Hysteresis for alarm filtering: 1-1/e */
#define THRESHOLD 0.6321
/* Create RSET - Record Support Entry Table*/

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

@@ -45,8 +45,9 @@ 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.
See L<Address
Specification|https://docs.epics-controls.org/en/latest/guides/EPICS_Process_Database_Concepts.html#address-specification>
for a description of the various hardware address formats supported.
=head3 Units Conversion
@@ -157,6 +158,10 @@ They do not affect the functioning of the record at all.
=over
=item *
NAME is the record's name, and can be useful when the PV name that a client
knows is an alias for the record.
=item *
DESC is a string that is usually used to briefly describe the record.
@@ -175,7 +180,10 @@ DOUBLE fields.
=back
=fields DESC, EGU, HOPR, LOPR, PREC
See L<Fields Common to All Record Types|dbCommonRecord/Operator Display
Parameters> for more about the record name (NAME) and description (DESC) fields.
=fields NAME, DESC, EGU, HOPR, LOPR, PREC
=head3 Alarm Limits
@@ -198,6 +206,11 @@ positive number of seconds will delay the record going into or out of a minor
alarm severity or from minor to major severity until the input signal has been
in the alarm range for that number of seconds.
See L<Alarm Specification|https://docs.epics-controls.org/en/latest/guides/EPICS_Process_Database_Concepts.html#alarm-specification>
for a complete explanation of record alarms and of the standard 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, AFTC, LALM
=head3 Monitor Parameters

2
modules/database/src/std/rec/aoRecord.c
View File

@@ -188,7 +188,7 @@ static long process(struct dbCommon *pcommon)
if(!status) convert(prec, value);
prec->udf = isnan(prec->val);
/* Update the timestamp before writing output values so it
* will be uptodate if any downstream records fetch it via TSEL */
* will be up to date if any downstream records fetch it via TSEL */
recGblGetTimeStampSimm(prec, prec->simm, NULL);
}

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

@@ -161,9 +161,9 @@ The analog output record sends its desired output to the address in the
OUT field. For analog outputs that write their values to devices, the
OUT field must specify the address of the I/O card. In addition, the
DTYP field must contain the name of the device support module. Be aware
that the address format differs according to the I/O bus used. See
Address Specification for information on the format of hardware
addresses.
that the address format differs according to the I/O bus used. See L<Address
Specification|https://docs.epics-controls.org/en/latest/guides/EPICS_Process_Database_Concepts.html#address-specification>
for information on the format of hardware addresses.
For soft records the output link can be a database link, a channel
access link, or a constant value. If the link is a constant, no output
@@ -308,7 +308,7 @@ for more information on simulation mode and its fields.
interest(1)
}
field(DOL,DBF_INLINK) {
prompt("Desired Output Loc")
prompt("Desired Output Link")
promptgroup("40 - Input")
interest(1)
}

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

@@ -37,6 +37,8 @@ The binary input record has the standard fields for specifying under what
circumstances the record will be processed.
These fields are described in L<Scan Fields|dbCommonRecord/Scan Fields>.
=fields SCAN, PHAS, EVNT, PRIO, PINI
=head3 Read and Convert Parameters
The read and convert fields determine where the binary input gets its
@@ -44,14 +46,15 @@ input from and how to convert the raw signal to engineering units. The INP
field contains the address from where device support retrieves the value.
If the binary input record gets its value from hardware, the address of the
card must be entered in the INP field, and the name of the device support
module must be entered in the DTYP field. See L<Address Specification> for
information on the format of the hardware address. Be aware that the format
differs between types of cards.
module must be entered in the DTYP field. See L<Address
Specification|https://docs.epics-controls.org/en/latest/guides/EPICS_Process_Database_Concepts.html#address-specification>
for information on the format of the hardware address.
For records that specify C<Soft Channel> or C<Raw Soft Channel> device
support routines, the INP field can be a channel or a database link, or a
constant. If a constant, VAL can be changed directly by dbPuts. See
L<Address Specification> for information on the format of database and
constant. If a constant, VAL can be changed directly by dbPuts. See L<Address
Specification|https://docs.epics-controls.org/en/latest/guides/EPICS_Process_Database_Concepts.html#address-specification>
for information on the format of database and
channel access addresses. Also, see L<Device Support for Soft Records> in
this chapter for information on soft device support.
@@ -102,9 +105,10 @@ C<MAJOR>. The ZSV field holds the severity for the zero state; OSV, for
the one state. COSV causes an alarm whenever the state changes between
0 and 1 and the severity is configured as MINOR or MAJOR.
See L<Alarm Specification> for a complete explanation of the discrete alarm
states. L<Alarm Fields|dbCommonRecord/Alarm Fields> lists other fields related to alarms that are
common to all record types.
See L<Alarm Specification|https://docs.epics-controls.org/en/latest/guides/EPICS_Process_Database_Concepts.html#alarm-specification>
for a complete explanation of record alarms and of the standard fields.
L<Alarm Fields|dbCommonRecord/Alarm Fields> lists other fields related
to alarms that are common to all record types.
=fields ZSV, OSV, COSV

2
modules/database/src/std/rec/boRecord.c
View File

@@ -211,7 +211,7 @@ static long process(struct dbCommon *pcommon)
} else prec->rval = (epicsUInt32)prec->val;
/* Update the timestamp before writing output values so it
* will be uptodate if any downstream records fetch it via TSEL */
* will be up to date if any downstream records fetch it via TSEL */
recGblGetTimeStampSimm(prec, prec->simm, NULL);
}

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

@@ -15,29 +15,6 @@ values into other records via database or channel access links. This record
can implement both latched and momentary binary outputs depending on how
the HIGH field is configured.
=head2 Parameter Fields
The binary output's fields fall into the following categories:
=over 1
=item *
scan parameters
=item *
convert and write parameters
=item *
operator display parameters
=item *
alarm parameters
=item *
run-time parameters
=back
=recordtype bo
=cut
@@ -47,13 +24,10 @@ recordtype(bo) {
=head3 Scan Parameters
The binary output record has the standard fields for specifying under what
circumstances the record will be processed. The fields are listed in
circumstances the record will be processed.
These fields are described in L<Scan Fields|dbCommonRecord/Scan Fields>.
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.
=fields SCAN
=fields SCAN, PHAS, EVNT, PRIO, PINI
=head3 Desired Output Parameters
@@ -65,14 +39,14 @@ output mode select (OMSL) field, which can have two possible values:
C<losed_loop> or C<supervisory>. If C<supervisory> is specified, the value
in the VAL field can be set externally via dbPuts at run-time. If
C<closed_loop> is specified, the VAL field's value is obtained from the
address specified in the desired output location (DOL) field which can be a
address specified in the Desired Output Link (DOL) field which can be a
database link or a channel access link, but not a constant. To achieve
continuous control, a database link to a control algorithm record should be
entered in the DOL field.
L<Address Specification> presents more information on database addresses
and links. L<Scanning Specification> explaines the effect of database
linkage on scanning.
See L<Address
Specification|https://docs.epics-controls.org/en/latest/guides/EPICS_Process_Database_Concepts.html#address-specification>
for information on hardware addresses and links.
=fields DOL, OMSL
@@ -130,15 +104,17 @@ The OUT field specifies where the binary output record writes its output.
It must specify the address of an I/O card if the record sends its output
to hardware, and the DTYP field must contain 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.
I/O bus used. See L<Address
Specification|https://docs.epics-controls.org/en/latest/guides/EPICS_Process_Database_Concepts.html#address-specification>
for information on the format of hardware addresses.
Otherwise, if the record is configured to use the soft device support
modules, then it can be either a database link, a channel access link, or a
constant. Be aware that nothing will be written when OUT is a constant. See
L<Address Specification> for information on the format of the database and
channel access addresses. Also, see L<Device Support For Soft Records> in
this chapter for more on output to other records.
Otherwise, if the record is configured to use the soft device support modules,
then it can be either a database link, a channel access link, or a constant. Be
aware that nothing will be written when OUT is a constant. See L<Address
Specification|https://docs.epics-controls.org/en/latest/guides/EPICS_Process_Database_Concepts.html#address-specification>
for information on the format of the database and channel access addresses.
Also, see L<Device Support For Soft Records> in this chapter for more on output
to other records.
=head3 Operator Display Parameters
@@ -243,7 +219,7 @@ for more information on simulation mode and its fields.
menu(menuOmsl)
}
field(DOL,DBF_INLINK) {
prompt("Desired Output Loc")
prompt("Desired Output Link")
promptgroup("40 - Input")
interest(1)
}

2
modules/database/src/std/rec/calcRecord.c
View File

@@ -37,7 +37,7 @@
#undef GEN_SIZE_OFFSET
#include "epicsExport.h"
/* Hysterisis for alarm filtering: 1-1/e */
/* Hysteresis for alarm filtering: 1-1/e */
#define THRESHOLD 0.6321
/* Create RSET - Record Support Entry Table */

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

@@ -28,8 +28,9 @@ recordtype(calc) {
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|dbCommonRecord/Scan Fields>.
These fields are described in L<Scan Fields|dbCommonRecord/Scan Fields>.
=fields SCAN, PHAS, EVNT, PRIO, PINI
=head3 Read Parameters
@@ -40,8 +41,9 @@ channel access link. If they are constants, they will be initialized with
the value they are configured with and can be changed via C<dbPuts>. They
cannot be hardware addresses.
See L<Address Specification> for information on how to specify database
links.
See L<Address
Specification|https://docs.epics-controls.org/en/latest/guides/EPICS_Process_Database_Concepts.html#address-specification>
for information on how to specify database links.
=fields INPA, INPB, INPC, INPD, INPE, INPF, INPG, INPH, INPI, INPJ, INPK, INPL
@@ -453,9 +455,12 @@ The following alarm parameters which are configured by the user, define the
limit alarms for the VAL field and the severity corresponding to those
conditions.
The HYST field defines an alarm deadband for each limit. See L<Alarm Specification>
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.
The HYST field defines an alarm deadband for each limit.
See L<Alarm Specification|https://docs.epics-controls.org/en/latest/guides/EPICS_Process_Database_Concepts.html#alarm-specification>
for a complete explanation of record alarms and of the standard 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

2
modules/database/src/std/rec/calcoutRecord.c
View File

@@ -245,7 +245,7 @@ static long process(struct dbCommon *pcommon)
if ( !pact ) {
/* Update the timestamp before writing output values so it
* will be uptodate if any downstream records fetch it via TSEL */
* will be up to date if any downstream records fetch it via TSEL */
recGblGetTimeStamp(prec);
}
/* check for output link execution */

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

@@ -535,13 +535,13 @@ the user and which describes the values being operated upon. The string is
retrieved whenever the routine C<get_units()> is called. The EGU string is
solely for an operator's sake and does not have to be used.
The HOPR and LOPR fields on;y refer to the limits if the VAL, HIHI, HIGH,
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.
=head4 Menu calcoutINAV
The INAV-INLV fields indicate the status of the link to the PVs specified
in the INPA-INPL fields, respectfully. These field can have four possible
in the INPA-INPL fields respectively. These fields can have four possible
values:
=menu calcoutINAV
@@ -568,7 +568,7 @@ The OUTV field indicates the status of the OUT link. If has the same
possible values as the INAV-INLV fields.
The CLCV and OLCV fields indicate the validity of the expression in the
CALC and OCAL fields respectfully. If the expression in invalid, the field
CALC and OCAL fields respectively. If the expression in invalid, the field
is set to one.
The DLYA field is set to one during the delay specified in ODLY.
@@ -590,10 +590,12 @@ The following alarm parameters, which are configured by the user, define the
limit alarms for the VAL field and the severity corresponding to those
conditions.
The HYST field defines an alarm deadband for each limit. See
L<Alarm Specification> for a complete explanation of alarms and these
fields. C<Alarm Fields> lists other fields related to alarms that are
common to all record types.
The HYST field defines an alarm deadband for each limit.
See L<Alarm Specification|https://docs.epics-controls.org/en/latest/guides/EPICS_Process_Database_Concepts.html#alarm-specification>
for a complete explanation of record alarms and of the standard 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
@@ -1218,7 +1220,7 @@ honors the alarm hysteresis factor (HYST). Thus the value must change by at
least HYST before the alarm status and severity changes.
=item 4.
Determine if the Output Execution Option (OOPT) is met. If it met, either
Determine if the Output Execution Option (OOPT) is met. If met, either
execute the output link (and output event) immediately (if ODLY = 0), or
schedule a callback after the specified interval. See the explanation for
the C<execOutput()> routine below.

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

@@ -67,11 +67,12 @@ The record-specific fields are described below, grouped by functionality.
=head3 Scanning Parameters
The compression record has the standard fields for specifying under what
circumstances the record will be processed. These fields are listed in
circumstances the record will be processed. Since the compression record
supports no direct interfaces to hardware, its SCAN field cannot be set to C<<<
I/O Intr >>>.
These fields are described in L<Scan Fields|dbCommonRecord/Scan Fields>.
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 >>>.
=fields SCAN, PHAS, EVNT, PRIO, PINI
=head3 Algorithms and Related Parameters
@@ -88,9 +89,11 @@ The following fields determine what channel to read and how to compress the data
As stated above, the ALG field specifies which algorithm to be performed on the data.
The INP should be a database or channel access link. Though INP can be a constant,
the data compression algorithms are supported only when INP is a database link. See
L<Address Specification> for information on specifying links.
The INP should be a database or channel access link. Though INP can be a
constant, the data compression algorithms are supported only when INP is a
database link. See L<Address
Specification|https://docs.epics-controls.org/en/latest/guides/EPICS_Process_Database_Concepts.html#address-specification>
for information on specifying links.
IHIL and ILIL can be set to provide an initial value filter on the input array.

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

@@ -43,7 +43,7 @@ originates, i.e., the data which is to be fowarded to the records in its
output links. The output mode select (OMSL) field determines whether the
output originates from another record or from run-time database access.
When set to C<closed_loop>, the desired output is retrieved from the link
specified in the desired output (DOL) field, which can specify either a
specified in the Desired Output Link (DOL) field, which can specify either a
database or a channel access link, and placed into the VAL field. When set
to C<supervisory>, the desired output can be written to the VAL field via
dbPuts at run-time.
@@ -59,8 +59,9 @@ undergoes no conversions before it is sent out to the output links.
=head3 Write Parameters
The OUTA-OUTH fields specify where VAL is to be sent. Each field that is to
forward data must specify an address to another record. See
L<Address Specification> for information on specifying links.
forward data must specify an address to another record. See L<Address
Specification|https://docs.epics-controls.org/en/latest/guides/EPICS_Process_Database_Concepts.html#address-specification>
for information on specifying links.
The SELL, SELM, and SELN fields specify which output links are to be
used.
@@ -71,42 +72,57 @@ SELM is a menu, with three choices:
=menu dfanoutSELM
If SELM=="All", then all output links are used, and the values of
If SELM is C<All>, then all output links are used, and the values of
SELL and SELN are ignored.
If SELM=="Specified", then the value of SELN is used to specify a single
If SELM is C<Specified>, then the value of SELN is used to specify a single
link which will be used. If SELN==0, then no link will be used; if SELN==1,
then OUTA will be used, and so on.
SELN can either have its value set directly, or have its values retrieved
from another EPICS PV. If SELL is a valid PV link, then SELN will be set to
the values of the linked PV.
SELN can either have its value set directly, or have it retrieved from
another EPICS PV. If SELL is a valid PV link, then SELN will be read from
the linked PV.
If SELM=="Mask", then SELN will be treated as a bit mask. If bit one of
SELN is set, then OUTA will be used, if bit two is set, OUTB will be used.
Thus if SELN==5, OUTC and OUTA will be used.
If SELM is C<Mask>, then SELN will be treated as a bit mask. If bit zero
(the LSB) of SELN is set, then OUTA will be written to; if bit one is set,
OUTB will be written to, and so on. Thus when SELN==5, both OUTC and OUTA
will be written to.
=fields OUTA, OUTB, OUTC, OUTD, OUTE, OUTF, OUTG, OUTH
=fields SELL, SELM, SELN, OUTA, OUTB, OUTC, OUTD, OUTE, OUTF, OUTG, OUTH
=head3 Operator Display Parameters
These parameters are used to present meaningful data to the operator. They
display the value and other parameters of the data fanout record either
textually or graphically.
These parameters are used to present meaningful data to the operator.
They do not affect the functioning of the record at all.
The EGU field can contain a string of up to 16 characters describing the
value on the VAL field.
=over
The HOPR and LOPR fields determine the upper and lower display limits for
graphic displays and the upper and lower control limits for control
displays. They apply to the VAL, HIHI, HIGH, LOW, and LOLO fields. The
record support routines C<get_graphic_double()> and C<get_control_double()>
retrieve HOPR and LOPR.
=item *
NAME is the record's name, and can be useful when the PV name that a client
knows is an alias for the record.
=item *
DESC is a string that is usually used to briefly describe the record.
=item *
EGU is a string of up to 16 characters naming the engineering units that the VAL
field represents.
=item *
The HOPR and LOPR fields set the upper and lower display limits for the VAL,
HIHI, HIGH, LOW, and LOLO fields.
=item *
The PREC field determines the floating point precision (i.e. the number of
digits to show after the decimal point) with which to display VAL and the other
DOUBLE fields.
=back
See L<Fields Common to All Record Types|dbCommonRecord/Operator Display
Parameters> for more on the record name (NAME) and description (DESC) fields.
Parameters> for more about the record name (NAME) and description (DESC) fields.
=fields EGU, HOPR, LOPR, NAME, DESC
=fields NAME, DESC, EGU, HOPR, LOPR, PREC
=head3 Alarm Parameters
@@ -119,9 +135,10 @@ in the corresponding field (HHSV, LLSV, HSV, LSV) and can be either
NO_ALARM, MINOR, or MAJOR. In the hysteresis field (HYST) can be entered a
number which serves as the deadband on the limit alarms.
See L<Alarm Specification> for a complete explanation of alarms and these
fields. L<Alarm Fields|dbCommonRecord/Alarm Fields> lists other fields related to alarms that are
common to all record types.
See L<Alarm Specification|https://docs.epics-controls.org/en/latest/guides/EPICS_Process_Database_Concepts.html#alarm-specification>
for a complete explanation of record alarms and of the standard 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
@@ -211,7 +228,7 @@ hysteresis factors for monitor callbacks.
interest(1)
}
field(DOL,DBF_INLINK) {
prompt("Desired Output Loc")
prompt("Desired Output Link")
promptgroup("40 - Input")
interest(1)
}

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

@@ -37,10 +37,10 @@ recordtype(event) {
=head3 Scan Parameters
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|dbCommonRecord/Scan Fields>.
it will be processed.
These fields are described in L<Scan Fields|dbCommonRecord/Scan Fields>.
=fields SCAN, PHAS, EVNT, PRIO, PINI
=head3 Event Number Parameters
@@ -73,8 +73,9 @@ The device support routines use the address in this record to obtain input. For
records that provide an interrupt handler, the INP field should specify the
address of the I/O card, and the DTYP field should specify a valid device
support module. Be aware that the address format differs according to the card
type used. See L<Address Specification> for information on the format of
hardware addresses and specifying links.
type used. See L<Address
Specification|https://docs.epics-controls.org/en/latest/guides/EPICS_Process_Database_Concepts.html#address-specification>
for information on the format of hardware addresses and specifying links.
For soft records, the INP field can be a constant, a database link, or a channel
access link. For soft records, the DTYP field should specify C<Soft Channel>.

2
modules/database/src/std/rec/histogramRecord.c
View File

@@ -160,7 +160,7 @@ static long init_record(struct dbCommon *pcommon, int pass)
prec->bptr = calloc(prec->nelm, sizeof(epicsUInt32));
}
/* calulate width of array element */
/* calculate width of array element */
prec->wdth = (prec->ulim - prec->llim) / prec->nelm;
return 0;
}

10
modules/database/src/std/rec/int64inRecord.c
View File

@@ -40,7 +40,7 @@
#undef GEN_SIZE_OFFSET
#include "epicsExport.h"
/* Hysterisis for alarm filtering: 1-1/e */
/* Hysteresis for alarm filtering: 1-1/e */
#define THRESHOLD 0.6321
/* Create RSET - Record Support Entry Table*/
#define report NULL
@@ -359,16 +359,16 @@ static void checkAlarms(int64inRecord *prec, epicsTimeStamp *timeLast)
}
/* DELTA calculates the absolute difference between its arguments
* expressed as an unsigned 32-bit integer */
* expressed as an unsigned 64-bit integer */
#define DELTA(last, val) \
((epicsUInt32) ((last) > (val) ? (last) - (val) : (val) - (last)))
((epicsUInt64) ((last) > (val) ? (last) - (val) : (val) - (last)))
static void monitor(int64inRecord *prec)
{
unsigned short monitor_mask = recGblResetAlarms(prec);
if (prec->mdel < 0 ||
DELTA(prec->mlst, prec->val) > (epicsUInt32) prec->mdel) {
DELTA(prec->mlst, prec->val) > (epicsUInt64) prec->mdel) {
/* post events for value change */
monitor_mask |= DBE_VALUE;
/* update last value monitored */
@@ -376,7 +376,7 @@ static void monitor(int64inRecord *prec)
}
if (prec->adel < 0 ||
DELTA(prec->alst, prec->val) > (epicsUInt32) prec->adel) {
DELTA(prec->alst, prec->val) > (epicsUInt64) prec->adel) {
/* post events for archive value change */
monitor_mask |= DBE_LOG;
/* update last archive value monitored */

2
modules/database/src/std/rec/int64outRecord.c
View File

@@ -146,7 +146,7 @@ static long process(dbCommon *pcommon)
if (!status) convert(prec,value);
/* Update the timestamp before writing output values so it
* will be uptodate if any downstream records fetch it via TSEL */
* will be up to date if any downstream records fetch it via TSEL */
recGblGetTimeStampSimm(prec, prec->simm, NULL);
}

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

@@ -154,7 +154,7 @@ monitoring deadband functionality.
interest(1)
}
field(DOL,DBF_INLINK) {
prompt("Desired Output Loc")
prompt("Desired Output Link")
promptgroup("40 - Input")
interest(1)
}

2
modules/database/src/std/rec/longinRecord.c
View File

@@ -41,7 +41,7 @@
#undef GEN_SIZE_OFFSET
#include "epicsExport.h"
/* Hysterisis for alarm filtering: 1-1/e */
/* Hysteresis for alarm filtering: 1-1/e */
#define THRESHOLD 0.6321
/* Create RSET - Record Support Entry Table*/
#define report NULL

2
modules/database/src/std/rec/longoutRecord.c
View File

@@ -148,7 +148,7 @@ static long process(struct dbCommon *pcommon)
if (!status) convert(prec,value);
/* Update the timestamp before writing output values so it
* will be uptodate if any downstream records fetch it via TSEL */
* will be up to date if any downstream records fetch it via TSEL */
recGblGetTimeStampSimm(prec, prec->simm, NULL);
}

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

@@ -38,10 +38,10 @@ The record must specify where the desired output originates, i.e., the 32 bit
integer value it is to write. The output mode select (OMSL) field determines
whether the output originates from another record or from database access. When
set to C<<< closed_loop >>>, the desired output is retrieved from the link
specified in the desired output (DOL) field (which can specify either a database
or channel access link) and placed into the VAL field. When set to C<<<
supervisory >>>, the desired output can be written into the VAL field via dpPuts
at run-time.
specified in the Desired Output Link (DOL) field (which can specify either a
database or channel access link) and placed into the VAL field. When set to
C<<< supervisory >>>, the desired output can be written into the VAL field via
dpPuts at run-time.
A third type of value for the DOL field is a constant in which case, when the
record is initialized, the VAL field will be initialized with this constant
@@ -68,8 +68,9 @@ For soft records, the OUT output link can be a constant, a database link, or a
channel access link. If the link is a constant, the result is no output. The
DTYP field must then specify the C<<< Soft Channel >>> device support routine.
See L<Address Specification> for information on the format of hardware addresses
and database links.
See L<Address
Specification|https://docs.epics-controls.org/en/latest/guides/EPICS_Process_Database_Concepts.html#address-specification>
for information on the format of hardware addresses and database links.
=fields OUT, DTYP
@@ -97,7 +98,7 @@ and database links.
interest(1)
}
field(DOL,DBF_INLINK) {
prompt("Desired Output Loc")
prompt("Desired Output Link")
promptgroup("40 - Input")
interest(1)
}
@@ -172,13 +173,17 @@ record's output. The IVOA field specifies the action to take in this case.
The limit alarms are configured by the user in the HIHI, LOLO, HIGH, and LOW
fields using floating-point values. For each of these fields, there is a
corresponding severity field which can be either NO_ALARM, MINOR, or MAJOR. The
HYST field contains the alarm deadband around each limit alarm.
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. For an explanation of the IVOA and IVOV fields, see L<Output
Records>. L<Alarm Fields|dbCommonRecord/Alarm Fields> lists the fields related to
alarms that are common to all record types.
The HYST field sets an alarm deadband around each limit alarm.
For an explanation of the IVOA and IVOV fields, see
L<Invalid Output Action Fields|dbCommonOutput/Invalid Output Action Fields>.
See L<Alarm Specification|https://docs.epics-controls.org/en/latest/guides/EPICS_Process_Database_Concepts.html#alarm-specification>
for a complete explanation of record alarms and of the standard 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, IVOA, IVOV

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

@@ -31,21 +31,21 @@ These fields are listed in L<Scan Fields|dbCommonRecord/Scan Fields>.
The long string output record must specify from where it gets its desired output
string. The first field that determines where the desired output originates is
the output mode select (OMSL) field, which can have two possible value:
C<closed_loop> or C<supervisory>. If C<supervisory> is specified, DOL is
ignored, the current value of VAL is written, and VAL can be changed externally
via dbPuts at run-time. If C<closed_loop> is specified, the VAL field's value is
obtained from the address specified in the desired output location field (DOL)
which can be either a database link or a channel access link.
the output mode select (OMSL) field, which can have two possible values:
C<closed_loop> or C<supervisory>. If C<closed_loop> is specified, the VAL
field's value is fetched from the address specified in the Desired Output Link
field (DOL) which can be either a database link or a channel access link. If
C<supervisory> is specified, DOL is ignored, the current value of VAL is
written, and VAL can be changed externally via dbPuts at run-time.
The maximum number of characters in VAL is given by SIZV, and cannot be larger
than 65535.
DOL can also be a constant in addition to a link, in which case VAL is
initialized to the constant value. Your string constant, however, may be
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>.
DOL can also be a constant instead of a link, in which case VAL is initialized
to the constant value. Most simple string constants are likely to be interpreted
as a CA link name though. To initialize a string output record it is simplest
to set the VAL field directly; alternatively use a JSON constant link type in
the DOL field.
=fields VAL, SIZV, DOL, OMSL

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

@@ -14,7 +14,8 @@ an array of 32 unsigned characters, each representing a bit of the word.
These fields (B0-B9, BA-BF, B10-B19, B1A-B1F) are set to 1 if the corresponding
bit is set, and 0 if not.
This record's operation is similar to that of the multi-bit binary input record,
This record's operation is similar to that of the
L<multi-bit binary input record|mbbiRecord>,
and it has many fields in common with it. This record also has two available
soft device support modules: C<Soft Channel> and C<Raw Soft Channel>.

4
modules/database/src/std/rec/mbbiRecord.c
View File

@@ -40,7 +40,7 @@
#undef GEN_SIZE_OFFSET
#include "epicsExport.h"
/* Hysterisis for alarm filtering: 1-1/e */
/* Hysteresis for alarm filtering: 1-1/e */
#define THRESHOLD 0.6321
/* Create RSET - Record Support Entry Table*/
@@ -177,7 +177,7 @@ static long process(struct dbCommon *pcommon)
if (prec->sdef) {
pstate_values = &(prec->zrvl);
prec->val = 65535; /* Initalize to unknown state*/
prec->val = 65535; /* Initialize to unknown state*/
for (i = 0; i < 16; i++) {
if (*pstate_values == rval) {
prec->val = i;

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

@@ -413,9 +413,12 @@ The change of state severity (COSV) field triggers an alarm when any change of
state occurs, if set to MAJOR or MINOR.
The other fields, when set to MAJOR or MINOR, trigger an alarm when VAL equals
the corresponding state. See the See L<Alarm Specification> for a complete
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.
the corresponding state.
See L<Alarm Specification|https://docs.epics-controls.org/en/latest/guides/EPICS_Process_Database_Concepts.html#alarm-specification>
for a complete explanation of record alarms and of the standard fields.
L<Alarm Fields|dbCommonRecord/Alarm Fields> lists other fields related
to 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

133
modules/database/src/std/rec/mbboDirectRecord.c
View File

@@ -88,6 +88,14 @@ static long writeValue(mbboDirectRecord *);
#define NUM_BITS 32
static
void bitsFromVAL(mbboDirectRecord *prec)
{
unsigned i;
for(i=0; i<NUM_BITS; i++)
(&prec->b0)[i] = !!(prec->val&(1u<<i));
}
static long init_record(struct dbCommon *pcommon, int pass)
{
struct mbboDirectRecord *prec = (struct mbboDirectRecord *)pcommon;
@@ -131,16 +139,21 @@ static long init_record(struct dbCommon *pcommon, int pass)
status = 0;
}
if (!prec->udf &&
prec->omsl == menuOmslsupervisory) {
/* Set initial B0 - B1F from VAL */
epicsUInt32 val = prec->val;
if (!prec->udf)
bitsFromVAL(prec);
else {
/* Did user set any of the B0-B1F fields? */
epicsUInt8 *pBn = &prec->b0;
epicsUInt32 val = 0, bit = 1;
int i;
for (i = 0; i < NUM_BITS; i++) {
*pBn++ = !! (val & 1);
val >>= 1;
for (i = 0; i < NUM_BITS; i++, bit <<= 1)
if (*pBn++)
val |= bit;
if (val) { /* Yes! */
prec->val = val;
prec->udf = FALSE;
}
}
@@ -174,29 +187,18 @@ static long process(struct dbCommon *pcommon)
}
prec->val = val;
}
else if (prec->omsl == menuOmslsupervisory) {
epicsUInt8 *pBn = &prec->b0;
epicsUInt32 val = 0;
epicsUInt32 bit = 1;
int i;
/* Construct VAL from B0 - B1F */
for (i = 0; i < NUM_BITS; i++, bit <<= 1)
if (*pBn++)
val |= bit;
prec->val = val;
}
else if (prec->udf) {
recGblSetSevr(prec, UDF_ALARM, prec->udfs);
recGblSetSevrMsg(prec, UDF_ALARM, prec->udfs, "UDFS");
goto CONTINUE;
}
prec->udf = FALSE;
bitsFromVAL(prec);
/* Convert VAL to RVAL */
convert(prec);
/* Update the timestamp before writing output values so it
* will be uptodate if any downstream records fetch it via TSEL */
* will be up to date if any downstream records fetch it via TSEL */
recGblGetTimeStampSimm(prec, prec->simm, NULL);
}
@@ -234,6 +236,9 @@ CONTINUE:
recGblGetTimeStampSimm(prec, prec->simm, NULL);
}
/* update bits to reflect any change made by dset */
bitsFromVAL(prec);
monitor(prec);
/* Wrap up */
@@ -255,60 +260,37 @@ static long special(DBADDR *paddr, int after)
return 0;
}
if (!after)
return 0;
switch (paddr->special) {
case SPC_MOD: /* Bn field modified */
if (prec->omsl == menuOmslsupervisory) {
/* Adjust VAL corresponding to the bit changed */
epicsUInt8 *pBn = (epicsUInt8 *) paddr->pfield;
epicsUInt32 bit = 1 << (pBn - &prec->b0);
if (*pBn)
prec->val |= bit;
else
prec->val &= ~bit;
prec->udf = FALSE;
convert(prec);
if(after==0 && fieldIndex >= mbboDirectRecordB0 && fieldIndex <= mbboDirectRecordB1F) {
if(prec->omsl == menuOmslclosed_loop) {
/* To avoid confusion, reject changes to bit fields while in closed loop.
* Not a 100% solution as confusion can still arise if dset overwrites VAL.
*/
return S_db_noMod;
}
break;
case SPC_RESET: /* OMSL field modified */
if (prec->omsl == menuOmslclosed_loop) {
/* Construct VAL from B0 - B1F */
epicsUInt8 *pBn = &prec->b0;
epicsUInt32 val = 0, bit = 1;
int i;
} else if(after==1 && fieldIndex >= mbboDirectRecordB0 && fieldIndex <= mbboDirectRecordB1F) {
/* Adjust VAL corresponding to the bit changed */
epicsUInt8 *pBn = (epicsUInt8 *) paddr->pfield;
epicsUInt32 bit = 1 << (pBn - &prec->b0);
for (i = 0; i < NUM_BITS; i++, bit <<= 1)
if (*pBn++)
val |= bit;
prec->val = val;
/* Because this is !(VAL and PP), dbPut() will always post a monitor on this B* field
* after we return. We must keep track of this change separately from MLST to handle
* situations where VAL and B* are changed prior to next monitor(). eg. by dset to
* reflect bits actually written. This is the role of OBIT.
*/
if (*pBn) {
prec->val |= bit;
prec->obit |= bit;
} else {
prec->val &= ~bit;
prec->obit &= ~bit;
}
else if (prec->omsl == menuOmslsupervisory) {
/* Set B0 - B1F from VAL and post monitors */
epicsUInt32 val = prec->val;
epicsUInt8 *pBn = &prec->b0;
int i;
for (i = 0; i < NUM_BITS; i++, pBn++, val >>= 1) {
epicsUInt8 oBn = *pBn;
*pBn = !! (val & 1);
if (oBn != *pBn)
db_post_events(prec, pBn, DBE_VALUE | DBE_LOG);
}
}
break;
default:
recGblDbaddrError(S_db_badChoice, paddr, "mbboDirect: special");
return S_db_badChoice;
prec->udf = FALSE;
convert(prec);
}
prec->udf = FALSE;
return 0;
}
@@ -330,8 +312,21 @@ static void monitor(mbboDirectRecord *prec)
events |= DBE_VALUE | DBE_LOG;
prec->mlst = prec->val;
}
if (events)
if (events) {
db_post_events(prec, &prec->val, events);
}
{
unsigned i;
epicsUInt32 bitsChanged = prec->obit ^ (epicsUInt32)prec->val;
for(i=0; i<NUM_BITS; i++) {
/* post bit when value or alarm severity changes */
if((events&~(DBE_VALUE|DBE_LOG)) || (bitsChanged&(1u<<i))) {
db_post_events(prec, (&prec->b0)+i, events | DBE_VALUE | DBE_LOG);
}
}
prec->obit = prec->val;
}
events |= DBE_VALUE | DBE_LOG;
if (prec->oraw != prec->rval) {

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

@@ -9,11 +9,14 @@
=title Multi-Bit Binary Output Direct Record (mbboDirect)
The mbboDirect record performs the opposite function to that of the mbbiDirect
record. It accumulates bits (in the fields B0 - BF) as unsigned characters, and
converts them to a word which is then written out to hardware. If a bit field is
non-zero, it is interpreted as a binary 1. On the other hand, if it is zero, it
is interpreted as a binary 0.
The mbboDirect record performs roughly the opposite function to that of the
L<mbbiDirect record|mbbiDirectRecord>.
It can accept boolean values in its 32 bit fields (B0-B9, BA-BF, B10-B19 and
B1A-B1F), and converts them to a 32-bit signed integer in VAL which is provided
to the device support. A zero value in a bit field becomes a zero bit in VAL, a
non-zero value in a bit field becomes a one bit in VAL, with B0 being the least
signficant bit and B1F the MSB/sign bit.
=recordtype mbboDirect
@@ -31,50 +34,86 @@ The mbboDirect record has the standard fields for specifying under what
circumstances it will be processed.
These fields are listed in L<Scan Fields|dbCommonRecord/Scan Fields>.
=fields SCAN, PHAS, EVNT, PRIO, PINI
=head3 Desired Output Parameters
The mbboDirect record, like all output records, must specify where its output
originates. The output mode select field (OMSL) determines whether the output
originates from another record or from database access. When set to C<<<
closed_loop >>>, the desired output is retrieved from the link specified in the
desired output (DOL) field--which can specify either a database or channel
access link--and placed into the VAL field. When set to C<<< supervisory >>>,
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.
Like all output records, the mbboDirect record must specify where its output
should originate when it gets processed. The Output Mode SeLect field (OMSL)
determines whether the output value should be read from another record or not.
When set to C<<< closed_loop >>>, a 32-bit integer value (the "desired output")
will be read from a link specified in the Desired Output Link (DOL) field and
placed into the VAL field.
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
record writes the VAL field's value without any conversion.
When OMSL is set to C<<< supervisory >>>, the DOL field is ignored during
processing and the contents of VAL are used. A value to be output may thus be
written direcly into the VAL field from elsewhere as long as the record is in
C<<< supervisory >>> mode.
=fields OMSL, DOL, VAL
=head4 Bit Fields
The fields B0 through BF and B10 through B1F provide an alternative way to set
the individual bits of the VAL field when the record is in C<<< supervisory >>>
mode. Writing to one of these fields will then modify the corresponding bit in
VAL, and writing to VAL will update these bit fields from that value.
The VAL field is signed so it can be accessed through Channel Access as an
integer; if it were made unsigned (a C<DBF_ULONG>) its representation through
Channel Access would become a C<double>, which could cause problems with some
client programs.
Prior to the EPICS 7.0.6.1 release the individual bit fields were not updated
while the record was in C<<< closed_loop >>> mode with VAL being set from the
DOL link, and writing to the bit fields in that mode could cause the record to
process but the actual field values would not affect VAL at all. Changing the
OMSL field from C<<< closed_loop >>> to C<<< supervisory >>> would set the bit
fields from VAL at that time and trigger a monitor event for the bits that
changed at that time. At record initialization if VAL is defined and the OMSL
field is C<<< supervisory >>> the bit fields would be set from VAL.
From EPICS 7.0.6.1 the bit fields get updated from VAL during record processing
and monitors are triggered on them in either mode. Attempts to write to the bit
fields while in C<<< closed_loop >>> mode will be rejected by the C<special()>
routine which may trigger an error from the client that wrote to them. During
initialization if the record is still undefined (UDF) after DOL has been read
and the device support initialized but at least one of the B0-B1F fields is
non-zero, the VAL field will be set from those fields and UDF will be cleared.
=fields B0, B1, B2, B3, B4, B5, B6, B7, B8, B9, BA, BB, BC, BD, BE, BF, B10, B11, B12, B13, B14, B15, B16, B17, B18, B19, B1A, B1B, B1C, B1D, B1E, B1F
=head3 Convert and Write Parameters
For records that are to write values to hardware devices, the OUT output link
must contain the address of the I/O card, and the DTYP field must specify
the proper device support module. Be aware that the address format differs
according to the I/O bus used. See L<Address Specification> for information
on the format of hardware addresses.
according to the I/O bus used. See L<Address
Specification|https://docs.epics-controls.org/en/latest/guides/EPICS_Process_Database_Concepts.html#address-specification>
for information on the format of hardware addresses.
If the mbboDirect record does not use the C<<< Soft Channel >>> device support
module, then VAL is converted to RVAL, and RVAL is the actual 16-bit word sent
out. RVAL is set equal to VAL and then shifted left by the number of bits
specified in the SHFT field (the SHFT value is set by device support and is not
configurable by the user). RVAL is then sent out to the location specified in
the OUT field.
During record processing VAL is converted into RVAL, which is the actual 32-bit
word to be sent out. RVAL is set to VAL shifted left by the number of bits
specified in the SHFT field (SHFT is normally set by device support). RVAL is
then sent out to the location specified in the OUT field.
For mbboDirect records that specify a database link, a channel access link, or a
constant, the DTYP field must specify either one of two soft device support
routines--{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.
The fields NOBT and MASK can be used by device support to force some of the
output bits written by that support to be zero. By default all 32 bits can be
sent, but the NOBT field can be set to specify a smaller number of contiguous
bits, or MASK can specify a non-contiguous set of bits. When setting MASK it is
often necessary to set NOBT to a non-zero value as well, although in this case
the actual value of NOBT may be ignored by the device support. If a device
support sets the SHFT field it will also left-shift the value of MASK at the
same time.
=fields OUT, RVAL, SHFT, B0, B1, B2, B3, B4, B5, B6, B7, B8, B9, BA, BB, BC, BD, BE, BF
For mbboDirect records writing to a link instead of to hardware, the DTYP field
must select one of the soft device support routines C<<< Soft Channel >>> or
C<<< Raw Soft Channel >>>. The C<<< Soft Channel >>> support writes the contents
of the VAL field to the output link. The C<<< Raw Soft Channel >>> support
allows SHFT to be set in the DB file, and sends the result of ANDing the shifted
MASK with the RVAL field's value.
=fields OUT, RVAL, SHFT, MASK, NOBT
=head3 Operator Display Parameters
@@ -104,7 +143,6 @@ Parameters> for more on the record name (NAME) and description (DESC) fields.
field(OMSL,DBF_MENU) {
prompt("Output Mode Select")
promptgroup("50 - Output")
special(SPC_RESET)
pp(TRUE)
interest(1)
menu(menuOmsl)
@@ -116,7 +154,7 @@ Parameters> for more on the record name (NAME) and description (DESC) fields.
interest(1)
}
field(DOL,DBF_INLINK) {
prompt("Desired Output Loc")
prompt("Desired Output Link")
promptgroup("40 - Input")
interest(1)
}
@@ -154,6 +192,11 @@ Parameters> for more on the record name (NAME) and description (DESC) fields.
special(SPC_NOMOD)
interest(3)
}
field(OBIT,DBF_LONG) {
prompt("Last Bit mask Monitored")
special(SPC_NOMOD)
interest(3)
}
field(SHFT,DBF_USHORT) {
prompt("Shift")
promptgroup("50 - Output")
@@ -166,11 +209,13 @@ These parameters are used by the run-time code for processing the mbbo Direct
record.
MASK is used by device support routine to read the hardware register. Record
support sets low order NOBT bits. Device support can shift this value.
support sets the low order NOBT bits of MASK at initialization, and device
support is allowed to shift this value.
MLST holds the value when the last monitor for value change was triggered.
OBIT has a similar role for bits held in the B0-B1F fields.
=fields NOBT, ORAW, MASK, MLST
=fields NOBT, ORAW, MASK, MLST, OBIT
=head3 Simulation Mode Parameters
@@ -242,17 +287,21 @@ for more information on simulation mode and its fields.
=head3 Alarm Parameters
The possible alarm conditions for mbboDirect records are the SCAN, READ, and
INVALID alarms. The SCAN and READ alarms are not configurable by the user since
they are always of MAJOR severity. See L<Alarm Specification> for a complete
explanation of Scan and Read alarms.
INVALID alarms.
The IVOA field specifies an action to take when the INVALID alarm is triggered.
The IVOA field specifies an action to take when an 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 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.
the IVOV field to the output.
See L<Invalid Output Action Fields|dbCommonOutput/Invalid Output Action Fields>
for more information about IVOA and IVOV.
See L<Alarm Specification|https://docs.epics-controls.org/en/latest/guides/EPICS_Process_Database_Concepts.html#alarm-specification>
for a complete explanation of record alarms and of the standard fields.
L<Alarm Fields|dbCommonRecord/Alarm Fields> lists other fields related
to alarms that are common to all record types.
=fields IVOA, IVOV

4
modules/database/src/std/rec/mbboRecord.c
View File

@@ -151,7 +151,7 @@ static long init_record(struct dbCommon *pcommon, int pass)
epicsUInt32 *pstate_values = &prec->zrvl;
int i;
prec->val = 65535; /* initalize to unknown state */
prec->val = 65535; /* initialize to unknown state */
for (i = 0; i < 16; i++) {
if (*pstate_values == rval) {
prec->val = i;
@@ -217,7 +217,7 @@ static long process(struct dbCommon *pcommon)
convert(prec);
/* Update the timestamp before writing output values so it
* will be uptodate if any downstream records fetch it via TSEL */
* will be up to date if any downstream records fetch it via TSEL */
recGblGetTimeStampSimm(prec, prec->simm, NULL);
}

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

@@ -198,7 +198,7 @@ for more information on simulation mode and its fields.
#=write Yes
}
field(DOL,DBF_INLINK) {
prompt("Desired Output Loc")
prompt("Desired Output Link")
promptgroup("40 - Input")
interest(1)
}

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

@@ -25,7 +25,9 @@ recordtype(printf) {
The printf record has the standard fields for specifying under what
circumstances it will be processed.
These fields are listed in L<Scan Fields|dbCommonRecord/Scan Fields>.
These fields are described in L<Scan Fields|dbCommonRecord/Scan Fields>.
=fields SCAN, PHAS, EVNT, PRIO, PINI
=head3 String Generation Parameters
@@ -144,7 +146,8 @@ which type of the data is requested through the appropriate input link. As with
C<printf()> a C<*> character may be used in the format to specify width and/or
precision instead of numeric literals, in which case additional input links are
used to provide the necessary integer parameter or parameters. See L<Address
Specification> for information on specifying links.
Specification|https://docs.epics-controls.org/en/latest/guides/EPICS_Process_Database_Concepts.html#address-specification>
for information on specifying links.
The formatted string is written to the VAL field. The maximum number of
characters in VAL is given by SIZV, and cannot be larger than 65535. The LEN

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

@@ -79,7 +79,7 @@ for each desired output link. Only those that are defined are used.
When the sequence record is processed, it uses a selection algorithm similar to
that of the selection record to decide which links to process.The select
mechanism field (SELM) has three algorithms to choose from: C<<< All >>>,
C<<<Specified >>> or C<<< Mask >>>.
C<<< Specified >>> or C<<< Mask >>>.
=head4 Record fields related to the Selection Algorithm
@@ -102,24 +102,26 @@ 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<SELM> has the value C<Specified> the B<SELN> field sets the index number
of the link that will be processed, after adding the B<OFFS> field:
SELN = SELN + OFFS
=over
LNKI<n> where I<n> = C<SELN + OFFS>
I<(By default, the OFFS is initalized to ZERO)>
=back
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:
I<(If not set, the OFFS field is ZERO)>
When B<SELM> has the value C<Mask> the B<SELN> field provides the bitmask that
determines which links will be processed, after shifting by B<SHFT> bits:
if (SHFT >= 0)
SELN = SELN << -SHFT
bits = SELN >> SHFT
else
SELN = SELN >> SHFT
bits = SELN << -SHFT
I<(By default, the SHFT is initalized to -1)>
I<(If not set, the SHFT field is -1 so bits from SELN are shifted left by 1)>
=head4 B<Note about SHFT and OFFS fields>
@@ -131,7 +133,7 @@ The SHFT and OFFS fields were introduced to keep compatibility of old databases
that used seq records with links indexed from one.
B<To use the DO0, DOL0, LNK0, DLY0 fields when SELM = Mask, the SHFT field must
be set to ZERO>
be explicitly set to ZERO>
=head4 Selection Algorithms Description
@@ -208,29 +210,37 @@ Routine process implements the following algorithm:
=item 1.
First, PACT is set to TRUE, and the link selection is fetched. Depending on the
selection mechanism, the link selection output links are processed in order from
LNK0 to LNKF. When LNKI<x> is processed, the corresponding DLYI<x> value is
used to generate a delay via watchdog timer.
selection mechanism chosen, the appropriate set of link groups will be
processed. If multiple link groups need to be processed they are done in
increasing numerical order, from LNK0 to LNKF.
=item 2.
After DLYI<x> seconds have expired, the input value is fetched from DOI<x> (if
DOLI<x> is constant) or DOLI<x> (if DOLI<x> is a database link or channel
access link) and written to LNKI<x>.
When LNKI<x> is to be processed, the corresponding DLYI<x> value is first used
to generate the requested time delay, using the IOC's Callback subsystem to
perform subsequent operations. This means that although PACT remains TRUE, the
lockset that the sequence record belongs to will be unlocked for the duration of
the delay time (an unlock occurs even when the delay is zero).
=item 3.
When all links are completed, an asynchronous completion call back to dbProcess
is made (see the Application Developer's Guide for more information on
asynchronous processing.)
After DLYI<x> seconds have expired, the value in DOI<x> is saved locally and a
new value is read into DOI<x> through the link DOLI<x> (if the link is valid).
Next the record's timestamp is set, and the value in DOI<x> is written through
the LNKI<x> output link. If the value of DOI<x> was changed when it was read in
a monitor event is triggered on that field.
=item 4.
Then UDF is set to FALSE.
If any link groups remain to be processed, the next group is selected and the
operations for that group are executed again from step 2 above.
If the last link group has been processed, UDF is set to FALSE and the record's
timestamp is set.
=item 5.
Monitors are checked.
Monitors are posted on VAL and SELN.
=item 6.
@@ -238,12 +248,11 @@ The forward link is scanned, PACT is set FALSE, and the process routine returns.
=back
For the delay mechanism to operate properly, the record is processed
For the delay mechanism to operate properly, the record is normally processed
asynchronously. The only time the record will not be processed asynchronously is
when there are no non-NULL output links selected (i.e. when it has nothing to
do.) The processing of the links is done via callback tasks at the priority set
in the PRIO field in dbCommon (see the Application Developer's Guide for more
information on call
if it has nothing to do, because no link groups or only empty link groups are
selected for processing (groups where both DOLI<x> and LNKI<x> are unset or
contain only a constant value).
=cut

2
modules/database/src/std/rec/stringoutRecord.c
View File

@@ -148,7 +148,7 @@ static long process(struct dbCommon *pcommon)
}
/* Update the timestamp before writing output values so it
* will be uptodate if any downstream records fetch it via TSEL */
* will be up to date if any downstream records fetch it via TSEL */
recGblGetTimeStampSimm(prec, prec->simm, NULL);
if (prec->nsev < INVALID_ALARM )

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

@@ -65,8 +65,8 @@ the output mode select (OMSL) field, which can have two possible value: C<<<
closed_loop >>> or C<<< supervisory >>>. If C<<< supervisory >>> is specified,
DOL is ignored, the current value of VAL is written, and the VAL can be changed
externally via dbPuts at run-time. If C<<< closed_loop >>> is specified, the VAL
field's value is obtained from the address specified in the desired output
location field (DOL) which can be either a database link or a channel access
field's value is obtained from the address specified in the Desired Output
Link field (DOL) which can be either a database link or a channel access
link.
DOL can also be a constant, in which case VAL will be initialized to the
@@ -80,7 +80,7 @@ cannot be C<<< closed_loop >>>.
=cut
field(DOL,DBF_INLINK) {
prompt("Desired Output Loc")
prompt("Desired Output Link")
promptgroup("40 - Input")
interest(1)
}

1
modules/database/src/std/rec/waveformRecord.c
View File

@@ -139,6 +139,7 @@ static long process(struct dbCommon *pcommon)
if (!pact && prec->pact)
return 0;
prec->pact = TRUE;
prec->udf = FALSE;
recGblGetTimeStampSimm(prec, prec->simm, &prec->siol);

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

@@ -120,9 +120,18 @@ at run-time.
VAL references the array where the waveform stores its data. The BPTR field
holds the address of the array.
The NORD field holds a counter of the number of elements that have been read
into the array. It is reset to 0 when the device is rearmed. The BUSY field
indicates if the device is armed but has not yet been digitized.
The NORD field indicates the number of elements that were read into the array.
The BUSY field permits asynchronous device support to collect array elements
sequentially in multiple read cycles which may call the record's C<process()>
method many times before completing a read operation. Such a device would set
BUSY to TRUE along with setting PACT at the start of acquisition (it could also
set NORD to 0 and use it to keep track of how many elements have been received).
After receiving the last element the C<read_wf()> routine would clear BUSY which
informs the record's C<process()> method that the read has finished. Note that
CA clients that perform gets of the VAL field can see partially filled arrays
when this type of device support is used, so the BUSY field is almost never used
today.
=fields VAL, BPTR, NORD, BUSY
@@ -367,14 +376,14 @@ Other: Error.
=head3 Device Support For Soft Records
The C<<< Soft Channel >>> device support module is provided to read values from
other records and store them in arrays. If INP is a constant link, then read_wf
does nothing. In this case, the record can be used to hold arrays written via
dbPuts. If INP is a database or channel access link, the new array value is read
from the link. NORD is set to the number of items in the array.
other records and store them in the VAL field. If INP is a constant link, then
C<read_wf()> does nothing. In this case, the record can be used to hold a fixed
set of data or array values written from elsewhere. If INP is a valid link, the
new array value is read from that link. NORD is set to the number of items
received.
This module places a value directly in VAL.
If the INP link type is constant, then NORD is set to zero.
If the INP link type is constant, VAL is set from it in the C<init_record()>
routine and NORD is also set at that time.
=cut

3
modules/database/src/std/softIoc/softMain.cpp
View File

@@ -114,7 +114,8 @@ void lazy_dbd(const std::string& dbd_file) {
if (verbose)
std::cout<<"softIoc_registerRecordDeviceDriver(pdbbase)\n";
softIoc_registerRecordDeviceDriver(pdbbase);
errIf(softIoc_registerRecordDeviceDriver(pdbbase),
"Failed to initialize database");
registryFunctionAdd("exit", (REGISTRYFUNCTION) exitSubroutine);
}