3 TROUBLESHOOTING

Q1 I need the latest and greatest features of bob, but I do not wish to update the entire VLT-software just for that. So can I use the current version of bob on top of a previous release of the VLT software?

It depends. New features of bob can be tightly linked to new features of the VLT Sequencer library, Tcl/Tk, the VLT CCS package or other VLT common software components, in which case a mere upgrade of bob will not give you the expected features (and may even lead to a crashing bob). So the recommendation is surely to upgrade everything at the same time, to be on the safe side. In case of doubt, consult the author.

Q2 I have a home-directory which is NFS-mounted on a HP-UX, a Solaris and a Linux box. When running bob I have some engineering mode password problems on some of these machines. How do I fix this?

This is due to the way passwords are encrypted by bob up to version 1.117 inclusive. The encryption is done with the help of the "crypt" utility, available only on HP-UX and Solaris, and there is no encryption used on Linux. But apart from the fact that this crypt utility is not available on Linux, its result are not identical between HP-UX and Solaris. This means that this password can only be validated on the platform it was generated.

For that reason there is since bob 1.118 a Tcl-based crypt procedure, which of course produces identical results cross-platform. So the solution is to upgrade to (at least) this version

Yes - just delete the old and new password files (~/.bobpasswd resp. ~/.bob.passwd). Although bob will attempt to convert automatically the old to the new, there are some conditions under which it will fail. The easiest way out is to deleted these password files. From that point on you should have the default (blank) password.

3.1.2 Start-up

Start-up these bob-processes with the -configFile option, pointing to individual configuration files. See also section 2.2. You can of course use this feature as well for the case that you want to use different configurations, still talking to the same OH and OS. If you need to distinguish these various bob-processes from CCS's point of view, you should use additionally the -ccsProcName option when starting them up.

3.1.3 Template scripts

The OBS-keywords are automatically sent to OS (when a START command is given), so you should not be worried about them not getting to OS. Caring about OBS keywords is generally not the task of the template; a template can deal with all keywords which are its own (TPL) or at a lower level (DCS, TCS, ....), not with the ones which are at a higher level (OBS). Remark that giving access to these OBS keywords within the template would expose them to modification - and this is forbidden, as this risks to invalidate the entire OB. If your template really depends on an OBS-keyword, there may be something wrong either with the design of the template script, or with the classification of this keyword.

However, since bob version 1.130 one can use the "seeBobVars -localcopy OBS" command to get a local copy of the OBS into the context of the procedure where this is called from.

You cannot - at least not easily. Some keywords have indeed a .VALUE entry in their .tsf file, with the purpose of flagging to P2PP/OT that these keywords should not be edited, i.e. have a fixed value. In fact, P2PP/OT currently do not include .VALUE keywords into the OB they produce; upon receipt of an OB bob verifies its contents and adds some info contained only in the .tsf files (e.g. the .VALUE keywords). After this verification/combination took place, there is for a template script no way to tell the difference between a keyword which was defined in the OB by P2PP/OT versus one which had its value fixed in its corresponding .tsf file - unless you start of course with your own analysis of the .tsf file.

3.1.4 Template signature files

Q7 I want to force the user (engineer) to edit some keyword values after he loads an OBD. Can I do this by leaving the keyword out of the OBD, and by setting the DEFAULT value of a keyword to "NODEFAULT" in the template signature file?

This is an invalid approach. The value "NODEFAULT" for the DEFAULT keyword in a template signature file is intended to show that there is no reasonable default value (see [1]) - it is not a flag to anyone that this keyword should be defined after loading the OB. It has been introduced for the purposes of P2PP, which will in this case force the users to enter a value. Which means none of these keywords are left undefined in the resulting Observation Block, by the time it gets to bob.

Defining a keyword after loading a template is actually explicitly forbidden by the ICD (see [1]). All keywords must be defined in the OBD, with the possible exception of the ones with a valid (i.e. matching the corresponding TYPE) DEFAULT or VALUE keyword in their resp. template signature file. "NODEFAULT" cannot be abused as a flag to have a keyword created which is not in the OBD. The .obd files are there for cases where you don't have P2PP, e.g. during development/testing. Their content however has to be identical to what P2PP would send, i.e. their syntax has to be correct, no stories about parameters which in this case can be dropped, etc.

Bob will complain (as it should) about all parameters defined in the TSF and absent in the OBD, also if in the TSF their DEFAULT value has been declared with NODEFAULT. Bob will however create the corresponding variable, which will allow editing.

The recommended, clean solution addressing the need for an editable parameter is in any case an .obd file which does contain also the keywords whose value you want to change.

3.1.5 Sounds

Q8 Running bob on an audio-equipped HP X-station, bob crashed when I clicked on the "enable/disable sounds" icon, with a segmentation fault. Is this a bug in bob?

There is a known problem on HP X-terminals with some versions of the Audio-server software, which these terminals normally download at boot-time from their server workstation. This bug makes *any* program accessing the audio-hardware core-dump. There is a patch (from Hewlett-Packard) for this Audio-server software available, which gets installed on a workstation when the normal installation procedure is followed.

Remark however that some X-terminals boot from a flash-ROM card, and consequently do not pick up this X-server update from the workstation. So make first of all sure that your X-terminal is configured to boot from an updated workstation. Ask "vltmgr" for more info / how to configure your X-terminal etc.

Q9 When I run bob from an HP-UX 10.20 box on an X-emulator or an HP X-station without audio hardware, bob crashed when I clicked on the "enable/disable sounds" icon, with a segmentation fault. Is this a bug in bob?

There is a problem with earlier versions of the "snack" audio extension (used by bob), leading to a core dump, on all HP-UX versions, when trying to access non-existing audio-hardware. This should only affect pre-MAR2002 versions, as the MAR2002 version of snack has been patched to correct this problem.

3.1.6 FITS header information

In principle this should of course never happen. OBS.START is calculated when the OB is started (after having been initialized when the OB was created), and is not modified further on. It is completely independent from the type of templates in the OB, their sequence of execution, etc. There are however a few situations which may produce "inconsistent" values (and these are all features rather than bugs):

a. The acquisition template (i.e. the first template of the OB) does not send a START command to OS, although it does produce one or more FITS files. This START command is the (documented) requirement to get all these OBS-keywords sent automatically to OS. If you cannot live with this mechanism, you should use the convenience procedure "sendObsKeys" to get them across - see section 2.7.2. In the absence of this new OBS-info and depending on how your OS is implemented, your OS may just insert the OBS.START of the previous OB, which is not the value you expect.

c. You press the "Reset Status" on the bob-panel (lower right button) after executing the acquisition template, and then start the OB again, this time skipping the acquisition template. Again, the result is what has been asked for...

3.1.7 Operational states

Q11 When I abort a running exposure via the OS-panel, bob doesn't seem to realize that this happens, and flags a normal termination of the template. How can that be?

A typical template should after starting an exposure issue a WAIT command to OS. This command should only return when the exposure is finished, indicating in its reply the exposure status (as an integer, see the "expStatus" database attribute as defined in [4]). It is then up to the template to interpret this status, and eventually to return with an "error" command instead of "return {}". Using this "error" command, the OB will be aborted. Using the "return {}" statement, bob will not be aware that the exposure was aborted at the OS level. bob itself does not interpret this expStatus returned by the WAIT command.

Q12 When I press the ABORT button on the bob-panel, the current exposure still proceeds, and only after it is finished, the template and OB get aborted. Why?

Bob's abort command aborts the currently running template and OB, it does not abort the currently active exposure, i.e. bob does not send automatically ABORT commands to OS. This is intentional, and was decided at design time. You can of course decide within a template to send ABORT commands to OS, using the sendCmd convenience procedure.

By the way, the template is only aborted when bob checks the abort-flag as set by pressing the ABORT button; this happens only if the "checkAbortFlag" convenience procedure is called within a template, and at the (normal) termination of the template - whichever comes first.

3.1.8 Engineering mode

Q13 In the template-logs, I occasionally see some messages in red complaining about keywords that have not been accessed. What does that mean?

This happens if the OB and/or template signature file contain some keywords which are not used by the template script, i.e. they are not read nor sent across to OS. This probably means there is a bug in the template script, the OB or the TSF: if a keyword gets defined, it probably needs to be accessed during the execution of the template script. Otherwise there is no sense in having this keyword.

Q14 In the template-logs, I occasionally see some messages in red complaining about keywords that have been modified or unset by the template script. What does that mean?

This happens if the template script and/or its library procedures attempt to modify or unset the keyword array element(s) listed in this message. So this message will appear whenever an existing element's value gets overwritten or unset. This points most likely to a bug in the template script: keywords are in principle read-only; they should either appear explicitly in the OBD, or be derived from DEFAULT/VALUE entries in the template signature file. The few exceptions (like TPL.NEXP) are filtered out before printing this warning message into the template-logs. See also section 2.7.1.

Q15 In the template-logs, I occasionally see some messages in red complaining about reading or writing into some gvar-variables instead of using the public interface. What does that mean?

This happens if the template script and/or its library procedures attempt to read, write or unset particular elements of the global array gvar. This array is used internally by bob to pass some information between the various panel widgets and bob itself - it is not intended for public use. To obtain the result you're after, please use the public API as documented in section 2.11.1.

Q16 In the template-logs, I occasionally see some messages in red complaining about `... keys of unknown category (due to misuse of "upvar")'. What does that mean?

This happens if the template script and/or its library procedures "hijack" the names of the categories (TPL, DET, ...), ie. if by the use of upvar commands these category names end up being referred to by any other name. As BOB has put traces on the original arrays, it will get a trace call-back referring to this new name; when this happens, it won't know anything about this mapping, so it won't be able to do the usual keyword checks (see also Q13).

Q17 I get in Engineering Mode a message in the template log, saying that the template did not use the TPL.EXPNO and TPL.NEXP keywords. Although I effectively do not use either of these explicitly in any of my templates, most templates do not complain about this. Why?

BOB takes always care of TPL.EXPNO (the current exposure's sequential number within the template), and sets TPL.NEXP (the number of exposures in this template) to a default value of 1 if it is not defined in the TSF nor OBD. These 2 keywords are passed automatically by BOB to OS when the template intends to send a START command to OS, or gives explicit instructions to forward all OBS and TPL header keywords by means of the sendObsKeys convenience procedure. So most likely, in the template which produces this log, there is neither a call to sendObsKeys nor a "sendCmd START".

This is all based on the assumptions for which BOB was designed, i.e. to deal with templates which start exposures, talking to an OS. This turned out to be not always the case, in particular not for technical templates and acquisition templates without exposures - which will then also produce this log. Hence, future versions of BOB could be modified to deal with this situation.

Q18 What's the purpose of editing keywords which are supposed to have a fixed value, assigned via a .VALUE entry in their template signature file?

This is for the purposes that Bob's OB-editor was created, i.e. engineering. So typically, if you want to tune these values, you'd edit them via the engineering mode, and after determining an optimum value you'd put this value back into the .VALUE entry of the template signature file.

Remark however that after the editing of an OB (or template), the resulting OB will be again checked against the .tsf file. Now if this modified keyword has a value which is different from what the .tsf dictates (via the .VALUE entry), bob will flag this by popping up a warning. This warning will appear independent of the user-level, and will stay up for 15 seconds or until acknowledged ("OK" pressed), whichever comes first. Just to make sure that this cannot ever be considered a standard procedure.