|
Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://www.adass.org/adass/proceedings/adass94/gavryusevv.html
Дата изменения: Sat Nov 4 01:46:25 2000 Дата индексирования: Tue Oct 2 03:31:03 2012 Кодировка: Поисковые слова: п п п п п п п п п п п п п п р п р п р п р п р п р п р п р п |
1632 kB PostScript reprint
V. Gavryusev and C. Baffa
Osservatorio Astrofisico di Arcetri,
Largo E. Fermi, 5,
Firenze, 50125 Italy
E. Giani
Dipartamento di Astronomia, Università di Firenze
Visiting Astronomer, Nuclear Physics Institute of Moscow State University, Moscow, Russia
The processes denoted for control of hardware (telescope and other instruments) should be executed currently on a PC dedicated for this task under DESQview/X, while all other components (user interface, tools for the data analysis, etc.) can also work under UNIX. The hardware independent part of software is based on the Athena Widget Set and is compiled by GNU C to provide maximum portability.
The design of a data acquisition package is, as always, a long struggle between many different and contrasting needs. Also, we have to bear in mind the fundamental consideration that software which gives the user fast operation and an immediate feeling for data quality raises the total (system + operator) efficiency. This has the same effect of a bigger telescope or a more sensitive instrument.
For effective support of the observations of the Arcetri two-dimensional infrared instruments, we need to put together cheap hardware, an easy and intuitive user interface, the fastest data acquisition, the best quick look possible, complete data documentation, infinite and safe data storage, code portability, and the possibility of shifting to a more powerful platform.
As usual, we were forced to choose a middle path between these conflicting requirements. As a start, we used an AT-Bus based machine for hardware construction. However, we found that neither DOS or Windows will do the work (Baffa 1991). This is due to a number of reasons; DOS is short of memory and lacks multi-tasking, while Windows is slow and completely lacks the code portability we wanted. We finally chose to use DESQview/X and the GNU C compiler as a reasonable compromise between our different needs (Gavryusev et al. 1993; Di Giacomo et al. 1993).
From DESQview/X, we get an X server, so we have excellent code portability, a native DOS Extender to have fewer memory problems, and the ability to run in a DOS-like exclusive task mode, which gives us a workable time control over our data acquisition (DESQview 1993). We can compile and run most of our modules on different platforms---PC's and workstations, under DESQview/X and UNIX. We can spread our processes over a network, so we can get data at a telescope, control the instrument from Firenze in Italy, and display the data on a computer in Baltimore.
It is always the best choice to solve independent tasks by independent software. Independently executed parts can be compiled by different compilers (if necessary), debugged separately, and their subsequent versions not influence other pieces of the software (if interface demands are followed). The situation is the same as with the use of DLL libraries. Moreover, if the interprocess communication interface includes support for networking, the software immediately becomes network distributed software. Such organization of the program can, in principle, cause some complexity from the point of view of the user, but this problem can be covered by providing well chosen default options and the permission to easily change them only for experienced users.
In our case we have to differentiate between a number of tasks: (1) a graphical user interface, (2) the display of images, (3) the hardware interface, and (4) data transfer between computers. These tasks are solved by different processes, generally more then one for each task when it is possible. The interprocess communication is provided by sockets and uses TCP/IP if the processes are executed on different computers.
Figure: The typical view of screen during the observations.
Original PostScript figure (1593 kB)
It is important to remember that we plan to use the same control program (without recompilation) for the two different infrared instruments: the camera ARNICA (Lisi et al. 1993) and the long slit spectrograph LONGSP (Gennari et al. 1993). This should be possible because the instrument dependent parts of the software can start or finish their work dynamically, or depending on their contents, an easily editable resource file for the current session.
Figure 1 shows the typical view of the screen during an observation. There is the window with main menu (marked xnir), the control/information window during the acquisition process (marked ACQUISITION) with an open display of the current image, obtained from ARNICA during the ``Single Frame'' measurements (marked Image (acquisition)). The menu for starting the frame viewer (marked Display Frame) is shown with a submenu that has a default list of the hosts where the display can be sent. In addition the view-window (here, SAOimage) is open as well.
We are grateful to R. Stanga and F. Lisi for useful discussions, to A. Di Giacomo for some of the preparation work, and to Professor F. Pacini who invited one of us (VG) to Arcetri.
DESQview/X User Guide 1993, Quarterdeck
Di Giacomo, A., Giani, E., & Baffa, C. 1993, Arcetri Technical Report
Gavryusev, V., Giani, E., & Baffa, C. 1993, Arcetri Technical Report
Gennari, S., & Vanzi, L. 1993, UCLA Conference
Lisi, F., Baffa, C., & Hunt, L. K. 1993, SPIES International Symposium on optical Engineering and Photonics in Aerospace and Remote Sensing (Orlando, SPIE)
1632 kB PostScript reprint