It uses a field strength sensing device such as a hall probe or an NMR to obtain the field strength and adjusts the current control for the magnet until the desired field strength is reached.
A table of field strength and current values is used as a guide for adjusting the magnet.
A program may be run before the tuning cycle starts. This may be used to close cups etc. before starting tuning.
MagScale(1) may be used to generate the piece tables needed by this program.
Usually this parameter has the refname MfieldC and is grouped under the bending magnet label. For example: "BM 01-1 MfieldC".
When the new field strength value message is received by the program a check is made to ensure that a tune operation is not already in progress.
Next, if specified in the configuration file, a program is run. BMmngr waits for the program to complete before proceeding.
This program may be used to do such things as close a Faraday cup to prevent beam from sweeping into undesirable locations (or beam of undesirable species or energy) while the magnet is being tuned.
Next, the program attempts to write lock the current control. If the write locks succeeds the BusySR parameter is set to the busy state.
A new current control value is calculated using a lookup table and interpolation and sent to the database.
If the TUNEtype parameter (another config parameter) is set to 1.0 the magnet is set to it’s full scale current setting first and on the next step set to the first of the series of moves to get it to the correct field strength.
The program then goes to sleep for a programable amount of time.
When the program wakes up it compares the field strength control with the reading and and computes a new current control setting. It then goes to sleep again.
This process is repeated a programmable number of times until either success is achieved or the programmed number of attempts is exceeded.
When the operation ends the BusySR is set back to rest.
The tuning operation may be canceled at any time by using the ClearSC control.
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.
If this is not specified it defaults to "." (the current working directory i.e. the directory where BMmngr was started).
If this is not specified it defaults to "." (the current working directory i.e. the directory where BMmngr was started).
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.
BMmngr uses "BMmngr" as the program name when searching the file.
One Group is assigned for each magnet to be managed. BMmngr handles up to 8 magnets, groups 1 thru 8 are used.
Parameters listed as required must be present in the config file for BMmngr to operate on the group. Parameters listed as optional are not required and will be ignored or overridden by defaults as appropriate.
comm1, read1, ctl2, and file1 should all be scaled in the same units. Be careful not use Gauss for one and Tesla for another.
It should be owned by whatever task BMmngr registers as and the write permissions should be set unconditional for the owner and indirect for everyone else.
When the value is 1.0 the tuning operation is halted.
The write permissions should be set for direct update and the ownership doesn’t matter.
The value is 1.0 when tuning is in progress.
The write permissions should be set for direct update and the datapoint should be owned by BMmngr.
This is usually named MfieldR in the database. Ownership doesn’t matter.
This is usually named PolSR in the database. Ownership doesn’t matter.
See the const0 and const1 entries for more information.
This is usually named CC in the database. Ownership doesn’t matter, however the datapoint should be writable by BMmngr.
This is usually named DeltaG in the database.
The write permissions should be set for direct update and the datapoint should be owned by BMmngr.
NOTE: the file name cannot exceed 8 chars due to length restrictions in the CONFLIST.
NOTE: the executable’s name and the arg cannot exceed 8 chars due to length restrictions in the CONFLIST.
If the Label and RefName are not null the value comes from the database else the value comes from the preset field in the config table.
This is usually named tuneTIME in the database. Ownership doesn’t matter.
This parameter should be limited in the database to a value greater than zero. If the value is zero in the database it will be ignored and the default value will be used.
If the Label and RefName are not null the value comes from the database else the value comes from the preset field in the config table.
This is usually named tuneSTEP in the database. Ownership doesn’t matter.
This parameter should be limited in the database to a value greater than zero. If the value is zero in the database it will be ignored and the default value will be used.
If the value is 1.0 tuning is done by first taking the magnet to full scale then adjusting the current to reach the desired field strength.
If the Label and RefName are not null the value comes from the database else the value comes from the preset field in the config table.
This is usually named tuneTYPE in the database. Ownership doesn’t matter.
BMmngr prints the loaded copy of the config table to stderr. The print call takes place after BMmngr has loaded to table and processed it. The values that will be used by BMmngr appear in the Current field.
This is very useful when debugging a new setup because you can see what values will actually be used for items like int0-2 regardless of whether they are loaded from the database or the Preset field.