When used for data acquisition, ICL is used to control one or more ‘instrumentation tasks’ (I-tasks). A I-task is used to control an individual instrument or other hardware component of the system. An I-task can respond to a number of different commands (referred to as Actions) rather than the single command of an A-task; they also have the ability to perform two or more actions concurrently.
Multiple I-tasks may be involved when several instruments are used in combination and sometimes it is convenient to have another I-task controlling the individual instrument I-tasks. In this case, ICL would be used to control the controlling task which would relay to ICL any messages or prompts from the subsidiary I-tasks intended for the operator.
Instrumentation tasks are fully described in SUN/134.
Instrumentation tasks combine the functions of Device (D) task and Control (C or CD) tasks which were used with ADAM V1. These old-style tasks are now considered ‘unfashionable’ but they continue to work with ICL and it will be some time before they are replaced in all systems.
In a data acquisition situation the task caching scheme described in the previous section is usually inappropriate. We don’t want tasks to be killed when the caching limit is exceeded, and we may not want a task to be killed when ICL exits (as happens with cached tasks). Also the unique process names created for cached tasks are undesirable as many different tasks may want to communicate with a given task, and therefore need to know its name.
Therefore I-tasks are normally loaded as uncached tasks, and this is achieved by explicitly loading them using one of the three ICL load commands.
Uncached tasks remain loaded until explicitly killed, or until the creating process is logged out. They remain loaded when ICL exits. Thus it is possible to use ICL to load a task, then exit from ICL, and subsequently communicate with the task from a second invocation of ICL (which might be started on a different terminal).
Tasks are killed using the KILL or KILLW commands.
Communication between ADAM tasks, and between ICL and tasks, makes use of the ADAM message system. The message system is involved in the communication between ICL and A-tasks described in the last chapter (§10), but in this case its details are largely hidden from the user. In the data acquisition case the use of the message system by the command language is usually more explicit.
ICL can send four types of messages to tasks, which are distinguished by a context which is one of GET, SET, OBEY or CANCEL.
The ICL command to send a message to a task is SEND.
As an example we will consider a I-task called PHOTOM which controls a simple optical photometer. The photometer includes a filter wheel with five positions.
The I-task has a parameter FILTER_DEMAND which specifies the required filter and an action FILTER which moves the filter wheel to the required position. These are specified in the interface file for the task as follows:
Many I-task parameters have VPATH specified as ’INTERNAL’ – this means that the parameter value is stored in memory for speed of access. The IN field specifies the valid values for the parameter (it is also possible to use a RANGE specification to restrict the values of a parameter).
The action entry specifies that the action FILTER may be obeyed and cancelled, and that they OBEY action needs the parameter FILTER_DEMAND which may be specified as the first (only) parameter on the command line.
The I-task could be used as follows:
The last command starts the FILTER action but does not wait for it to complete. ICL can accept and execute other commands while the filter wheel is moving to its position. When the action finally completes the I-task returns a completion message to ICL which will be output on the terminal.
A parameter in the NEEDS list for an action may be supplied along with the OBEY message rather than set independently with a SET message. Thus we can use:
The CANCEL context enables us to cancel the FILTER action before it has completed by issuing the following command:
If we try to start the FILTER action without specifying a value for the FILTER_DEMAND parameter (either by SEND SET or by specifying it on the command line), the parameter system will attempt to get a value in the same way that it does for A-tasks (but note that ‘INTERNAL’ parameters will not be prompted for – a pseudo VPATH of ‘DYNAMIC,DEFAULT’ is used and there is no implied PROMPT at the end.) Therefore, as there is no DEFAULT value specified for FILTER_DEMAND, and assuming that no dynamic default value is specified by the program, the null response is assumed.
Note that old-style D-tasks always had parameters defined as ’INTERNAL’ and could not prompt for missing parameters anyway.
A SEND PHOTOM GET command causes the parameter value to be output on the terminal. It is often more useful to put the value into an ICL variable. This can be accomplished using the GET command.
It is often more convenient to let ICL wait for an action to complete rather than have it proceed concurrently with other ICL commands. The OBEYW command is used for this purpose.
The OBEYW command waits until the action has completed before the ICL prompt reappears and more commands may be entered.
I-tasks have the ability to perform more than one action concurrently. ICL includes two commands which enable actions to be performed concurrently while waiting for all of the actions to complete. Suppose our PHOTOM I-task has another action APERTURE which moves the aperture wheel to a required position. The following is a procedure which would allow the filter and aperture wheels to be moved simultaneously.
STARTOBEY starts an action and returns the path and message identifier, which together uniquely identify a given invocation of an action, into two ICL variables. ENDOBEY can then be used to wait for the completion of such an action. The above procedure will therefore exit only when both actions are complete.