<P> EPICURE Software Release Note 69.0<P> <b> Generic Status Bit Definitions</b>


Purpose of this document

This document examines generic status bits as they appear in the EPICURE data aquisition and control system from three perspectives: 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.


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:

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:

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

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:

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:

Bit offset for each generic status bit defined. (required)
Set and clear colors. The present system does not support colors, but they are required for each defined generic status bit (required)
Override text for on and off states (optional)
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:

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



Security, Privacy, Legal