Standard software practices were employed, like modular structure, code re-use, and utilization of the latest tools, but with care to avoid the temptation of only showing off new tools. The final system was built using many components that existed even when your first author was still in a baby crib. Core components include a Unix/X system, a VT100 color-capable terminal (emulator), the ``curses'' text library, GNU readline, bourne shell scripts, and SGML to describe the graphical interface (SGML is an old standard similar to XML but with some added conveniences.) Some of our solutions may not seem spectacular, but the bottom line is they work well and reliably. A single night that is affected by a problem with a license manager, Java interpreter, or complex custom software can quickly cancel anything gained from a more glamorous implementation.
Experience showed us that an ideal system would have both command line and graphical interfaces. A clean solution was to have everything driven by commands with a consistent and fool-proof syntax, and have the graphical interface trigger commands as a completely separate layer. Our observers and staff engineers alike have noted the advantages of a command line:
From the developers' point of view, a command or menu driven program is also one of the fastest and easiest to implement.
The command-line interpreter (CLI) that controls the CFH12K is a C program called ``DetCom.'' DetCom runs on the machine closest to the camera hardware, takes commands on ``standard input'' and writes FITS files (or Multi-Extension FITS files) directly to disk (either local disk or an NFS mounted disk.) As each command is completed, a new prompt is returned with a token indicating if the last command passed or failed. All other diagnostics are printed in human-readable feedback messages to the terminal. DetCom has very few dependencies. It needs access to the camera hardware, which means it typically runs on a different computer than the one used by the observer. It also needs assembled DSP code files, which it transfers to the SDSU II CCD controllers (Leach et al. 1998). With only these two software components, it is possible to take an exposure and write a FITS file. This can be a useful to isolate problems or check if the camera is functioning in a lab setting. DetCom reads basic mosaic and detector parameters from the DSP file and does not require any other configuration files or databases.
DetCom can process pixel data from the camera in one of three ways:
At the same time, a binned-by-8 composite of the entire mosaic is generated in standard FITS format. This, and the complete FITS file(s) are ready within a few seconds of the end of a readout.
A simple CLI such as DetCom has many limitations. But these can be overcome without any modifications to DetCom itself. Instead, a generic command line wrapper (similar to a Unix command shell) was created to make the command line more user-friendly, and more powerful. The basic features are:
One final feature of Director which has proven quite useful to our staff is the capability to run multiple instances of the user interface from any internet location with telnet and Web access. Each copy of the interface shows the same buffer although different views can have the debugging messages hidden or revealed. Think of it as a chat room, where everybody can see what is going on at the same time. After appropriate authentication, it is even possible to send commands from the copies or broadcast messages to the other windows.
More information on Director can be found at:
A single threaded command line is not the easiest environment to parallelize actions. There are two solutions to this problem, which have served our needs well:
Most users demand more than a command line to operate the system. Graphical interfaces are the most effective way to display current instrument status, and are also the best way to illustrate all the options to an new or altitude-impaired observer (the summit of Mauna Kea is at 14 000 ft., or 4200 meters.)
We were determined not to allow our software design to be driven by a choice of graphical interface. The graphical interface for the CFH12K uses the normal command set to trigger actions, and listens for feedback through a status database. This separation keeps DetCom simple, and also makes it easy to test the graphical interface separately. We just click on various buttons, checkboxes, and pulldown menus to verify that the appropriate commands are echoed.
This approach has the added benefit of teaching a user the command syntax. A text terminal with Director/DetCom shows the observer the commands that their button presses have caused. Users often start observing using the graphical interface and migrate to typing commands as they learn the syntax.
Currently, user interfaces are accessed locally and from around the world using HTTP to our custom intra-web server (RPM). Demonstration versions of the actual CFH12K interface are available at:
The interfaces use HTML forms and JavaScript (if available). The Web server generates the forms on the fly using a custom SGML DTD. The document structure and syntax is modeled after HTML, and is very easy to learn and maintain. Creating a new interface form that talks to our databases and sends commands is as simple as creating a new SGML text document.
The first incarnation of RPM was a CGI script that could parse these SGML files. It became apparent that the Web server (apache) was doing very little. Modifying the CGI script to listen on a socket directly, instead of relying on the Web server to invoke it improved performance and simplified the system, and essentially turned RPM into its own Web server. RPM is written in C++ and makes use of data structures provided by GNU libg++. Details on RPM and the SGML files that it converts into HTML forms can be found at:
Cuillandre J.-C., Luppino, G., Starr B., Isani S. 2000, PASP, submitted
Leach, R., Beale, F., Eriksen, J. 1998, SPIE, 3355, 512
Starr B., Luppino, G., Cuillandre, J.-C., Isani S. 2000, SPIE, in print