Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.adass.org/adass/proceedings/adass00/reprints/P1-17.pdf Дата изменения: Wed May 30 01:22:20 2001 Дата индексирования: Tue Oct 2 10:34:56 2012 Кодировка: Поисковые слова: п п п п п п п

Astronomical Data Analysis Software and Systems X ASP Conference Series, Vol. 238, 2001 F. R. Harnden Jr., F. A. Primini, and H. E. Payne, eds.

The Stellar Sp ectra Acquisition, Reduction, and Archiving Systems at the Ondejov Observatory 2-meter Telescop e r
Petr Skoda, Jaroslav Honsa, Miroslav Slechta Astronomical Institute of the Academy of Sciences of the Czech Republic, 251 65 Ondejov, Czech Republic r Abstract. The 2-meter telescope of the Ond jov Observatory near re Prague is a middle-class instrument fully devoted to high dispersion stellar spectroscopy. The data are produced by two acquisition systems of different generations. The older linear detector Reticon 1872 AF is controlled by a DOS program providing quick-look display capability as well. The second is a CCD driven by a stand-alone Linux program. The quick-look is provided by SAOimage or XImtool through data pipes. An easy access to both the raw and reduced data is provided by a simple WWW-based archiving system. We give a basic overview of these systems and software methods used for their communication with the spectrograph control system.

1.

Scientific Instruments

The 2-meter telescope built by Carl Zeiss, Jena, was put into operation in 1967 and since the beginning it was devoted to high dispersion spectroscopy of earlytype (mainly Be) stars in its 64-m coudґ focus. The plate archive of the 2-m e telescope contains almost 6000 spectral plates exposed until the beginning of year 1993, when the Reticon AF1872 detector was commissioned. Using it, more than 4000 stellar spectra were secured, giving with calibrations a total of 16600 frames until the end of the year 2000. The Reticon was then replaced by a new CCD camera with ISA 2000 в 800 chip. 2. The Spectrograph Control System Overview

All detectors are installed in the coudґ spectrograph which can operate either e with the 700 mm or the larger 1400 mm camera. In the summer of 1998 the oldfashioned manual control was replaced by a new microcontroller-based system which takes care of a number of controlled devices: Flat field lamp - to switch on the pro jector flat. Flat field mirror - to tilt the mirror into the lightpath. Comparison arc lamp - to switch on the ThAr lamp. Comparison arc mirror - to tilt the ThAr lamp mirror into the lightpath. Grating - to set desired angle by AC motor, measuring by incremental angle encoder, two limit sensors. Slit - to set desired slit height by stepping motor, two limit sensors, the position 423 c Copyright 2001 Astronomical Society of the Pacific. All rights reserved.


424

Skoda, Honsa, and Slechta

must be reset by driving to the limit sensor. Col limator mask - to set desired mask (open, close, open-left, open-right) by rotatingmask wheel by AC motor, optical encoders are used to recognize masks. Dichroic mirrors - to set desired dichroic mirror by rotating wheel with mirrors by stepping motor, optical encoders are used to recognize actual position. Spectral filters - to set desired filter by rotating filter wheel by stepping motor, optical encoders are used to recognize actual position. Focusing the 700 mm and 1400 mm camera - to set desired position by stepping motor, two limit sensors. Correction plate for 700 or 1400 mm camera - read-only signal to distinguish the plate position (in beam, out of beam, intermediate). Exposure-meter - to start/stop countingpulses from photo-multiplier, to measure frequency (per second) and sum of pulses during exposure, to zero this sum. The spectrograph control system is based on these ideas: · Each controlled device in the spectrograph has its own driver unit based on a single-board microcontroller. All units are connected to a common serial line bus. · The main unit periodically reads the status of controlled devices and sends commands to driver units over this line. This unit is connected to the serial port of the control computer. · The control computer runs a daemon which is used like a server for clients running on an arbitrary computer in the local net. 2.1. Server for Communication with Spectrograph Driver Units

The server runs as a daemon on the control computer and is started at system startup. After startup the server forks into two processes: · Process-1 listens on one port for a UDP connection from a client and replies with status data from controlled spectrograph devices on the same port. It also listens on second port, reads a command from it, converts to a special format, and sends to a serial port of the local host (to main control unit). · Process-2 periodically reads the serial port of the local host and saves the data to memory shared with Process-1. This configuration has several advantages. The server itself knows at every moment the status of controlled devices and can send the answer immediately to a client; the spectrograph may be controlled from any computer which is connected to Ethernet and is allowed to do so; the client can be linked to various programs and so it can extend their functions; and several clients can run at the same time, some of them only monitoring the status of the spectrograph. The only disadvantage is that it does not work for DOS machines. 2.2. Client-1 - Monitor and Control Program of Spectrograph

This program shows the status of all controlled spectrograph devices and allows the user to control them. The program is written in Tcl/Tk. The client part for communication with the server is written in C as a set of functions compiled as shared libraries by SWIG. This organization radically simplifies the design of new monitor and control programs since the routine work of making a TCP/IP


Stellar Spectra Systems at Ond jov Observatory re

425

connection to a computer, reading data from it, sending data to it, or closing the connection is reduced to only four Tcl-like functions. Using these functions is enabled by a load my library.so command at the beginning of a Tcl program. 2.3. Client Part of a Program Controlling CCD

The client for communication with the server is included in a large program which controls the CCD. A function which establishes a UDP connection to the server is called at the start of the program and at the end, after quitting other functions, and closes the connection. The function for getting data from the server is periodically called in a loop during the execution of the program. It displays the status of the CCD. The function for sending commands to the spectrograph is called whenever the CCD needs a change of status of a spectrograph device. The program then waits for the finish of the change--it is sometimes unpleasantly time demanding. The function for readingdata from the server must be designed to anticipate possible failure of the UDP connection. The wait for a reply after sending a request for data is limited by a timeout. The timeout is made by a system call of the alarm() function. 2.4. Spectrograph DOS Driver

The reticon 1872 AF detector is controlled by a home-made ISA card (containing PIO 8255 and timer 8253) and driven by the program creticon, which was written in Turbo Pascal 5.5 and contains time-critical code for the synchronous Reticon readout. This was achieved by disabling interrupts, including waiting loops and direct reading I/O port with embedded assembler commands. Most critical and time-consuming was the tuning of the loops to fit the particular computer's (alkaid) speed and compiler options. As this program cannot easily be replaced due to its complexity (it is also taking care of the target star catalogues, maintaining the observing logs, providing the simple debiasing and flat-fielding, as well as the quick-look display and many more services). We decided to change only several small routines that make the very calls to hardware. As the new spectrograph controlling computer mizar is a stand-alone Linux machine connected to the ethernet network, we needed an easy way of reading the status of devices and sending them commands over the network without the need of fundamental changes in the code. The solution we have developed is quite tricky: · We have installed the TCP/IP stack called PCTCP by FTP Inc. on the DOS machine alkaid. · At the top of this stack was installed the NFS client called Interdrive. · The small partition /home/coude on the Linux computer mizar is NFS exported using the pcnfsd and mounted as the logical drive Q: on alkaid. · When the creticon program is run the special daemon couded is started on mizar using a rsh command. The daemon periodically reads the status of the devices from the serial bus and writes the results in a short ASCII file /home/coude/data1 each second. · The daemon waits 200 msec to give the client enough time to read the data by simple Pascal readln from Q:data1 into an memory array. After that the file is deleted and new one written with updated status.


426

Skoda, Honsa, and Slechta

· Each status file also includes unique counter which is incremented after new data from the serial bus units is read. So the client only checks this number, and when it is the same, it does nothing. · At thesametimethe presence of thefile command is checked by the daemon expc on the mizar. When the DOS program sends a command to the particular device it will create the file Q:command with simple commands like FF=1 exit. · If the file /home/coude/command exists, it is opened by expc and the commands for the driving units sent through the serial line. After finishing all hardware changes the file command is deleted by the daemon. · Before the opening of files on the client side the existence of them should by checked by the IOResult routine in loop. The quite interesting result of this setup is the speed of status updates though NFS--more than 250 readouts per second. The unique counter is very good for timeout control in case the communication is broken. 3. Data Reduction and Analysis Software

At present the most important data for the current research at Ond jov are re the Reticon electronic spectra. They are small (about 4 kB) and quite simple to handle. For the basic reduction and analysis of these data a proprietary program SPEFO1 written by J. Horn has been used for years in the stellar department. The new spectra from the CCD detector (about 3 MB per image) are processed by standard packages in IRAF. All the necessary FITS headers are provided by the data acquisition software. 4. Data archiving

In order to be able quickly find the detailed information about the exposure of a particular spectrum (plate or Reticon file) a SQL-based archive of observing logs has been under development in the Stellar department. Its preliminary version is based on the free RDBMS PostgreSQL and a Web interface, WDBI, is accessible on the 2-m telescope home page2 . The raw data will not be available on-line (due to its specific nature as a result of long-term monitoring observation) but those interested may contact the staff of the stellar department by e-mail to stelveda@sunstel.asu.cas.cz. Acknowledgments. This work was partially supported by the Ministry of Education, Youth and Sports of the Czech Republic (grant LB98251).

1 2

http://iraf.noao.edu/ADASS/adass_proc/adass_95/skodap/skodap.html http://stelweb.asu.cas.cz/