<P> EPICURE Software Release Note 69.0<P>
<b> Generic Status Bit Definitions</b>
Abstract
Purpose of this document
This document examines generic status bits as they appear in the
EPICURE data aquisition and control system from three perspectives:
- How to define and customize generic status
bit information in the EPICURE database.
- How the EPICURELIB scaling services can
be used to obtain generic status bit
information from ``raw'' status information.
- How the PAGE application
displays generic status bits in its STATUS field.
This document seeks primarily to clarify the function and implementation
of generic status bits in the EPICURE data aquisition and control
system.
Intended audience
This note is intended for anyone who needs to read, modify, or create
module templates for the EPICURE database. Such people may include
EPICURE system programmers working with new hardware, those in charge
of EPICURE database management, and possibly control system application
programmers. Users of EPICURE who do not have occasion
to work with module template files will probably not need this
document.
Assumptions
This document primarily concerns generic status bits in EPICURE database
module templates. A familiarity on the part of the reader with the basic
purpose and format of EPICURE module templates and device entries is assumed.
The EPICURE Data Aquisition and Control System was developed primarily
on the Fermilab Research Division WARNER Local Area VAXCluster (LAVC).
Therefore, when file or directory specifications, VMS command sequences, etc.,
are shown in this document, it is assumed that they refer to the WARNER VAXCluster
environment unless context clearly indicates otherwise.
This document assumes that the reader has a working knowledge of the
VAX/VMS operating system and the DCL interpreter. An understanding
of the EPICURE data-aquisition system is essential to viewing
generic status bits in the context of an extensible and evolving
beamline control system.
For further information and answers
Unfortunately, there is a dearth of documentation on the required format of
module templates and device entries in the EPICURE database. Luckily,
most of what one needs to know in order to create and modify EPICURE\
database module templates can be gleaned from the central module template (MDT)
source file for the EPICURE database, MDT_FILE.TXT. Users who need to
create a new module template can often just cut and paste a related existing module
template, modifying it as necessary to fit the ``new'' module.
There are three additional sources of information, for times when more
help is necessary. Some information about the structure and syntax
of module templates and device entries (MDT and DDT files, respectively)
can be found in the following files:
EPICURE_ROOT:[WORK.ECDB.PRODUCTION.DIBS.COMMON_FILES]OAMOD_TABLES.CLD
EPICURE_ROOT:[WORK.ECDB.PRODUCTION.DIBS.COMMON_FILES]OADEV_TABLES.CLD
The .CLD files above define the command-language for EPICURE device and
module files. The file OAMOD_TABLES.CLD describes the syntax of
MDT files, and OADEV_TABLES.CLD describes the DDT file format.
Application programs can conveniently access generic status bits for an
EPICURE device by calling the EPICURELIB scaling routines
scl_is_on(), scl_is_positive(), scl_is_ramped(), scl_is_ready(),
and scl_is_remote(). These routines are part of the EPICURELIB\
UTI routines for the EPICURE control system. On-line help libraries
for EPICURELIB routines are kept reasonably up-to-date, and can be
accessed by typing at the DCL prompt:
$ HELP @FERMIHELP EPICURELIB
The same documentation is maintained in a
file generated by the
EPICURE document extractor application
. To obtain
a QUIC-format version of this document, type at the DCL prompt:
$ @TEX$:TEXV2 ! Command to set-up LaTeX
$ LATEX RDCS$DOC:EPICURELIB ! Convert .TEX --> .DVI
$ QTEX EPICURELIB ! Convert .DVI --> .Q (QUIC)
(For output, use the command XTEX with
the same parameter.) Then, just copy the or file
to an appropriate laser printer, bearing in mind that the document is
on the order of 70 pages long!
Also, the EPICURE consultants can advise on database formats. To
obtain a list of who's who in EPICURE, type:
$ HELP @USERGUIDE CONSULTANTS
Please make sure that you can state your needs clearly and briefly
before contacting an EPICURE consultant. VAXMail is usually the
preferred method of communication.
Finally, there are two documents that give sort of an overview of the composition
and purpose of the EPICURE database. They are Creation of Initial
EPICURE OA Database from EPICS and New Devices by T. Lahey and T.
Fink
,
and EPICURE Temporary Database Builder by T. Fink
.
The former describes the differences between module templates and device
templates. The latter document shows how one goes about building a
database, something one will need to do once the central database
module file MDT_FILE.TXT has been modified.
If all else fails...
If, after exhausting all possible avenues of help and consultation,
problems still persist in defining generic status bits ``just right'' and getting
them to work correctly, there is probably an error or an ambiguity in this
document. The author respectfully requests that any suggestions
or corrections regarding this document be VAXMailed to WARNER::RAMSEY.
The STATUS property in the EPICURE system
Overview of EPICURE data aquisition
The EPICURE Beamline Control System makes available to the user
a vast amount of information about beamline devices in the fixed-target
and experimental areas of the Research Division. The creators of EPICURE\
have deemed it convenient to
divide the set of all possible device information into two subsets.
These subsets of data correspond roughly to two differing channels of
data aquisition in the EPICURE system. Our focus will be on the
EPICURE database, the repository for static device information.
The EPICURE database
Beamline device data which changes rarely is generally considered to
be ``static,'' and much of this information has been integrated into
the EPICURE device database. This database at present consists of
a set of three binary section files formatted for optimized access, and
numerous source text files. The source files obey a specified syntax
and protocol. A database ``build'' consists of creating the section
files from the source files, and then distributing the section files
to select nodes in the WARNER and DISNEY LAVCs.
PLEASE NOTE: the present organization of the EPICURE
database and the method
by which database builds and modifications take place are subject
to major change in the near future.
The source files for the EPICURE device database are at present
the human-readable repository for database
information. They are stored in EPICURE_ROOT:[WORK.DATABASE.FE].
The ``grammar'' of the EPICURE database source files is defined in
the two Command Language Definition
(CLD) files OAMOD.CLD
and OADEV.CLD listed above, which are in turn compiled by
the Command Definition Utility (CDU) into an object file readable
by the Command Language Interpreter (CLI).
There are two types of database source files, DDT and MDT files.
MDT files define the different types of modules in the beamline systems
and their default properties. DDT files consist of device entries
which describe the specific properties of each of the devices in the
EPICURE system.
When a database is built, these source files are
compiled into three binary section files which make up the Optimized
Access (OA) database
by a program called COA (Create Optimized Access database). The section
files for the EPICURE OA database are centrally located for the WARNER\
LAVC in EPICURE_ROOT:[WORK.DATABASE]. They are:
- OA_DEVICES.SEC --- Contains device records
- OA_HASH.SEC --- Contains shared records
- OA_SHARED.SEC --- Contains hash tables
The OA section files are optimized for quick access, and are not
designed for human-readability. Therefore, an intermediary is
necessary to make the information contained in the OA database
available to users. The EDBServer is a process which must
be running on a system for processes on that system to access
the EPICURE database. A facility of UTI routines have been
written to allow application programs (and the DARSERVER) to
communicate with the EDBServer. These db_... routines
are in EPICURELIB and on-line help for them is available
.
This is the channel for accessing database information through
EPICURE at the present time. There are numerous application
programs which facilitate this process, such as DBPEEKER
. Numerous enhancements to the
existing EPICURE database system are either planned,
under development, or in test
.
EPICURE Data Aquisition and Control
Data which comes from beamline devices themselves is generally obtained
via a different data aquisition channel than database information,
under the EPICURE system.
The data aquisition channel under EPICURE, however, is not
altogether independent of the database channel described above.
This is because a database look-up for addressing and data aquisition
protocol information is almost always required in order to get data
from a beamline device. The important distinction is that the
data from the beamline devices themselves is generally not
made available as a part of the EPICURE static device database.
This is in contrast to the ACNET system, where some setting values
and dynamic alarm information is contained in the ``static'' database
.
The standard EPICURE data-aquisition channel centers around
a front-end
-VAX system with custom EPICURE data-aquisition
software and hardware. Application programs on experimenter nodes
can obtain data from the front-ends by passing requests to the DARSERVER
process on their system. Requests are passes to and from the DARSERVER
by way of VMS mailboxes. The DARSERVER collates requests with appropriate
database information and sends them over DECnet to the DAS_SERVER
running on the appropriate front-ends. There are several documents which
provide an excellent overview of the data-aquisition system. A good place
to start is the EPICURE User's Guide Volume III, EPICURE Software
Release Note 37.2, pub. 28 August 1989.
Properties and attributes
Information in the EPICURE database is indexed by property and attribute.
For each device in the database which has a STATUS property defined, a number
of attribute fields must be defined, such as data size and scaling information.
The STATUS property is read-only, generally the digital reading of a device.
Many beamline devices are capable of supplying more than one bit of status
information to the data-aquisition system. Status data is typically 1, 2, or
4 bytes in length. Table
lists some of the primary attributes
associated with the database STATUS property, with brief explanations of their
functions.
The property and attribute codes for the EPICURE system are defined in
EPICURE_INC:DBUSER.H. This document deals almost exclusively with the STATUS
property, but there are many other important properties in the control system, as
well. Consult EPICURE User's Guide: Volume III, page 80 for a list of
such properties.
Defining STATUS bits in the EPICURE database
By itself, a word or longword of status information from an EPICURE device is
not terribly useful. Information such as bit offsets and display text
must be present if the status data is to be properly interpreted.
Thus, it is not enough for the data-aquisition system to just return
the status data for a device. The bit masks and other information about
the status data must also be provided. This information is ideally suited for
the EPICURE database, since it is considered static.
Information about a device's status bits is stored by the database in
an array of structures called BITNAMES.
The BITNAMES structure
is defined in the public include file EPICURE_INC:DBUSER.H. Status bit names for
a device are defined in the database MDT and DDT source files. The following
should serve as an example of how status bits are defined in the database files:
B_STSNAMES ! Command verb to start BITNAMES list
STSNAME - ! Command verb to start BITNAMES record
/BITNUMBER=0 - ! Bit offset in status data
/SHORTNAME=OPEN - ! Short bit name text
/LONGNAME=VALVE_OPEN - ! Long bit name text
/SETTEXT=OPEN - ! ON state text
/CLRTEXT=0 - ! OFF state text
/SETCOLOR=0 - ! Not supported at this time
/CLRCOLOR=0 ! Not supported at this time
STSNAME - ! Command verb to start BITNAMES record
. ! <--+
. ! |------- Another record...
. ! <--+
E_STSNAMES ! Command verb to end BITNAMES list
Bit names are defined in groups of text that closely resemble records
and fields. Each status bit defined has its own record, and the
bit text and other data occupy the fields of the record.
The command verb B_STSNAMES begins the list of status bit definitions.
Each status bit definition begins with the verb STSNAME, followed
by a number of qualifiers. The list is terminated with the E_STSNAMES
command verb. COA assigns a BITNAMES structure from a BITNAMES array
to each STSNAME ``record'' as it parses the MDT file. Note that the
continuation hyphen is not included after the last qualifier
in each STSNAME ``record.''
The /BITNUMBER qualifier refers to the offset of the status bit
in question in the status data from the device, starting from
the 0 bit.
The /SHORTNAME and /LONGNAME are short and long names, respectively,
for the status bit. They are displayed in the ``extended status page''
in the PAGE application, among other places
.
The /SETTEXT and /CLRTEXT define the text associated with each state
of the status bit. If the hardware returns a 1, then PAGE will
display the /SETTEXT string as the current ``state'' of the status bit.
The same applies if the hardware returns a 0, except that PAGE will
instead display the /CLRTEXT string.
The /SETCOLOR and /CLRCOLOR qualifiers are not supported at this time.
This concludes the discussion on bit names in general. It is important
to distinguish between status bits and generic status bits, in order
that the module templates will make some sense. Subsection
introduces generic status bits.
The need for generic status bits
With providing all the flexibility of custom status bits for
each EPICURE device comes a little snag. How can bit-number
transparency for scaling services be preserved when each device
can potentially have a completely unique status bit ordering?
The solution chosen by the EPICURE designers has been to
create five ``generic status bits'' which are tailored for
use with magnet power supplies. The text associated with these
generic status bits can be changed by adding a qualifier to the
database MDT file. Thus, while the default generic status bit
names won't always apply to every device, it is possible to
override the text associated with the generic status bits.
Having five system-wide status bits allows for the creation of
five scaling routines to provide transparent status bit translation
for application programs.
Section
will discuss how to define and use the EPICURE\
generic status bits to display important status information for
beamline device on a PAGE.
Generic status bits in the EPICURE database
The ON/OFF bit states
Any EPICURE device can have up to five generic status bits. Of
course, if a device has no STATUS property, then the notion of
defining generic status bits for the device seems a little silly.
Each generic status bit has a name, which corresponds to some
binary-state property of a power supply-type device. From the
standpoint of the database, there are two possible states of any
status bit: ON and OFF. The database does not assign
a ``good'' or ``bad'' property to either state. It is possible
to equate the ON state with either a hardware 1 or 0, and as well
for the OFF state. The default is that a hardware 1 corresponds to
the ON state, and a hardware 0 corresponds to the OFF state.
Table
illustrates the default relationship between
hardware bits and ON/OFF states.
The Hardware column in Table
is the bit value returned from the hardware. The State
column in Table
is the ON/OFF state associated
by default with each hardware bit value. It will be shown below
how to override the default ON/OFF bit values for generic status bits.
Default text for generic status bit states
Each generic status bit also has two four-character
strings associated with it (the strings are not null-terminated,
but instead space-padded), one for the ON state and one for the OFF
state. The four-character strings are abbreviations of names
corresponding to the physical states of the device.
Table
lists the five system-wide generic
status bits, their names, the long text associated with each of
their states, and a unique numerical identifier (1-5) for each
of the bits.
For the default display text associated with the two states of each of
the generic status bits, refer to Section
and
Table
.
Defining generic status bits in the database
In order to define a generic status bit for an EPICURE device,
certain information must be provided to the database, so that
COA can put together a PDB for the EPICURELIB scaling services.
This information includes the following:
- Mask
- Bit offset for each generic status bit defined.
(required)
- Color
- Set and clear colors. The present system does
not support colors, but they are required
for each defined generic status bit
(required)
- Text
- Override text for on and off states (optional)
- Invert
- List of generic status bits for which the
ON state is a hardware 0 and the OFF state
is a hardware 1. The default is that a
hardware 1 is ON and a hardware 0 is OFF.
(required)
Usually, all devices of the same module type will have the same
status bit definitions. If this is the case, then all one needs
to do is to make a module template with the appropriate generic
status bit definitions; then those definitions will serve as
defaults for every device of that module type. Of course, the
defaults can always be overridden by re-defining the generic status
bits in the device files. In either case, the commands are basically
the same. All generic status bit information is specified by qualifiers
of the form:
/QUALIFIER=value -
The hyphen at the end of the command is a continuation marker. The
last qualifier in a list of qualifiers should not be followed
by a qualifier, or COA might get confused. Above, QUALIFIER
is the name of the qualifier as defined in the CLD (``grammar'') file,
and value is the string or number which the qualifier is to be
``equated'' with.
Bit Masks
The bit mask of a generic status bit is specified by a qualifier
in the STATUS verb record of a template file. The order or placement
of the qualifier within the record is not critical. The qualifier
is of the form /..._MASK, where `` signifies a 2, 3,
or 4-character abbreviation of the generic status bit name. The
qualifiers for defining bit masks associated with each generic status
bit are listed in Table
. Note that some generic
status bits, namely the on, polarity, and ramp bits,
have more than one qualifier associated with them. In those cases, only
one of the multiple qualifiers need be specified.
The format of the bit mask qualifier in the module template is as follows:
/RAMP_MASK=0x0001 -
The number above is in hexadecimal, and it indicates that the RAMP bit
corresponds to bit position 0. The hyphen is a continuation hyphen,
telling COA that more qualifiers are to follow.
Status Colors
Color information is not presently supported by the data aquisition system,
but the color attributes must be included into the database PDB nonetheless.
This will facilitate an easy change if and when color becomes supported in
the future. There are two color qualifiers for each generic status bit
defined. They are of the form /..._A and /N_..._A.
The strings `` are 2, 3, or 4-character abbreviations of the names
of the generic status bits.
The color qualifiers are lists of color keywords for ON and OFF states of the
generic status bit. ``Dummy'' colors can be placed in the lists for now.
The format of a set- or clear-color definition statement is as follows:
/REM_A=(GREEN,.) -
The hyphen above is a continuation hyphen, telling COA that more qualifiers
are to follow. The color qualifiers take a parameter list of color keywords.
The interested reader should consult the CLD definition files for EPICURE
module templates.
Refer to Appendix
for another example of how color qualifiers
are specified in the module template file.
Table
lists the color-definition qualifiers associated
with each generic status bit.
Override Text
Like the color and bit mask information, the display text of generic status
bits is specified with qualifiers in the STATUS verb record of a database template. Unlike
the color and bit mask information, the display text qualifiers are optional
for defined generic status bits. The text qualifiers for generic status bits
are actually overrides for the default display text for those bits, so it
makes sense that they are optional qualifiers. There are two text qualifiers
for each generic status bit, one for the ON state and one for the OFF state.
The qualifiers are equated with character strings of up to 4 characters in length.
The strings are placed in the status scaling PDB (for devices of the same
module type) as space-padded fixed-length strings when the database is built.
Quotes are optional for the string specification. A null string can be specified
by ``'', or by a zero. Text override qualifiers are of the
form /#_ON_..._STATE and /#_OFF_..._STATE, where the
``ON'' qualifiers correspond to the ON-state text, and so forth. Table
lists the override text qualifiers for each generic status bit.
The format of an override text statement is as follows:
/ON_POLARITY_MASK="Tpa" -
In the above example, quotes around the text string are optional, and the
hyphen at the end of the statement is a continuation hyphen, telling COA
that more qualifiers are to follow.
Invert Flag
The default relationship between hardware bit value and ON/OFF state is, 1=ON and
0=OFF. Table
illustrates this relationship. For any generic
status bit, the default states can be changed by specifying the generic bit's name
in the parameter list of the /S_DI_FLAGS qualifier. This inverts the
state-to-value relationship above, so that 0=ON and 1=OFF.
Table
illustrates the effect of including a generic
status bit in the /S_DI_FLAGS qualifier's parameter list. The syntax of
the qualifier list is the same as for most CLI parameter lists:
/S_DI_FLAGS=(bit1, bit2, ..., bitn)
In the above example, bit# corresponds to the name of a generic status
bit, as listed in Table
. Any subset of the five generic
status bit names can be included in the parameter list.
Refer to Appendix
for an example of how the /S_DI_FLAGS
qualifier works.
Building a test database
When overriding the default display text of generic status bits of a module, it
is often necessary to make several tries before the invert flags and display text
work right together. Even for simple one-bit devices, it's tricky business.
Modifying the central EPICURE MDT file can be perilous, too, because a small
mistake in one's module template can cause COA to blow up during the next database
build. Database builds take at least 90 minutes at the time this document is
published, and are expected to increase in the future. It is grossly impractical
to rebuild the entire EPICURE database multiple times in order to get the
override text for a generic status bit just right. What to do?
For the above reasons, it is frequently advantageous to build a private test database
in a work directory/area separate from the [WORK.DATABASE] project area. Such
a database would have only a few devices and probably only one module template
record, the template that is being ``customized.'' Building a private test database
permits fast rebuilds and lets one be sure that a module template won't crash COA
before appending it to MDT_FILE.TXT. It is beyond the scope of this
document to explain how to generate a test database, but the process is not
inherently difficult. Consult EPICURE Software Release 18.0 for more specifics
on running COA to make a private test database.
Generic status bits and EPICURELIB scaling services
Each generic status bit has an EPICURELIB scaling service of the form
scl_is_...(). These five scaling routines interpret raw status
data from a device using the information in a structure called a status process
data block, or PDB. The information in the PDB is defined in the database template
and device files, and the format of the PDB structure is based on the ACNET PDB
. Unlike most EPICURELIB services,
which return a 32-bit condition code,
these scaling services return a boolean value corresponding to the state of the generic
status bit, ON or OFF. Table
shows how the return values of
the scaling services correspond to generic status bit states. An argument specified
on the command-line allows for a status longword to be returned by the scaling services.
The scaling routines
also return the four-character text string describing the current state of the status
bit, as defined in the supplied status PDB. In this sense, an application can use
any device's status PDB, or can alternately use its own custom PDB, with the scaling
services. Table
lists the scaling routines and the default text that
they return.
For more information on these and other EPICURE scaling services, consult the
various sources of information listed in Subsection
.
One of the best examples of the utility of generic status bits coupled with
the EPICURE scaling services is in the PAGE application. Section
will demonstrate how PAGE obtains and displays generic status bit data for beamline
devices.
Generic status bits in the PAGE application
The PAGE application makes it possible to examine the status bits of just about
any EPICURE device. There is a STATUS field in which PAGE displays
status information for each device on the ``page.'' This is an ideal
layout for devices with five or fewer status bits, making it easy to call up
a ``page'' and see immediately in what state a device is. However, some devices
have just too many status bits to display practically in a 15-character field.
PAGE Uses the EPICURELIB scaling services
The solution implemented in PAGE is the use of generic status bits as defined
in the EPICURE database. PAGE uses the EPICURELIB scaling services
scl_is_...() to translate the raw status data it obtains for a device
into defined states for some or all of the generic status bits. The scaling
services return a bit value that indicates whether the status bit in question
is in an ``ON'' or ``OFF'' state. The four-character text string corresponding
to the present state of the status bit is also returned. If the generic status
bit is not defined for this device, the error code SCL__UDFSTSBIT is returned
in the status argument
.
Typically, the most important status bits of a
device are assigned (in the database) generic status bits. This way, the most
important status information for a device is displayed on the ``page,'' while
the other status bits can always be obtained by hitting PF3 to get to
the ``extended status page
.''
The use of the EPICURELIB scaling services to obtain generic status bit information
makes messing with the status PDB more or less transparent to the application.
Provided that the status bits are defined correctly in the database, an application
need only obtain the raw status data and the PDB, and then call the scaling
service to interpret the data. No bitwise manipulation is needed.
The good, the bad, and the...
PAGE divides the generic status bits into two groups. One group, consisting
of the on, ready, and remote bits, PAGE considers to have
a defined ``good'' state: ``ON,'' and a defined ``bad'' state: ``OFF.''
Table
summarizes how the boolean value returned by the scaling
services is translated by PAGE.
Those bits with a defined ``good'' state are displayed in the following
way by PAGE. If a bit is ON/GOOD, then PAGE displays the text string ``
in the STATUS field. If the bit is OFF/BAD, then PAGE displays the text
of the bit state returned by the scaling services in the STATUS field.
If the bit is undefined, the PAGE displays three blank spaces in that portion
of the STATUS field.
The other two generic status bits, polarity and ramp, PAGE considers
to have no defined ``good'' states. Therefore, PAGE always displays the text of
the states of the polarity and ramp bits if they are defined. If
the bits are undefined, then blank text is displayed, just as for the on,
ready, and remote bits.
Each device has one horizontal line on the screen associated with it in PAGE.
PAGE displays the STATUS field of whatever line the cursor is on in a
special way. All text in the STATUS field is capitalized, and for all five
bits the text of the bit states is displayed, regardless of whether the bits are
ON or OFF. Table
summarizes how PAGE displays generic status bit
information in the STATUS field.
In Table
, the column PAGE Field contains the ordering
of generic status bits as they are displayed in the STATUS field
in the PAGE application. For an example of how status bits are displayed
on an actual ``page,'' refer to Appendix
.
Appendix: two sample ``pages''
The following are two sample ``pages'' with status bits defined.
The status information is displayed in the STATUS field. Notice
that the default text for the generic status bits has been
overridden.
Appendix: sample module template STATUS verb
Module templates for the EPICURE database are stored in
MDT_FILE.TXT] in the EPICURE project area
EPICURE_ROOT:[WORK.DATABASE.FE]. The following
is the STATUS property record from the module template for the RAD (type 116R)
device, along with a sample STSNAMES status bit definition:
STATUS -
/READ_PROTECT=NONE - ! Read protection for devices
/CRATE=0 - ! Stub for device CAMAC crate number
/SLOT=0 - ! Stub for device CAMAC slot number
/CHANNEL=0 - ! Stub for device channel
/NODE=0 - ! Source node
/MAXSIZE=2 - ! Max request data size
/DATA_SIZE=2 - ! Status data size (bytes)
/SS_SUBSYS=3 - ! Subsystem number
/SS_CRATE=0 - ! Subsystem crate number
/SS_DEVICE=0 - ! Subsystem device number
/S_DI_FLAGS=(ON,READY,REMOTE) - ! ON/OFF state inversion flag
/ON_MASK=0x1000 - ! Mask for on/off bit <=======+
/OFF_MASK=0x1000 - ! Mask for on/off bit ||
/RDY_MASK=0x0800 - ! Mask for ready bit BIT
/REM_MASK=0x0100 - ! Mask for remote bit OFFSETS
/POL_MASK=0x2000 - ! Mask for polarity bit (req.)
/RAMP_MASK=0x4000 - ! Mask for ramp/dc bit ||
/DC_MASK=0x4000 - ! Mask for ramp/dc bit <=======+
/1_ON_ON_STATE=" " - ! ON text for on/off bit <-------+
/1_OFF_ON_STATE=TPB - ! OFF text for on/off bit |
/2_ON_READY_STATE=" " - ! ON text for ready bit |
/2_OFF_READY_STATE=TPA - ! OFF text for ready bit OVER-
/3_ON_REMOTE_STATE=" " - ! ON text for remote bit RIDE
/3_OFF_REMOTE_STATE=FAL - ! OFF text for remote bit TEXT
/4_ON_POLARITY_STATE=SCR - ! ON text for polarity bit |
/4_OFF_POLARITY_STATE=CHP - ! OFF text for polarity bit |
/5_ON_RAMP_STATE=BYP - ! ON text for ramp bit |
/5_OFF_RAMP_STATE="..." - ! OFF text for ramp bit <-------+
/ON_A=(GREEN,.) - ! Set color for on/off bit <=======+
/RDY_A=(GREEN,.) - ! Set color for ready bit ||
/REM_A=(GREEN,.) - ! Set color for remote bit ||
/POL_A=(WHITE,*) - ! Set color for polarity bit ||
/RAMP_A=(WHITE,.) - ! Set color for ramp bit COLOR
/N_ON_A=(RED,*) - ! Clear color for on/off bit (Not
/N_RDY_A=(RED,*) - ! Clear color for ready bit supp)
/N_REM_A=(YELLOW,-) - ! Clear color for remote bit (req.)
/N_POL_A=(YELLOW,-) - ! Clear color for polarity bit ||
/N_RAMP_A=(YELLOW,*) - ! Clear color for ramp bit <=======+
/QTI=2 -
/RATE_INDEX=1 -
/SET_DATA_OFFSET=0 -
/ARRAY_OFFSET=0
B_STSNAMES ! Begin list of status bit defs.
STSNAME - ! Begin status bit def. #1
/BITNUMBER=0 - ! Bit offset
/SHORTNAME=LFAIL - ! Short name of status bit
/LONGNAME=LATCHED_FAIL - ! Long name of status bit
/SETTEXT=FAILED - ! Display when bit ON
/CLRTEXT=OK - ! Display when bit OFF
/SETCOLOR=" " - ! Set color (not supp.)
/CLRCOLOR=" " ! Clear color (not supp.)
E_STSNAMES ! End list of status bit defs.
Appendix: distribution and keywords
Keywords:
EPICURE, RDCS, controls, status property, generic status bits, database.
Distribution:
normal.
Security, Privacy, Legal
rwest@fsus04.fnal.gov