Telescope-Control DRAMA ``D-task''.

DRAMA-based TCS D-task for INT (& JKT) - Function and Philosophy.

1. Introduction.
   The word `D-task' is inherited from ADAM, but only because nobody can think of a better name. The tcs D-task runs on the ICS sparc (currently lpss12 in the INT control room) and provides a DRAMA interface to the rest of the new ICS, and a serial interface to the existing Perkin Elmer based TCS.

2. Philosophy:
   The goals are to 1) not overload the TCS/IPL, yet 2) provide reasonably rapid response to external commands.

3. Functionality: polling.
   The D-task provides both telescope control and information feedback. A polling loop runs continuously at around 1HZ collecting information from the TCS, principally coordinates, which telescope, telescope focus, tube temperature. A number of other `telescope packet' parameters are generated inside the D-task, for example Julian-Date, on the principle that such calculations in the Sparc are as good as instantaneous, whereas information from the TCS via the IPL can be 10-20 seconds out of date. Thus the current state of the telescope is stored in the D-task, so that when a request for a FITS archive packet is made, the response is immediate.

4. Functionality: Control:
   Various DRAMA `actions' provide a standard interface for telescope control. Some translate directly to TCS commands, sent straight down the IPL. For example, FOCUS consists of setting the focus-value in the TCS task-common (via the appropriate IPL packet) and triggering the focus-slew routine. Some other features are simulated in the D-task, in particular catalogue-handling. Since the IPL protocol does not support string-passing (it seems to have been intended but never finished off...) it is not possible to pass object names over the link (see catalogue handling).

5. Functionality: Demands:
   From time to time, the TCS will make spontaneous, or unsolicited, demands down the IPL. These are directed at a task AGSP on the ICS Perkin Elmer, or PFCU for prime-focus. The tcs D-task handles these by self- executing an AGSP and PFCU action permanently, which have handlers for all the messages which may arrive. An example is, when the cass rotator is rotated, the TCS sends the position to AGSP via the IPL.

6. The IPL link hardware.
   The Inter-Processor Link consists of a 7-wire RS232 connection; the TCS end connects to a CAMAC 3340 module, while the tcs end connects to a Digi PortServer (portserver1.ing.iac.es). The tcs on the sparc opens a RealPort terminal port, currently /dev/term/a002. RealPort is a Digi- provided software package which is a bit like VMS LAT-application ports; the application just sees a normal terminal special file, and has full control via termio(4). On the PortServer, port 2 is set up dev=prn. The physical wire is 8-core cat-5 - bit of an overkill. At the other end is an RJ-45 to 25-pin male D adapter, compatible with the CAMAC 3340 RS232 port, but actually plugged into a T-switch. The other leg of the T-switch has the original IPL cable going off to the Perkin Elmer ICS.

   The CAMAC 3340 has a 128-byte buffer; an IPL packet is 73 bytes including the CR terminator, and so a single message can be stored without readout. It is important not to send two message quickly, or the buffer will overflow.

7. The IPL link software.
   The IPL is read (in iplInit.c) as a DITS `alternative-input' which is almost like a software interrupt. When a message arrives, the read routine reads the destination `TASK' and DitsSignal's the `action' of the same name. In this way, the original Perkin-Elmer inter-task message-sending fits in very neatly with Drama actions. If an action called FOCUS has sent a message over the IPL, the TCS will send an acknowledgement to `TASK' FOCUS, and so the action initiating the request receives a completion message.

   In order to synchronise traffic on the IPL, actions put messages in a queue; then tcsPoll, which normally runs through its information polling list, actually sends the message.

   Because the link, and the service to the link, in the Perkin Elmer is quite slow, the information requested is prioritised; that nearer the front of the list is polled most frequently, such as the telescope coordinates.

8. Catalogue handling.
   The tcs catalogue exists as a unix file, in $OBSSYS/etc/tcs.cat It's format is the same as the WHT. As mentioned above, the normal TCS (Perkin Elmer) catalogue cannot be used; the advantage of the system used is that the catalogue can be operated on by any text editor, or other normal shell commands. However, the implementation is not yet very complete. One can add new coordinates, add the current position as a catalogue object, do a `gocat'. To delete an entry, or modify one, or input a new catalogue, you just do it from the shell.