TSU is building a 2-m telescope with an alt-azimuth mount for automated observing (high-dispersion spectroscopy). Control of this telescope is through C programs running under Linux, a variant of UNIX, on a several personal computers. Primary functions of the control programs are (1) keeping the telescope pointed at a specified position on the sky throughout the night, which requires driving it continually at constantly varying rates in both axes, (2) deciding which star to observe at a given time, i.e., application of some scheduling algorithm, (3) guiding on stars, (4) exposing a CCD to record the spectra, and (5) monitoring the health of the system. These various functions are divided among several different computers that communicate through sockets over ethernet. An executive computer decides what observations to make through a scheduling routine, monitors the weather and general conditions of the observatory, and decides when to open and shut the observatory. A separate computer physically located on the moving part of the telescope runs the telescope's motion control and guide/acquisition camera. A third computer runs the spectrograph and its CCD. This division of labor ensures that scheduling and motion control are not interrupted by reading the CCD (20-80 seconds per image) and that scheduling does not interfere with motion control.

The heart of the control system is a module that calculates a star's instantaneous coordinates (altitude and azimuth) and their rates of change and feeds this information into servo loops controlling the two telescope axes. To do these calculations, we use a timing board ( TrueTime PCI-GPS with accuracy of 1 µs) to determine the time and a stand-alone controller (Galil DMC-2060 with serial communications) to read the encoders and run the servo loops. Originally, we tried to use an ISA motion-control card (an Optimised Controls NextMove-PC) but found it too unreliable running under our linux driver. The Galil controller has much more capacity than the NextMove card for tracking the encoder counts, as well. The motors being controlled are Compumotor DM1015B's, which have internal incremental encoders for running the servo loops. These are coupled to the telescope axes through friction-coupled rollers giving a reduction of 20 for the azimuth drive and 25 for the altitude drive. Each motor has appx 655,000 steps per revolution, or 14,000,000 steps per rotation of the azimuth axis. Since we have four motors on the azimuth axis, each with a separate drive roller, we can latch, read, and average four encoder values to improve the precision of the position by roughly a factor of two, although this has turned out to be unnecessary. We are operating these drive motors in parallel in torque mode, so we use one channel to calculate the servo loop and the other three channels to collect the observed position of the axis. The servo loop is to be updated 500 times a second in the control card, 10 times a second in software, and about once a second at the guide camera. Similarly, we have two motors and their encoders running the motion on the tilt axis. A separate computer owned by Fairborn Observatory runs the enclosure (front flap and rolling roof). It also collects weather data for the control system to use in deciding whether to keep observing.

The drive rates are continuously variable, 0-15 arcsec/sec (1-150 encoder counts/sec) for altitude and 0-250 arcsec/sec (0-2500 encoder steps/sec) for azimuth for tracking stars at least 3 deg from the zenith. Slewing rates are 70,000 encoder counts/sec (2 deg/sec) for both axes. The drive rates for azimuth sound rather high, but the largest apply only close to the zenith, where the telescope will hardly ever point. Furthermore, tracking motion in the telescope's image plane along the direction of azimuth is reduced by the sine of the zenith distance (along with errors in the drive rate), giving a rather small effective drive rate. In any case, the effective drive rate for both axes combined is exactly the same as for an equatorial telescope and would never be more than siderial. The rate of rotation of the image plane are likewise moderate, except on the meridian near the zenith, where they can approach 90 deg for a 20-min exposure.

We have set up a simulation of the two axes in our lab at TSU, using steel discs to represent the reflected inertia of the two telescope axes. The experimental setup here shows one of the motors and its mount without the reaction wheel, and here we see the full setup. This simulator makes it easy to develop control programs for running tests in the telescope, such as those for repeatability of the axes. Industrial controllers use a PID servo algorithm, with a signal Proporthonal to the positional error, reduced by a Derivative term proportional to the rate at which the axis is approaching equilibrium, but increased by an amount proportional to the error Integrated over some interval of time. The simulator gives a good first stab at choosing the constants in this PID scheme, but the servo requires further tuning in the actual telescope. The telescope drives have a lot more friction than the simulator and require much higher efforts than in the lab, typically 10-15% of full capacity vs. 5%. An effect of this is to require us to use a much softer servo for slewing than for tracking. The PID constants derived in the lab, however, work well in the telescope at tracking speeds.

The control system consists of several separate processes running on a computer in the telescope. They communicate with one another through internal pipes and with an overall control program on a separate computer through an Internet socket. Figure 1 shows this structure, and Figure 2 shows the processes involved and the hardware they control. The control of an alt-azimuth telescope goes beyond the usual control of industrial machinery in that two axes must be positioned to accurate, coordinated positions at precise times. The heart of such a control system is a process that drives the axes, measures their errors, and corrects for these errors. We implement this process by driving the axes at accurately calculated rates through an industrial motion controller. We then check the positions by using a digital output on the motion controller to latch the positions of the axes (which the motion controller knows by summing encoder signals from the motors), and the time from our GPS card. Given the latched time, we then calculate the expected position (azimuth and zenith distance) and compare it with the calculated position. We then use that error to correct the drive rate. We also have errors derived from a guide camera feeding into this control algorithm for further corrections. The same digital pulse can latch the absolute encoders, which give the absolute positions of the axes to better than a arc minute.

The control algorithm has several advantages. First, it does not require latching and reading the positions at precise, predetermined times, so we do not require a real-time operating system. Second, since we are latching the position/time with a signal essentially initiated in software, we can vary the update frequency any amount that's convenient if it's consistent with the speed of the computer and hardware. The update frequency is not critical from the standpoint of accelerations of drive rates. Errors in position build up so slowly during intervals of 0.1 sec or even 1 sec as to be inconsequential. Even intervals of 10 sec might be acceptable in this regard.

The expected pointing accuracy depends on the mount model incorporated into the control system. As of August, 2000, we are expecting to use primarily the corrections for an alt-azimuth mount incorporated into P. Wallace's TPOINT program. These are fairly simple, even logically obvious, given the expected misalignments of such a mount. Details of these corrections are given in our discussion of aligning the telecope under maintenance documents, but in summary the expected misalignments should give uncompensated pointing errors of the order of 2-3 arcmin on the sky and to be dominated by the optical axis not being perpendicular to the tilt axis. Corrections to the azimuth and zenith distance are straightforward to calculate, but the important question is how rapidly they must be reapplied to keep the pointing accurate enough to give adequate tracking. We would like to update these corrections often enough to avoid drifts more than about 0.25 arcsec. The dominant misalignment, nonperpendicularity of the optical axis, gives drift rates of the order of 10 arcsec/min, so an update rate of the order of 1 cps is required near the zenith.

The field of view of the acquisition camera (i.e., the guide camera) is roughly 2.6 arcmin in tilt (altitude, or zenith distance) and 3.5 arcmin parallel to the azimuth. The scale of the instrument is roughly 12.5 arcsec/mm at the Cassegrain focus. The absolute pointing expected with a mount model should be better that 0.5 arcmin from pointing experiments conducted in September and October, 2000, so we expect to get almost all the stars into the field without searching for them. However, we have a spiral search available for cases in which it may be needed, and we tested a preliminary version of this routine in September, 2000. As of April, 2002, the telescope is finding stars reliably in 94% of its pointings on good to decent nights (fewer than 20 stars not found [note circular reasoning, but read on]), and most missed stars have been behind clouds or trees in the west or were too close to the zenith. We assess the these reasons by recording images of the fields for missed stars; very few of them are blank, and those that are tend to be taken on nights with clouds. In fact, the number of missed stars seems to be a pretty good indication of how good the weather was.

Guiding of the telescope is by an acquisition/guide camera that looks at the focal plane of the telescope through a 45-degree flat through which the data fibers project. This engineering drawing shows the arrangement, which is essentially the same as it looks during integration. Since the focal plane of the telescope rotates as the telescope moves to track stars, any guide stars off axis must be tracked through their expected motion. Although for a star 3 deg from the zenith, the field would rotate nearly 90 deg during a 20-minute observation, for most observations, field rotation would be 1-2 orders of magnitude lower.

The guide camera is the same model that Fairborn Observatory is using for acquisition and guiding in three new photometric telescopes and one imaging telescope we are buying from them. The exposure may be controlled easily by writing directly to the ISA bus. We have images of the sky, such as these 2-sec and 8-sec exposures, to use for calibrating the guide camera. In prectice, the camera is sensitive enough for most stars we anticipate observing at high dispersion, although it may be a bit too sensitive at its standard 0.03-sec exposure for really bright stars.

At the heart of the guiding strategy for this telescope is the question of whether to use light spilling over the edges of the fiber, which we would prefer to do for bright stars, or whether to use a guide star within the rather limited field of view of the telescope. We have conducted a study of the availability of guide stars for random fields. It appears that there will be guide stars available in about one half of the fields at most, so we expect to be guiding on light spilling over the edges of the fiber in most situations. Lab tests related to this strategy show that the scale of the guide camera from an image of a 0.1-inch grid is 0.41 arcsec/pixel horizontally (along azimuth) and 0.31 arcsec/pixel vertically (along tilt). Other images of a focus target (Scotch tape on end of the fiber-support probe) indicate it should be possible to focus the guide camera on the tip of the probe silhouetted against a bright sky background. An actual image of the fiber-support probe projected against a bright background in the lab shows a sharp shadow of its tip, roughly 6 arcsec in diameter, and a penumbral shadow cast by the out-of-focus body of the probe. It should be possible to calibrate the positions of the three guide probes during twilight, every night if need be. Also, the images of bright stars can be exposed to the measured size of the tip of the guide probe.

We started tests using a fiber holder (without an actual fiber in place) in April, 2001, and find the control system can place the image of a star on the end of this stalk and keep it there through a rather simple guiding algorithm we have used for our first tests at prime focus. Images of actual stars on the feed looked like the following for a moderately bright star and this for Arcturus. Further tests with a test fiber glued in the probe show this telescope actually gets light through the fiber as measured by a photomultiplier tube lent us by Fairborn Observatory.

This part of the control system runs on the executive computer. As of Fall, 2001, we are using a scheme for selecting stars to observe from a list on the basis of the highest instantaneous priority. Each star has a general priority (but may have a specific time of observation which trumps all other priorities if the observation is possible). The executive computer calculates an instantaneous priority on the basis of some simple rules, somwhat like those in ATIS for our photometric telescopes, that favor stars in the west and in the south and discriminate against long slews in azimuth. As of Spring, 2002, this scheme has worked very reliably in routine pointing/tracking on roughly six months of operations with a scientific instrument. The allgorithm we are using as of April, 2002, tends to favor stars too close to the horizon in the east in both actual operations and in our simulations, so it will probably evolve. We also have yet to put code for making observations at specific times into the executive program for the telescope, but we have verified it with a simulator.

During summer, 2001, we had Allen Keel write a program to simulate the operation of the telescope that has evolved into the scheduling program we actually use to run it. This simulator takes a list of stars to observe, with either priorities for observing them or fixed times of observation, applies some rules to this list to derive an instantaneous priority for each star, and calculates how long the observation will take. The program decides after each simulated observation is finished which star to observe next. Further refinements will be probabilities for various kinds of failures and interference by the weather. We integrated this algorithm into the control system for the telescope (June-Oct. 2001) and used it for extensive tests during Sept.-Oct. 2001. The telescope has run automatically both unattended and with Williamson watching it in real time. All the systems in the control system as of 1 Nov. 2001 seemed to be working reliably, with the telescope finding and tracking up to 150 stars per night, depending on the list of stars we gave it. As a result of these experiments, we expect we may have to change the algorithm for choosing stars somewhat ad develop procedures to update the starlist every few days to get full coverage of all the stars required in our various programs.

We (Eaton and Shawn Vaughns) have extended this simulator to make observations at specific times and to plot the progression of the telescope through the sky. In running a simulation, one puts in the calendar date to observe and a file containing the stars to observe, and the program prints a list of the stars, their priorities and specific times to observe them. It next calculates a simulated schedule, scheduling observations within half their exposure time of specific times as required, and recording how many stars it observed and how long the night lasted. Next, it prints a sequence of stars observed, noting any observed at specific times, such as observation 110 here. It then will plot the stars in the sky in both azimuth-altitude and RA-Dec, along with positions of the Sun, Moon, and any stars with specific times of observation in red. Finally, if desired, it will slowly run a line from star to star to show how the telescope would progress through the sky.

One of the challenges of operating an automatic telescope is protecting it from bad weather and other adverse conditions. This means shutting down gracefully when the wind becomes too strong, or rain threatens, or the Sun comes up. Coordination of the telescope with its enclosure is especially important because the moving roof could actually hit the telescope in most of its operating positions. We are getting information about the weather from a weather station maintained by Fairborn Observatory and used to open and shut the enclosures for the other telescopes. The executive (schedulong) computer gets files giving weather conditions from a computer running the enclosure roof, which has a cron job to transfer them from another computer in the Fairborn-Observatory system. These files incorporate status bytes for various tests used with the photometric telescopes, and we use the status bytes for wind, clouds, rain, and sunlight to decide when to close the AST. Figuring it's cloudy, we also close down if the telescope fails to acquire a running total of ten stars (count of stars found decreased by those found, kept >= 0). In this case, we keep the observatory closed for two hours, then try to continue observing if the weather status is good. We also test for the condition of the power on roughly the same schedule to shut the observatory if it's running on the batteries in the UPS.

The interlock between telescope and roof consists of checks on limit switches by computers that actually run the telescope and roof. The telescope-control computer looks at the state of four switches, two that determine whether the front flap is closed and two that determine whether the roof is retracted enough that the moving telescope would not hit it. The telescope may not move (through a software test) if any switch detects a closed part of the building. The roof drive uses an optical switch looking at a retroreflector on the top end of the telescope to make sure the telescope is stowed before moving the roof. This device has worked well in tests through October, 2001, although its infrared beam was once apparently blocked by a bug. It has also worked in practice when the telescope either did not get completely back to its stowed position or the sensor was again bugged.

We are continuing to think about what information to retain in the log files from the various control computers, although we've pretty much decided this question for the telescope-control and executive computers as of January 2002. Logging for the executive computer consists of two files, one showing the commands sent the telescope computer and responses as a function of time and another recording the pointings in azimuth and ZD. The former gives a chronology of the pointings and information on stars the telescope could not find. In future, it will also include data about the spectrograph. The second file (now largely redundant) gives pointings in a form that can be plotted and compared with similar data from the simulator.

Logging on the telescope computer is intended to record information on status of the oil pump/bearings, on some other critical systems, and on tracking. We record the demand on the servo motors roughly every 3 seconds, both during slews and tracking. This gives a good indication of when the wind is too strong to observe and whether there are problems developing in the drives or azimuth bearing. We also record measured drive errors and offsets in azimuth/zenith distance determined by the guide camera. These data give an idea of problems in the drives and their control software. The log file for the telescope computer runs to about 1MB of data per night. The three logfiles have names of the form c13_?????, azzd_?????, and t13_?????, where ????? is the last five digits of the Julian Date for the middle of the night. In addition to these basic log files, we save offset data to use to update the mount model, an image from a weather satellite near midnight local time, and images of the field when the telescope did not find a star.

To sort out the data in these rather large log files, we have developed a parsing program that looks for various lines in the files, notes known error conditions, and plots up useful information, such as pointings in the sky, torque and errors vs. time, and offsets. Examples of these plots are demand vs. time for azimuth, errors in azimuth and in zenith distance. Pointing errors have been running 3-4 encoder counts (0.3-0.4 arcsec) RMS. We have extended this plotiting in early 2002 to include a plot of the progression through the sky in RA-Dec, fields of view when the telescope did not find the star, and a weather map for midnight.

In a demonstration of an actual application of this quality-control program (8-9 April 2002), it starts out by reading and parsing the logfile from the executive computer, plotting the weather map and the distributions of stars in both azimuth-ZD and RA-Dec. It then reads and parses the logfile from the telescope computer, plots some environmental data (temperatures and humitity), the demand of the motors for AZ and ZD versus both time and position, and the deviations of the axes from their nominal positions in both time and position. If desired, it will then plot the offsets from the nominal positions determined by the guide camera, to determine if the mount model is working properly, and guide-camera fields when the telescope did not find a star, to discover problems with weather, focus, or pointing.

We are controlling the spectrograph with a separate computer which will be housed in the control room (computer to the left in Figure 3). It will (1) configure the spectrograph, (2) control its CCD detector, and (3) monitor of the spectrograph. This computer started out as a Sun workstation running Solaris, but we have switched the control programs for the CCD controller to a PC with linux. We also have obtained a JPEG server to grab periodic pictures of the telescope for viewing on our intranet, which doesn't need to be part of the telescope control system.