4.4 COMMUNICATION

· the database to share data between processes. The consuming process does not normally know if and when data in the database has been changed. If such knowledge is required, this functionality can be achieved by using the event mechanism, see CCS and LCC User Manuals, [1] and [2].

4.4.1 Message System Protocol

Obituary messages can be sent from an environment when a process terminates, or when the environment terminates.

On LCUs the behavior of a process can be defined by a parameter to the function ccsInit. It is possible to define if an obituary message shall be sent when the process terminates and/or if the process shall receive obituary messages when other processes terminates. The termination can be normal or abnormal (exception or crash).

Applications sending periodic or multiple replies shall register to receive obituaries. In this way it can detect if the process receiving the replies dies and it can take proper action, e.g. stop sending replies.

On workstations, the behavior regarding obituaries is defined in the RtapEnvTable as described in section 4.13.3.2.

The scope of obituary notification cannot be specified down to single processes.

This imposes to processes requesting obituary notification to parse the received obituary message to make sure it is coming from the process of interest.

4.4.2 Message System Syntax

The message system protocol is described in the CCS User Manual [1]. Section 5.2.1 of the LCC User Manual [2] defines the command syntax.

Normally all commands and replies shall be sent in ASCII format. This format is portable over all platforms.

To avoid double conversion when passing data from one application to another, formatted binary format can be used. This format is also portable, allows range checking, but includes only a few data types (integer, float and string).

Unformatted binary format shall only be used if required for performance reasons. This format does not allow any checking of parameters and can give problems when passing commands between machines of different architecture. The use of unformatted binary must be approved by ESO, case by case.

When sending a command from a CCS application it is possible to select if syntax checking of the command shall be done or not. Commands sent from user interfaces and the sequencer shall always be checked. During the development phase it is also advisable to check the syntax of commands sent from applications.

4.4.3 Command Naming Conventions

Commands can be maximum 7 characters long. Allowed characters are A-Z and 0-9 only.

The command name shall describe the action (a verb). The name shall be as clear and intuitive as possible. The destination of the command shall be the object to control, so there is no need to include this in the command name. Examples:

The commands shall relate to the function executed when the command is received. Example, the function xxxMoveSlit is executed when the command MOVE is received by the software device SLIT1.

In case the receiving process controls several objects and the object has to be part of the command, use an abbreviation of the verb (3 characters) followed by the object name (abbreviated to max. 4 characters, in total maximum 7 characters).

It might not always be easy to understand the functionality of a command from its name, because the 7 characters are too limited to give a good description. Therefore it is possible to define synonyms for a command, which can have more meaningful names. If the command at the destination call a function (normally done using the LCC Command Interpreter) it is recommended to use the function name as a synonym, see example above.

4.4.4 CDT and CIT for standard commands

Templates for Command Definition Tables (CDT) and Command Interpreter Tables (CIT) for the LCU are available in the citmp module. Use these templates to build your LCU application.

4.4.5 Parsing of commands

On the LCU parsing of commands is supported by the Command Interpreter (CI). The CI

· parses the parameters. The parameters are given in a buffer in binary format to the function.
Observe that the format is different if parameters are repeated or optional. In this case the buffer starts with an array, where each element contains the number of times the parameter is found in the buffer, followed by the parameter values. See also [2] for more details.

On the workstation command parsing is supported by the cmd module. A set of functions:

cmdFormatReply, cmdInit, cmdParamDefault, cmdParamDelete, cmdParamGetByIndex, cmdParamGetByName, cmdParamList, cmdParamSetByIndex, cmdParamSetByName, cmdParamToMsg, cmdParseCDT, cmdReplyList, is provided to encode and decode messages according to their description in the CDT. It is recommended to use these functions. See [1] for more details.