|
|
AUSTRALIAN
NATIONAL UNIVERSITY System Design Note 11.01 Created: 11 September 2001 Last modified: 11 September 2001 |
NIFS INSTRUMENT SEQUENCER SOFTWARE DESIGN
Peter Young
Research School of Astronomy
and Astrophysics
Institute of Advanced
Studies
Australian National
University
Revision History
|
Revision No. |
Author & Date |
Approval & Date |
Description |
|
Revision 1 |
Peter Young 10 March 2000 |
Peter J. McGregor 05 September 2001 |
Original document. |
|
Revision 2 |
Mark Jarnyk 10 September 2001 |
Peter J. McGregor 10 September 2001 |
Revised after CDR |
|
|
|
|
|
Contents
4 Spectrograph
Instrument Sequencer Design
5 Instrument
Sequencer Software Implementation Detail
5.1.2 Status and
Alarm Database
1 Purpose
This document describes the software design for the Gemini Near-infrared Integral Field Spectrograph (NIFS) Instrument Sequencer. As described in the CICS Detailed Design Document, this process is responsible for the overall operation of the instrument. It sequences the subsystems and ensures that commands directed to one subsystem do not clash with the requirements of another (e.g., it prevents the Components Controller reconfiguring the instrument while the Detector Controller is making an observation).
2 Applicable Documents
|
Document
ID |
Source |
Title |
|
cics_smb_041 |
IGPO |
CICS Detailed Design Document |
|
|
|
|
3 Introduction
A conforming Gemini Instrument Control System (ICS) has three software components that are required to run on an EPICS-based Input Output Controller (IOC) running the VxWorks operating system. The Instrument Sequencer (IS) interfaces to the Gemini Observatory Control System (OCS) and sequences commands to the Components Controller (CC) and Detector Controller (DC; Figure 1). The IS shares the same IOC as the CC while the DC, having greater performance requirements, runs on a separate IOC.
Figure 1: ICS subsystems.
4 Spectrograph Instrument Sequencer Design
The NIFS Instrument Sequencer is a close copy of the NIRI Instrument Sequencer. The only changes were the removal of the DIAGNOSE and SETUP sequences, as NIFS does not support these. In this section, we detail the implementation of the Instrument Sequencer software.
The
Instrument Sequencer receives commands from the Observatory Control System and
decides how to act on these commands. It is implemented as two EPICS databases
(Figure 2) with underlying EPICS sequence code (SNL code). The
databases communicate with the CC, DC, and OIWFS groups of databases through
EPICS channel access mechanisms.
Figure 2: Instrument Sequencer databases.
4.1 NIFS Sequence Commands
The NIFS IS uses the same sequences as NIRI, except that it does
not support NIRI’s DIAGNOSE and SETUP sequences.
INIT
On receipt of this command, the IS ensures that an observation is
not taking place. It then executes its initialization sequence, in which it
reads its hardware set-up files and lookup tables, and resets itself to the
start-up state. This command is forwarded to the CC, DC, and OIWFS CC. The
"initC" CAR record goes "BUSY" while the initialization is
being carried out and will go to "IDLE" if completed suc-cessfully or
to "ERR" if the initialization fails.
The CC reads its hardware set-up files and lookup tables, and
resets itself to the start-up state. No mechanisms are moved.
The
DC reads its hardware setup files, and starts/restarts the SDSU VxWorks control
tasks that are put into the READY
state.
The OIWFS CC reads its hardware set-up files and lookup tables,
and resets itself to the start-up state. No mechanisms are moved.
TEST
On receipt of this command, the IS ensures that an observation is
not taking place, and then forwards this command to the DC and CC. The
"testC" CAR record will go "BUSY" while the tests are being
carried out and go to "IDLE" if completed successfully or to
"ERR" if the tests fail.
The CC accepts, but ignores this command.
The
DC accepts this command if an INIT has been successfully performed. Depending
on the testMode parameter, communication link tests between the DC IOC and the
SDSU controller electronics are performed using the SDSU TDL command.
For
the CC, because the TEST command is not permitted to move any mechanisms, it is
unable to detect any problems with the Components Controller. Use the REDATUM
command instead.
DATUM
On receipt of this command, the IS ensures that an observation is
not taking place and then forwards the command to the CC, the DC, and the OIWFS
CC. The "datumC" CAR record goes "BUSY" while the datum
search is being carried out and goes to "IDLE" if completed
successfully or to "ERR" if the datum search fails.
The CC locates the datum for all its mechanisms.
The
DC accepts but ignores this command.
The OIWFS CC locates the datum for its mechanisms.
VERIFY
On receipt of this command, the IS ensures that an observation is
not taking place and then forwards the command to the CC and DC.
The CC does not support this command.
The
DC accepts but ignores this command.
ENDVERIFY
On receipt of this command, the IS ensures that an observation is not
taking place and then forwards the command to the CC
and DC.
The CC does not support this command.
The
DC accepts but ignores this command.
GUIDE
On receipt of this command, the IS ensures that an observation is
not taking place. It then sets a flag as a reminder that guiding is taking
place (as this information may affect its interaction with the On-Instrument Wavefront
Sensor). The IS also forwards this command to the CC and DC.
The CC does not support this command.
The
DC accepts but ignores this command.
ENDGUIDE
On receipt of this command, the IS ensures that an observation is
not taking place. It then resets the guiding flag to indicate guiding has
stopped. The IS then forwards this command to the CC and DC.
The CC does not support this command.
The
DC accepts but ignores this command.
OBSERVE
On
receipt of this command, the IS ensures that an observation is not taking place
and then forwards the command to the DC. The IS rejects the command if its
control software or the CC control software is still configuring its
mechanisms. If accepted, the DC "observeC" CAR record is changed to
"BUSY". It goes back to "IDLE" when the data set
observation completes (or "ERR" if the observation was not
successful).
The CC does not support this command.
The
DC will start an observation according to the currently set observation
parameters. The NIFS DC supports two readout modes – IDLE and RUN. At startup
NIFS will automatically go into IDLE mode, move to RUN mode during an OBSERVE
sequence, and return to IDLE mode at the end of the sequence. Separate
parameters are maintained for each mode.
ENDOBSERVE
On
receipt of this command, the IS forwards the command to the DC. No changes are
made to the "observeC" CAR record.
The CC does not support this command.
The
DC accepts but ignores this command.
PAUSE
On receipt of this command, the IS forwards the command to the DC.
The
CC does not support this command.
In
the DC accepts but ignores this command.
CONTINUE
On
receipt of this command, the IS forwards the command to the DC. The command is
rejected if an observation has not been paused. If successful, the "observeC"
CAR record is changed to "BUSY".
The
CC does not support this command.
The
DC accepts but ignores this command.
STOP
On
receipt of this command, the IS forwards the command to the DC. The command is
rejected if an observation is not being made. If successful, the
"observeC" CAR record is changed to "IDLE".
The
CC does not support this command.
The
DC stops the current observation at the next non-destructive read (NDR) cycle
and retains any data up to that point.
ABORT
On
receipt of this command, the IS forwards the command to the DC. If successful,
the "observeC" CAR record is changed to "IDLE".
The
CC does not support this command.
The
DC stops the current observation immediately and throws out any data. The
system is returned to the READY
state.
PARK
On
receipt of this command, the IS ensures that an observation is not taking place
and then forwards the command to the DC and the CC.
The
CC moves its mechanisms to a configuration in which it can safely be switched
off. It utilizes all the low-level CAD records dedicated to parking the
individual mechanisms. The "parkC" CAR record will go
"BUSY" while the mechanisms are being parked and then go to
"IDLE" if completed successfully or to "ERR" if any
mechanism fails to park.
The
DC readies the SDSU controller electronics so that they can be safely switched
off.
REBOOT
This
command causes the system to reboot, reload the software, and perform the init
command.
The
CC shuts down its VxWorks control tasks cleanly.
The
DC shuts down its VxWorks control tasks cleanly.
DEBUG
On
receipt of this command, the control software changes to the given debug mode
(NONE, MIN, or FULL). This mode determines the amount and frequency of
information logged, as described in the "Debugging Modes" section of
ICD 1a. The "debugC" CAR record will go briefly "BUSY" and
then back to "IDLE".
The CC sets its debug level.
The
DC sets its debug level.
APPLY
The APPLY command causes the system to match the configuration that has been sent to it by the OCS. Depending on the APPLY directive and which CADs are marked, commands will be accepted for execution, if verified, in predetermined order. If any CAD parameter is not verified the command will be rejected.
5 Instrument Sequencer Software Implementation Detail
The NIFS IS receives commands from the Observatory Control System. Each command is forwarded to the appropriate CAD record (one CAD for each command), which decides whether the command is valid, and can be acted upon at this time. If so, then, it forwards the command to the appropriate CAD records in the CC, DC, and OIWFS CC CAD/CAR databases. When a command is valid, the IS always forwards it to the DC. Only some commands are forwarded to the other databases. In NIFS, if the command is to be forwarded to multiple databases, then for every command save the INIT command, it is forwarded simultaneously to each database.
5.1 Databases
5.1.1 CAD/CAR Database
In the IS CAD/CAR database, there is a CAD for each of the sequences. Most CADs call a unique subroutine, such as CADobserve for the case of the observe CAD, which determines if the command is valid and can be carried out at this time. If the command can be processed, then the connections in the database determine whether the Components Controller CAD/CAR database is given the command. In all cases, valid commands are forwarded to the Detector Controller CAD/CAR database.
5.1.1.1 Capfast Diagrams
The abbreviated hierarchy of schematics that make up the Instrument Sequencer CAD/CAR database is shown in Error! Reference source not found.. Essentially, the database consists of a CAD and CAR for each of the sequence commands.
Figure 3: Hierarchy of Capfast diagrams in the IS CAD/CAR database design.
5.1.2 Status and Alarm Database
The IS Status and Alarm Database (SAD) is a separate EPICS database; mainly a collection of Status Information Records (SIRs) for each of the components, for each temperature sensor, and for each interlock. SNL code monitors these elements and updates the associated SIR records.
5.1.2.1 Capfast Diagrams
The hierarchy of schematics which make up the IS SAD are shown in Figure 4. The isSysSad schematic consists of eleven SIRs reporting a mix of static information (instrument name, etc.), forensic data, state information, and health.
Figure 4: Hierarchy of Capfast schematics in the IS SAD design.
5.2 SNL Code
The Instrument Sequencer employs two CICS state sets, isAnd_ss and is_ss. The state set isAnd_ss (Figure 5), simply takes the logical AND of a record field in the OIWFS CC SAD and another record field in the CC SAD, storing the result in the IS database. For NIFS, this is used to indicate whether the OIWFS is obstructed or not. The state set is_ss (Figure 6) handles the INIT sequence.
Figure 5: State transition diagram for the isAnd_ss state set.
Figure 6: State transition diagram
for the is_ss state set.
6 Testing and Simulation
Gemini simulation modes are described in ICD 1a. The NIRI software supports FAST and FULL simulation modes, therefore these are the modes that will be available for NIFS.
Appendix A: List of Figures
|
Figure 1 |
figure.gif |
|
|
|