Äîêóìåíò âçÿò èç êýøà ïîèñêîâîé ìàøèíû. Àäðåñ îðèãèíàëüíîãî äîêóìåíòà : http://www.arcetri.astro.it/science/irlab/doc/adass_94.ps Äàòà èçìåíåíèÿ: Thu Jul 28 18:22:04 2005 Äàòà èíäåêñèðîâàíèÿ: Sat Dec 22 06:55:24 2007 Êîäèðîâêà: Ïîèñêîâûå ñëîâà: arp 220

Distributed Software for Observations in Near Infrared
V. Gavryusev 1 and C. Baffa
Osservatorio Astrofisico di Arcetri
E. Giani
Dipartamento di Astronomia, Universit`a di Firenze
Abstract. We have developed an integrated system that performs as­
tronomical observations in Near Infrared bands operating two­dimensional
instruments as the Italian National Infrared Facility's ARNICA and
LONGSP.
This software consists of several communicating processes, gener­
ally executed across network as well as on a single computer. The user
interface is organized as widget­based X11 client; the interprocess com­
munication is provided by sockets and uses TCP/IP.
The processes denoted for control of hardware (telescope and other
instruments) should be executed currently on PC dedicated for this task
under DESQview/X, while all other components (user interface, tools for
the data analysis, etc.) can work also under Unix. Hardware independent
part of software bases on Athena Widget Set and is compiled by GNU C
to provide the maximum portability.
1. Design
The design of a data acquisition package is, as always, a long struggle between
many different and contrasting needs. Also we bear in mind the fundamental
consideration that a software which give the user fast operation and a immediate
feeling of data quality raise total (system plus operator) efficiency. This has the
same effect of a bigger telescope or a more sensible instrument.
For effective support of the observations by Arcetri two­dimensional infrared
instruments we need to put together a cheap hardware, an easy and intuitive
user interface, the fastest data acquisition, the best quick look possible, a com­
plete data documentation, an infinite and safe data storage, code reuse and the
possibility to shift to a more powerful platform.
As usual we were forced to choose a median path between these contrasting
pushes. We used, as a start, an AT­Bus based machine for hardware constraint.
But we understood that nor vanilla DOS neither Windows can do the work
(Baffa 1991). That happens for different reasons: DOS is short of memory
1
Visiting Astronomer, Nuclear Physics Institute of Moscow State University, Moscow, Russia
1

and lack multiple processing, while Windows is slow and lack completely the
code reusability we wished. We finally chosen to use DESQview/X and GNU C
compiler as a reasonable compromise between different needs (Gavryusev et al.
1993, Di Giacomo et al. 1993).
From DESQview/X we get an X graphical server, so we have excellent
code reusability, a native DOS Extender to have less memory concern and the
ability to run in a DOS­like exclusive task mode, which give us not a real­
time environment but a workable time control over 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 network, so we can get data at telescope,
control the instrument from Firenze in Italy and display data on a computer in
Baltimore.
2. Structure
It is always the best choice to solve independent tasks by independent software.
The independently executed parts can be compiled also by different compilers (if
necessary), debugged separately and their subsequent versions will not influence
other parts of software (if interface demands are followed). The situation is
the same as with the usage of DLL libraries. Moreover, if the interprocess
communication interface includes support of networking, the software becomes
immediately a 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 easy change them only for experienced persons.
In our case we have individuate the next tasks:
ffl graphic user interface
ffl display of frames
ffl hardware interface
ffl data transfer between computers
These tasks are solved by different processes, generally more then one for
each task when it is preferable. The interprocess communication is provided by
sockets and uses TCP/IP if the processes are executed on different computers.
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). It will be possible because instrument dependent parts of software
can start or finish their work dynamically or depending on the contents of easy
editable resources file for current session.
The Figure 1 shows the tipical view of the screen during the observations.
There are the window with main menu (marked xnir), the control/informative
window of acquisition process (marked ACQUISITION) with open display of
the current image, obtained from ARNICA during the Single Frame measure­
ments (marked Image (acquisition)). The menu for starting of the frame viewer
2

Figure 1. The tipical view of screen during the observations.
3

(marked Display Frame) is open too, as well as the viewer window (SAOimage)
is presented.
Acknowledgments. We are grateful to R. Stanga and F. Lisi for useful
discussions, to A. Di Giacomo for some of the preparation work and to prof.
F. Pacini who have invited one of us (VG) to Arcetri.
References
Baffa C., 1991, Arcetri Technical Report 11/91
DESQview/X User Guide, 1993, Quarterdeck
Di Giacomo A., Giani E., Baffa C., 1993, Arcetri Technical Report 4/93
Gavryusev V., Giani E., Baffa C., 1993, Arcetri Technical Report 6/94
Gennari S., Vanzi L., Ucla Conference, 1993
Lisi, F., C.Baffa, L.K.Hunt, 1993, SPIES's International Symposium on optical
Engineering and Photonics in Aerospace and remote Sensing, Orlando
4