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 making offsets or focus changes, and with the filter wheel for changing filters.

For more information about ArcVIEW itself, see

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

1.1  Software Architecture


The system works on a client-server scheme. There is a server, which 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 WIRC software, the client, which requests actions, is the main GUI itself. When the main GUI is opened, it connects to the server (which is already running on the machine).
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 on the same computer that the server does. This means that the actual GUI can be, moved away from the WIRC machine without any change.
 

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 module which will need to know the internals of the process or the systems that it is handling. For example, if some controller command arrives (i.e. EXPOSE), the server will call to the specific SDSU-II module. This module knows how to send the command to the controller (only it knows about the Linux driver and the C library 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. If a different controller than the SDSU-II needs to be controlled, it is just a matter of adding a new specific module for that hardware without affecting any other part of the system. The same applies for the TCS, filter wheel, etc. For a list of all the available modules, see the Software Tree.
 
 

Client

As mentioned before, in the WIRC case the client is the main GUI itself. All of the buttons in this GUI are being transformed into ascii commands (like "TCS FOCUS 40").
The GUI system is composed of a main GUI, and several "Plug-Ins". The "Plug-Ins" are dynamically loaded GUIs which extend the basic functionality of the main GUI. This allows the user to open only the functions desired; all the other functions can be avoided. For example, from an engineering point of view, there are a lot of low-level commands which are quite useful (commands which are not interesting for the normal observer). For that specific purpose there is a special Plug-In (a special GUI) which can be loaded for adding this extra functionality. The Plug-Ins are basically GUIs opened on demand around the main GUI for performing specific sets of commands.
In this specific application, besides the main camera GUI (which takes care of the basic imaging issues and detector communication), we have the following Plug-Ins available:

- PI_WircFiterGUI : takes care of all the filter-related commands and status
- PI_TCSP200GUI: takes care of all the TCS-related commands and status. This GUI will send all the commands and receive all the responses to and from the TCS
- PI_ScriptServer: This PI allows the user to handle the whole system using external scripts (under IRAF, csh, TCL or any other scripting language).
PI_ROI : Allows the selection of a Region Of Interest (array subwindow) to be read

Apart from these, and only for engineering, we have:

- PI_Labmain: opens a GUI specialized on low-level commands (like setting DACs, reading or writing DSP memory locations, etc)
- PI_voltages: allows user to read back and log the values of the power supplies of the controller
- PI_ViewLogs: allows user to see, in real time, all the logs that the system is generating (command/responses, errors, information, messages, etc)
 
 

1.2. -Virtual Network Computing


The Virtual Network Computing (VNC) is basically a Windows Manager (like KDE or GNOME)  that can be accessed through the net. This VNC Windows manager (VNC server) accepts 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 because it allows to have remote access to anything which is happening inside the server.

VNC is being used on the WIRC machine. All the ArcVIEW applications are being started inside a VNC server; therefore, all of what is happening can be watched remotely using a VNC client.
More information on the VNC software can be found on  http://www.uk.research.att.com/vnc/.
Information on how to connect to the servers remotely is on the "starting the application" page.
 

1.3 NTP

Network Time Protocol is used on the WIRC instrument machine for synchronizing the Local Clock with Palomar's GPS server clock. This synchronization gives a typical error of less than 30 msecs, which means that the times indicated on the image headers (UT, 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/