Table of Contents
The Postgres[3] database manager is used to construct and maintain the control system database. In addition, it is used to generate the wire lists needed to assemble the CAMAC interfaces.
All of the relevant information needed to build the control system database is entered via SQL[4] into the Postgres database.
After the database is entered into Postgres, each one of the tables needed by the accelerator control system is extracted from the Postgres database via SQL queries. They are then processed by other programs to translate the information into a format used by the runtime system.
This manual gives definitions for the fields in the tables maintained by the Postgres database and how they are related to each other.
A bold field name indicates the primary key. In some cases the table is keyed by more than one field. This is called a composite key. An italicized field name indicates an alternate (candidate) key. An alternate key is a field that can be used to uniquely identify a record (row, tuple) in a table in place of the primary key. This means that it must remain a unique value for each record, just like a primary key.
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.
The button tables (BoxRec and PadRec) have been deprecated and are slated for obsolete status. The original function of these tables was to provide touch screen or other alternative input support.
These tables are used to validate fields of other tables in the database. The following is true unless marked with an asterisk (*). These tables should not be modified by the user. The tables will only change if new functionality is added to AccelNET.
Table of RefName definitions.
The RefName.
An integer value for the RefName. Used to sort Desc records in the Label report.
Comments field.
A more descriptive name.
Table of DataType definitions.
The DataType name.
An integer value for the DataType.
Comments field.
Table of display key (CrtKey) definitions.
The display key name.
An integer value for the display key.
Comments field.
Table of control key (CtlKey) definitions.
The control key name.
An integer value for the control key.
Comments field.
Table of Owner definitions. Owner names correspond to task numbers in the control system.
The owner name.
The task number of the owner.
Comments field.
Database scaling keys.
The scaling key name.
The scaling key value.
Comments field.
Table of device type definitions.
Device type name.
An integer value for the device type.
Comments field.
Table of driver type definitions. The control system is designed in a way that allows data acquisition from more than one type of data acquisition system at the same time. The driver type specifies which data acquisition system to use.
Driver name.
An integer value for the driver type.
Comments field.
The display page database is made up of several record types.
PgKeys contains the master records for a display page. There is one record in PgKeys for each page in the system.
The rest of the records define display entities. There is one record for each entity on the screen. An entity can be an alphanumeric field or an icon.
This table associates a display page name with a page number.
Page name.
Page number.
Display flag. The value of this field is either 'Y' or 'N'. If the value is 'Y', all of the records associated with the page are displayed unless their individual Dflags are set to 'N'. If the value is 'N', the entire page is inhibited from being displayed.
Comments field.
This table defines static text strings in a display page. These strings can be used for comments and other permanent text.
Together PgNme and RecId form the key for this table.
Name of the page.
Validated by PgKeys.PgNme.
A serial number used to identify the record.
X coordinate on display page.
Y coordinate on display page.
Display flag. The value of this field is either 'Y' or 'N'. If the value is 'Y', this record is displayed. If the value is changed while the page is displayed, the field is erased.
Width (in characters) of the string.
Font setting to display the text.
Valid values are: default, big, and user1 through user8.
The string to be displayed.
This table defines database fields for display.
Name of the page.
Validated by PgKeys.PgNme.
Type of field to display.
Validated by DFkeys.DFnme.
A serial number used to identify the record.
X coordinate on display page.
Y coordinate on display page.
Display flag. The value of this field is either 'Y' or 'N'. If the value is 'Y', this record is displayed. If the value is changed while the page is displayed, the field is erased.
Width (in characters) of the string.
Font setting to display the text.
Valid values are: default, big, and user1 through user8.
Name of the parameter to display. If DFnme is set to Label or Name, only the Label must be set. The RefName field may be NULL.
This table defines Display/Control parameter sets for a display page. The first display parameter (DCdisp1_Label, DCdisp1_DrefNme) is the one displayed on the screen at the given coordinates. The DCdisp and DCctl fields work in sets. For example, when a DCpnt is selected on the screen, DCdisp1 will be displayed as the readback parameter and DCctl1 will be displayed as the control parameter. The # in DCdisp# and DCctl# identify the layer number. The first time an item is clicked, the first layer will appear. Subsequent clicks will increment the layer.
Name of the page this record is associated with.
Validated by PgKeys.PgNme.
A serial number used to identify the record.
X coordinate on display page.
Y coordinate on display page.
Display flag. The value of this field is either 'Y' or 'N'. If the value is 'Y', this record is displayed. If the value is changed while the page is displayed, the field is erased. However, the field may still be selected by the mouse until a new page is loaded or the same page is reloaded.
Width (in characters) of the string.
Font setting to display the text.
Valid values are: default, big, and user1 through user8.
First read back parameter.
Second read back parameter.
Third read back parameter.
Fourth read back parameter.
First control parameter.
Second control parameter.
Third control parameter.
Fourth control parameter.
Icon display definition table. ICdisp and ICctl fields are treated in the same way as in the CrtDCpnt table.
Name of the page this record is associated with.
Validated by PgKeys.PgNme.
Type of icon to display.
Validated by IconKeys.IconNme.
A serial number used to identify the record.
Name of the beamline region associated with this record.
Validated by GrpKeys.GrpNme.
X coordinate on display page.
Y coordinate on display page.
Second X coordinate on display page. This field is used to stretch/modify the geometry of the icon. A value of "0" will result in the default geometry for the given plane.
Second Y coordinate on display page. This field is used to stretch/modify the geometry of the icon. A value of "0" will result in the default geometry for the given plane.
Amount (in degrees) to rotate the icon from its base orientation (right hand coordinates). A value of "0" will result in the no rotation.
Amount to scale the icon size. The default (and most common) size is 1.0.
Display flag. If the value is 'Y', this record is displayed. If the value is changed while the page is displayed, the field is erased. However, the field may still be selected by the mouse until a new page is loaded or the same page is reloaded.
Data point from which to get the icon color.
First Display parameter.
Second Display parameter.
Third Display parameter.
Fourth Display parameter.
First Control parameter.
Second Control parameter.
Third Control parameter.
Fourth Control parameter.
Comments field.
These tables are used to validate fields of other tables in the database. These tables should not be modified by the user. The tables will only change if new functionality is added to AccelNET.
This table is used to validate entries in CrtFixed.DFnme.
Display field name.
An integer value for the display field.
Comments field.
See DFkeys(7) in the AccelNET manual pages for a list of valid DFkeys.
Interlocks are used to provide conditional actions on data points. They are usually used to provide software equivalents of hardware interlocks. An example might be to prevent a Faraday cup from moving out of the beamline unless the next beamline valve is open. The beamline valve cannot be opened unless there is good pressure on either side of it. Icon colors are also determined by entries in this table.
Interlocks are defined by first choosing a data point to be acted on. The point chosen is entered into a record in the ChkList table.
An interlock chain is created by defining records in the ChkPoint table. The ChkPoint table defines what data points will affect the action. The way in which the data point is evaluated is determined by the CPtype field.
The ChkAct table looks at the word formed by the entries in ChkPoint to determine what will happen to the data point in ChkList. If the word matches the checked criteria, a new value is returned for the ChkList data point.
The ChkAlarm table is processed in a similar way that ChkAct is processed, but returns an error message to the user, instead of a value to the data point.
This table defines the data point to be acted on. When a request is made to modify a data point listed in this table, the chain is started. A timer is started lasting the timeout value (in seconds) of TMOvalue. If the interlock does not match an entry in ChkAct by the end of the timer, the default value (Value) is entered into the data point.
A serial number used to identify the record.
Data point to be acted on.
Value to write into the data point if there is no match in ChkAct table.
Amount of time to wait before writing the default value.
Comments field.
This table defines the data points from which to collect data for interlock evaluation. The records in this table are used to build an evaluation word. An evaluation word is the composite of each record's result specified for the interlock chain. Each record defines an offset (bit) position in the evaluation word to store the result.
RecId of the Chklist entry that this record is associated with.
Validated by ChkList.RecId.
A serial number used to identify the record.
Data point to obtain information from.
Type of evaluation to be performed.
Validated by CPTkeys.CPTnme.
Offset in the evaluation word to write the evaluation into.
Set lower limit for evaluation in certain values of CPtype.
Set upper limit for evaluation in certain values of CPtype.
Comments field.
The value of the evaluation word is filtered and compared using Mask and Mask2 in this table. The Mask field defines which bits of the evaluation word to look at. The Mask2 is compared to the bits of the evaluation word defined by Mask. If there is a match, Value is written to the data point described in ChkList.DSkey.
RecId of the ChkList entry that this record is associated with.
Validated by ChkList.RecId.
A serial number used to identify the record.
Bits in the evaluation word to be checked. A bitwise 'AND' operation is performed on this field and the evalution word to generate a check word.
Bit pattern to be matched. This is compared to the previously generated check word.
Value written to the data point described in ChkList.DSkey if Mask2 is identical to the check word.
Comments field.
This table contains information needed to select an alarm message if the interlock evaluation fails. The same method of processing Mask and Mask2 in ChkAct is used to process ChkAlarm. Instead of a value being written into the data point, a message is displayed to the user.
RecId of the ChkList entry that this record is associated with.
Validated by ChkList.RecId.
A serial number used to identify the record.
Bits in the evaluation word to be checked. A bitwise 'AND' operation is performed on this field and the evalution word to generate a check word.
Bit pattern to be matched. This is compared to the previously generated check word.
Error message.
The numeric processing system allows simple algebraic manipulation of data points to form a value to be written into a data point. This is used to perform calculations such as total injection voltage.
Just like the interlock tables, the numeric processor works off a chaining system. The data point to be affected is set in the NumList table.
The NumPoint table is used to perform the algebraic operations. The operations are peformed in order based on RecId. NPtype is used to define what algebraic function to perform (e.g. add, subtract, multipy, divide, sin, cos). A chain is started with an initial stored value of 0. The first record usually inserts an initial value using 'load' or 'add' as the NPtype. When a record is processed, the data point specified by NPdskey is multiplied by the Scale field to create the operand. If NPdskey is NULL, the Scale field is used as a constant operand in the calculation. Once the operand is determined, the operation specified by NPtype is evaluated on the stored value and operand. The result is placed in the stored value. This continues until all of the records in the chain have been processed. Once the chain has completed, the resulting stored value is written to the data point specified in NumList.
To facilitate complex algebraic equations, four subtotal values are available. They can be used by appending '_S#' to NPtype, where # is 1 through 4. Once the subtotal has been calculated, it can be evaluated into the main total using 't_add_S#', 't_sub_S#', 't_mul_S#', or 't_div_S#'. When the above evaluations are done with the main total, the subtotal is automatically cleared.
This table defines the data point to be acted on.
A serial number used to identify the record.
Name of the data point to write the result into.
Comments field.
RecId of the NumList entry that this record is associated with.
Validated by NumList.RecId.
A serial number used to identify the record.
Type of algebraic operation to perform on this point and the accumulated value.
Validated by NPTkeys.NPTnme.
Data point to obtain information from. If these values are NULL, the value of 1 is assumed.
Value obtained from the database is multiplied by this before evaluation. A good use of this is to invert the sign of the database value with -1. By using NULL for NPdskey, this field can be used as a constant.
Comments field.
These tables are used to validate fields of other tables in the database. These tables should not be modified by the user. The tables will only change if new functionality is added to AccelNET.
This table is used to validate entries in ChkPoint.CPtype.
ChkPoint type name.
An integer value for the ChkPoint type name.
Comments field.
This table contains the jack number and jack types for every connector in the interfaces. It is used to validate connector number entries in the RPrecord, Zrecord, and Trecord tables and to specify connector type on some of the reports.
The two fields, JackTypA and JackTypB, allow specification of both halves of the connector set.
Name of the connector.
Connector type.
Connector type.
Comments field.
This table specifies a connection for one pair in a device connector on the interface.
Parameter associated with this pair.
Pair number of the parameter.
Jack this connection is located in.
First pin in the pair.
Second pin in the pair.
Color of the first wire in the pair.
Validated by ColKeys.ColNme.
Color of the second wire in the pair.
Validated by ColKeys.ColNme.
Name of the signal associated with the first wire in the pair.
Name of the signal associated with the second wire in the pair.
Bus to connect to in order to obtain power. If no connection is required, use "none" in this field.
Validated by BusKeys.BusNme.
First bus pin.
Second bus pin.
Comments field.
Comments field.
This table is used to define a connection point to a CAMAC module. Connection points to modules are associated with DataRecs.
RecId of the DataRec this record is associated with.
Wire pair number for the RecId.
First pin in the pair.
Second pin in the pair.
Jack this connection is located in.
Comments field.
Comments field.
This table is used to provide connection pairs between any two jacks in the interface without the use of data points.
Typically this is used where connections need to be made between two points in an interface, but there is no entry in the database that corresponds to the signal.
For example:
If there are two interfaces associated with a single CAMAC crate, signals often need to be routed from one interface to the other through the trunk cable. In this case it is used to pass signals on the destination side of the jumper's connection to the device connector.
It is used to make the shield connections for the device cables. In this case the destination connector is a ground block inside the interface and there is only one wire in the pair.
In cases where signals must be passed from connector to another without involving CAMAC. This can happen when hardware interlocks need to be passed between devices.
The fields in the Trecord table are:
Index number used to identify the record.
"Source" jack.
Validated by JackRec.JackNo.
"Destination" jack.
Validated by JackRec.JackNo.
First "source" pin.
Second "source" pin.
First "destination" pin.
Second "destination" pin.
First wire color pin.
Validated by ColKeys.ColNme.
Second wire color pin.
Validated by ColKeys.ColNme.
First signal name.
Second signal name.
"Source" connection first comment field.
"Source" connection second comment field.
"Destination" connection first comment field.
"Destination" connection second comment field.
These tables are used to validate fields of other tables in the database. These tables should not be modified by the user. The tables will only change if new functionality is added to AccelNET.
Wire Color Key table. This table is used to validate wire colors entered into RPrecord and Trecord color fields. The color value may be used to sort by wire color.
Color name.
An integer value for color name.
Comments field.
This is list of valid wire colors that may be entered into the color fields in the RPrecords and Trecord. All of the entries listed appear in the ColKeys table.
Black
Brown
Red
Orange
Yellow
Green
Blue
Violet
Gray
White
None
Shield
The CAMAC interface usually contains one or more power buses. They are used to provide power to drive relays and other such devices. Sometimes the bus is switched to provide interlocking functions. For example, in some machines the tank pressure switch controls power to a bus in the interface. The power from the switched bus is connected to the rotating shaft, gvm power status control, etc. If the tank is under vacuum, power is not applied to the bus. Even if the control system may have told the device to be on, it won't be. The BusKeys table allows the buses to be given names and incorporated in the wire lists.
This table is slated for deprecation/obsolete status and will be replaced by JackRec, but is still in active use.
Bus Name.
An integer value for the bus name. This field is provided in order to allow an arbitrary sort by bus.
Comments field.
This is a list of common entries for RPrecord.Buss. All of the entries listed should appear in the BusKeys table.
No bus connection.
Camac 24v pwr supply.
Interlock Bus 1.
Interlock Bus 2.
dbreport <report_type> <report_arg>
List the interlock records.
List the CAMAC modules.
List records of <arg> Key table. (e.g. RefKeys)
List records of <arg> Message table. (e.g. MsgTbl)
List major database fields, sorted by Label, Desc.
List records of the DataRec table sorted by RecId.
List records of the DataRec table sorted by Module Address.
List the database scaling coefficients.
List the database spans and limits.
List records of the JackRec table.
List records of the RPrecord table.
List records of the Zrecord table.
List valid values of <arg> for generating wiring reports. These values are contract dependent.
Example: 'C1I1' means Crate 1, Interface 1.
Generate Buss connection list.
Generate Buss2 connection list.
Generate rear panel to Z pin wiring list.
Generate Z pin to rear panel wiring list.
Generate a composite of Buss, Buss2, Rpanel, and Zpanel wiring lists.
Most reports generate a file with a name of the form <report_type>.lst where <report_type> is the argument to dbreport.
All reports are stored in $LST, which can be expanded to /AccelNET/pg/$CONF/lst/.
For example "Label.lst" is the report file from "dbreport Label".
The report may be printed by using the command "lp <arg>" where <arg> is the name of the report file.
The Label report shows an overview the database. The report is sectioned by LabelRec entries and detailed by RefName.
Device name (LabelRec.Label).
Long device name (LabelRec.Name).
Comments (LabelRec.Lcomm).
Integer value associated with the RefName (RefKeys.RefVal).
Parameter name (DescRec.RefName).
Long parameter name (RefKeys.RefAttNme).
Physical units (DescRec.Units).
Data conversion key (DescRec.DataType).
Display format key (DescRec.CrtKey).
Device control key (DescRec.CltKey).
Name of the task that owns the record (DescRec.Owner).
Parameter scaling key (DescRec.ScaKey).
Write permissions (DescRec.WpermD).
Name of the Message List if DataType=Ldisp (MsgKeys.MsgNme).
Physical value that corresponds to the minimum binary value of the data point (DescRec.SpanMin).
Physical value that corresponds to the maximum binary value of the data point (DescRec.SpanMax).
Minimum physical value for write limit or read back limit checking (DescRec.PhyMin).
Maximum physical value for write limit or read back limit checking (DescRec.PhyMax).
Size of the binary data field (DescRec.Size).
Offset into the data word from which to extract the binary data (DescRec.Offset).
DRkey value (DescRec.DRkey).
RecId of DataRec associated with this parameter (DescRec.Addr/DataRec.RecId).
Device type (DataRec.DevType).
Data acquisition driver name (DataRec.Driver).
CAMAC crate number (DataRec.Crate).
CAMAC slot number (DataRec.Slot).
Module channel number (DataRec.ChanNo).
DTkey value (DataRec.DTkey).
Comments (DescRec.Comments).
The RecId and Module reports are the same information sorted two different ways. The RecId report is sorted by DataRec.RecId in ascending order. The Module report is sorted by Driver, C, N, DevType, ChNo in ascending order.
Both forms of the report are a cross reference listing showing which parameters (DescRecs) in the database are associated with data acquisition channels.
RecId (DescRec.Addr/DataRec.RecId).
DTkey value (DataRec.DTkey).
Data acquisition driver name (DataRec.Driver).
CAMAC crate number (DataRec.Crate).
CAMAC slot number (DataRec.Slot).
Module channel number (DataRec.ChanNo).
Size of the binary data field (DescRec.Size).
Offset into the data word from which to extract the binary data (DescRec.Offset).
Device type (DataRec.DevType).
Label of the parameter (DescRec.Label).
RefName of the parameter (DescRec.RefName).
Long name associated with the RefName (RefKeys.RefAttNme).
This is a listing of all of the jack numbers in the system.
Jack number (JackRec.JackNo).
Jack type for end A (JackRec.JackTypA).
Jack type for end B (JackRec.JackTypB).
This is a listing of all of the records in the RPrecord table organized by jack number and pair number.
Jack number (JackRec.JackNo).
Pair number in the jack.
For each record there are two possible pin numbers listed, one above the other. The top one is the first pin in the pair (RPrecord.PinA). The bottom one is the second pin in the pair (RPrecord.PinB).
For each record there are two possible colors listed, one above the other. The top one is the first color in the pair (RPrecord.ColorA). The bottom one is the second color in the pair (RPrecord.ColorB).
For each record there are two possible signal names listed, one above the other. The top one is the first signal name in the pair (RPrecord.SigNameA). The bottom one is the second signal name in the pair (RPrecord.SigNameB).
First side of the buss connection, if needed (RPrecord.BussP1).
Name of the bus this signal is passed through, if needed (RPrecord.Buss).
Second side of the buss connetion, if needed (RPrecord.BussP2).
Name of the parameter this connection is associated with (DescRec.Label, DescRec.RefName).
Comments (RPrecord.Comments1/RPrecord.Comments2).
This is a listing of all of the records in the Zrecord table organized by RecId and pair number.
RecId of the DataRec this record is associated with (Zrecord.ZRecId).
DTkey value (DataRec.DTkey).
Data acquisition driver name (DataRec.Driver).
CAMAC crate number (DescRec.Crate).
CAMAC slot number (DataRec.Slot).
Module channel number (DataRec.ChNo).
Device Type (DataRec.DevType).
Jack number (Zrecord.Zjack).
Pair number of the RecId (Zrecord.Zpair).
For each record there are two possible pin numbers listed, one above the other. The top one is the first pin in the pair (Zrecord.PinA). The bottom one is the second pin in the pair (Zrecord.PinB).
Comments (Zrecord.Comments1, Zrecord.Comments2).
This is a listing of all of the connections in the interfaces organized from the device connectors to the Z connectors or other device connectors. This report is customized for each contract.
If a connection is made from one rear panel connector to another (one use of the Trecord), the connection will appear twice in the listing. Once from the first connector, again from the second connector.
At the start of each new connector, the page is ejected and the jack number and jack type are printed.
If the record being listed is a RPrecord, the parameter name from the database is listed on the first line of the signal pair (DescRec.Label, DescRec.RefName).
If the record being listed is a Trecord, the Comments1 and Comments2 fields are listed on the first line and the Comments3 and Comments4 fields are listed on the second line.
For each record there are two possible signal names listed, one above the other. The top one is the first signal name in the pair based on the type of record (RPrecord.SigNameA or Trecord.SigNameA). The bottom one is the second signal name in the pair based on the type of record (RPrecord.SigNameB or Trecord.SigNameB).
For each record there are two possible pin numbers listed, one above the other. The top one is the first pin in the pair based on the type of record (RPrecord.PinA, Trecord.PinA1, or Trecord.PinB1). The bottom one is the second pin in the pair based on the type of record (RPrecord.PinB, Trecord.PinA2, or Trecord.PinB2).
For each record there are two possible colors listed, one above the other. The top one is the first color in the pair based on the type of record (RPrecord.ColorA or Trecord.ColorA). The bottom one is the second color in the pair based on the type of record (RPrecord.ColorB or Trecord.ColorB).
First bus pin, if used (RPrecord.BussP1).
Bus the pair is routed through, if used (RPrecord.Buss).
Second bus pin, if used (RPrecord.BussP2).
Jack number of the connector this pair is connected to (Zrecord.Zjack).
For each record there are two possible pin numbers listed, one above the other. The top one is the first pin in the pair based on the type of record (Zrecord.PinA, Trecord.PinA1 or Trecord.PinB1). The bottom one is the second pin in the pair based on the type of record (Zrecord.PinB, Trecord.PinA2, or Trecord.PinB2).
RecId of the DataRec this entry is associated with (DataRec.RecId).
CAMAC crate number (DataRec.Crate).
CAMAC slot number (DataRec.Slot).
Module channel number (DataRec.ChNo).
Offset into the data word from which to extract the binary data (DescRec.Offset).
For each record there are two comments listed, one above the other. The top one is the first comment field, depending on the type of record (RPrecord.Comments1 or Trecord.Comments3). The bottom one is the second comment field, depending on the type of record (RPrecord.Comments2 or Trecord.Comments4).
This listing is similar the Rpanel report except that it is from the Z connector point of view. This report is customized for each contract.
Jack number of the Z connector this pair is connected to (Zrecord.Zjack).
There are two possible pin numbers listed for each record, one above the other. The top one is the first pin in the pair (Zrecord.PinA). The bottom one is the second pin in the pair (Zrecord.PinB).
There are two possible colors listed for each record, one above the other. The top one is the first color in the pair (RPrecord.ColorA). The bottom one is the second color in the pair (RPrecord.ColorB).
First bus pin, if used (RPrecord.BussP1).
Bus the pair is routed through, if used (RPrecord.Buss).
Second bus pin, if used (RPrecord.BussP2).
Jack number of the connector this pair is connected to (RPrecord.RPjack).
There are two possible pin numbers listed for each record, one above the other. The top one is the first pin in the pair (RPrecord.PinA, Trecord.PinA1, or Trecord.PinB1). The bottom one is the second pin in the pair (RPrecord.PinB, Trecord.PinA2, or Trecord.PinB2).
If the record being listed is a RPrecord, the parameter name from the database is listed on the first line of the signal pair (DescRec.Label, DescRec.RefName).
If the record being listed is a Trecord, the Comments1 and Comments2 fields are listed on the first line and the Comments3 and Comments4 fields are listed on the second line.
There are two possible signal names listed for each record, one above the other. The top one is the first signal name in the pair based on the type of record (RPrecord.SigNameA or Trecord.SigNameA). The bottom one is the second signal name in the pair based on the type of record (RPrecord.SigNameB or Trecord.SigNameB).
RecId of the DataRec this entry is associated with if it is a RPrecord (DataRec.RecId).
Pair number of the Zrecord associated with this entry if it is a RPrecord (Zrecord.Zpair).
CAMAC crate number (DataRec.Crate).
CAMAC slot number (DataRec.Slot).
Module channel number (DataRec.ChNo).
Offset into the data word from which to extract the binary data (DescRec.Offset).
If the record being processed is a RPrecord, then RPrecord.Comments1 and RPrecord.Comments2 are used. Otherwise Zrecord.Comments3 and Zrecord.Comments4 are used.
After the database is entered, the data conversion coefficients for all of the data points must be calculated. This is done by invoking the BuildMB family of programs.
The buildmb script should be run after the initial creation of a new database, as well as when one of the following has been changed in the DescRec table: SpanMin, SpanMax, DataType, Size, DRkey, MBconvKey, or MBsetIncKey. If MBconvKey is not set to 'Y', buildmb will ignore the record when calculating M and B. If MBsetIncKey is not set to 'Y', buildmb will ignore the record when calculating IncVal.
Invoke a buildmb function by typing the following (as user 'postgres'):
buildmb <arg>
Build coefficients for records with DataType = 'Lin'.
Build coefficients for records with DataType = 'NLin'.
Build coefficients for records with DataType = 'Alog'.
Build coefficients for records with DataType = 'NAlog'.
Build coefficients for records with DataType = 'CVG'.
Build coefficients for records with DataType = 'CVG_275'.
Build coefficients for records with DataType = 'CCVG'.
Build coefficients for records with DataType = 'PVG'.
Build coefficients for records with DataType = 'TCG'.
Build coefficients for records with DataType = 'IGCgp'.
Set IncVals for records with DataType = 'Lin'. See rules below.
Set IncVals for records with DataType = 'NLin'. See rules below.
Invokes all of the arguments.
Here is a list that explains, by DataType, how buildmb treats a record.
Constructs coefficients for all cases. IncVal is set to the value of M for records where DataType = 'Lin' and Owner = 'CrtTsk'.
Constructs coefficients for all cases. IncVal is set to the value of M for records where DataType = 'NLin' and Owner = 'CrtTsk'.
Constructs coefficients for all cases. IncVal is not set.
Constructs coefficients for all cases. IncVal is not set.
Not supported. When used, coefficients should be entered manually, usually with M = 1.0 and B = 0.0.
Sets M and B to the correct values to provide a scaler between 0 and 10 for the conversion routine. IncVal is not set.
Sets M and B to the correct values to provide a scaler between 0 and 10 for the conversion routine. IncVal is not set.
Sets M and B to the correct values to provide a scaler between 0 and 10 for the conversion routine. IncVal is not set.
Sets M and B to the correct values to provide a scaler between 0 and 10 for the conversion routine. IncVal is not set.
Sets M and B to the correct values to provide a scaler between 0 and 10 for the conversion routine. IncVal is not set.
Not supported. When used, coefficients should be entered manually, usually with M = 1.0 and B = 0.0.
Not supported. When used, coefficients should be entered manually, usually with M = 1.0 and B = 0.0.
Sets M and B to the correct values to provide a scaler between -10 and 0 for the conversion routine. IncVal is not set.
Constructs coefficients for all cases. IncVal is not set.
Constructs coefficients for all cases. IncVal is not set.
DataTypes marked with an * are handled by the runtime system in the following way: When the data(X) is processed, M and B are applied to scale the value between the desired range (Y = MX + B). The scaled value is then sent to what is called a piece table. A piece table is a predefined set of steps/ranges. Each range contains an internal set of M and B values. The internal set of M and B are applied using the same equation to the scaled value to obtain the final physical value.
The database must be converted to the correct format before it can be used by the control system. The format conversion is done by a family of programs that all have roughly the same structure.
The table to be converted is extracted from the Postgres database by a SQL query and placed in a file. When the table is extracted, a filter is applied to substitute integer values for names on certain fields. For example, in the DescRec table, the name in the DataType field is substituted for the integer value known by the runtime system. In the above example, the Dkeys table is considered an immutable table. This means that it cannot/should not be changed. The table is in place to prevent bad entries in database. The actual integer values are defined in the filter/AccelNET source code. The Dkeys table will only be changed when there is a change in AccelNET that affects it. The result of this is an ASCII file where each line contains a number of fields separated by a field separator (usually a vertical bar '|') and terminated by a linefeed.
A program then translates the created file into the record structure used by the control system. This process involves steps such as converting strings of characters into floating point numbers. The program that does the translation is specifically tailored for the table in question, producing a new result file.
It is presently arranged so that the extracted Postgres tables occupy a directory. The SQL scripts share the directory with the extracted files along with a shell script that is used to translate the tables.
The table translation programs, invoked from a shell script, are in a separate directory. They read from the directory containing the extracted files and write into another directory.
As you become familiar with the fields of the database and how to manipulate them through the data entry screens you may want to learn to use the tools the Postgres database manager provides for manipulation of the database.
SQL is a programming language that allows records to be added, deleted, and modified to/from the database. It makes adding large quantities of records (for example, if a new beam line is added to the system) very easy to do. Consult the Postgres manuals for more information.
All of the reports described in this manual are generated using SQL, some of the UNIX tools, and a report written in C. Examine the report scripts provided with the system for examples.
For more information on SQL, visit http://www.postgres.org/docs/ as well as other online or printed documentation.
To help facilitate construction and maintenance of the database a collection of tools have evolved over time. This collection is not guaranteed to be complete. It is provided as a convenience to the customer.
Using the tools requires a working knowledge of the database design, SQL, and the UNIX shell. There are many existing script files to serve as examples.