Next: Quicklook IRAF Scripts for Data Acquisition Management
Previous: The Integration of Telescopes, Instruments, and User Interfaces at KPNO and WIYN
Table of Contents --- Search ---
PS reprint
C. Mayer, R. Laing, P. B. Taylor
Royal Greenwich Observatory, Madingley Road, Cambridge, CB3 0HS
P. T. Wallace
Rutherford Appleton Laboratory, Chilton, Didcot, Oxon, OX11 0QX
The main purpose of the TCS software is to take a target position, which can be specified in a variety of coordinate systems, and calculate mount, rotator and optical surface positions so that the target is imaged perfectly at a given point in the focal plane.
To accomplish this task the TCS must co-ordinate the activities of the TCS subsystems in response to high level commands from the user. The TCS itself does not control any hardware directly but issues commands to its subsystems as the result of commands it receives from the user. The TCS is responsible for the control of the Mount (MCS), Cassegrain Rotator (CRCS), the Primary and Secondary Mirror (PCS and SMCS) and Enclosure (ECS). It is also responsible for some aspects of the control of the A&G box (AGCS), the Adaptive Optics System (AOS) and the on-board instrument wavefront sensors (OIWFS).
The TCS software runs within the EPICS environment as developed by Los Alamos National Labs (LANL) under the VxWorks real time operating system. It communicates with the other principal systems and with its subsystems using the EPICS channel access protocol.
The software is designed around the concept of the virtual telescope as first described by Straede & Wallace (1976) for the AAT and subsequently implemented on a number of other telescopes. In this design the imperfections of the real telescope are hidden as far as possible from the user by a layer of software. The Gemini TCS extends the concepts of the virtual telescope to include both guiding and the control of the optics.
The Gemini Control system is distributed, with each system or subsystem controlled by a VME crate with a 680x0 processor running VxWorks. The systems are connected by a number of ``buses''. Commands and status pass between the systems over a Control LAN (currently a standard Ethernet). In situations requiring high speed deterministic transfer of data, the synchro bus is used which is implemented with reflected memory cards from VMIC. An interlock system is implemented in hardware in conjunction with Programmable Logic Controllers but systems connected to the interlock system can request and respond to interlock events. An event bus is used to pass chop and nod synchronization signals between systems. Finally, all VME systems are connected to a time bus which carries time encoded in the IRIG-B format.
To appreciate the role of the TCS it should be noted that the TCS is connected only to the Control LAN, the time bus and the interlock system (this latter connection is still under discussion). Thus, the TCS does not control any hardware directly itself but does so by sending commands to its subsystems. The TCS has a key role in relation to the Time bus as it is the bus ``master'', i.e., it provides the master timing signal for the other VME systems. The TCS gets its time information through a Bancomm 637 card connected to a GPS receiver.
The structure of the TCS software is hierarchical. The observer and operator interact with the TCS by sending commands to the Observatory Control System which the TCS in turn sends on to its subsystems.
The Gemini project has adopted EPICS (Experimental Physics and Industrial Control System) as the environment in which to run these applications. EPICS was initially developed by Los Alamos National Labs for control of particle accelerators. EPICS incorporates a real-time database consisting of both hardware and software records. Writing to the fields of these records causes processing in the database. EPICS also provides a number of client programs that run on the host. In particular, the display editor and manager allow easy construction of graphical interfaces to control and monitor the database. The communication mechanism between the host and the VxWorks system is Channel Access. This provides connection management as well as set, get and monitor capabilities on the records in a database.
One problem with EPICS from the GCS point of view is that it does not support the concept of commands. If a client sets a value in the database and this causes the database to process then there is no built in mechanism that informs the client when the processing is complete. The designer of the database must provide a record that the client can monitor in order to tell when the action it initiated has finished. To ensure this is done in a consistent manner over all the Gemini systems two new record types called the Command Action Directive (CAD) and Command Action Response (CAR) have been produced by the Gemini Project Office. The way in which these records are used is as follows :
Each command in the system has associated with it a CAD record of the same name and a corresponding CAR record. To activate the command in the database a client will first set the parameters of the command into the input parameters of the CAD and then activate the command by writing to the Trigger field. On receipt of the trigger a subroutine attached to the record is run which validates the input parameters. If the parameters are invalid then the Accept/Reject field will be set to Reject and a description of the cause of the rejection will be written to the Reason field. There is then no further processing in the database. If the parameters are valid then the input parameters are written to the output parameters and a Forward Link is triggered. Forward Links in EPICS cause the record to which the link is pointing to process. The first thing the link will do is set the CAR record Status out field to BUSY. What happens next will be command specific---e.g., it might be that the command is to move a filter wheel or slew the telescope. Whatever the action is, when the operation is complete the database must write either DONE or ERROR into the Status out field. If the action ended in error (perhaps the filter wheel never got to the requested position) then an appropriate message can be placed in the Message out field.
These records thus provide a standard means for a client to trigger processing in a database and discover when processing is complete.
The Gemini TCS is a development of control systems for existing telescopes, particularly the AAT, UKIRT and the WHT. It is built around the concept of a virtual telescope but extends this idea to include control of the guide probes as well as the optics. In the virtual telescope model the user interacts with an ideal device. The imperfections of the real hardware are hidden by layers of software.
The first part of the TCS software is the pointing engine. It is the job of this code to take the user's input coordinates and pass them through the pointing transformations in order to generate azimuth, elevation and rotator position angle as well as demands for the enclosure and shutters.
The pointing transformations themselves are constructed as a series of cascaded loops. The fastest of these runs at 20 Hz and produces timestamped azimuth, elevation and rotator position angle to send to the mount, rotator and enclosure. As far as possible all astrometric calculations are done with full rigor.
Whereas it is the responsibility of the pointing engine to align the mount, the virtual guider has the job of aligning the WFS probes with a chosen guide star. The virtual guider is structured very much like the pointing engine except that it starts with the RA & Dec. of the guide star and uses the wavelength of the star/guider combination in its calculation of refraction. Using the azimuth and elevation of the rotator axis as computed by the main pointing flow, the virtual guider can then calculate the tangent plane coordinates of the guide star together with the focal position, allowing for optical distortions and any probe flexure model.
Control of slow tip/tilt and translation of the Primary and Secondary mirror is handled by a process that models the flexure and movement of the mirrors as a function of elevation and temperature. The models are maintained in the TCS so that it can coordinate displacements of the optics with compensating adjustments to the mount in order to ensure a target stays at a fixed point on the detector. The model for the forces that are to be applied to the Primary to maintain its shape under the varying gravity vector and thermal loads is maintained in the PCS. This model will be derived by observations with the high resolution WFS.
The description so far has concentrated on the open loop operation of the TCS. The normal mode of operation will be closed loop. In this context closed loop means that correction signals are applied to the open loop model demands from one or more PWFS. The purpose of closed loop control is to correct for all non-repeatable sources of error both of pointing and image quality. The errors we are concerned with are:
The final major component of the TCS software is a process to calculate the expected signal from the PWFS. Given the position of the WFS in the focal plane and the coordinates of the guide star, the expected outputs will be calculated as a set of Zernike coefficients. The measured Zernike coefficients will be rotated into a coordinate system fixed with respect to the optics and averaged as necessary. Any differences will then be sent to the appropriate subsystem for correction. Wavefront errors other than tip/tilt focus or coma can only be removed by the primary mirror. The differences between expected and measured coefficients which are sent to the PCS are multiplied by an influence matrix and the resulting forces added to the open loop demands to the actuators.
Since tip/tilt and focus data bypass the TCS and are sent directly from the PWFS to the secondary mirror, the secondary control system maintains an average of these signals which the TCS can monitor. Any DC term that builds up is passed as a correction signal through the pointing engine to the mount. The effect of this will be to cause the measured DC term to tend to zero and hence for the secondary to tip/tilt about its nominal central position.