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 offset or focus, 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 request 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 in the same computer that the Server does. This means that the actual GUI can be, if desired, moved away from the WIRC machine without any change
 

Server

The Server load and call specific modules for performing any requested command. This means that the actual action es performed for some specific module. This module is the only 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 cal to the specific SDSU-II module. This module knows how to send the command to the controller (only he 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 we said before, in the WIRC case the Client is the main GUI itself. All 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   extends the basic functionality of the main GUI. This allows  having opened only the functionality desired; all the other functionality 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 an special Plug-In (an special GUI) which can be loaded for adding this extra functionality. The Plug-Ins are, then, basically GUIs opened on demand around the main GUI for performing an 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 command and receive al the responses to the TCS
- PI_ScriptServer: This PI allows to handle the whole system using external scripts (under  Iraf, Csh, TCL or any other scripting language).
PI_ROI : Allows selecting a Region Of Interest (array subwindow) to be read

Apart of this, and only useful for  engineers, 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 to read back and log the values of the power supplies of the controller
- PI_ViewLogs: allows 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) 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 WIRC machine. All the ArcVIEW application is 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/
The VNC is being started automatically when you start the application
A second VNC server is being used for the Real Time Display, so both the complete application and the images can be watched remotely
Indications on how to connect to this servers remotely is on the "starting the application" page
 

1.3 NTP

Network Time Protocol is being used on the WIRC 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 (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/