7 STANDARD COMMANDS

Not only the commands need to have standard names, but within the proposed syntax also the names of certain standard parameters. All parameters related to a device shall be referenced by the short format of their hierarchical FITS keyword - the so-called Short-Hierarchical or Short-FITS format (see [8]).

7.1 Command syntax and conventions

Standard INS commands and parameter-names shall be made case-insensitive, by shifting them to uppercase before sending/evaluating (they are automatically converted whenever they are checked by the CCS/LCC message system against the so-called Command Definition Tables). Parameter-values on the other hand shall not be upshifted.

A restriction imposed by the CCS message system is that command names are limited in length to 7 characters, although longer synonyms may be defined in the CDT. The base command name, i.e. maximum 7 characters long, is also the name to be used in the internal transport format.

The internal transport format does not contain the parameter names and has instead position dependency for the parameter values. One should keep in mind that in general all applications are required to conform to the internal transport format for the messages they send (see [10]). The reason is that requesting the CCS/LCC message system to convert the more explicit, named parameter format to the internal, CDT complying transport format, requires processing time; this overhead can be tolerated for more interactive programs like the UIF and Sequencer, but not for a general application.The Sequencer syntax (see [12]), which in its turn is based on Tcl/Tk (see [13]), is compatible with this. The principle is that the first word is the command, the following words are arguments of the command; words are separated by one or more blanks.

Command-arguments are either parameter-names or parameter-values. Parameter-names are always preceded by a dash (minus-sign), as is usual in UNIX. Each parameter-name is generally accompanied by one or more parameter-values, according to the CDT definition of this particular command. The parameter-names are not required for the UIF nor the Sequencer, provided one uses the so-called expert format which is - like the internal transport format - position dependent, and uses commas to separate parameters. For the commands where only one parameter is possible (i.e. with a single parameter entry in the CDT), this simplifies into the fact that mentioning the parameter-name is really optional.

Short-Hierarchical keywords related to devices should always appear in a command as parameter-values, generally preceded by the parameter-name -function.

These basic syntax rules should be followed for all INS commands. In particular replies should be whenever possible ASCII strings, for the Sequencer to be able to do something with them. The command syntax must be supported by CDTs and be context independent.

Evaluation of parameters of a standard command is from left to right. The indirection introduced by using setup files as parameters must first be resolved internally, yielding a "longer" command string with only keywords. The order in which the keywords, accompanied by their values (if any), appear on the resulting command line is for not repeated keywords irrelevant. But if a keyword appears more than once, the right most one will take precedence over the previous occurrences. These previous occurrences will be discarded (i.e. skipped) before the command is executed. E.g. the ICS command SETUP -file MySetup -function filter B will result in a "move to filter B" command to the LCU controlling the filter wheel, skipping possible filter settings given in the setup file MySetup. So this can a.o. be used to override efficiently selected parameters contained in a setup file. There will be no warning when this overriding occurs. If a single parameter contains several values, the order of these values will usually be meaningful and important.

If a command contains an error that is detected at the level it is issued, the complete command will be discarded.

Remark that the distinction between absolute and relative positions has to be made on the basis of different keywords (e.g. INS.FILT1.ENC for absolute position in encoder units and INS.FILT1.ENCREL for relative position in encoder units).

In all standard commands where the word all can be used as a parameter, all means the entire list of devices controlled by the module for which the command is defined.

Commands may accept flags, which are preceded by a dash (minus sign), and are not followed by a value. They are parameters whose value can only be TRUE or FALSE. This value is given by the presence resp. absence of this flag, i.e. if a flag is not given with a command, the corresponding logical value will be automatically set to FALSE.

7.2 ICS

All the standard ICS commands are defined in the file $VLTROOT/CDT/icbControl.cdt.

7.3 DCS

All the standard DCS commands are defined in the files:

· $VLTROOT/CDT/fcdconCI.cdt for FIERA DCS

· $VLTROOT/CDT/iracqServer.cdt for IRACE DCS

· $VLTROOT/CDT/ccdconCI.cdt for TCCD DCS

7.4 OS

The most obvious way to distinguish between the different exposures, for an OS controlling more than one exposure¹, is via the unique exposure identifier. The exposure identifier must be returned by OS as soon as the exposure starts its life-cycle for OS, i.e. as a reply to the first SETUP command. The exposure identifier also allows to differentiate between e.g. 2 detectors controlled simultaneously by OS. It is however also allowed to use the DCS sub-system name to identify an exposure. Once the detector is identified, the exposure defaults to the one containing the currently integrating exposure; if there is no exposure integrating, but there is one being read out, the latter is the default. In the absence of detector identification info, the default for the optional identification of an exposure becomes the exposure corresponding to the last setup command creating a new exposure. If an exposure is identified explicitly, this one becomes the default, until the next exposure is created.

For instruments controlling more than one detector, the DET category of the short-FITS setup keywords needs to be extended with an index to allow OS to identify the detector each keyword refers to. However, because the detector data contained in each FITS file come from one detector only, the hierarchical FITS keywords belonging to the DETx category written in the FITS header should NOT contain indices (the detector name and/or ID shall appear in one of the DET keywords).

Commands to TCS (e.g. SETINS) are normally sent via OS Server through the command FORWARD. In some cases, to simplify OS and optimize parallelism, they may be sent directly to TCS from templates.

All the standard OS Server commands are defined in the file $VLTROOT/CDT/osbControl.cdt.

The same set of commands applies also to the Supervisory OS (SOS) Server (see [6]).

¹

Whether or not OS needs to control more than one exposure, depends of course on the design of the instrument.

Quadralay Corporation http://www.webworks.com Voice: (512) 719-3399 Fax: (512) 719-3606 sales@webworks.com