The ESI Spectrograph Online Documentation

WHAT IF SOMETHING BAD HAPPENS?

inconfig diagnostic notes

Since I said in the Overview that inconfig was dangerous, how would you recover if you did something bad with it? That depends on your level of expertise and the level of error.

Let's consider several possible failure modes, in descending order of severity.

WORST CASE:

You have got a bad mapRON.cfg file, and bad data in the dynamap table, and you don't have access to the database server or to inconfig, or inconfig is broken or lost.

SOLUTION:

revert to "factory" settings. Do this by
  1. deleting the dyna/mapRON.cfg file
  2. starting the GUI with the -z flag which suppresses dynamaps
  3. provide the user with a paper document mapping filter positions to names

COST:

useless names in FITS headers

INCONFIG ERROR:

You have used inconfig and messed up the dynamap data. But you still have privs to use inconfig.

SOLUTION:

Start inconfig again. Use the Copy Defaults button for the messed-up stage to copy the factory values into the dyna values. Do your editing again, more carefully this time. Commit.

COST:

nothing but your time

LOST FILE:

The mapRON.cfg file in dyna has been lost. The GUI no longer agrees with the dispatcher.

SOLUTION:

If you have inconfig privs, use inconfig to restore the lost cfg file. If you do not, go to WORST CASE above.
What are the likely symptoms of something going wrong?
  1. GUI shows yellow highlighting at startup.
  2. attempts to move the afflicted stage fail, and the dispatcher reports errors mapping the named position to a raw position
  3. BUT ordinal moves using the modify cmd still work

How should you diagnose the problem?

FIRST, before doing anything else, check the dyna/mapRON.cfg file!

Do the position labels in that file match the menu items in the GUI?

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.