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:
- the graphical
user interface tool we will use to create a DEIMOS GUI.
Figure 3.1 Spectrograph Control
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
The BEKINS process runs on Galil DMC-1500 series motor controllers.
It is the daemon process that handles all stage motion. This includes
calibrating the stages by finding home references, moving the stages
to a physical position, and stopping moves in progress.
BEKINS communicates to other processes via variables maintained in motor controller memory. The UHAUL and dispatch processes send stage movement request data to BEKINS by setting these variables. They also check movement status by reading variables set by BEKINS. Every stage on a motor controller has an independent set of the following variables used by BEKINS to satisfy their interprocess communication needs for stage motion requests:
An important feature of the request flags described above (MoveReqJ, MoveReqD, MoveReqR, StopReq and InitReq), is that they are interlocked by the UHAUL and dispatch processes. Only one move request flag can be set at a time. If a move is in progress, the stop flag must be set prior to starting a new move, and UHAUL or dispatch must wait for the stage to stop before setting the new move parameters, including the request flags for the new move. The same is true for initializing a moving stage, the stage must be stopped, then the new request flags are set.
Another important feature of BEKINS is how it handles long duration actions, such as waiting for a motion to complete. While waiting for an initialization, move or stop action to complete, BEKINS always continues to service new requests, and start new actions required by other stages to complete requests pending on them.
The module flow diagrams for BEKINS use the variables described above to show the actions of the BEKINS process as it watches for requests or acts on requests.
The BEKINS process consists of three basic parts executed in the order shown on the first flow diagram (figure 3.2). An initialization section handles incoming initialization requests and steps the stage through the sequence of actions required to initialize stages. A movement section handles incoming move requests of any of the three types of move options: jogging, moving to a raw encoder position, and move to a position found in a look-up-table mapping discrete values (such as 0, 1, 2, 3,...) to raw encoder positions (such as -35245, -1834, 23456,...). After handling a move request, BEKINS will execute any sequencial actions required by the move. The stop section is similar to the move sections and the initialization sections, it handles stop requests and the sequence of actions required to stop the stage.
Each stage has a unique set of functions to perform the actions identified on the first flow diagram. Each stage's initialization routine is called during the initialization phase shown in figure 3.2. Each stage's move routine is called during the move phase, and each stage's stop routine is called during the stop phase of the BEKINS service loop.
The second flow diagram (figure 3.3) shows the common elements in a stage initialization function executed during the initialization portion of the BEKINS service loop. UHAUL and dispatch set the initialize acknowledge flag (InitAck) to FALSE and the initialize request flag (InitReq) to TRUE when they want a stage initialized. The following is an outline of some of the elements of the flow diagram.
Figure 3.4 shows the BEKINS process control flow through the jog move procedure. The jog move request flag (MoveReqJ) is tested followed by the direction information. Limits are tested prior to starting the jog. Then the jog speed and direction is set and the jog is started.
Figure 3.5 shows the BEKINS process control flow through the raw move procedure. The raw move request flag (MoveReqR) is tested followed by a test determining if a move is in progress. If a move is in progress a stop request is set up and the next pass through the service loop the same procedure is followed until the stage has stopped. If the stage is not moving the move acknowledge and move request flags are reset and the target value and move phase vaiables are set up to cause a move when the move handler is reached. If the stage isn't homed the initialization request flag is set to cause the stage to home at the time it moves.
Figure 3.6 shows the BEKINS process control flow through the discrete move procedure. It is identical to the raw move procedure, with the addition of the shortest path algorithm. The signal flags are changed to MoveReqD, MoveAckD and TargetD to signal discrete movements.
The move handler flow diagram in figure 3.7 shows a simple three step move procedure.
Figure 3.8 shows the final section of the BEKINS service loop, the stop function.
Figure 3.2 BEKINS Program Flow - Overview
Figure 3.2: BEKINS Program Flow - Overview
Figure 3.3 BEKINS Program Flow - Initialization
Figure 3.3: BEKINS Program Flow - Initialization
Figure 3.4 BEKINS Program Flow - Jog Moves
Figure 3.4: BEKINS Program Flow - Jog Moves
Figure 3.5 BEKINS Program Flow - Raw Moves
Figure 3.5: BEKINS Program Flow - Raw Moves
Figure 3.6 BEKINS Program Flow - Discrete Moves
Figure 3.6: BEKINS Program Flow - Discrete Moves
Figure 3.7 BEKINS Program Flow - Move Handler
Figure 3.7: BEKINS Program Flow - Move Handler
Figure 3.8 BEKINS Program Flow - Stop Procedure
Figure 3.8: BEKINS Program Flow - Stop Procedure
Modifies no keywords directly. Services no keywords directly. Keyword requests can cause responses by BEKINS. For example, setting the DWFILORD keyword can cause BEKINS to move the dewar filter wheel.
The UHAUL process runs on the Galil DMC-1500 series of motor controllers. It is the daemon process that catches digital input signals from the switches and buttons on the manual control box for a motor controller. UHAUL sets output signals to show control status information on the box, and sets interprocess communication variables shared with BEKINS and dispatch. The variables request actions by BEKINS to move stages or provide safe transfer of device control between dispatch and UHAUL.
A discription of the following motor controller variables can be found the module description of the BEKINS process: StopReq, InitReq, MoveReqD, MoveReqJ, JogSpd, TargetR, and TargetD. These variables inform BEKINS of the type of action requested by UHAUL and pass on additional data required to perform the UHAUL request. Variables unique to UHAUL include:
An outline of the basic UHAUL service loop is in the upper right of figure 3.9 or 3.10. UHAUL checks the input signals from the switches and buttons on a manual control box, performs any actions required by the signals, and provides feedback to the operator at the control box via LEDs. The LEDs show movement and limit status data for motor stages and position data for air cylinder stages such as the hatch.
Figure 3.9 shows a key loop in the UHAUL task. When the Auto/manual switch changes state, UHAUL sets appropriate flags to cause BEKINS to stop of all motor controller motors and prevent either UHAUL or the dispatch process from moving any stages until all of the motors have stopped moving. Only after the AutoMan flag is set to Auto at the end of the loop can dispatch send stage move commands to BEKINS. Only after all motors have stopped can UHAUL exit the loop.
Figure 3.9 also shows the conditions that results in a reset (cold start) of the controller (hold all three motion control buttons (FWD, REV and STOP) down for three seconds), and a halt of all stage motion (hold the stop button down for three seconds). (Note: This last condition is likely to change such that the stop button always halts all stages immediately. It is also likely that UHAUL will be changed to allow only one stage to move at a time.)
Figure 3.10 selection of the move routine appropriate for the switch selected stage when any of the motion control buttons are pressed.
Figure 3.11 shows the conditions necessary to request one of the four following actions from BEKINS: stop a stage, initialize a stage, move the stage to a discrete position, or jog the stage. It also shows how each action, except the stop action is bypassed while the stage is still moving.
Figure 3.9 UHAUL Signal Handling Part 1
Figure 3.9: UHAUL Signal Handling Part 1
Figure 3.10 UHAUL Signal Handling Part 2
Figure 3.10: UHAUL Signal Handling Part 2
Figure 3.11 A Typical Manual Move Procedure for UHAUL
Figure 3.11: A Typical Manual Move Procedure for UHAUL
Modifies no keywords directly. Its actions can change the values
of keywords for devices controlled by the manual control box, such as
HATCHPOS.
Services no keywords.
The dispatch process should be able to run on any unix system that it can be compiled on. It is the daemon process that services keyword requests directed to instrument control hardware, monitors and controls functions such as dewar filling, and maintains and validates mapping data relating instrument control keywords.
Dispatch communicates with clients requesting keyword data or keyword changes via MUSIC messages. The MUSIC messages arrive on a socket connected to the traffic process. Dispatch returns response messages via traffic sending them in the opposite direction. Dispatch passes change requests to hardware controllers, such as the bar code readers and Galil controllers, in their own language.
Dispatch uses the message service type and device id in the message to map data service requests arriving as music messages to internal devices and their information structures. Data in the device information structures identifies the controller with the hardware associated with the internal dispatch device and I/O routines required to access its data. Data in the controller information structure identifies the port data, information and I/O routines required to access the devices data on the hardware controller (e.g. a Galil controller).
Figures 3.12 through 3.14 describe the major elements of dispatcher control flow. The most important of these is figure 3.13 showing the event sequence of the dispatcher service loop. It consists of five autonomous sections. They could almost be seperate processes sharing the same memory. The first section handles reconnection to traffic and serial ports when connections are lost. The second section reads all status information in one gulp from a controller or simple device with a serial interface. The third section processes incoming MUSIC messages until no more are pending. The fourth section checks the status data read from section two and the message request data from section three to determine if any responses to request messages need to be sent due to a device completing a change request or having a change request cancelled. The last section of the loop checks for any changes to device state data. Broadcasts messages are sent with all of the new device states.
Figure 3.12 Dispatch Overview
Figure 3.12: Dispatch Overview
Figure 3.13 Dispatch service loop
Figure 3.13: Dispatch service loop
Figure 3.14 Service MUSIC messages
Figure 3.14: Service MUSIC messages
Can modify the value of all readable DEIMOS instrument control keywords.
Services requests for all writeable DEIMOS instrument control keywords.
The Galil DMC-1500 dispatch I/O library handles the keyword data and device I/O for all stages and other hardware controlled by Galil DMC-1500s. I/O for all DMC-1500 controller keywords (CTRLxxxx and MANxxxxx keywords) is also managed by the library.
The bar code reader dispatch I/O library handles the device I/O for all bar code reader key words (xxBARCFG, xxBARCMD, xxBARGET, xxBARRSP, xxBARSCN.
The piezo controller dispatch I/O library handles the device I/O for all bar code reader key words (TMIRRCAL, TMIRRHLT, TMIRRMSG, TMIRRNAM, TMIRRORD, TMIRRRAW, TMIRRTRG, TMIRRVAL).
The Lantronix terminal server dispatch I/O library handles the device I/O for all Lantronix terminal server key words (TBD).
Watch_irot watches the telescope position via requests to DCS and, based on the desired rotation mode, sends position or velocity commands to the instrument rotator to keep the image positioned correctly.
Reads ???
Modifies ROTATRAW or ROTATVEL and ROTATMOD.
The DEIMOS keywords are defined in the database. See the keyword brick. The DEIMOS FIORD keyword library will be automatically generated from the data in the database.
Provides protocol for passing keyword data between processes, but does
not modify or wait for specific keywords.
The traffic process receives MUSIC messages from client processes and pass on the messages to other client processes. The messages usually contain keyword data being transmitted between the client processes.
For a complete description of traffic, see Lick Technical Report #55.
The KTL support libraries include ktl, ktlker, kicsglue, fiord, music, info, d, and traffic.
A command line application written for Keck I. It is invoked with a list of keyword=value pairs. It can either wait for the keywords to equal the specified values, or exit before the change completes.
modify is a KTL client, it uses the KTL support libraries and a FIORD keyword library to access keyword data.
Can change any writable keyword.
A command line application written for Keck I. It is invoked with a list of keywords to display. The information is displayed as keyword=value pairs in the window.
show is a KTL client, it uses the KTL support libraries and a FIORD keyword library to access keyword data.
Can display any readable keyword.
A command line application written for Keck I. It is invoked with a list of keyword=value pairs. It waits for the keywords to equal the specified values.
Waitfor is a KTL client, it uses the KTL support libraries and a FIORD keyword library to access keyword data.
Can wait for any writable keyword to change.
Xshow is a KTL client, it uses the KTL support libraries and a FIORD keyword library to access keyword data.
Can display any readable keyword.
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.
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.
Both LaTex and html versions of the manuals will be provided.
The Programmer's Manual describes the software components, interfaces, data, and their relationships.
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.