Double Beam Spectrograph Software

1.- Basic Components of the system

The ArcVIEW software allows the user to interact with the detector controller for taking images, as well as with the TCS for collecting header info,
and in general with any sub-system connected ot it.

For more information about ArcVIEW itself, see

http://www.ctio.noao.edu/instruments/arcview

1.1 General Software Architecture

The system works on a client-server scheme. The Server  receives requests from the connected clients to execute actions, like sending a command, etc.
After the action has been executed, the Server sends back to the client the response or any error condition.
For the Echelle software, the Client which requests actions, is the main GUI itself. When the main GUI is opened, it connects to the Server (which may be already running on the instrument workstation)
The connection between the Server and the Clients is done using sockets (TCP/IP), which means that the Client (the GUI in this case) doesn't need to be in the same computer that the Server does. This means that the actual GUI can be, if desired, moved away to any other host

Server
The Server loads and calls specific modules for performing any requested command. This means that the actual action is performed for some specific module. This module is the only one which will need to know the internals of the process or the systems that it is handling. For example, if some controller command arrives (ex, EXPOSE), the Server will call to some specific controller module. This module knows how to send the command to the controller (only it knows, for example, about the specific Linux driver and the specific C library that may exist for communicating with the specific hardware). After the action has been done, the Server receives the response from the module, and repeats it back to the client. This modularity allows the software to be independent on any specific hardware, and this is why in the current system it is transparent to the user the fact that we are running a SDSU controller on the blue side, and  a Palomar CCD controller on the red side.
This is also true for any other hardware-controlled part.

Client
In this case, the "client" is the GUI themselve. Every command sent by the GUI is actually an ascii command sent through a socket to the server. For example, when the "GO" button is pressed, a command like "DHE EXPOSE" is actually sent. This implies that the whole system can, actually, be ran using only ascii command (like scripting). If a command is sent to the server using a client (for example, running a script) the server in turn sends an async. message to all the connected clients; in this way the GUI will know that an image is in progress, and hence updating itself accordingly.


"Image Pulling"
When an image is finished on the acquisition machine (it is on disk with full header information), another program which runs on a diferent machine can "pull" the image automatically across the network in order to have the image outside of the acquisition machine, allowing any custom data pipeline to start here, and serving as an automatic image backup. For more information about the puller, go to the reduction machine page.


The "output" of the ArcVIEW server is a FITS image on local disk. This FITS image can be a flat or a Multi-extension FITS (MEF) image.
The  "raw data" acquiered image has full header information (TCS, geometry, detector temperature, etc).
Since the image gets stored on local disk, there is an external package that will pull out from the echelle host any new image as soon as it is ready.
These external package is called "Image Puller", and they work by asking to the ArcVIEW internal database for the list of any newly done image. The database will respond with the full-path list of all the new images (since the last pull). The puller then will transfer them using secure ftp (sftp) to get them. The pullers can replicate the local directory, so at the end the "reduction" machine will be have an exact mirror of the directory structure and images of the dbsp acquisition machine. Complete documentation on the puller's  GUI can be found here

1.3. -Virtual Network Computing

The Virtual Network Computing (VNC) s basically a Windows Manager (like KDE or GNOME)  that can be accessed through the net. This VNC Windows manager (VNC server) accept connections from multiple clients through the network. Every client connected can see and, if allowed, act over the server. This means that every client can see exactly what other client is doing inside the VNC server.

This is quite useful, cause allows to have remote access to anything which is happening inside the server.

VNC is being used on the EChelle application extensivelly. The real Echelle machine, where all the software lives, is on a remote location (computer control room, on the electronics lab), and the machine at which the observer seats acts only as a console for the real application. This means that the "console" machine has a VNC viewer that gets connected to the real application. This also means that the system can be addressed/handled using any computer that can access the VNCserver.
The current system has 2 VNC servers: the main one, where the GUI is show, which acts as the primary user interface (GUIs, ds9 for data analysis, iraf,etc), and another which runs the real time display. This also means that the actual image can be watched from any place on the network.

Indications on how to connect to this servers remotely is on the "starting the application" page  
More information on the VNC software can be found on  http://www.uk.research.att.com/vnc/

1.3 NTP

Network Time Protocol is being used on the DBSP machine for synchronizing the Local Clock with the Palomar's GPS server clock. This synchronization is giving a  typical error of less than 30 msecs, which means
that the times indicated on the image headers (UTSHUT, for example) are within this range of error
The NTP server starts automatically when the machine boots.
The NTP configuration file is on /etc, and it is called ntp.conf. More ntp files are in /etc/ntp
More information about this protocol can be found in  http://www.eecis.udel.edu/~ntp/