Broad Architecture

Ned's scheme has 3 loops:
  1. Prepare (includes scheduling and tiling code). One night prepared each afternoon. Sam Ray (Tamara student) working with Marc White on this loop.
  2. Observe (mostly configured). No commitment from AAO yet on the timing of the software below.
  3. Reduce (i.e. is data OK, and how much of the data is OK)
taipan_funnelweb.jpg

VObserver Details


At the beginning of each night, the TAIPAN Vobserver process will be provided with a list of fields, including:
  1. Co-ordinates of all stars, guide-stars etc.
  2. Observing time constraint.
  3. Sky temperature constraint, plus possibly others.
  4. Exposure time
  5. Any required calibrations that make the observing block. This includes a "time since last calibration" option.
The Vobserver will choose the first field in the list that matches this.

The required subsystems include:
  • Spectrograph (??)
  • Telescope/Very Local Weather (ACE, maybe with DRAMA interface,Keith)
  • [MAYBE] Other Weather? (depends on what is attached to the dome)
  • Detector (??)
  • Positioner (Nuria)
  • Calibration Sources (?? maybe no hardware)
  • Guider (Nuria lead - similar to positioner)
  • [MAYBE] Archive

The requirement for AAO from the Vobserver is that:
  1. Each subsystem should have a single call that returns the status of that subsystem. If this could be pub/sub, that would be great.
  2. Each actuator or system of actuators within a subsytem should have a command-response interface for it. We don't want super-low level access. e.g. no motor co-ordinates for slewing... just RaDec or AltAz (and something in the status that tells us if we're there).

Hopefully the Vobserver can start each component with a single python class, e.g. with:

Telescope = UKSComponent("Telescope.json")
... or something like this. Such a configuration means that the AAO has to only write one (relatively simple) class, the "UKSComponent", as well as keeping the settings for each component in a simple file.

The most basic command-response is "configure" where a name-value pair is sent. An exception is raised (via, at low-level, an error being sent over TCP/IP) if there is an error. Acknowledge timeout is something like 0.1 seconds or less.One example of the "configure" may be "restart" - implementatino of this has to be carefully considered.

For example:

try Telescope.configure("RaDec","04 30 00 -20 30 00"):
except ValueError:
HERE WE KNOW THE VALUE WAS OUT OF RANGE
except UserWarning:
CHECK THE "LASTERROR" PART OF THE STATUS MESSAGE BECAUSE THERE IS AN UNUSUAL ERROR

This would e.g. be implemented in ZMQ using:

import zmq
context = zmq.Context()
sock=zmq.socket...
ALL_GOOD=0
INVALID_VALUE=1
WARNING=2

def configure(keyword,command):
sock.send( keyword + " " + command)
response=sock.recv()
if (response==INVALID_VALUE):
raise ValueError
elif (response==WARNING):
raise UserWarning

The key is that the Telescope.configure command waits for a response from the component server, but this response should come back immediately (e.g. doesn't wait for a mechanism to move). Part of the (detailed) component status should be a list of all possible commands.

Status is a set of name-value pairs. Preferably with not the entire set sent every time. e.g. common commands could be: status["status"] which would be "ready", "moving" etc etc. Another key item is "dir" for where output files are stored, file number etc.

Our preference is pub/sub and req/rec communication pairs (e.g. using ZMQ, or another standard socket protocol) that are accessible to python.

Open Questions:

  1. Where does the fits header information go? This could be assembled by vObserver from the raw data products made available by the subsystems. Or, it could be another DRAMA task. Or both (DRAMA assembles most of the header, followed by extra keywords from the vObserver).

Chris Tinney's vision for the Scheduler based on his prior experience.



I envisage OBSERVER running a loop in which it is continually asking questions
on the status of the system, and making decisions on what do do next based on that.


I envisage OBSERVER maintaining a small internal QUEUE of proposed observations,
so that it always has a model for what it is doing now, what is planned next, and what
is planned after that.


OBSERVER runs a BASIC_LOOP that queries a bunch of status flags, and if required
initiates actions, setting action_STARTED_FLAGs. When actions complete, they set
action_COMPLETE_FLAGs via callbacks from the DRAMA tasks.


DRAMA tasks will also trigger interrupting callbacks based on error conditions, etc,
that need to get handled.




BASIC_LOOP
UPDATE_STATUS (a general function that updates all state variables,
queries state form DRAMA tasks, updates the output status GUI)


if (QUEUE empty)
Request QUEUE to be filled by the NEXTOBS module
break
if (positioner not in config required by next object in queue && !POSITIONER_STARTED_FLAG )
Start positioning
POSITIONER_STARTED_FLAG=1
break
if (FLAPS not in config required by next object in queue && !FLAPS_STARTED_FLAG )
Position FLAPS
FLAPS_STARTED_FLAG=1
break
if (LAMPS not in config required by next object in queue && ! LAMPS_STARTED_FLAG)
Control LAMPS
LAMPS_STARTED_FLAG=1
break
if (TEL not in position on sky required by next object in queue && !SLEW_STARTED_FLAG )
Slew telescope
SLEW_STARTED_FLAG=1
break


if (SLEW_COMPLETED_FLAG && FLAPS_COMPLETED_FLAG && LAMPS_COMPLETED_FLAG &&
POSITIONER_COMPLETED_FLAG )
#The hardware is all ready to go.
if (next observation is a flat )
START_EXPOSURE EXPTIME FLAT
EXPOSURE_STARTED_FLAG=1
break
else if (next observation is an arc)
START_EXPOSURE EXPTIME ARC
EXPOSURE_STARTED_FLAG=1
break
else
# Next observation must be an object
Start guider acquisition
GUIDER_ACQUIRE_STARTED=1
break
else
break


if (SLEW_COMPLETED_FLAG && FLAPS_COMPLETED_FLAG && LAMPS_COMPLETED_FLAG &&
POSITIONER_COMPLETED_FLAG && GUIDER_COMPLETED_FLAG && !EXPOSURE_STARTED_FLAG )
START_EXPOSURE EXPTIME OBJECTNAME
break


end BASIC_LOOP

Chris Tinney's version of the Low-Level communication based on his previous experience


Obviously all tasks need to be able to trigger an ERROR callback that returns meaningful error messages when tasks fail, crash or otherwise run into trouble.

TEL

slew [-nowait] RA REC (positions telescope and dome, sets the telescope to tracking, then returns).
callback RAINSTOP
callback HUMIDSTOP
callback CLOUDSTOP
monitorable parameters RA DEC RA_REQUEST DEC_REQUEST DOMEAZ DOMEALT DOME_VIGNETTED
STATUS=SLEWING,TRACKING
RAINSTOP=OK/STOP
HUMIDSTOP=OK/STOP
CLOUDSTOP=OK/STOP

SPECTROGRAPH

backilluminate ON/OFF
monitorable parameters
FOCUS_BLUE FOCUS_RED BACKILLUMINATED

GUIDER (NB: guider must interact directly with the telescope, but that need not be through Drama)

acquire (finds the guide stars, offsets the telescope to put them near the selected guide points, starts guiding, wait for telescope to settle, set status to GUIDING)
stop (stop guiding, set status to INACTIVE, stop recording)
pause (pause guiding, set status to PAUSED, keep recording)
start_recording (starts recording a time-stamped list of seeing estimates, guide star brightnesses, telescope offset requests)
stop_recording (stop recording this data)
get_recording (return the current time-stamped list of seeing estimates, guide star brightnesses, telescope offset requests since recording started)
callback LOST
monitorable parameters STATUS=ACQUIRING/GUIDING/PAUSED/LOST/INACTIVE
LASTSEEING=(value,time,g_exp_time)/NONE
LASTBRIGHTNESS=(value,time, g_exp_time)/NONE
LASTOFFSET=(ravalue,decvalue,time, g_exp_time)/NONE

When guidestars are lost, system should fall back into ACQUIRING mode, recording should record a ‘null entry’ every g_exp_time, it should try to re-find the guide stars, but if that fails within a timeout, then set status to LOST, and attempt to ACQUIRE again every 4*timeout.

DECTECTOR
Q: Is there a need to send different exposure times to the two cameras? At the moment the following schema assumes both cameras are always triggered to do everything in parallel.

run EXPTIME OBJECTNAME OBSCLASS
update EXPTIME
pause
stop
abort

callback READOUTSTARTED
callback READOUTCOMPLETE
callback FILEWRITTEN
callback ABORTED
monitorable parameters STATUS=IDLE/EXPOSING/READING/WRITING
EXPTIME
TIMELIEST (timeleft in exposure when exposing, timeleft in readout when reading)

POSITIONER
configure CONFIG_DEFN
callback CONFIGCOMPLETE
monitorable parameters STATUS=IDLE/POSITIONING
FIBRESCOMPLETED LASTCOMPLETED_CONFIG_DEFN
CALIBSYSTEM
What hardware is this?

flaps IN/OUT
lamp LAMPTYPE ON/OFF
monitorable parametersLAMP1 LAMP2 LAMP3 (either ON or OFF)
FLAPS (either IN or OUT)
OK/EMERGENCYSTOP