next up previous contents
Next: 2. Users' Guide Up: CFHT Director/Agent Model Revision Previous: List of Figures   Contents


1. Introduction

How to use this manual

  1. This section, and the Abstract, explain what the Director program is all about.
  2. The Users' Guide contains mostly the same information you can get from Director by invoking it with the ``-h'' command line option. There is also some information here on how to make sure you are running the right version of the program.
  3. The Programmers' Guide contains information on creating an ``Agent'' command line program.
  4. The Director section contains a summary of new features that Director brings to the CFHT observing software
  5. Any additional reference material, including where to get and how to build and install Director, is in the Appendix.

1.1 What's New in 3.x

The documentation for Director 2.x mostly described features of that version of Director. The current version of this document now covers the Director 3.x. Updated sections include the Abstract, the section on the big picture, expanded options for the ``agent restart/start'' builtin,

New sections describing libcli functions useful for writing agents, and also libcli cli_cmd for clients and descriptions of runon, clicmd, clicap, and clidup have been added. A new timing diagram illustrates how overlapping commands using the intent/go/wait model can be used to control slow moving devices efficiently.

1.2 Unix Shell Comparison

Director is essentially just an interactive shell. Like other interactive unix shells (csh, bash, etc.):

Director differs from other unix shells in the following ways:

1.3 The Big Picture

Since we are using Director for image acquisition systems at CFHT, it might help to look at the full observing environment. There are three major types of data or messages passed in our system:

  1. Command / Response (Director)
  2. Image Transfer of Pixel Data
  3. State Information

Image Transfer is currently handled by writing directly from the Detector Agent (DetCom) to a file on disk (or network disk). Other than triggering the commands, Director has no connection with Image Transfer.

State Information will some day be handled by a Status Server, but currently we store values in ``par files'' on disk. This serves as a (sometimes troublesome) distributed status database. Director has no connection with a Status Server or par files.

In the absence of a Status Server, there are a few clunky ways to get by. One of these actually does involve Director, and is described in the section on the clicap utility.

Director only addresses the first aspect of our acquisition system: passing commands and getting a response. Warnings and errors (which Agents transmit to Director using calls like printf()) are merely presented to the operator highlighted or in color to draw attention, but are never interpreted by Director. Director also does not use any kind of error return codes. The only two possibilities for a command are for it to complete with PASS, or complete with FAIL (which halts any scripts or other commands that were waiting to be processed.)

For a detailed diagram showing how commands and responses flow in and out of Director, see figure 3. NOTE: This diagram shows some other Pegasus components which are not described in this document. A full understanding of this diagram is not necessary to use Director. See the section on Director's features for a summary of the practical advantages Director brings to an acquisition environment.

Figure 3: Command and Response Flow
\epsfig {file=director.eps, height=8.7in}\end{center}\end{figure}

next up previous contents
Next: 2. Users' Guide Up: CFHT Director/Agent Model Revision Previous: List of Figures   Contents
Sidik Isani