NARA 5SDH-2
NARA 5SDH-2
Timers are created in the AccelNET database with a Lin datatype. The variable is usually displayed with a Thms or Tdhms display key.
TIMEmngr can increment or decrement the datapoint according to instructions in the configuration table. Increment or decrement can be gated on/off and the datapoint may be reset by either writing a new value into the datapoint or by using a reset input.
If the counter is in down count mode terminal count is taken from the resp1 variable’s DESC.PhyMin value. If the counter is in up count mode terminal count is taken from the resp1 variable’s DESC.PhyMax value. The comm4 parameter may be used instead as the terminal count value.
When TIMEmngr is started it looks for the logging file using log_path if present otherwise the current working directory is used with the name TIMEmngr_data. If the file is found the values from it are loaded into the database.
If the file is not found a defaults file is looked for and if found the values are loaded into the database. The file name for the defaults file is formed by adding .def to the filename.
After startup TIMEmngr logs the timer values to disk once per minute using the pathname given by log_path.
When the file is updated the old copy is renamed <filename>.old and a new copy is created.
The program is also capable of performing averaging, integration and finding the peak min and max values.
If this feature is in use then each time TIMEmngr "ticks" the value of read1 is added to a running total then divided by the number of "ticks" to produce the average value. The final result is placed in the database variable named by resp4.
That is: resp4 = Vintegral/elapsed_time
If the counter is reset by using the comm2 parameter the average value is set to zero.
If this feature is in use then each time TIMEmngr "ticks" the value of read1 is first multiplied by read1.preset to scale the value then the result is multiplied by deltaT (the tick interval, approximently one second) and the final result is added to the value of resp1.
That is: resp3 += (dT * (read1.current * read1.preset))
If the counter is reset by using the comm2 parameter the integration value is set to zero.
resp5 index 0 is used for peak minimum and resp5 index 1 is used for peak maximum.
The AccelNET datatyping rules are followed when performing the calculation. If the datatype is Lin or Alog the maximum is the most positive value and the minimum is the least positive value.
If the datatype is NLin or NAlog the rules are reversed.
These tests follow the same logic as the normal AccelNET rules for DESC record processing.
If the counter is reset by using the comm2 parameter the peak minimum and maximum values are set to zero.
The behavior of this input depends on the datatype of the parameter associated with it. Presently the supported datatypes are: Lin, NLin, Alog, NAlog, and Ldisp. Other datatypes could be supported, they just aren’t at the moment.
Note that TIMEmngr will silently not run, i.e. there are no error messages, if this parameter is provided and the datatype is unimplemented.
If this is not specified it defaults to "MNGRconf" in the current working directory (i.e. the directory where the program was started).
If this argument is not specified it generally defaults to the program name.
The log files in this directory are given the name "<log_path>".
The old log files are given the name "<log_path>.old".
The default files are given the name "<log_path>.def".
This argument is useful when setting up the parameters for the PID loop(s) because it makes it very easy to kill and restart the program after changing the config file.
Parameters needed by this program can be combined with parameters belonging to other programs. The "program name" field in the configuration file differentiates the entries.
TIMEmngr uses "TIMEmngr" as the program name when searching the file.
Any number of groups up to the maximum may be used.
The write permissions should be set for direct update and the owner may be any task.
See the Gating Input section for more information.
if (V == preset) then resp1.current = resp1.preset
The write permissions should be set for direct update and the owner may be any task.
If comm3 is present it will be used to reload the counter instead of resp1.preset. See comm3 below for more information.
If this parameter is present then it will be used instead of resp1.preset for reloading the timer.
The value will be taken from comm3.preset if the Label and RefName are NULL else it will be taken from the database.
The write permissions should be set for direct update and the owner may be any task.
Note that the normal database PhyMin and PhyMax rules still apply to resp1 when using the parameter.
This means (using the Lin datatype as an example) that the value entered into this datapoint must fall between the PhyMin and PhyMax values for the resp1 data point.
TIMEmngr enforces these rules internally.
If this parameter is present then it will be used as the terminal count value.
The write permissions should be set for direct update and the owner may be any task.
The value will be taken from comm4.preset if the Label and RefName are NULL else it will be taken from the database.
Note that the normal database PhyMin and PhyMax rules still apply to resp1 when using the parameter.
This means (using the Lin datatype as an example) that the value entered into this datapoint must fall between the PhyMin and PhyMax values for the resp1 data point.
TIMEmngr enforces these rules internally.
The user may enter a new value into this variable and the counter will count up or down (depending on the count direction, see const0) starting from this value.
The write permissions should be set to ______IU (indirect update by users, unconditional update by owner) and the owner should be the same as what TIMEmngr registers as.
Note that the normal database PhyMin and PhyMax rules still apply when using the parameter. In other words PhyMax must be set to value greater than or equal to the largest expected time value or the counter will stop when the value exceeds PhyMax.
TIMEmngr enforces this rule internally.
The datapoint should be made large enough to hold four possible values. The four values are:
0
- stopped
1 - paused
2 - running
3 - not used
The write permissions should be set for direct update and the owner should be the same as what TIMEmngr registers as.
The user may enter a new value into this variable and integration will begin or continue from this value.
The write permissions should be set to ______IU (indirect update by users, unconditional update by owner) and the owner should be the same as what TIMEmngr registers as.
Note that the normal database PhyMin and PhyMax rules still apply when using the parameter. In other words PhyMax must be set to value greater than or equal to the largest expected value or integration will stop when the value exceeds PhyMax (but the counter will still run).
See the Integration calculation section for more information.
The write permissions should be set for direct update and the owner should be the same as what TIMEmngr registers as.
Note that the normal database PhyMin and PhyMax rules still apply when using the parameter. In other words PhyMax must be set to value greater than or equal to the largest expected value or integration will stop when the value exceeds PhyMax (but the counter will still run).
See the Average calculation section for more information.
index0 is used for the minimum and index1 is used for the maximum.
The write permissions should be set for direct update and the owner should be the same as what TIMEmngr registers as.
Note that the normal database PhyMin and PhyMax rules still apply when using these parameters. In other words PhyMax must be set to value greater than or equal to the largest expected value or integration will stop when the value exceeds PhyMax (but the counter will still run).
See the Peak minimum and maximum calculation section for more information.
See also the NOTES section below.
The value is multiplied by the preset field.
This may be used to provide scaling of the integral otherwise preset should be set to 1.0.
See the Integration calculation section for more information.
If the value is zero the timer increments, otherwise it decrements.
If the Label and RefName fields are not NULL i.e. they point to a valid parameter in the database that value will be used, else the value of CONFLIST.Preset will be used.
The code was tested using a Faraday cup current read. In this particular case the CR was being calculated by NUMmngr from a voltage read.
Usually when this is done the CR is defined a Lin datatype with PhyMin and Max set to -1.0 and 1.0.
The particular cup read used was a preacceleration cup. This produced a somewhat strange result in the peak min/max parameters because they were reversed.
For example when the CR was varied between -1.1e-5 and -9e-6 the value placed in peak_min was -1.1e-5 and peak_max contained -9e-6.
This is reasonable because indeed -1.1e-5 is less the -9e-6 however this may not make sense in terms of beam current.
There are a couple of solutions to this problem:
1) change the CR to be NLin. This won’t make any difference to the current read but will make TIMEmngr handle the peak min/max values in a more "sensible" way (sensible at least to a physicist).
2) reverse the peak min/max assignments for resp5 in the MNGRconf file. TIMEmngr will go about it’s merry way producing peak min/max according to it’s internal rules but the parameters used in the AccelNET database will be reversed so the outside world respresentation will make physicist sense.
