next up previous contents index
Next: 4 CCD Control Up: Part II: Subsystem Designs Previous: 2 Acquisition & Slitmask

3 Spectrograph Control

3.1 Overview

  The spectrograph control subsystem primarily connects commands and data requests from DEIMOS user interfaces and other processes such as watch_irot, the instrument rotation monitor, with the underlying mechanical hardware that moves optics, turns on lamps, controls temperature, and performs similar hardware control functions. See figure 3.1.

The DEIMOS spectrograph control subsystem consists of both pre-existing software modules already in use at Keck and new software modules developed at Lick for DEIMOS and other Keck II instrumentation. The pre-existing modules include:

These pre-existing modules will be included in the component module section of this document, but will not be covered in any great detail. References to existing documents describing them will be included.

New software modules unique to the DEIMOS spectrograph control subsystem include:

New software modules related to the spectrograph control subsystem, described in detail in other chapters of this document include:

3.2 Figures

Figure 3.1 Spectrograph Control

 

figure849


Figure 3.1:   Spectrograph Control

Figure 3.2 BEKINS Program Flow - Overview

Figure 3.3 BEKINS Program Flow - Initialization

Figure 3.4 BEKINS Program Flow - Jog Moves

Figure 3.5 BEKINS Program Flow - Raw Moves

Figure 3.6 BEKINS Program Flow - Discrete Moves

Figure 3.7 BEKINS Program Flow - Move Handler

Figure 3.8 BEKINS Program Flow - Stop Procedure

Figure 3.9 UHAUL Signal Handling Part 1

Figure 3.10 UHAUL Signal Handling Part 2

Figure 3.11 A Typical Manual Move Procedure for UHAUL

Figure 3.12 Dispatch Overview

Figure 3.13 Dispatch service loop

Figure 3.14 Service MUSIC messages

3.3 Nomenclature

dashboard:
The module using keyword information from the database to create flexible graphical user interfaces for DEIMOS.

dispatch:
The hardware control interface module which communicates via traffic with MUSIC messages to KTL clients, such as dashboard, and other MUSIC message clients, such as watch_irot.

FIORD:
FITS Input/Output Routine Database.

FIORD keyword library:
A library of keyword data I/O routines and a table describing keyword I/O information used with KTL to provide access to an instrument or subsystem's set of keyword data.

KICS:
Keck Instrument Control System

KTL:
Keck Tasking Library, developed at Keck and used by Keck instruments and telescope control system to impliment keyword-based multi-process applications for instrument control.

modify:
A shell command used to change a KICS keyword value. "modify" uses KTL and a FIORD keyword library to accomplish this goal.

MUSIC:
Multi-User System for Instrument Control. An interprocess communications protocol developed at Lick for transporting data between user interface processes and instruments. Currently in use at Lick and at Keck.

show:
A shell command used to display a snapshot of a KICS keyword value. "show" uses KTL and a FIORD keyword library to accomplish this goal.

xshow:
A shell command used to start a simple X window process continuously displaying keyword-value pairs, or the X window process itself. The xshow display uses KTL and a FIORD keyword library to access and update the display.

waitfor:
A shell command used to wait for a KICS keyword to equal a value. "waitfor" uses KTL and a FIORD keyword library to accomplish this goal.

3.4 Component Modules

 

3.4.1 BEKINS

 

3.4.2 UHAUL

 

3.4.3 dispatch

 

3.4.4 Galil DMC-1500 Dispatch I/O Library

 

3.4.5 Bar Code Reader Dispatch I/O Library

 

3.4.6 Piezo Controller Dispatch I/O Library

 

3.4.7 Lantronics Terminal Server dispatch I/O Library

 

3.4.8 watch_irot

 

3.4.9 DEIMOS FIORD keyword library

 

3.4.10 traffic

 

3.4.11 KTL support libraries

 

3.4.12 modify

 

3.4.13 show

 

3.4.14 waitfor

 

3.4.15 xshow

3.5 Subsystem Procedures

3.5.1 Overall Instrument Control Data Flow

Figure 3.1 shows a diagram of the instrument control data flow. At the top KTL clients and other processes, such as watch_irot (not pictured), pass MUSIC messages downward to the traffic process. Traffic passes the messages to their destination, in the case of a request message, the message would go to the dispatch process responsible for handling the request. Once the dispatch process receives the message, it calls a service routine that parses data in the message and passes it on to a device I/O routine. The device I/O routine accesses local information for the device to provide response message data, if the request was for a keyword value. If the request was for a change to a keyword state, such as a stage position, the device I/O routine sets up the request information in the device's data such that the change request is sent to the device or device controller. Requests to serial devices are sent via a socket connection on a terminal server.

Data flow in the opposite direction starts at the controller level. The dispatch processes reads keyword and other status data changes from the controllers. The data is saved in device data structures in dispatch. The read takes place during the "read status data from controllers" step in the dispatch service loop (see figure 3.13). Status keyword data is returned to requesting processes during the next step in the service loop. If the data indicates that a change service request is complete, the response is set to the requesting task in the send MUSIC response messages step of the service loop. Finally at the end of the service loop, broadcasts of status keyword data changes are sent.

To maximize response time by the dispatch processes, a separate process is used for each device requiring a serial connection.

3.5.2 Loading New Data and Programs onto Controllers

For Galil controllers, new data describing device positions and downloadable program changes can be sent to the controller via the DISPxCFG keyword. Writing this keyword causes the old position and program information to be erased and the new program(s) and data loaded from the file specified by the keyword. A "BP" command must be sent via the DISPxCMD keyword to burn in a new program.

3.6 Deliverable Documents

Both LaTex and html versions of the manuals will be provided.

3.6.1 Programmer's Manual

The Programmer's Manual describes the software components, interfaces, data, and their relationships.

3.6.2 Operations Manuals

The operations manuals describe normal operating procedures and contain information important to the Observers, Night Assistants and Engineers. Each manual is oriented to simplify the different tasks these people encounter when working with DEIMOS.


next up previous contents index
Next: 4 CCD Control Up: Part II: Subsystem Designs Previous: 2 Acquisition & Slitmask

DEIMOS Software Team <deimos@ucolick.org>
1997-06-13T00:18:19