| The ESI Spectrograph |
|
Online Documentation |
Rather than infoman, inconfig uses a database server,
and dispatcher files, to cache the mapping of names
to ordinal positions.
The user of inconfig can reconfigure not only
name/detente mapping, but also the raw encoder count
positions of the different detentes. This makes
inconfig a potentially dangerous tool. Only
an instrument scientist or other instrument support
staff should use it.
When the user hits COMMIT two things happen, not
necessarily in this order.
A crippled version of CodeGen runs, which produces only
dispatcher config files. Of those, it copies only
one to the target location, which is
The mapRON (map Raw/Ord/Nam) file tells the dispatcher how
to map the NAM and ORD keywords to raw positions. If you
ask for filter "V" the dispatcher has to translate that
into an encoder position so it can tell the Galil to move
the stage.
The dispatcher has a mapRON.cfg file by default that contains
"vanilla" position names like "Filter 1" and "Filter 2".
If it starts with the -u flag
So, the control (backend) part depends on 2 things: you
have to update the database and generate a new dyna mapRON
file, AND the dispatcher must be started with the "use dynamic"
flag so that it knows to use that file.
Now, what inconfig did before running CodeGen was to update
the database server. CodeGen used these data to generate
the dispatcher config files, which are the first human-visible
result of running inconfig.
The dispatcher is started before the GUI. So the effect
of inconfig on the dispatcher is described first. However,
the change to the database also affects the GUI (dashboard)
the next time it is started up.
How about the UI? How will it know the new names or
detentes defined by the instrument scientist?
It does not "ask" the dispatcher about this map.
It can't. Instead, at startup, it looks in the database.
inconfig wrote on a table called "DynaMaps" which is
a "shadow" of the Mmaps table. The UI, on startup, is
smart enough to check DynaMaps data and use them to
OVERRIDE the default (Mmaps) data which it inherited
with its kwd file. Any menu or bar graph which is
"dynamic" (has a "dyna" flag set by the designer) will
paint itself using these values.
This is why you can't have lots of directories under
KROOT/data/INSTRUMENT and just switch around between
setups. The database (of which there is only ONE copy)
has to match. Otherwise you would have one set of names
in the menus of the GUI and another inside the dispatcher,
and unhappiness would result. Only one "state" is
possible at a time.
$KROOT/data/INSTRUMENT/dyna
for example
/opt/kroot/data/pfcam/dyna
The file it copies is mapRON.cfg. This file is human-
readable. It's just ascii. The user can and should
visually verify whether it contains the info we think
it should.
-u dyna
then it looks in KROOT/data/INSTRUMENT/dyna for an alternate
"dynamic" mapRON.cfg file which it will use in preference
to the vanilla (factory) file. 'dyna' in this case is the
name of the directory. But it doesn't have to be called dyna.
-u foo
would make the dispatcher look in KROOT/data/INSTRUMENT/foo!
One could imagine starting dispatchers with different -u
flags to get canned setups, but don't go there! There's
another dependency which I will describe in a minute.
The Observer documents are hand-written. The Technical Documents are produced from plain text files in the CVS source tree by some Tcl scripts written at UCO/Lick Observatory. The Reference Documents are mostly generated by software from data in a relational database. Individual authors are responsible for the content of the Observer and Technical Documentation. The Lick SPG as a whole is responsible for the content of the Reference doco. Send mail to de@ucolick.org to report inconsistencies or errors in the documentation.