}

Abstract

The control system for the Apache Point 3.5m telescope utilizes small computers (controllers) to control hardware, and a larger computer (the telescope control computer or TCC) to direct the controllers. The controllers provide fast real-time performance and hardware interfacing; the TCC, a DEC microVAX II, provides raw computing power in a standard multi-tasking environment. Major tracking, guiding, and acquisition computations are performed in the TCC, including correction for physical imperfections and computation of slewing paths.

Introduction

The Apache Point 3.5m optical telescope design includes a fast mirror (f/1.75) and an altitude/azimuth mount to achieve a compact, stiff structure. We expect this mount, combined with precise drive mechanics and a software model for flexure and other physical imperfections, to allow the acquisition of objects to 1 arcsec (rms error) and tracking to 0.2 arcsec over a ten minute period (1, 2, 3). Other notable features of the telescope include quick-change instrumentation (the tertiary may be rotated to direct light to seven instrument positions), high acquisition speed (6 deg/sec), and remote operation (4).

The control system is implemented in two levels of hardware (see fig. 1 ). The mechanical components are controlled by small computers called, naturally enough, controllers. The controllers are, in turn, directed by a single larger computer, the telescope control computer (TCC). In essence, the TCC determines how to move the telescope and the controllers implement the motion.

Figure 1. Overview of the telescope control system.

The controllers provide text-command driven interfaces to the telescope hardware, and perform all fast, time-critical functions such as servo-feedback control. The TCC implements high-level control functions in a powerful but friendly computing environment, with a high-level language, multi-tasking and minimal real-time requirements.

The most important controllers are the axes controllers (azimuth, altitude, instrument rotation and guide camera position) and the guide camera controller. There will be several rotation controllers and guide controller pairs, one for each instrument position requiring these services. Other controllers perform such functions as adjusting the secondary and tertiary, reading the weather station, and controlling the dome. In all, we will have approximately ten controllers in use at one time and more at idle instrument positions; thus it has been our goal to keep the controllers small, simple, and self-contained.

Hardware

The telescope control computer is a Digital Equipment Corporation microVAX II running the VMS operating system. All code is written in VAX FORTRAN, and multi-tasking is implemented with existing VMS system tools. Most of the controllers are 8088 STD-bus computers running FORTH, with time-critical code written in assembly language. Each controller is connected to the TCC via a separate RS-232 serial line.

Time

The TCC and controllers have accurate internal clocks which are synchronized to a WWVB clock. The WWVB clock supplies a 1 Hz pulse with edges accurate to about 1 ms for the controllers, and the full time of day for the TCC. The TCC can reset a controller's internal clock if it loses track of absolute time. The TCC computes sidereal time by interpolating predictions obtained from the U. S. Naval Observatory's Computerized Data Service.

Tracking

All coordinate conversions and telescope model corrections are performed in the TCC. Position commands are sent to each axis controller once per second, one second in advance. A full position command includes position, velocity, and time. Each axis controller performs third-order interpolation to determine position and rate commands for its servo system. On request, an axis controller returns a summary of its recent tracking performance. The tracking error arising from interpolation is completely insignificant. Using a 1 second interval and a forbidden region about the zenith of 0.5 deg the maximum error is far less than 0.001 arcsec.

Our tracking method differs from that used elsewhere. Typically, the main control computer performs all axes calculations 10 or 20 times a second, sending position or velocity, but not both, to the axes controllers or directly to the motors (5, 6, 7). This offers the simplicity of synchronous axes control. However, we feel that our method makes more effective use of the main control computer. The real-time performance requirements are greatly reduced, and different functions may be separated naturally into small, distinct processes. These considerations are especially important in a case such as ours, where the main control computer performs many functions in addition to axes control.

Acquisition

An alt/az telescope offers no natural distinction between tracking and slewing speeds; tracking must be achievable at the same high speeds used for slewing (at least in azimuth). This suggests an economical scheme for acquisition. Instead of implementing special slewing commands in the axes controllers, we use the ordinary tracking commands. To acquire an object, the TCC computes the slew path in advance, then sends it to the axes controllers as a set of position commands. Thus we isolate slewing computations in the TCC, which has computing power to spare, and keep the axes controllers simple.

Guiding

The mechanical distance between the guide camera and the instrument being guided must be kept small for guiding to offer an improvement over tracking. Thus each guided instrument position must have its own guider. The guide controller pair at the current instrument position is connected to the TCC and the others sit idle.

The active guide camera controller determines the position of the guide star in camera coordinates and sends it to the TCC. The TCC converts this position to an alt/az offset (guide correction) and immediately sends it to the altitude and azimuth axes controllers. The TCC also continues to track while guiding, so that the guide corrections stay small.

Using the TCC to convert guide corrections from guide camera coordinates to alt/az greatly simplifies the guide camera controllers. However, it also limits the maximum guide rate to about 10 Hz. Normally this should be sufficient, but if an instrument requires faster guiding, its guide camera controller may talk directly to the secondary mirror controller or axes controllers.

Tasks

Tracking commands are sent to the axes only once a second, yet faster response is desirable for offsets, new positions, and so on. This is provided by multi-tasking (see fig. 2 ).

Figure 2. Major processes in the telescope control system.

The user process interprets and executes all telescope control commands. Thus, among other things, it acquires objects, specifies guide stars, and initiates guiding. The tracking process maintains the telescope's position, once an object has been acquired. Once each second it sends a new position command (position, velocity, and time) to the axes controllers. The guiding process reads guide star positions sent by the current guide camera controller. The guide process converts these positions to alt/az guide corrections, and sends them as offsets to the azimuth and altitude axes controllers.

These processes execute independently of each other, yet all send commands to the axes controllers. To prevent collisions, only one process at a time is allowed access to the axes controllers, and then only for a restricted amount of time. The maximum possible delay for any process attempting to access the axes controllers is thus well defined. The tracking process must not be late, so it starts early enough to compensate for this potential delay.

These processes also maintain a database containing the positions of the object and guide star, and related information. This database is read by the secondary process, which controls the secondary mirror (maintaining focus and collimation) and the atmospheric dispersion corrector.

Finally, a host of small process (not shown) perform infrequently needed tasks. These include reading the WWVB clock, monitoring the weather station, and updating slowly varying coordinate system data such as refraction coefficients and the sidereal time offset.

Acknowledgments

We wish to thank Patrick Wallace, of the Starlink Project, Rutherford and Appleton Laboratories, for assistance with coordinate conversions and telescope pointing models, and Clayton Smith and the staff of the U. S. Naval Observatory, for assistance with coordinate conversions and time.

References

1. W. Siegmund , E. Mannery, J. Radochia, P. Gillett: Proceedings of the SPIE 628, 377 (1986)
2. E. Mannery, W. Siegmund, M. T. Hull: Proceedings of the SPIE 628, 390 (1986)
3. E. Mannery, W. Siegmund, B. Balick, S. Gunnels: Proceedings of the SPIE 628, 397 (1986)
4. B. Balick, R. Loewenstein, D. York: Remote Use of the Apache Point 3.5m Telescope , these proceedings
5. A. Poyner, J. Montgomery: Proceedings of the SPIE 628, 9 (1986)
6. P. Wallace: Proposals for Keck Telescope Pointing Algorithms , 1987 (unpublished)
7. J. Straede, P. Wallace: Pub. As. Soc. Pac. 88, 792 , 1976