Summary of a discussion on a proposed level 0 GUI for observing with NAOMI

 

20 July 1999 at ATC                                                                             wht-naomi-41

 

Present:

Matthieu Bec <mdcb@ing.iac.es>,

Tom Gregory <tgregory@ing.iac.es>,

Frank Gribbin <fjg@ing.iac.es>,

Dennis Kelly <bdk@roe.ac.uk>,

Andy Longmore <ajl@roe.ac.uk>,

Richard Myers <R.M.Myers@durham.ac.uk>,

 

Notes:

1.        These were preliminary discussions

2.        They involved many issues external to NAOMI (i.e. OCS issues such as the coordination of instruments, AO and the TCS) but did not aspire to be proposing a generalised OCS GUI.

 

The guiding principle adopted was:

 

Each top-level observing GUI should show only what the observer and NAOMI-trained TO need to know for normal operation.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


Details:

Hierarchical Status is something like

Observing P-BULBO with INGRiD and NAOMI

                Script: My_script

                Script Status:

                                On source

                                                9-point dither

                                                                dither point: 3

                                                                                Integrating

 

Clicking on something or other in the NAOMI status will bring up something very like the TO’s NAOMI-specific GUI. This is itself very close to the NAOMI TopGUI which Nigel Dipper proposed on 19/7/1999 except it now has an External Control status box and a somewhat better defined Probe/field status indicator. The latter shows the location of the NAOMI probe, the RA and Dec axes and the sky position angle. The former shows if NAOMI is being externally controlled (it normally will be – by the OCS).

 

The external control mechanism envisages programmed pauses in OCS scripts that would allow adjustment of the AO system followed by an abort or continue. This raises the question of how the level-0 GUI and OCS system in general handle NAOMI being put in an improper state. This could happen in the following ways:

 

1.        the operator or observer leaves NAOMI in the wrong state (e.g., loop open/closed) when continuing from a programmed “invitation to adjust NAOMI” pause in the OCS observing script. To handle this the script or OCS would have to check things were in the expected state before continuing

2.        an asynchronous change of NAOMI state whist the script were running. This needn’t be an operator error (eg. opening the loop mid-exposure). It could happen anyway just because the seeing got much worse or cirrus blocked out the WFS light. We decided that the required action would depend on context: for example, if it were a long CCD integration you would probably want to close the shutter and either wait or readout depending how near to the end you were. A short broad-band IR integration might just be flagged as suspect and otherwise continue as normal. The handling of these events must basically be pre-selected by the observer. Either way the GUI statuses must be updated promptly (eg. the compound “clear for astronomy” status indicator must be set to false if a change to a NAOMI subsystem makes it actually untrue). Within NAOMI such  error handling and propagation is foreseen in the sequencer design. Clearly some part of this mechanism needs to extend across the NAOMI-OCS boundary.