Table of Contents

Name

libmngr - configuration table manipulation

Description

libmngr is a collection of functions for managing a configuration table used by a program to map internal variables to parameters in an AccelNET database.

The problem arises when writing an AccelNET program that parameters in the AccelNET database need to be accessed without hardcoding the Label and RefName values within the program.

libmngr solves this problem by allowing the program using the facility to "look up" parameter names in a configuration table. Entries in the configuration file consist of a three fields to key the entry followed by the Label and RefName of the AccelNET parameter of interest.

A value field is provided which the program may use for any purpose. For example, an application may want use the value for comparison with the database value before performing an operation.

A user data pointer is also provided. This pointer may be used for any purpose within an application.

Configuration File Format

Entries in the configuration file consist of seven fields. The fields are program name, group, function, index, label, refname and value.

Each line in the file is one entry. Entries are terminated with a linefeed. Comments may be placed in the file by using a # at the beginning of a line. Comments end at the end of the line.

The program name, group, function and index fields key an individual entry in the file.

program name

The name of the program using the entry. The configuration file may be shared between multiple programs. When the configuration file is processed entries which match program name are loaded into the CONFLIST for use.

BldConfTbl(3mngr) is used to load configuration file into memory.

BldConfTbl(3mngr) ’s PN argument corresponds to the program name in the configuration file. Records are loaded when there is a match between these two items.

Most of the time argv[0] is used for the PN argument. This makes it possible for AccelNET programs to share the configuration file. Many programs such as McSNICSmngr(8) , FSmngr(8) , and ENERGYmngr(8) do this.

Other programs such as PHItask(8) , and TMGtask(8) supply an argument on the command line which is used for the PN argument. This makes it possible for multiple invocations of the same program to share the configuration file.

group

Parameters within the configuration table may be placed within groups. This helps associate parameters together for control.

For example, DSmngr(8) treats all of the controls for a double slit as one group. Different double slit assemblies are given different group numbers. When a new value is entered for a slit position DSmngr looks for the PosSC within the same group as the DC in order to start the slit moving.

See the section Group field details for more information.

function

Parameters within a group are assigned a function code. Function names and codes are divided into groups with certain function names intended to be used for certain purposes. Remember, this is only a guideline, the writer of the program must decide what associations to use.

See the section Function field details for more information.

index

Sometimes it is convenient to be able to associate more than one entry with a particular group and function.

For example, BPMserv does this because more than one datapoint may need to be activated to complete the path between the bpm preamplifier and the display on the control console.

Group field details

Valid values for use with the group field are given below.

The symbol CFGnil is reserved for internal use by the libmngr package. It is used to represent items for which a group has not yet been assigned, i.e. unused entries in the table.

When the CONFLIST table is initialized by InitConfList(3) the group field in all of the entries are assigned the value CFGnil. CFGnil is replaced with the value from the configuration file as entries are added to the table.

file conf.h description
------ ------ ----------------
CFGnil not assigned

g1 CFG1 group 1
g2 CFG2 group 2
g3 CFG3 group 3
g4 CFG4 group 4
g5 CFG5 group 5
g6 CFG6 group 6
g7 CFG7 group 7
g8 CFG8 group 8
g9 CFG9 group 9
g10 CFG10 group 10
g11 CFG11 group 11
g12 CFG12 group 12
g13 CFG13 group 13
g14 CFG14 group 14
g15 CFG15 group 15
g16 CFG16 group 16
g17 CFG17 group 17
g18 CFG18 group 18
g19 CFG19 group 19
g20 CFG20 group 20
g21 CFG21 group 21
g22 CFG22 group 22
g23 CFG23 group 23
g24 CFG24 group 24
g25 CFG25 group 25
g26 CFG26 group 26
g27 CFG27 group 27
g28 CFG28 group 28
g29 CFG29 group 29
g30 CFG30 group 30

Function field details

Valid values for use with the function field are given below.

The symbol CFnil is reserved for internal use by the libmngr package. It is used to represent items for which a function has not yet been assigned, i.e. unused entries in the table.

When the CONFLIST table is initialized by InitConfList(3mngr) the group field in all of the entries are assigned the value CFnil. CFnil is replaced with the value from the configuration file as entries are added to the table.

file conf.h description
------ ------ ----------------
CFnil used internally by libmngr

command variables

This section describes function names which are used as command variables. Usually these are inputs to a program and are not associated with hardware.

For example, BMmngr(8) has the parameter MfieldC which is used to set the field strength.

file conf.h description
------ ------- ----------------
comm1 CFcomm1
comm2 CFcomm2
comm3 CFcomm3
comm4 CFcomm4
comm5 CFcomm5
comm6 CFcomm6
comm7 CFcomm7
comm8 CFcomm8
comm9 CFcomm9

response variables

This section describes function names which are used as response variables. Usually these are outputs from a program and are not associated with hardware.

For example, BMmngr(8) has the parameter TuneSR which is used to indicate that magnet tuning is in progress i.e. BMmngr is busy.

file conf.h description
------ ------- ----------------
resp1 CFresp1
resp2 CFresp2
resp3 CFresp3
resp4 CFresp4
resp5 CFresp5
resp6 CFresp6
resp7 CFresp7
resp8 CFresp8
resp9 CFresp9

control variables

This section describes function names which are used as control variables. Usually these are outputs associated with hardware.

For example, BMmngr(8) has the parameter CC which is the current control for the magnet power supply.

file conf.h description
------ ------ ----------------
ctl1 CFctl1
ctl2 CFctl2
ctl3 CFctl3
ctl4 CFctl4
ctl5 CFctl5
ctl6 CFctl6
ctl7 CFctl7
ctl8 CFctl8
ctl9 CFctl9

readback variables

This section describes function names which are used as readback variables. Usually these are outputs associated with hardware.

For example, BMmngr(8) may have the parameter PolSR which a readback of the position of a polarity switch in the magnet power supply.

file conf.h description
------ ------ ----------------
read1 CFread1
read2 CFread2
read3 CFread3
read4 CFread4
read5 CFread5
read6 CFread6
read7 CFread7
read8 CFread8
read9 CFread9

filename variables

This section describes function names which are used as filename variables. In some applications there is a need to associate a file with a controlled device.

For example, BMmngr(8) needs to associate a lookup table of currents and field strengths with each magnet. The lookup tables are all kept in the same directory so BMmngr is given the pathname to the directory on the command line when the program is started. The configuration file provides a name for an individual file within the directory. Note that an alternative to this might be to use libconfig(3cf) and have a separate configuration file for the table names.

When an entry of this type is parsed by BldConfTbl(3mngr) the Label field and the RefName field are both available for use. By convention usually the Label field is used.

file conf.h description
------ ------- ----------------
file1 CFfile1
file2 CFfile2
file3 CFfile3
file4 CFfile4
file5 CFfile5
file6 CFfile6
file7 CFfile7
file8 CFfile8
file9 CFfile9

integer variables

Sometimes it is convenient to keep local variables (variables not in the AccelNET database) in the configuration table.

For example BMmngr needs to keep a timer for each magnet to tell it when to advance to the next step of the magnet tuning process. This timer can be kept in the CONFLIST database. The variables allocated in this way may come from the configuration file or may be created within the program using libmngr by using AddConfEntry(3mngr) .

A possible alternative to this approach is to use the UserData pointer and allocate space for the variable.

When an entry of this type is parsed by BldConfTbl(3mngr) the Label field and the RefName field are both processed. LabelPnt and DescPnt are set as usual if the Mode arg to BldConfTbl(3mngr) is set to BM_MODE_lcl.

file conf.h description
------ ------- ----------------
int0 CFint0
int1 CFint1
int2 CFint2
int3 CFint3
int4 CFint4
int5 CFint5
int6 CFint6
int7 CFint7
int8 CFint8
int9 CFint9
int10 CFint10
int11 CFint11
int12 CFint12
int13 CFint13
int14 CFint14
int15 CFint15
int16 CFint16
int17 CFint17
int18 CFint18
int19 CFint19

constant value variables

Sometimes it is convenient to be able to specify coefficents to be used by a program.

For example MFCmngr(8) needs to know how much distance to maintain between two movable Faraday cups.

When an entry of this type is parsed by BldConfTbl(3mngr) the contents of the Label field are turned into a floating point number and placed in the Current field, RefName is ignored and Preset is filled in if present.

Usage of the const entries in this manner has been deprecated as of 2-14-2003.

The behavior for const entries has been changed and now the behavior is that the Label field is filled with whatever is in the Label field in the input file.

If the value is not set to "NULL" it is assumed to be a number and the value is placed in the Current field and BldConfTbl(3mngr) prints a warning to stderr.

Otherwise the Preset field is copied to the Current field.

The RefName field is ignored but should be set to "NULL".

The attempt here is to make the library behave as it did before it was changed so that existing software will not break.

Even though this works existing programs should have the MNGRconf file changed so the value is in the Preset field as the opportunity arises.

The use of const entries in new programs is very strongly discouraged. Use int entries instead.

file conf.h description
------ -------- ----------------
const0 CFconst0
const1 CFconst1
const2 CFconst2
const3 CFconst3
const4 CFconst4
const5 CFconst5
const6 CFconst6
const7 CFconst7
const8 CFconst8
const9 CFconst9
const10 CFconst10
const11 CFconst11
const12 CFconst12
const13 CFconst13
const14 CFconst14
const15 CFconst15
const16 CFconst16
const17 CFconst17
const18 CFconst18
const19 CFconst19

Structures

This is the data structure used by mngrlib. An array of these structures should be created and initialized by the program using libmngr. allocCONFLIST(3mngr) is used to allocate space for the array. InitConfList(3mngr) is used to initialize the array.

typedef struct ConfList {
   int Group;

   int Function;

   int Index;

   char Label[LabelSize];

   char RefName[RefSize];

   LABEL *LabelPnt;

   DESC *DescPnt;

   double Preset;

   double Current;

   double Prev;

   unsigned int Status;

   void *UserData;

   } CONFLIST;

Functions

See necmngril.h for a list of the functions contained in the library. See the manual page for each function for a description and argument usage.

See Also

AddConfEntry(3mngr) , BldConfFunc(3mngr) , BldConfGroup(3mngr) , BldConfTbl(3mngr) , BusyWait(3mngr) , CountConfTbl(3mngr) , FindConfFunc(3mngr) , FindConfMatch(3mngr) , FindNextConfMatch(3mngr) , GetCtlReadVals(3mngr) , GetCtlReadValsAll(3mngr) , InitConfList(3mngr) , MatchCtlReadVals(3mngr) , PostIlisten(3mngr) , PostListen(3mngr) , PostListenAll(3mngr) , PrintConfTbl(3mngr) , ReqCtlReadVals(3mngr) , ReqCtlReadValsAll(3mngr) , ValueWait(3mngr) , allocCONFLIST(3mngr) , rmt_FindConfMatch(3mngr) , rmt_FindNextConfMatch(3mngr) , rmt_GetCtlReadVals(3mngr) , rmt_PostListen(3mngr) , rmt_PostListenAll(3mngr) , rmt_ReqCtlReadVals(3mngr) , rmt_ReqCtlReadValsAll(3mngr) , rmt_UnPostListen(3mngr) ,

Notes

This facility has grown over time and new functionality has been added as the need arises. Therefore, not all of the programs using this facility behave according to the descriptions given here.

There are functions contained in this library which should be renamed to make them consistent.

There are functions for local mode which are missing counterparts for remote mode and vice versa.

Despite the length of this manual page libmngr is still underdocumented....

If I were to ever rewrite this thing I would get rid of the use of an array (of CONFLIST records). Most of the time when I’ve used arrays for things like this they have been annoying and eventually have been eliminated, in fact it’s annoying here but it’s been tolerable enough to survive so far, however, maybe this library will get it’s turn someday.... rlk 3/5/2002

Manual page revision

$Id: libmngr.3,v 1.8 2006/04/27 19:19:25 kitchen Exp $


Table of Contents