1 Control Software

1.1 Changes Since CoDR

Since the NIFS CoDR, the software design has been developed in the following areas:

• NIRI software for the OIWFS, IS, and CC has been adopted and is running in simulation mode.
• The temperature control record has been extended to support the Lake Shore temperature controller.
• The EPICS database for the DC has been refined.
• The DC software architecture has been finalized.
• The DC hardware has been chosen and acquired.
• An EPICS training course has been undertaken by Jarnyk and Young.

Most of the software design and its rationale are unchanged since CoDR. The areas that have been changed are indicated in what follows.

1.2 Software Requirements

Software requirements were discussed in the NIFS CoDR documentation and are not repeated here.

1.3 Software Design Overview

1.3.1 Software Architecture – CICS Model

NIFS employs the Gemini Core Instrument Control System (CICS), which was developed to provide a template for instrument developers to use. It handles common operations of the Gemini telescope as well as providing standard schematics for handling instrument control. CICS consists of a suite of Capfast schematics implementing Command Action Directive (CAD), Command Action Response (CAR), Status Information Record (SIR), and APPLY records, State Notation Language (SNL) code, C-code, and user interfaces.

The CICS model is described well, and in detail, by Beard (1997). There are four key elements that are the responsibility of the instrument developer (Figure 121); the Instrument Sequencer (IS), the Components Controller (CC), the Detector Controller (DC), and the On-Instrument Wavefront Sensor Components Controller (OIWFS CC). Each element is responsible for specific actions; the three controllers control hardware and the instrument sequencer coordinates them.

Figure 121: CICS software architecture.

1.3.1.1 The Instrument Sequencer

The Instrument Sequencer is responsible for the overall operation of an instrument. It sequences the subsystems ensuring that there are no conflicting operations. So, for example, for a simple observation sequence, it may cause the Components Controller to move a filter into position, open the Environmental Cover, and select a Focal Plane Mask Wheel position. When these actions are successfully completed, it commands the Detector Controller to perform an exposure.

1.3.1.2 The Components Controller

This subsystem is responsible for the mechanisms that define the optical path through the instrument and for controlling the instrument's environment.

1.3.1.3 The Detector Controller

The Detector Controller is responsible for controlling the instrument's detector and acquiring and processing data from it.

1.3.1.4 The OIWFS Components Controller

This is a separate components controller responsible for the mechanisms belonging to the On-Instrument Wavefront Sensor. It differs from the Components Controller, in that it is only initialized by the Instrument Sequencer, and thereafter it is under the control of the acquisition and guidance system of the Observatory Control System (OCS).

1.3.2 Network Architecture

EPICS is a distributed system. The EPICS system used in NIFS has two Input-Output Controllers (IOCs) running under VxWorks on a Power PC system and the Operator Interface running on a Sun workstation, with communications over TCP/IP (Figure 2). The database resides on the IOC and the user communicates with the database (and, hence, the underlying hardware) from the workstation through an operator screen. For performance reasons, the Detector Controller occupies its own IOC.

It is, of course, necessary to get information into and out of the records. This is achieved using channel access. By uniquely naming a record, it is possible to access a record's fields for reading and writing. In the CICS model this feature is used extensively.

Figure 122: Network architecture of NIFS.

1.3.3 NIRI

The NIFS IS, CC, and OIWFS CC software are based on the NIRI software. The NIRI software, which is CICS based, is designed to handle eight mechanisms in the Components Controller and five in the OIWFS CC. As NIFS uses fewer, but similar, mechanisms, adaptation of the NIRI software to suit NIFS has been conceptually easy.

1.4 Instrument Sequencer Software Design

1.4.1 Changes Since CoDR

The Instrument Sequencer was implemented as anticipated in the CoDR; the NIRI Instrument Sequencer software was used with minor changes.

1.4.2 Introduction

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 123), 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 123: Instrument Sequencer databases.

1.4.3 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 which 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.

1.4.4 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 (detailed in §8.4.3). 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.

1.4.4.1 Databases

1.4.4.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.

1.4.4.1.1.1 Capfast Diagrams

The abbreviated hierarchy of schematics that make up the Instrument Sequencer CAD/CAR database is shown in Figure 124. A description of each schematic is given in Appendix G (§16.2). Essentially, the database consists of a CAD and CAR for each of the sequence commands.

Figure 124: Hierarchy of Capfast diagrams in the IS CAD/CAR database design.

1.4.4.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.

1.4.4.1.2.1 Capfast Diagrams

The hierarchy of schematics which make up the IS SAD are shown in Figure 125. A description of each schematic is given in Appendix G (§16.3). The isSysSad schematic consists of eleven SIRs reporting a mix of static information (instrument name, etc.), forensic data, state information, and health.

Figure 125: Hierarchy of Capfast schematics in the IS SAD design.

1.4.4.2 SNL Code

The Instrument Sequencer employs two CICS state sets, isAnd_ss and is_ss. The state set isAnd_ss (Figure 126), 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 127) handles the INIT sequence.

Figure 126: State transition diagram for the isAnd_ss state set.

Figure 127: State transition diagram for the is_ss state set.

1.5 Components Controller Software Design

1.5.1 Changes Since CoDR

The Components Controller design follows the anticipated design of the CoDR closely, viz. using the NIRI software and modifying it to handle fewer components. Thus, just as for the Instrument Sequencer, we have implemented and now have working Components Controller software. We detail that implementation in this section.

In addition, we have added a further command to the mechanism command set: EngMoveOffset, which moves a number of engineering steps from the current position. This was necessary for fine control of the Grating Turret and the Focal Plane Mask Wheel.

At the CoDR, it was noted that since NIFS uses the Lake Shore temperature controller rather than NIRI’s Omega temperature controller, it may have become necessary to write EPICS support for the Lake Shore controller. Owing to the differences between the two controllers, this has been necessary and the design is discussed in §8.5.3.3.4.

1.5.2 Introduction

Like the Instrument Sequencer, the Components Controller consists of an EPICS Capfast hierarchy, SNL code, and C support routines.

The Components Controller controls the instrument elements that are in the light path. These are:

· Focal Plane Mask Wheel.

· Order Blocking Filter Wheel.

· Grating Turret.

· Environmental Cover.

· Flip Mirror.

As NIFS is an instrument designed to use a copy of the NIRI cryostat, the methods used to control and position these active elements are identical to those used in NIRI which have been developed at the IfA.

1.5.3 Components Controller Software Implementation Detail

1.5.3.1 Overall Architecture

The Components Controller consists of four databases (Figure 128); the Components Controller CAD/CAR database where commands are issued, the Components Controller mechanism database that controls motors, the Components Controller temperature database which controls temperatures, and the Components Controller SAD. Sequencer code acts on commands, controlling the motors through the mechanism database, and transferring status and alarm information into the SIR records of the SAD.

Figure 128: Components Controller Architecture.

1.5.3.2 Specific Differences to NIRI

NIRI has support for more mechanisms than required for NIFS. Both systems use Hall effect sensor controlled stepper motors. The NIFS Components Controller databases were created by removing the extraneous mechanisms and adding a mechanism to handle the flip mirror. Each mechanism has a look-up table that defines the sensor positions. These are configured at set-up time.

At least one mechanism, the grating turret, requires greater precision than can be obtained currently with the NIRI datum strategy. Therefore, one Hall effect sensor on the grating turret will be employed for fine-tuning the datum, requiring a change to the Hall effect record, and the device support record. This change has yet to be implemented.

The grating turret also requires the ability to make small offset movements from the nominal position. To this end, we have added EngMoveOffset to the mechanism command set. This change has required small modifications to the eng_ss sequence and the comp1mCad schematic. No change to the underlying record or device support code was necessary. The focal plane mask wheel also uses this new facility.

1.5.3.3 Databases

1.5.3.3.1 CAD/CAR Database

The CC CAD/CAR database provides the means to control the mechanisms and temperature controllers of the Components Controller. All commands, whether system sequences or local commands (such as opening a cover) are processed by CAD records.

The complete hierarchy of Capfast schematics is shown in Figure 129. A description of each schematic is given in Appendix G (§16.4).

Figure 129: Hierarchy of Capfast schematics in the CC CAD/CAR database design.

1.5.3.3.2 Status and Alarm Database

The CC Status and Alarm Database is a separate EPICS database, largely a collection of SIRs for each of the components, for each temperature sensor, and for each interlock. SNL code monitors these elements and updates the associated SIR.

The full hierarchy of Capfast diagrams for the CC SAD is shown in Figure 130. As can be seen, there is a schematic group for each of the components. Each of the schematics that makes up this CC SAD is described in Appendix G (§16.5).

Figure 130: Hierarchy of Capfast schematics in the CC SAD design.

1.5.3.3.3 Mechanism Database

As shown in Figure 128 the hardware records are contained in databases that are separate to those containing the CAD and CAR records. SNL state sets transfer information between the CAD, CAR, and SIR records and their hardware counterparts.

The Components Controller mechanism database is detailed in Figure 131. A description of each schematic is given in Appendix G (§16.6). Two records, with associated device handlers and drivers, were created for NIFS; the hallstep record and the hmotor record. These are described in detail in Yamada (1997). Neither of these records is accessed directly. Rather the user connects to the EPICS "mech" record.

Figure 131: Hierarchy of Capfast schematics in the CC mechanism database design.

1.5.3.3.4 Temperature Database

The Components Controller temperature database is a trivial database (Figure 132). A description of each schematic in Figure 132 is given in Appendix G (§16.7). In addition to the hmotor record, it uses three other records created for NIFS; the tsen, tcon, and cool records.

Figure 132: Hierarchy of Capfast schematics in the CC temperature database design.

NIRI employs three Omega CYC321-01 temperature controllers. NIFS replaces one of these with a Lake Shore Model 340 temperature controller, which, unlike the Omega CYC321-01, is a dual controller. To accommodate the new instrument, the tcon record has been changed, and a device handler and driver have been written. These changes and additions are detailed here.

1.5.3.3.4.1 Temperature Controller Record

In keeping with the EPICS’ philosophy of decoupling records from the hardware, we have not created a new temperature controller record specifically for the Lake Shore device. Rather, we have generalized the exisiting record (tcon) to handle both the Lake Shore and Omega controllers. The only change required has been the addition of a single input called LOOP. For the Lake Shore device handler, this specifies the control loop to which the command refers. The Omega device handler will ignore this input.

1.5.3.3.4.2 Device Support

The device handler code used as a starting point was the device handler code for the Omega controller, devOcyc. The new code uses a similar command set with a few additional commands to handle self-testing, set a settling time, and to handle readbacks (which are different to the Omega controller). It uses the LOOP parameter passed to it to select the appropriate loop of the Lake Shore temperature controller.

1.5.3.3.4.3 Device Driver

The device driver code is based closely on the driver code for the Omega controller, drvOcyc. Essentially, the only differences are the different command set.

1.5.3.4 SNL Code

State sets, written in SNL, are the means of implementing state machines within EPICS. They are not part of the database proper, but rather, coexist with it and are bound to it. In CICS, the state sets monitor the CAD records waiting for incoming commands to these records. Issuing a command changes a CAD record field and this change triggers a state set. The state set acts on the command, updating CAR records in the CC CAD/CAR database, changing fields in the CC mechanism database, and updating SIRs in the CC SAD.

The NIFS components controller employs six state sets:

cc_ss Manages the initialization of the CICS components controller.

datum_ss Process the "datum" command and manage "datumC" CAR records.

park_ss Process the "park" command and manage "parkC" CAR records.

eng_ss Process commands for one axis of a component issuing commands to the underlying mechanism database.

compPseudo_ss Handle BUSY state for one axis of a component.

engMode_ss Handles BUSY-IDLE state.

Each of these state sets, except for eng_ss, was adopted from the NIRI code without modification. Eng_ss was modified to handle the extra command, EngMoveOffset. The state transition charts of Figure 133 to Figure 138 illustrate each of these state sets. Note, particularly in reference to Figure 138, that there is an order in which each case is evaluated. The order for a particular state is indicated by a number in the diagram.

Figure 133: State transition diagram for the cc_ss state set.

Figure 134: State transition diagram for the compPseudo_ss state set.

Figure 135: State transition diagram for the datum_ss state set.

Figure 136: State transition diagram for the park_ss state set.

Figure 137: State transition diagram for the engMode_ss state set.

Figure 138: State transition diagram for the eng_ss state set.

There are multiple instances of each state set. For example, there are five mechanisms in the components controller, and so, there are five eng_ss state sets running, each responsible for its own mechanism. The state sets are configured at run-time. For example, the eng_ss state set controls the database record field {top}{mech}EngTol. At run-time, the state set for the Environmental Cover is loaded, thus:

seq &engSt, "name=ccCov, top=nifs:cc:, sadtop=nifs:cc:, eng=nifs:eng:cc:, sys=sys, mech=cov"

Therefore in the eng_ss state set (a state set in the engst file) the record field {top}{mech}EngTol becomes nifs:cc:covEngTol.

1.5.4 Testing and Simulation

NIFS has mechanism simulation provided – we will use this for testing software before any hardware is in place.

Gemini simulation modes are described in ICD 1a. The NIRI software supports FAST and FULL simulation modes, so these are the modes that will be available for NIFS.

1.6 OIWFS Components Controller Software Design

1.6.1 Changes Since CoDR

Like the Components Controller, the design of the OIWFS Components Controller software follows the anticipated design of the CoDR closely, viz. using the NIRI software and modifying it to handle fewer components.

1.6.2 Introduction

The OIWFS CC is responsible for three mechanisms:

• Gimbal mirror x-axis.
• Gimbal mirror y-axis.
• Filter wheel.

NIRI has an additional mechanism, and thus adapting the NIRI software has been a simple case of removing the extra component from the databases. Reusing the NIRI software has allowed us to have working software, and in this section we describe this implementation.

1.6.3 OIWFS Components Controller Software Implementation Detail

The OIWFS CC software is simply another components controller. It differs from the main components controller, in that it is only initialized by the Instrument Sequencer, and thereafter it is under the control of the acquisition and guidance unit of the Observatory Control System. Like the main components controller it operates motors and a filter wheel, and thus, its software is similar to the Components Controller software. The OIWFS CC consists of three databases: the OIWFS CC CAD/CAR database, the OIWFS CC mechanism database, and the OIWFS CC SAD.

1.6.3.1 Databases

1.6.3.1.1 CAD/CAR Database

The full hierarchy of the OIWFS database is shown in Figure 139. A description of each schematic is given in Appendix G (§16.8).

Figure 139: Hierarchy of Capfast schematics in the OIWFS CC CAD/CAR database design.

1.6.3.1.2 Status and Alarm Database

The full Capfast hierarchy for the OIWFS CC SAD is shown in Figure 140. Most of the schematics employed are also used by the CC SAD (§16.5). A description of the additional schematics employed by the OIWFS CC SAD can be found in Appendix G (§16.9).

Figure 140: Hierarchy of Capfast schematics in the OIWFS CC SAD design.

1.6.3.1.3 Mechanism Database

The OIWFS CC mechanism database is a small database (Figure 141), handling the motors of the filter wheel, and the x-y axes of the gimbal mirror. A description of each schematic in Figure 132 is given in Appendix G (§16.8). The OIWFS CC mechanism database employs the "mech" record as used in the CC mechanism database.

Figure 141: Hierarchy of Capfast schematics in the OIWFS CC mechanism database design.

1.6.3.2 SNL Code

As the OIWFS CC is another components controller, it uses the same state sets employed by the main components controller (see §8.5.3.4).

1.6.4 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.

1.7 Spectrograph Detector Controller Software Design

1.7.1 Changes Since CoDR

Since the NIFS CoDR the following areas of the DC software design have been enhanced and or modified:

· The DC architecture has been refined to match the latest OCDD requirements (§8.7.3.1).

· EPICS CAD/CAR and SAD databases have been developed (§8.7.3.2).

· Capfast schematics for the EPICS databases have been completed (Appendix G, §16.11 and §16.12).

· Operational commands and parameters have been defined and formed into PDF tables (ICD 1.9f/3.1).

· The DC IOC hardware has been purchased and its performance verified (SDN0011.04).

· The Control task has been re-designed to use SNL state sets (§8.7.4.1.1).

· The interface layer between EPICS and NIFS VxWorks tasks has been refined.

· Some prototyping and testing has been done to verify some of the design decisions in the DC architecture (§8.7.4.2).

· The software project plan has been updated and incorporated into the NIFS management plan.

Otherwise this design document is much the same as the CoDR DC software document.

1.7.2 Introduction

The design for the Detector Controller has been driven by the need to fast-track the construction of the NIFS instrument and therefore reuses as much software as possible from multiple sources. To meet Gemini interface requirements and to make things as simple as possible, it was decided to copy the “thin EPICS layer” approach adopted by the GMOS detector controller group. This approach is described in the GMOS CCD Controller Software Manual (Wolff & Ruckle 1999). This will be coupled with a suitably modified copy of RSAA’s existing SDSU-2 controller interface software to take advantage of code reuse.

Full detail of this approach and a description of the rationale can be found in the NIFS CoDR documentation and will not be repeated here. This document concentrates on the actual design adopted.

1.7.3 Spectrograph Detector Controller Software Design

The DC software consists of a multiple task architecture designed to optimally support the requirements of the NIFS science detector.

1.7.3.1 Overall Architecture

The DC architecture used tasks written as EPICS SNL code to interface to Gemini. We refer to these as the Control tasks, They are responsible for interfacing to the Gemini systems using EPICS channel access. The Control tasks pass commands to the Slave task for taking exposures and setting up the detector using the SDSU-2 controller. The Slave task monitors the progress of the Readout task during a detector readout and signals readout progress to the Data task. Progress is monitored through the use of an interrupt service routine (ISR) that is executed in response to an interrupt generated by the SDSU-2 VME Interface Board. The Data task will then transfer image data to the Gemini Data Handling System (DHS) for storage and quick look display. Figure 142 illustrates this architecture.

Figure 142: NIFS DC software architecture.

The architecture also shows five external systems and five internal data stores. Two of the data stores are EPICS databases for storing configuration and status information. There are also shared memory areas for storing operational parameters, copied from the EPICS CAD/CAR database, and status information before being moved to the EPICS SAD database. A shared memory area is again used for storing the detector image data at various stages of processing.

1.7.3.2 Gemini CAD/CAR/APPLY/SIR Interface – EPICS Databases

Gemini requires that instrument developers use EPICS CAD/CAR/APPLY and SIR records to interface to the Gemini observatory systems and control the instrument. We have decided to adopt the "thin-layer" EPICS approach used by the NOAO CCD detector controller group. In this approach the EPICS layer supports the setting of parameters and handling of commands through CAD and APPLY records by the OCS, but lower level code does any parameter verification and performing of required actions. The EPICS layer simply passes parameters and commands, gets back status, and does nothing else. Operational parameters are moved to the lower level shared memory area after they are modified. This is done using the CAD SNAM subroutines. This shared memory area is then accessed by the lower level tasks during the operation of the NIFS detector.

The NIFS DC recognizes all the OCS detector controller commands and uses the CAD/CAR records specified in ICDs 1a and 1b. Some of these are ignored but handled correctly by the toggling of the action state from BUSY to IDLE.

Configuration and status parameters in Gemini parameter definition format are available in ICD 1.9f/3.1. Settings for two observation modes are maintained: Idle and Run mode. In addition, SDSU-2 controllers settings are also detailed.

NIFS DC Capfast diagrams are based on the CICS DC (Beard 1997) and GMOS DC (Wolff & Ruckle 1999) hierarchy of Capfast diagrams. Changes have been made to reflect the requirements of NIFS.

1.7.3.2.1 CAD/CAR Database

Figure 143 shows the Capfast diagrams for the DC CAD/CAR database design. Note that they are arranged according to similar grouping. CADs are APPLIED in order from left-right and top-bottom. A description of each schematic is given in Appendix G (§16.11).

Figure 143: Hierarchy of Capfast diagrams in the DC CAD/CAR database design.

The following describes how this database is designed (and is taken from Wolff & Ruckle 1999):

- Top level APPLY record

The DC CAD/CAR database has a top level APPLY record that can control the actions of all of the CAD records connected to it. If a CLEAR or MARK is given to the APPLY record, all of the CAD records connected to it will perform that action. If a PRESET, START, or STOP is sent, only the CAD records that are currently marked will be processed. The CAD records are marked by either sending them a MARK directive, or sending a new value to one of their inputs (A,B,C...fields).

- Lower level APPLY records

The CAD records are assembled into groups depending on their function. Each group has an APPLY record assigned to it. This lower level APPLY record gets a command from the top level APPLY and sends it along to the CAD records one by one. If the first CAD record finishes with CAD_ACCEPT, then the next one is started, otherwise, a CAD_REJECT is returned, and no other CAD records are processed. When all the CAD records under this APPLY are done, an ACCEPT or REJECT is returned to the upper level CAD. Which will either allow the processing of the next group, or stop processing with a REJECT.

- CAR records

CAR records retrieve responses from the CAD records when a START directive is received by a marked CAD record. They are set to BUSY while the CAD is processing, and set to IDLE or ERROR depending on the result of processing. The VAL, OERR, and OMSS of all the CAR records are connected to the APPLYC CAR record through a structure of GENSUB records. The GENSUB records look at the VAL fields of the CARs connected to it and pass along the value that is the greatest along with the corresponding OERR and OMSS fields.

This database includes CAD records for the reboot, init, test, park, debug, set up SDSU, set up readout sequence, set up data processing (including setDhsInfo), observe, stop, and abort commands. Other mandatory Gemini sequence commands are also included but are ignored except for the toggling of the corresponding CAR from BUSY to IDLE (verify, endVerify, guide, endGuide, endObserve, pause, continue, and datum).

1.7.3.2.2 Status and Alarm Database

The DC SAD has Capfast diagrams for system, SDSU, exposure, and data status information. Figure 144 shows this arrangement. A description of each schematic is given in Appendix G (§16.12).

Figure 144: Hierarchy of Capfast diagrams in the DC SAD design.

Each of these Capfast schematics have SIR records that describe each of these areas of the DC design. A full description of all SIR records is available in ICD 1.9f/3.1. Some SIR records are updated directly from CAD output parameters when they are verified with the CAD PRESET directive. The remainder are updated from the operational NIFS C++ status object whenever they are modified. This immediate update is implemented by the use of C++ class methods that are called by the lower layer NIFS C++ code when updating a status parameter. That is, access to the SAD database by the non-EPICS layer of NIFS is encapsulated in the class implementation – each status member variable in the nifs_status class has a corresponding SIR record which is updated whenever the private member variable is updated using the appropriate class method.

1.7.3.3 SNL Code

The DC design uses three SNL state sets. These are used to interface between the Gemini EPICS layer and the NIFS VxWorks tasks. They are described fully in §8.7.4.1.1. The SNL code, typically, monitors the st.VAL field of a CADPLUS schematic for an indication that a particular CAD has received a START directive. These CADPLUS schematics are connected to the STLK forward link of a CAD record.

1.7.3.4 Support Routines

The DC CAD/CAR database CAD records call VxWorks support routines named in their INAM and SNAM fields at record initialization or in response to a directive passed in from an APPLY record. These routines are called directly from the EPICS database code. For NIFS, the INAM routines are used to write default values to a lower level C++ class object which is accessed by VxWorks tasks. The SNAM routines need to respond appropriately to each CAD directive, including verifying input parameters (PRESET directive), and starting any associated command (START directive). For NIFS, during a PRESET, parameters are copied from the CAD record field (inputs A-T) to the C++ class object, using a method of the class that will perform the actual verification and return a status result to the support routine for passing back to EPICS (see §8.7.4.1.5). The input parameters, if verified, are also copied to the CAD output fields. Note, that it is very important to maintain the correct mapping between an input CAD record field and the NIFS functional parameter. These support routines provide that mapping and therefore must be kept aligned with the CAD EPICS database generated by Capfast.

1.7.3.5 SDSU-2 IR Controller Interface

The lower layers of code running in the Slave, Readout, and Data tasks are triggered by commands from the Control task. These codes interface directly with the SDSU-2 electronics. RSAA has experience using this controller and intend to take advantage of code already in use. Code reuse issues were covered at the NIFS CoDR and will not be repeated here. We will also be making use of work done by Tim Hardy of the National Research Council of Canada, by using ideas from their sdsuLib code.

1.7.3.6 RSAA’s SDSU-2 Camera C++ Class

This section provides an overview of the RSAA Camera class and shows how this can be developed into a reusable component for Gemini cameras in a way that has been successfully deployed at RSAA.

The Camera class is a hierarchical arrangement of C++ classes that form a code infrastructure to support different electronic readout hardware. Because camera readouts are similar in most operations, this code uses common methods where possible. When specific hardware operations are required, base class methods are overridden with specific methods in the sub-class. The diagram in Figure 145 illustrates this hierarchical arrangement.

Figure 145: Camera class hierarchy.

The base level Camera class contains member variables and methods that are generic for all controller types. These include support for:

· Camera description - generic camera description information including number of controllers, controller type, number of detectors, detector type, detector size, detector location, number of readouts, readout size, readout location, and readout direction and orientation.

· Configuration - information about how the camera is currently configured.

· Regions of interest information.

· Image buffer information.

· Observation settings.

· Status detail.

· Readout progress monitoring.

· Image transfer methods, including unscrambling the data stream.

Controllers of different types make use of this common code for handling camera operations. For NIFS, the sub-classes SDSU and SDSU2_IR will model the behavior of the SDSU-2 infrared hardware. The class SDSU handles all functionality generic to this type of controller and includes support for:

· Controller communication, including device access, command passing, reply handling, and DSP code downloading.

· Generic controller initialization functions. Some initialization commands are common for the different SDSU controller types, e.g., power on and DSP code downloading.

· Controller hardware tests.

· Exception handling – including interrupts.

The SDSU2_IR class will handle functionality specific to the infrared controller. Including:

· Exposure handling.

· Infrared readout methods. Specifically, these will be linear fitting, double correlated sampling, and Fowler sampling.

The NIFS sub class will handle image processing specific to the NIFS IFU. This relates to recombining the image slices into a data cube and then compressing the cube along the spectral axis.

At RSAA, the classes Camera, SDSU, SDSU1 and SDSU2 are in place, so for NIFS, coding of the SDSU2_IR and NIFS classes are required as well as some repackaging of the base classes to handle integration.

1.7.3.6.1 The SDSU2_IR Class Specific Readout Methods

Three readout methods will be supported by NIFS. These are:

1. Double Correlated Sampling

This method resets the array and then performs an immediate read. At the end of the exposure a final read is performed and the resultant image is the difference between the two images. Parameters for setting the number of resets and the delay after a reset will be available through a CAD record.

2. Fowler Sampling

Fowler & Gatley (1990) show that read noise can be reduced by performing multiple non-destructive reads of the detector at the beginning and end of the integration ramp.

This algorithm operates by averaging N full readouts of the detector at the beginning of the exposure and then N full readouts at the end of the exposure. The resultant image is the difference between the two averaged images.

Saturated pixel and cosmic ray handling for these first two methods are limited to masking out relevant pixels during data reduction – if detected. That is, these pixels can only be detected if values are saturated by the time of the second set of reads. If so detected an array S is marked.

3. Linear Fitting

In this method, the detector is first reset, then the array is read, non-destructively, N times over the total exposure time at regular intervals. As the data are accumulated a least-squares linear regression is fitted through each pixel to define the incident photon rate. The algorithm used to calculate the slope of the regression is taken from Chapman et al. (1990). This is shown in rewritten form to enable progressive computation and hence progressive display of the integration as

where V_i is the voltage of sample i, n is the total number of samples, and dt is the period between NDR samples. This is a much-simplified version of the general straight line fitting equation due to the constant value of the NDR period, dt.

To compute the variance array for this fit, the calculation of E below has to be made for each pixel (see Neter & Wasserman 1974).

Memory has to be set aside to save values for SiV, SV, and SV² for each pixel, while the other terms are constant. The time needed for this processing is of the order of 3.3 s for the full detector size on the 400 MHz SVGM5 (see §8.7.4.2.4).

A detailed analysis of the comparative advantages of each of the readout methods with respect to image quality is provided in §6.8.

Complications arise when pixels saturate or cosmic rays are encountered. These issues are described below.

1.7.3.6.1.1 Saturated Pixels

When V becomes saturated for any pixel, accumulation of the sums will cease and the data recorded up until the current time will be used to calculate the slope. This will require a recording of NDR number at which a pixel saturates, in array S. This array will be initialized to zeros and is implemented using single bytes, allowing NDR values of up to 254 to be recorded (the value 255 is reserved for bad pixels, see §8.7.3.6.1.3). NIFS is unlikely to perform more than 254 NDRs per exposure due to the accumulated effect of multiplexer glow (§6.8.4). .

1.7.3.6.1.2 Cosmic Rays

Cosmic rays can, perhaps, be detected by checking the rate of change of the calculated slope. If this goes above a threshold then accumulation of data for the pixel will cease and, in the first instance, begin again in secondary arrays SiV2, SV2, and SV2². A weighted-average of the two slopes will be used for calculating the final pixel value. To indicate whether a pixel has encountered a cosmic ray, an array C will be used to record the time. A second cosmic ray encounter for a pixel will result in data recording stopping and the array S marked, that is, the pixel will be deemed to have saturated.

1.7.3.6.1.3 Bad Pixels

Bad pixels will be recorded in the array S with the value of 255. These will be initialized from a bad-pixel file loaded from disk when the system starts up.

1.7.3.6.2 Detector Readout Linearity

Consideration has to be made of the linearity of the detector integration. This is discussed in §6.12.4, but is essentially a correction applied to each pixel using a calibrated parameter. Setting of this parameter will be made through the CAD database with reflection in the SAD. Final details are yet to be determined.

1.7.3.6.3 Subtracting Out the Sky

The Readout task will subtract out the sky for each image before the image processing mentioned below (§8.7.3.6.4) is performed and the resultant image displayed in a DHS quick-look tool. It does the image subtraction by using a loaded sky frame for the particular operating mode Idle or Run. See §8.7.4.1.3 for a full description of this process.

A DHS quick-look tool will be used to perform image-subtraction for display of the raw data frame after it is transferred to the DHS.

1.7.3.6.4 NIFS Specific Image Processing.

Some image processing needs to be performed before quick-look displays are useful to the astronomer because of the nature of the NIFS IFU. In addition to the raw data file (suitably unscrambled and fitted), the image data need to be reformatted into a spatial image of the object from the 29 IFU slitlets.

In the case where the flip mirror is in use (i.e., during object acquisition), the IFU slit staircase (see §4.6.12) is collapsed so that each of the slitlets are aligned next to each other to form an image of the object with slitlet height on the y axis and each of the slitlets along the x axis.

In the case where the spectrum is dispersed, the data are formed into an image cube with slitlet height on the y axis, each of the slitlets along the x axis, and wavelength along the z axis. This cube is then compressed along the z axis, over a user-chosen wavelength interval, to form an image of the object.

Because each IFU slitlet is 0.103^″ wide and the pixel height in the spatial direction is 0.043^″ , each detector pixel is sub-divided by five and two in width and height, respectively, to form a final display pixel size of ~ 0.02^″×0.02^″ on the sky. The resulting image size is 145×140 pixels. This image is sent to a quick look display for preview. See the NIFS OCDD for a detailed description of this requirement.

The time needed for this processing is 0.23 s for the full detector size on the 400 MHz SVGM5 (see §8.7.4.2).

1.7.3.6.5 Internal Data Storage Requirements

The arrays described in Table 68 will be required to support the minimum data processing requirements for the NIFS readout methods. These sizes are based on pixels from four quadrants each of size 1024 × (1024 + 32) pixels, where each readout row (or column, depending on readout orientation) will usually have 32 reference samples appended (§6.7.2).

Table 68: Data Storage Arrays – Linear Fitting.

Array Name	Data Type	Size (MB)	Description
pix x 2	U16	16.5	Raw pixels – double buffering (V).
fitPix	R32	16.5	Fitted pixels (f(V)).
pixSum	U32	16.5	Sum of raw pixels (SV).
pixSqrSum	U32	16.5	Sum of raw pixels squared (SV^2).
iPixSum	U32	16.5	Sum of iteration times raw pixel (SiV).
pixSumC	U32	16.5	Sum of raw pixels after a cosmic ray (SV2).
pixSqrSumC	U32	16.5	Sum of raw pixels after a cosmic ray (SV2^2).
iPixSumC	U32	16.5	Sum of iteration times raw pixel after a cosmic ray (SiV2).
cosmic	U8	4.0	Cosmic ray flags (C).
saturated	U8	4.0	Saturated/bad pixels flags (S).
pixCumSum	R32	16.5	Cumulative sum for series of short exposures (Sf(V)).
skyIdle	R32	16.5	Sky image for idle mode.
skyScience	R32	16.5	Sky image for run mode.
intensity	R32	16.5	Fitted and unraveled pixels (F).
variance	R32	16.5	Variance for fitted pixels (E).
Total		222.5

Note that the data buffers for intensity, variance, and saturated data will be used when transferring the data to the DHS. Before transfer to the DHS begins pixels will be unraveled into correct array coordinates (see §8.7.3.7).

For the Double Correlated Sampling and Fowler Sampling methods, more than one pix array will be needed. Table 69 indicates the buffer requirements for N=16 (in the Fowler Sampling case).

Table 69: Data Storage Arrays - Double Correlated Sampling and Fowler Sampling

Array Name

Data Type

Size (MB)

Description