Difference between revisions of "RRM 3-14 Binary Input"

From EPICSWIKI
 
Line 20: Line 20:
=== Scan Parameters ===
=== Scan Parameters ===


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


=== Read and Convert Parameters ===
=== Read and Convert Parameters ===


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


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


If the record gets its value from hardware or uses the <CODE>Raw Soft Channel</CODE> device support, the device support routines place the value into the RVAL field which is then converted using the process described in the next section.
If the record gets its value from hardware or uses the <CODE>Raw Soft Channel</CODE> device support, the device support routines place the value into the RVAL field which is then converted using the process described in the next section.
Line 58: Line 58:
These parameters are used to present meaningful data to the operator. The <CODE>get_enum_str</CODE> record support routine can retrieve the state string corresponding to VAL's state. So if the value is 1, <CODE>get_enum_str</CODE> will return the string in the ONAM field; and if 0, <CODE>get_enum_str</CODE> will return the ZNAM string.
These parameters are used to present meaningful data to the operator. The <CODE>get_enum_str</CODE> record support routine can retrieve the state string corresponding to VAL's state. So if the value is 1, <CODE>get_enum_str</CODE> will return the string in the ONAM field; and if 0, <CODE>get_enum_str</CODE> will return the ZNAM string.


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




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


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




Line 112: Line 112:




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




Line 163: Line 163:


# Check to see that the appropriate device support module exists. If it doesn't, an error message is issued and processing is terminated with the PACT field still set to TRUE. This ensures that processes will no longer be called for this record. Thus error storms will not occur.
# Check to see that the appropriate device support module exists. If it doesn't, an error message is issued and processing is terminated with the PACT field still set to TRUE. This ensures that processes will no longer be called for this record. Thus error storms will not occur.
# readValue is called. See [[RRM 3-13 Common#Input Records|Input Records]] for details.
# readValue is called. See [[RRM 3-14 Common#Input Records|Input Records]] for details.
# If PACT has been changed to TRUE, the device support read routine has started but has not completed reading a new input value. In this case, the processing routine merely returns, leaving PACT TRUE.
# If PACT has been changed to TRUE, the device support read routine has started but has not completed reading a new input value. In this case, the processing routine merely returns, leaving PACT TRUE.
# Convert<pre>
# Convert<pre>
Line 187: Line 187:


<TABLE BORDER="1"><TH>Name<TH>Summary<TH>Description<TR>
<TABLE BORDER="1"><TH>Name<TH>Summary<TH>Description<TR>
<TD>PACT<TD>Processing Active<TD rowspan=5>See [[RRM 3-13 dbCommon|Fields Common to All Record Types]] for an explanation of these fields.<TR>
<TD>PACT<TD>Processing Active<TD rowspan=5>See [[RRM 3-14 dbCommon|Fields Common to All Record Types]] for an explanation of these fields.<TR>
<TD>DPVT<TD>Device Private<TR>
<TD>DPVT<TD>Device Private<TR>
<TD>UDF<TD>VAL Undefined<TR>
<TD>UDF<TD>VAL Undefined<TR>
Line 248: Line 248:
If the INP link type is constant, then the constant value is stored into VAL by init_record, and UDF is set to FALSE. VAL can be changed via dbPut requests. If the INP link type is PV_LINK, then dbCaAddInlink is called by init_record.
If the INP link type is constant, then the constant value is stored into VAL by init_record, and UDF is set to FALSE. VAL can be changed via dbPut requests. If the INP link type is PV_LINK, then dbCaAddInlink is called by init_record.


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


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

Revision as of 19:06, 18 April 2008

EPICS Record Reference Manual


bi - Binary Input

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

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

Parameter Fields

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

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

Scan Parameters

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

Read and Convert Parameters

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

For records that specify the Soft Channel or Raw Soft Channel device support routines, the INP field can be a channel or database access link, or a constant. If a constant, VAL can be changed directly by dbPuts. See Address Specification for information on the format of database and channel access addresses. Also, see Device Support for Soft Records in this chapter for more information on soft device support.

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


FieldSummaryTypeDCTInitialAccessModify Rec Proc MonitorPP
INPInput LinkINLINKYes0NoNoN/ANo
DTYPDevice TypeDEVCHOICEYes0YesNoNo 
ZNAMZero NameSTRING [20]YesNullYesYesNoYes
ONAMOne NameSTRING [20]YesNullYesYesNoYes
RVALRaw ValueULONGNo0YesYesYesYes
VALValue FieldENUMNo0YesYesYesYes


Conversion Fields

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


ZNAMASCII string defining state zero
ONAMASCII string defining state one


Operator Display Parameters

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

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


FieldSummaryTypeDCTInitialAccessModify Rec Proc MonitorPP
ZNAMZero NameSTRING [20]YesNullYesYesNoYes
ONAMOne NameSTRING [20]YesNullYesYesNoYes
NAMERecord NameSTRING [29]Yes0YesNoNoNo
DESCDescriptionSTRING [29]YesNullYesYesNoNo


Alarm Parameters

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

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

See Alarm Specification for a complete explanation of discrete alarm states. Alarm Fields lists other fields related to a alarms that are common to all record types.


FieldSummaryTypeDCTInitialAccessModify Rec Proc MonitorPP
ZSVZero SeverityGBLCHOICEYes0YesYesNoYes
OSVOne SeverityGBLCHOICEYes0YesYesNoYes
COSVChange of State SeverityGBLCHOICEYes0YesYesNoYes


Run-time Parameters and Simulation Mode Parameters

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

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

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

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

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


FieldSummaryTypeDCTInitialAccessModify Rec Proc MonitorPP
ORAWOld Raw ValueULONGNo0YesNoNoNo
MASKHardware maskULONGNocomputeYesNoNoNo
LALMLast Alarmed valueUSHORTNo0YesNoNoNo
MLSTLast Monitored ValueUSHORTNo0YesNoNoNo


The following fields are used to operate the binary input in the simulation mode. See Fields Common to Many Record Types for more information on these fields.


FieldSummaryTypeDCTInitialAccessModify Rec Proc MonitorPP
SIOLSimulation Value LocationINLINKYes0NoNoN/ANo
SVALSimulation ValueDOUBLENo0YesYesNoNo
SIMLSimulation Mode LocationINLINKYes0NoNoN/ANo
SIMMSimulation ModeGBLCHOICENo0YesYesNoNo
SIMSSimulation Mode Alarm SeverityGBLCHOICEYes0YesYesNoNo


Record Support

Record Support Routines

init_record

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

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

If device support includes init_record, it is called.

process

See next section.

get_value

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

get_enum_str

Retrieves ASCII string corresponding to VAL.

get_enum_strs

Retrieves ASCII strings for ZNAM and ONAM.

put_enum_str

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

Record Processing

Routine process implements the following algorithm:

  1. Check to see that the appropriate device support module exists. If it doesn't, an error message is issued and processing is terminated with the PACT field still set to TRUE. This ensures that processes will no longer be called for this record. Thus error storms will not occur.
  2. readValue is called. See Input Records for details.
  3. If PACT has been changed to TRUE, the device support read routine has started but has not completed reading a new input value. In this case, the processing routine merely returns, leaving PACT TRUE.
  4. Convert

status=read_bi PACT = TRUE TIME = tslocaltime if status is 0, then set VAL=(0,1) if RVAL is (0, not 0) and UDF = False if status is 2, set status = 0

  1. Check alarms: This routine checks to see if the new VAL causes the alarm status and severity to change. If so, NSEV and NSTA and LALM are set. Note that if VAL is greater than 1, no checking is performed.
  2. Check to see if monitors should be invoked:
    • Alarm monitors are invoked if the alarm status or severity has changed.
    • Archive and value change monitors are invoked if MLST is not equal to VAL.
    • Monitors for RVAL are checked whenever other monitors are invoked.
    • NSEV and NSTA are reset to 0.
  3. Scan forward link if necessary, set PACT FALSE, and return.

Device Support

Fields Of Interest To Device Support

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


NameSummaryDescription
PACTProcessing ActiveSee Fields Common to All Record Types for an explanation of these fields.
DPVTDevice Private
UDFVAL Undefined
NSEVNew Alarm Severity
NSTANew Alarm Status
VALValue FieldThis field is set by a device support routines only if it doesn't want record support to set it.
INPInput LinkThis field is used by the device support routines to locate its input.
RVALRaw ValueIt is the responsibility of the device support routine to give this field a value.
MASKHardware mask.The device support routine must give this field a value if it needs to use it.


Device Support routines

Device support consists of the following routines:

report

report(FILE fp, paddr)

Not currently used.

init

init()

This routine is called once during IOC initialization.

init_record

init_record(precord)

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

get_ioint_info

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

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

read_bi

read_bi(precord)

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

0: Success. A new raw value is placed in RVAL. The record support module forces VAL to be (0,1) if RVAL is (0, not 0).
2: Success, but don't modify VAL.
other: Error.

Device Support for Soft Records

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

Soft Channel

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

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

read_bi calls recGblGetLinkValue to read the current value of VAL. See Soft Input for details.

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

Raw Soft Channel

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

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




EPICS Record Reference Manual - 19 MAY 1998