Äîêóìåíò âçÿò èç êýøà ïîèñêîâîé ìàøèíû. Àäðåñ îðèãèíàëüíîãî äîêóìåíòà : http://www.arcetri.astro.it/science/irlab/doc/xnir_proj.ps Äàòà èçìåíåíèÿ: Thu Jul 28 18:23:22 2005 Äàòà èíäåêñèðîâàíèÿ: Sat Dec 22 07:01:31 2007 Êîäèðîâêà: Ïîèñêîâûå ñëîâà: http www.astronomy.ru forum index.php topic 4644.0.html

V.Gavryusev 1;3 , E. Giani 2 , C. Baffa 1
1 Osservatorio Astrofisico di Arcetri
2 Dipartimento di Astronomia, Universit`a di Firenze
3 Moscow State University, Moscow, Russia
Arcetri Technical Report N
ffi 6/1994
Firenze Gennaio 1994

Abstract
The present report describes the project to realize a new pro­
gram for the control of the infrared instruments ARNICA and
LONGSP. We have chosen as general approach the develop­
ment of our software as open distributed system, based on X11
standards. Hardware support will be isolated in device--dependent
modules. It permits to support both instruments ARNICA and
LONGSP by the same software and offers a softer transition
to the GALILEO instrumentation system. New possibilities
for data analysing during the observations are provided for ob­
servers.

The Arcetri instrumental group has developed two new instruments
based on the recently avaible large panoramic detector for near in­
frared: a widefield camera (ARNICA [1] ) and a longslit spectrometer
(LONSGSP [2] ). At the present both instruments are managed by one
control program, NIRTEST, developed nearly two years ago.
NIRTEST is a laboratory program that provides really basic data ac­
quisition capabilities and some tests to verify the various sub--systems
and from then some features has been added in order to be able to
get data at the telescope. Its graphic interface is quite simple: it is
organized in a main menu with several options to set the necessary ac­
quisition parameters and to start the different operations (data acqui­
sition, display of data, re­initialization of the devices etc.). Currently
it runs under MS­DOS and under DesqView/X. At the beginning of
the infrared camera's software project it was already shown [3] that the
control program should be so easy and efficient in use as only possible
and has to be powerful enough, because the principal task of such
program is to put the observer in the best working situation. That is,
the user has not to spent the observing time to learn how to use the
control program and to execute the different procedures but should
have the flexible way to control the observing process.
The existent program shows good enough features from this point of
view during the exploitation in real conditions while, of course, there
is a place to make it better. This report contains our present view
how to make things better. We would like to provide for observer re­
ally multi­task environment, standard X11 user interface, distributed
across network software (as much as it could be useful).
At the present day there are several operating environments that help
a DOS user to rise his working capabilities keeping intact his DOS
dependent software. Among them there are DesqView/X [4] and Win­
dows 3 [5] .
Windows 3 has powerful graphic user interface and is used very
widely now. It provides also task--switching. DesqView/X is a better
approximation to a multitasking environment, it permits to execute
concurrently many DOS applications in different DOS windows (one
has not to do anything to make his preferable application DesqView
compatible, in a great number of cases they will work as on native
1

DOS) and it provides the easy way to define critical sections of the
program which has not to be disturbed during the execution (very
important feature for the software whose main aim is to control de­
vices). DesqView/X offers also the X11 user interface, hence the PC
immediately becomes to be workstation when it is included into net­
work. X11 is now the standard of user graphic interface across any
kind of networks and any kinds of computers and operating systems.
The software developed in this standard can be easily ported to any
system across network, while the software developed in MS Windows
environment can be executed only there. We have to think about the
portability because the next generation of infrared instruments could
be based on other then PC hardware, such as UNIX workstations. We
would like to provide the observer the possibility to execute some time
consuming parts of software on UNIX based powerful workstations or
at least to display there some information, so we have chosen to work
with DesqView/X.
As programming language we will continue in using the C language
but, instead of the Microsoft 6.0 compiler, used in compiling the pre­
vious program, we have preferred to work with the 32--bit compiler of
GNU that represents the natural choice in the DesqView/X operating
environment.
Such compiler is a powerful environment to transfer and to use
UNIX programs on hardware Intel (80386 and 80486) and it also per­
mits to fully use the mathematical capabilities of these processors.
The same compiler can be used for compilation of that part of our
software which can be executed on the UNIX workstations as well as
on PC.
We have already successfully worked with this compiler in trans­
porting, from UNIX to MS--DOS environment the display package
SAOIMAGE [6;7] .
To guarantee a correct development and good maintenance of our
program we have decided to use the software tool RCS (Revision Con­
trol System).
It manages multiple revisions of files, automates the storing, retrieval,
identification and merging of revisions.The necessity of maintaining an
efficient organizazion of the global work, is more stringent when the
developers of a software project are more than one (as in our case).
Before describing the organization of our program, we want briefly
explain the different choices of programming tools that can be used
2

under a X Window System.
A X Window System is composed of three different parts: the
X Server, the X Client and the X Protocol. The X Server is the
application that controls the display, the keyboard and the pointer and
it produces the graphical output when another process called X Client
does a graphical output request. These applications interact through
a continuous exchange of information and messages that constitute
the X Protocol.
The whole of graphical requests that a X Client can send to a X
Server are already built in the Xlib library which represents the lowest
level interface between the X Client and the X Server. The Xlib library
only satisfy the application request without giving any kind of
look to it; the real appearance of the graphical output is deter­
mined by the X Toolkit which, in general, can be considered divided
in two parts: the Intrinsics and the Widgets set: the first provides the
functions and mechanisms to build user--interface elements while the
second supplies a set of abstract data objects (called widgets) such
as menus, dialog boxes, scrollbars, command buttons and so on, that
determine a particular user interface. It results in different graphical
interface styles determined by different sets of widgets.
The most known widget sets are:
ffl Athena Widget Set
ffl OPEN LOOK
ffl OSF's Motif
The simplest one is the Athena Widget Set which is distributed free
along with the MIT X Window System distribution and, although
the others are more quite complete and have a better appearance, we
have chosen the first to write a program as standard and portable as
possible.
Under DesqView/X we have always the limitation of 640 Kb for the
execution of one single DOS­prepared process. A way to avoid, or bet­
ter, to trick this limitation is to divide the global process in small tasks,
each one executes a precise operation. Of course our choice of GNU C
compiler permits too to avoid this limitation. But such sub­dividing
follows not only from memory limitations. It is always the best choice
to solve independent tasks by independent software. The indepen­
dently 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. More­
over, if the interprocess communication interface includes support of
3

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 per­
mission 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
It is important to remember that we plan to use the same con­
trol program (without recompilation) for the two different infrared
instruments: ARNICA and LONGSP (in future, the support for new
instruments can be added). 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. We are now going to discuss how we will wish to organize
each single task.
3.1 User interface
The graphic user interface consists in the main shell (or menu or
widget) which should integrate the control of all sub­tasks and task­
dependent interfaces solving particular problems of information, cur­
rent dialogs and possible data presentation.
To organize our work, we have started from the previous planning
of NIRTEST program dividing the total set of options between `com­
mands' and `variables setting'. We have tried to maintain the same
names for the command and information options to simplify the work
of the future users of this program. The main window has been di­
vided in two sub--windows.
The left one is organized in a set of command buttons (several frames,
single frame, free run, display frame, focusing, saturation, test device,
setup, exit and maybe others) vertically disposed, each one allows to
start an operation (sub­task maybe).
The right window lets the user to insert the acquisition variables (as in­
tegration time, number of groups, number of measurements for group
etc.) and information (as observer name and source name) typing
them in the right position.
4

The choice and selection of any of these buttons or text windows can
be done moving the pointer and selecting the item with the mouse
buttons or using particular keys combinations (such as CTRL!key?,
ALT!key?).
One of the improvement we have brought is the choice of the filters
and the mosaic files (and also the diaphragms for LONGSP) that now
can be done by the selection of the corresponding item from a pre­
defined lists. This procedure simplifies the user operation since one
has not to remember (as instead happens with the previous program)
the conventional names attributed to each filter, file or diaphragm.
Moreover, together with the name of the filter, file or diaphragm we
can provide other useful information as the filter's range wavelength,
the diaphragm dimension or any kind of comments. We provide also
additionally the 'SETUP' button that will permit to configure the
system dynamically.
3.2 Display of frames
Under DesqView/X we have now the possibility to use the display
package SAOIMAGE which provides the lot of possibilities to manip­
ulate images. This package was ported from the UNIX where it is
used usually for offline analysis. So we have a good instrument on any
node of the network and we will chose it as an instrument to analyse
the data taken during the observation and already stored on the disk.
It will be implemented in the control program through the 'display'
command. This command will provide small sub­menu for easy choos­
ing of the source file to be displayed and then will start SAOIMAGE as
separate (and completely independent) process on the local computer
or anywhere, depending on the user choice and default environment.
Because it is a real X11 package, images can be displayed on any avail­
able screen across the network. The observer can start more then one
such display process, providing the information for other people or for
himself for the quick comparison of the data.
Practically there are no restrictions on the choice of the existent
package for reduction of the data to be used as a display instrument
in our software and, moreover, we can also use several display package
at the same moment. Of course, the chosen package has to fit into the
memory and performance of that computer where it is executed.
3.3 Hardware interface
The hardware interface includes all that part of software that executes
the initial tests on the instruments and their connections, intializes
5

them and, when requested during the working session, moves them.
This task can not be organized as completely independent process
only started from the main menu. There should be continuous inter­
process communication between this process and main user interface.
Some interactions toghether with the presentation of the information
about the execution situation can and should be supported indipen­
dently of the main menu.
We plan to extract from NIRTEST program all the routines serv­
ing the hardware and to add some restricted, Xt based graphic user
interface in the same way we did for the main menu. At the moment
we think this process should start at the very beginning, in parallel
with the main menu.
3.4 Data transfer between computers
At the present the transfer of the data obtained during the the obser­
vations happens at the end of the night. The process of data transfer
is not executed by the control program: it is a separate task. There
is always some idle time during the observation, so theoretically the
transfer of the data can be executed by low level priority during the
time of the observation. Moreover, if we really like to look for the data,
executing SAOIMAGE on powerful workstation like SUN (it will be
nice because of their high performance), we need to transfer some data
there during the observation.
In our approach it can be easy to provide such possibility adding
the corresponding button to the main menu, but we can also use
the FTP protocol supported by the DesqView/X and, in the future,
we can use the NFS network service included in the last version of
DesqView/X.
We don't want to put any limitation to our work, so this last
point will have to be discussed in deeper manner and, even if we don't
implement this task in the first version of our program, it can be done
in the future.
In present report we have tryed to illustrate the choices we have done
in development of the program for two infrared instruments ARNICA
and LONGSP.
Starting from the previous control program, we are developing a new--
step software designed and realized to run under DesqView/X. The
choice of such working environment permits us to improve the fea­
tures of the old control program, obtaing an easier and more efficient
6

observative program. The approach, discussed here, offers the possi­
bility to develop logically different parts of the program separatly and
prepare them for running on different computers, where it is possible
and useful. It offers also new possibilities for the observers. The in­
tegration of the new hardware, which properties are unknown at the
moment is facilitated. It is important in view of the Galileo project.
7

[1] Lisi, F., 1991, ARNICA ­ La camera IR di Arcetri, Arcetri Internal
Report 16/91
[2] S.Gennari.,1991,Il punto sul progetto LONGSP, Arcetri Technical
Report 3/91
[3] Baffa C., 1991, Arcetri Technical Report 11/91
[4] DESQview/X User Guide, Quarterdeck
[5] MS Windows 3.1, Microsoft Corporation.
[6] User Manual for SAOIMAGE, Van Hilst M., Harvard/Smithsonian
Center for Astrophysics, Cambrige, Massachusetts.
[7] Di Giacomo A., Giani E., Baffa C., 1993, Arcetri Technical Report
4/93
8

Figure 1: Main menu
9