BAIT: communication protocol

COMMUNICATION PROTOCOL

The BAIT project relies on BSD socket communication between various computers. In this way the hardware control can be maintained in a modular fashion without regard to the operating system used on the client or the server. The tserver command can then be used to concatenate servers from various nodes into one server. The basic command structure consists of ASCII messages similar to:

point ra=00:57:45 dec=35:12:55 nodome

Each message consists of one or more fields delimited by spaces. The delimiter is a NULL character (newlines will be allowed in a future release). The first field contains the command. The other fields can contain keywords or keyword=value pairs. The replies are limited to the two forms: 

done point dist=.03 
  or
ERROR point power not on
The ordinary case reponds with the word, done followed by the name of the command followed by any optional keyword, keyword value pairs. The second ERROR form lists the command name and any error message. This message results from problems in either interpreting or executing the command.

Each command must have a help feature so that if the first keyword is help the command will report back immediately with a string showing the allowable options. (With optional keywords in [] brackets.) For example: 

point help
done point ra= dec= [epoch=] [nodome] [noapp] [nocorr]

Every server must have a help command which lists the commands that are available. This command is used by tserver to link up servers under one roof. For example one telescope server may have the following conversation. 

help
done help beep dome mirror move_sec offset point power slit temps track

Generic Protocols

Protocols for the following devices have been written: These protocols are templates and vary from installation to installation depending on the properties of the instrument.

DATA TRANSMISION

The ASCII protocol will bog down if large amounts of data are to be transmitted. We have therfore put in an exception to the done/ERROR reply mentioned above. If the reply is of the form 
nbytes=xxx
where xxx is a number, the next transmission will consist of the specified number of bytes. This transmission will then be followed by the usual done message. The nbytes are rarely transmitted without a request and usually they are asked for with a nbytes= option.

The received bytes can be stored as uninterpreted bytes but the other following keywords can be used to help interpret the incoming bytes:

All data are transmitted in BIGENDIAN order. In addition if the keyword/value pair channels= is present in the receiving message, the data are presumed to be arranged in the specified number of columns. If the keyword/value pairs bzero= or bscale= are present these values are transferred into FITS headers.

POSSIBLE IMPROVEMENTS

interruptibility- all commands are blocking and cannot be stopped once started. If you Cntrl^C the tx command, it simply stops the program and not the action. It would be nice to be able to stop the action.

time estimate - some commands take a long time to execute and a preliminary message with a time estimate would be helpful.

port specification - the port specification in the tx command should really be tied directly to the node (eg node=foobar,0x1342) rather than a special keyword.

multiple devices - some way of allowing multiple devices with the same name is needed. We often have two CCDs connected.

access control - It would be nice to be able to have 1) single user access so that one user could lock out all other say when doing maintenance. 2) read only access so that we could grant others access to weather or position without granting telescope positioning access.

server restart - if a remote server crashes an auto restart would be nice.

SEE ALSO

Last Revised June 1, 2001
Email: rtreffers@astro.berkeley.edu