## Chapter 11ADAM as a Data Acquisition Environment

11.6 An Example

11.6.2 Running PHOTOM

11.6.4 Cancelling Actions
11.6.5 Missing Parameters
11.6.6 The GET command
11.6.7 The OBEYW command

B.1 ALLOC
B.3 APPEND
B.5 CLEAR
B.6 CLOSE
B.7 CREATE
B.8 CREATEGLOBAL
B.9 (DCL)
B.10 DEALLOC
B.11 DEFAULT
B.12 DEFHELP
B.13 DEFINE
B.14 DEFPROC
B.15 DEFSHARE
B.16 DEFSTRING
B.18 DEFUSER
B.19 DELETE
B.20 DISMOUNT
B.22 EDIT
B.23 ENDOBEY
B.24 EXIT
B.25 GET
B.26 GETGLOBAL
B.27 GETNBS
B.28 GETPAR
B.29 HELP
B.30 INPUT
B.31 INPUTI
B.32 INPUTL
B.33 INPUTR
B.34 KEY
B.35 KEYTRAP
B.36 KEYUSER
B.37 KILL
B.38 KILLDCL
B.39 KILLW
B.40 LIST
B.44 MOUNT
B.45 NOREP
B.46 OBEYW
B.47 OPEN
B.48 PRINT
B.49 PROCS
B.50 PUTNBS
B.55 REPFILE
B.56 REPORT
B.57 SAVE
B.58 SAVEINPUT
B.59 SEND
B.60 SET
B.60.1 SET ATTRIBUTES

B.60.4 SET EDITOR
B.60.5 SET HELPFILE

B.60.7 SET PRECISION
B.60.8 SET PROMPT
B.60.9 SET SAVE, SET NOSAVE
B.60.10 SET SCREEN, SET NOSCREEN
B.60.11 SET TRACE, SET NOTRACE
B.61 SETGLOBAL
B.62 SETPAR
B.63 SIGNAL
B.64 SPAWN
B.65 STARTOBEY
B.67 VARS
B.68 WAIT
B.69 WRITE

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.

— Loads a task into a detached process and waits for completion.

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.

KILL
— Kills a task without waiting for completion
KILLW
— Kills a task and waits for completion

### 11.5 The ADAM message system

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.

### 11.6 An Example

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.

#### 11.6.1 The I-task Interface File

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:

PARAMETER FILTER_DEMAND
TYPE ’_CHAR’
VPATH ’INTERNAL’
IN ’U’,’B’,’V’,’R’,’I’
ENDPARAMETER

ACTION FILTER
OBEY
NEEDS FILTER_DEMAND
ENDOBEY
CANCEL
ENDCANCEL
ENDACTION

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.

#### 11.6.2 Running PHOTOM

The I-task could be used as follows:

ICL> SEND PHOTOM SET FILTER_DEMAND V
ICL> SEND PHOTOM GET FILTER_DEMAND
V
ICL> SEND PHOTOM OBEY FILTER
ICL>

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.

ICL>
"obey" FILTER - action complete

#### 11.6.3 Supplying Parameters in the Obey Message

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:

ICL> SEND PHOTOM OBEY FILTER B

#### 11.6.4 Cancelling Actions

The CANCEL context enables us to cancel the FILTER action before it has completed by issuing the following command:

ICL> SEND PHOTOM CANCEL FILTER

#### 11.6.5 Missing Parameters

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.

ICL> SEND PHOTOM OBEY FILTER
ICL>
%PAR-I-NULL, Null parameter value
ICL>

Note that old-style D-tasks always had parameters defined as ’INTERNAL’ and could not prompt for missing parameters anyway.

#### 11.6.6 The GET command

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.

ICL> GET PHOTOM FILTER_DEMAND (F)
ICL> =F
B
ICL>

#### 11.6.7 The OBEYW 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.

ICL> OBEYW PHOTOM FILTER I
ICL>

The OBEYW command waits until the action has completed before the ICL$>$ prompt reappears and more commands may be entered.

#### 11.6.8 Multiple Concurrent Actions

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.

PROC SETUP  F  A

{  move filter to position F and aperture to position A  }

{  Start both actions  }

STARTOBEY (P1) (M1) PHOTOM FILTER (F)
STARTOBEY (P2) (M2) PHOTOM APERTURE (A)

{  Wait for the actions to complete  }

ENDOBEY (P1) (M1)
ENDOBEY (P2) (M2)

END PROC

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.