The LabelRec, DescRec and DataRec tables all work together to provide a definition of the data points in the control system.
More information concerning the use of the Label and RefName fields can be obtained in the operators manual in the section titled "Organization of machine parameters in the Control System Database".
The LabelRec table defines a list of valid device names.
Identifier for the device/group. (e.g. FC 01-1)
String describing the device. (e.g. Faraday Cup)
Comments field.
Not in use. The intention was to associate a part number for a controller with a label and print the information on the wire lists.
This table provides a view of individual parameters for a device. The bit field to be viewed comes from the DataRec table.
The current binary parameter values are located in DataRec.DataVal. A record in this table allows the word and the bit field within the word to be located, masked and right justified. Other fields determine how the value obtained is converted to a physical value and formatted for display.
A parameter value is extracted from the runtime database using DataCvt(). The scaled value is checked against the limit fields (PhyMin and PhyMax) and is returned along with an error code that indicates whether the value is within limits.
If the parameter is used for control, a field specifies the method for control input. See the section titled "CtKeys" for more information. A check is made to see if the writer is attempting to write a value within acceptable limits and if the writer has permission to write into the database through this record.
First half of the tag name. (e.g. FC 01-1)
Validated by LabelRec.Label.
Second half of the tag name. (e.g. PosSC)
Validated by RefKeys.RefName.
Specifies a logical (symbolic) link to another Label.
Specifies a logical (symbolic) link to another RefName. Causes the rest of the fields to be ignored and the fields of the linked Label/RefName pair to be used. It is highly recommended that all of the ignored fields be set to the equivalent of nil or 0. This is due to a possible future overriding capability. Using the same power supply for two pieces of equipment might be an example use for this. (e.g. EQ TX-1 PwrSC might link to CPS TX-1 PwrSC)
An eight char field containing the physical units string. (e.g. KV, V, A, G, or T)
Data conversion key.
Validated by Dkeys.DtNme.
See the section titled "DataTypes."
Display format key.
Validated by CrKeys.CrNme.
See the section titled "CrtKeys."
Modify control format key. Determines how a mouse, keyboard, or other input device affects a parameter.
Validated by CtKeys.CtNme.
See the section titled "CtlKeys."
Name of the task that owns the record.
Validated by OwnKeys.OwnNme.
See the section titled "OwnKeys."
Write permissions.
See the section titled "Write Permissions."
Database scaling key. Used by the auto-scaling program(s).
Validated by ScaKeys.ScaNme.
See the section titled "ScaKey."
When the value of DataType field is Ldisp this field specifies a message table.
Validated by checking MsgKeys.MsgNme.
See the section titled "MsgKeys."
The minimum physical(hardware) value of the parameter. This is used to calculate M and B.
See the section titled "BuildMB."
The maximum physical(hardware) value of the parameter. This is used to calculate M and B.
See the section titled "BuildMB."
The minimum virtual(software) value of the parameter. Used in the runtime database to determine if an attempted write or read is within bounds.
The maximum virtual(software) value of the parameter. Used in the runtime database to determine if an attempted write or read is within bounds.
Used in most CtlKeys to determine step(increment) size of a change. In most cases this value is created automatically by the BuildMB process.
See the section titled "BuildMB."
Conversion coefficient 1. In most cases this value is created automatically by the BuildMB process.
See the section titled "BuildMB."
Conversion coefficient 2. In most cases this value is created automatically by the BuildMB process.
See the section titled "BuildMB."
Used to determine how to treat the extracted binary field.
See the section titled "DRkey Usage."
Size of the extracted binary field in bits.
Offset into the binary word from which to extract the binary field.
RecId of the corresponding binary field in the DataRec table.
Validated by DataRec.RecId.
Comments field.
Enables automatic calculation of the M and B values.
Enables automatic calculation of the SetInc value.
See write_perm(7) in the AccelNET manual pages for an explanation of the write permissions.
The DRkey is a one character field that specifies how to interpret the extracted binary field.
The values of the field and their meanings are as follows:
Treat the extracted field as an unsigned number.
Treat the extracted field as a signed number. The minimum value of the integer is -(2^(size-1)). The maximum value of the integer is 2^(size-1)-1. For example, if size = 12 the integer has a range of -2048 to 2047.
Treat the extracted field as in 'I.' Negative values are treated as zero.
Treat the extracted field as in 'I.' Positive values are treated as zero.
SpanMin and SpanMax are used to calculate the values of the data conversion coefficients M and B. SpanMin is the physical value that corresponds to the minimum binary value of the data point. SpanMax corresponds to the maximum binary value. DescRec.DataType, DescRec.Size, DescRec.DRkey and DataRec.DTkey all play a role in the process.
Calculation of the coefficients is carried out by a family of programs that traverse the database and calculate the values for all of the records at one time. Each member of the program family is responsible for handling one value of DataType. Not all of the possible values of DataType are supported. See the section titled "BuildMB" for more information.
The message tables are used in conjunction with the Ldisp datatype. A message is provided in a table for each possible value of the data point. The value of the data point and the message type are used as an index into the table.
The runtime data conversion and formatting process is split into two pieces. The first part is concerned with obtaining the physical value of the data point. The second part is the display formatting.
The goal of the Postgres implementation is to allow the collection of information needed to create and maintain the message tables. This has been done by creating two tables (MsgKeys and MsgTbl) for message table management. These tables also exist in the runtime system.
The DescRec table contains a field (Message) that associates a message list with it. The field is used only with DescRecs that have DataType = Ldisp. DescRecs with other DataType values have "NullMsg" entered into the Message field as a place holder.
The messages to be displayed are entered in the MsgTbl. There should be an entry for each possible value of the data point even if not all values are expected to occur. This is done to prevent any unexpected behavior. Each entry in the table must have a unique value of MsgVal for a given MGown (Postgres enforces this).
During runtime, the Message field from the DescRec table is used as MsgNme/MGown. A value is extracted from the DataRec table using information stored in the DescRec entry. The resulting value is checked against PhyMin and PhyMax and becomes MsgVal. A list of messages is traversed looking for a matching MGown/MsgVal pair to determine which message to use (MsgText). If no match is found, '*overrange*' is used.
The DataVal field from the DataRec table is used as MsgVal to retreive the particular message (MsgText) from the MsgTbl referenced by MGown and MsgVal.
The MsgKeys table allows each message list to be given a name by which it is referred to in the DescRec.Message field. (e.g. "PwrMsgSC", "PwrMsgSR")
It is necessary for the value of CrtKey to be 'Lmsg' to display the messages.
This table defines a message list and its size.
Name of the message list.
Number of messages in the list.
Comments field.
The DataRec table defines a record where data is stored. Usually this record is associated with the data acquisition hardware, however, this is not always the case. There are quite a few places in the control system where information is acquired, rescaled, or otherwise processed to obtain new results. Total beam energy calculation or magnet field strength deviation might be examples of this.
There are also many places where a number is read into the system and never written out to any hardware. Examples might be charge state, desired magnet field strength, or desired particle mass.
A serial number used to identify the record.
Used by the I/O software to determine the type of hardware I/O transactions to perform in order to obtain data from (or write to) the device.
Validated by DevKeys.DevTypeK.
See the section titled "DevType."
Data acquisition group.
Validated by DrvKeys.DrvNme.
First part of the hardware address. In CAMAC this is the crate number that is set on the actual crate. This value is also used for grouping/sorting of reports.
Second part of the hardware address. In CAMAC this is the slot number. This value is also used for grouping/sorting of reports.
Third part of the hardware address. In a CAMAC A/D converter this is the channel number. The software that builds the I/O transactions for a module interprets this for a given device. This value is also used for grouping/sorting of reports.
Number of bits to mask off for dither reduction. Used by the analog read service.
Format of the DataVal, PrevVal and SaveVal fields. 'I' is an integer field, 'F' is a floating point field.
Present/current value.
Previous/last value.
Value saved by operator command.
Comments field.