Previous: Mechanics
Up: The Utrecht Echelle Spectrograph UES
Next: State of the Union
Previous Page: Mechanics
Next Page: Hardware
Previous: Mechanics
Up: The Utrecht Echelle Spectrograph UES
Next: State of the Union
Previous Page: Mechanics
Next Page: Hardware
The aim in the design of the control system has been to allow the observer (eventually) to control the entire observing machine from a single terminal (aided by displays such as TV, autoguider, MIMIC and DMS). To avoid complex interactions of unrelated parts of the system, a hierarchical design was imperative; this is mainly reflected in the software, but also in lower levels of the hardware.
To allow all parts of the system to communicate with each other when necessary, an Ethernet system runs through the entire electro-mechano-optical complex. Source and destination of each message are identified within the messages and each local device uses only the messages meant for it. Wherever there is a concentration of devices to be served (controlled or read out), a Network Interface Unit (NIU) picks up the messages intended for up to 4 local subsystems. The NIU extracts the bare message and passes it to a local microprocessor for further attention. Such a local microprocessor may be the Telescope Control Computer (TCS), a detector controller, a 4MS system controlling an instrument (or an A&G), or a powerful controller for the Autoguider (....) or Data Memory System (DMS). Some of these systems (such as a 4MS) control still lower levels of `intelligent' microprocessor control (such as Stepping Motor Drive Module SMDM, Barcode Reader Module BCRM or a UES Standard Electronic Control Unit SECU), which control the opto-mechanical assemblies either directly or through still lower levels of control such as dedicated motor control chips. In other cases (such as the Nasmyth A&G and TAURUS), the 4MS system directly controls electronic hardware which in turn contains the basic motor control in hardware form (digital and analogue servos with integrated encoders which are not accessible to the software).
This Ethernet structure emphatically does not include a hardwired hierarchy: any subsystem can in principle control the others. So at the levels of Ethernet and above, the software must define the hierarchy. Below the NIU's, the hierarchy is mostly hardwired.
Since the hardware is from different sources (DEC, RGO, Dwingeloo, Utrecht and Roden, to name a few prominent in UES), unity of results must be imposed at some level. Ethernet messages must conform to a certain protocol, and the several 4MS systems also work mainly with standard hardware selected by RGO and use RGO's standard basic kernel. Below the 4MS systems, individual preferences and equipment demands run riot, above the NIU's the reign of Ethernet and the VAXes is supreme.
However the hardware is implemented, the principle of hierarchical control
is always to start an action, then forget about it at the initiating level
until the next level down signals its completion. At that point, a status
variable is updated in the initiating system, so that the level above can,
by a simple `read status' message, find out what state the system is in;
while a device or system is in transit from one well-defined state to
another, its status is `undefined'. The MIMIC display shows the observer
what the recorded state is of each component of interest to him (green for
a well-defined state, white for undefined, red for error). At the very
highest control level (ICL), the aim is that the observer can use a
single command for the equivalent of such sequences as: Configure UES
according to table x, the CCD window and binning according to table y,
point the telescope to NGCnnnn (from catalogue abc), set the UES slit
position angle to 
on the sky, centre the object for maximum
detector output, find the nearest star brighter than magnitude m and lock
on to it for autoguiding. When all of this is properly set up, start a
20-minute exposure and, 5 minutes before its end, sound the buzzer in the
coffee room. Oh yes, calibration spectra both before and after NGCnnnn,
please; use the lamp which is most suitable for my spectral region. Data to
be displayed on the DMS for as long as this does not interfere with the
next exposure, and also saved on disc. Quick-look reduction; observer
control of the observing sequence to do repeats on failed or especially
interesting exposures.
If this were all that observers needed, monolithic control from a single computer would in theory be possible (though distinctly unfriendly to service-technicians). However, other observers want sequences of exposures for polarimetry or time-variability, or an automatic telescope focus test, or the same signal-to-noise for objects of different brightness, etc etc. The control hierarchy has been designed to cater for all of these situations and many more that are still dormant in future observers' minds. The system of status variables, available on demand to the next level up, allows construction of simple commands performing complex sequences of actions at the next lower level, of the type: `Start this, wait for it and, if successful, start that and wait again'. This works fine (though slowly), until an error condition develops; in that case, the error information must propagate all the way to the observer (unless an intermediate level of control has been programmed to correct the error and put the system back on to the rails).
Observers will appreciate that, even when the hardware is installed and has proved reliable, the complex sequences at the behest of ever changing observers require a substantial amount of programming at a number of levels in the hierarchy; this is the price one pays for present and future flexibility. Since, for historical reasons, the languages (or dialects) in the computers are mostly different, arranging for a new top-level application to be automated requires many months of hard labour. Therefore, observers who wish to do state-of-the-art observational work have no option but to assist in a continuing task force which repeatedly reprogrammes parts of the system; they must be prepared to help out wherever a vacancy threatens and they must be prepared to use temporary fixes at some lower level of control than the observers' terminal. More pedestrian observers, who are happy to do large projects after the bugs have been taken out, can skip the rest of this section on control. It is for the would-be state-of-the-art observers that the control hardware and software is summarised below.