Gemini Near-Infrared Integral-Field Spectrograph (NIFS)

 

 

 

 

Control Software

 

9.1 Software Requirements

 

9.1.1 Introduction

 

NIFS is a conforming Gemini instrument which is closely modeled after NIRI. As a conforming instrument the software requirements for NIFS fall into the following categories:

 

·         Compliance with Gemini software design requirements as described in ICDs 1-16 which describe a conforming ICS as one which runs on a VME-based IOC running VxWorks and EPICS.

·         A conforming ICS is made up of three distinct components – the Instrument Sequencer (IS), the Components Controller (CC) and the Detector Controller (DC). Each of these components has particular requirements.

·         NIFS is required to be a fast-track instrument. The instrument is modeled after NIRI, hence software should be very similar. The NIRI software model followed the CICS template, which turned out to be somewhat problematic (Yamada 1999b). Regardless, the NIFS software design will adopt the NIRI code, except for the Detector Controller (DC) package, not expecting any significant differences.

·         NIFS will also have an OIWFS which will be a duplicate of the NIRI OIWFS.

·         Performance: Different readout methods employed by the DC package have specific processing and memory needs on the IOC.

 

9.1.2 Compliance with Gemini Software Design Requirements

 

The following list of requirements were gleaned from relevant Gemini documentation:

 

·         Programming languages will be GNU C and, with justification, GNU C++.

·         Software must follow the CICS model as closely as possible.

·         All Gemini systems must interact via CAD/CAR/APPLY/SIR records.

·         All widgets on the Engineering interface must connect to a CAD, CAR, APPLY or SIR record.

·         The engineering user interface must be written in the EPICS tools edd/dm.

·         All EPICS databases must be written in Capfast.

·         All public process variables must be made accessible via SIR records.

·         Provide a historyLog record for logging status to the DHS.

·         Provide a top-level debug command.

 

9.1.3 Fast-track Development

 

The initial approach taken by the NIFS team was to copy as much of the NIRI software effort as possible – at least with respect to the Instrument Sequencer (IS) and Components Controller (CC). Recently, however, it has become clear that this is now not the recommended approach to take. Both the Gemini Project Office and the NIRI software developers have advised us to look to other groups for a preferred software model. Immediately the requirement that NIFS be fast-tracked is at risk. Presently the Gemini software working group is considering how to redevelop the CICS so that instrument groups have a more flexible, efficient model to work with. But this work has yet to be completed, so we will adopt the NIRI code as is.

 

NIFS will use the SDSU-2 array controller for reading the detector. Software for this is a new piece of work but existing RSAA experience and software developed for this controller can be utilized. In addition, work done by the NOAO Gemini instrument group for the Gemini CCD controller can assist our development in the EPICS area.

 

9.1.4 Functional Requirements

 

The functional requirements of the components of NIFS are described below – the definition of each component is taken from the CICS Detailed Design Document.

 

9.1.4.1 OIWFS

 

This subsystem is a separate Components Controller responsible for the mechanisms belonging to the OIWFS of the instrument.

 

The NIFS OIWFS will be a duplicate of the NIRI OIWFS.

 

9.1.4.1.1 OIWFS Mechanisms

 

The OIWFS CC will control and position these 3 active elements:

 

·         X-Axis Gimbal

·         Y-Axis Gimbal

·         Filter Wheel

 

9.1.4.1.2 OIWFS Interfaces

 

The OIWFS is part of the Gemini A&G system. The Gemini document ICD 5 describes the interfaces to the OIWFS.

 

9.1.4.2 Spectrograph Instrument Sequencer

 

This process is responsible for the overall operation of an 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).

 

9.1.4.2.1 Spectrograph Instrument Sequences

 

The OCS provides the instrument with the science configuration and then issues a sequence of the following commands to run the instrument:

 

-          TEST – test all components

-          INIT – setup the instrument and read the hardware configuration file

-          RESET – change to the start-up configuration

-          CHECK – check a target configuration is feasible

-          APPLY – move to a target configuration

-          OBSERVE – make an exposure

-          PAUSE – pause an exposure (not relevant for NIFS - ignored)

-          CONTINUE – continue an exposure (not relevant for NIFS – ignored)

-          STOP – cancel an exposure

-          FLUSH – complete any pending data processing operations and store the data generated by an exposure

-          ABORT – emergency stop

-          PARK – adopt a safe configuration

 

These are the standard set of Gemini OCS commands more fully described in the SDD.

 

9.1.4.2.2 Spectrograph IS Interfaces

 

The IS software package will interface to the following Gemini subsystems:

 

-          Gemini observatory control system (OCS).

-          NIFS components controller running on the NIFS components controller IOC.

-          NIFS detector controller running on the NIFS detector controller IOC.

-          NIFS engineering interface running on a Sun Solaris workstation.

-          Gemini status and alarms database (SAD).

-          Gemini synchronization bus

-          Gemini time bus

 

9.1.4.3 Spectrograph Components Controller

 

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

 

9.1.4.3.1 Spectrograph CC Mechanisms

 

The spectrograph Component Controller (CC) is responsible for moving and positioning all of the optical elements associated with the NIFS cryostat. Externally there is also a light tight window cover.

 

The spectrograph CC will control and position these 4 active elements (§7.1):

 

·         focal plane mask wheel

·         order blocking filter wheel

·         grating wheel

·         environmental cover

 

The spectrograph active elements will mostly be controlled using copies of the NIRI mechanisms. An open loop scheme using stepper motors and dead reckoning is employed using Hall effect sensors to provide "home" or "datum" positions (§7.1). Once a zero-point is established, the number of steps taken by the stepper motor determines position.

 

The NIRI software developers have developed the MECH EPICS record for interacting with the motors and sensors. NIFS will make use of this record with appropriate modifications (e.g., number of positions and steps).

 

9.1.4.3.2 Spectrograph CC Interfaces

 

The CC software package will interface to the following Gemini subsystems:

 

-          NIFS instrument sequencer running on the NIFS components controller IOC.

-          NIFS engineering interface running on a Sun Solaris workstation.

-          Gemini interlock bus

-          Gemini time bus

-          Gemini status and alarms database (SAD).

 

9.1.4.4 Spectrograph Detector Controller

 

This subsystem is responsible for controlling the instrument’s detector array and obtaining and processing data from it.

 

The Detector Controller (DC) will be setup using standard CAD records and will be read out using the RSAA developed SDSU-2 camera C++ class. This will be modified to interface to the Gemini DHS.

 

9.1.4.4.1 Spectrograph Detector

 

The NIFS science detector will be the Rockwell HAWAII-2 array (§8.1). This detector will be read out from four outputs simultaneously, therefore the DC software will need to preprocess the data into a correct sequence before it is sent to the DHS.

 

9.1.4.4.2 Spectrograph Detector Electronics

 

The detector electronics will be the SDSU-2 infrared array controller from San Diego State University (§8.3).The DC software will need to support the direct configuration of the SDSU-2 controller and handle all communications via the SDSU-2 VME interface card installed in the DC IOC. Fiber optic cable will connect the VME interface to the SDSU-2 electronics.

 

9.1.4.4.3 Spectrograph DC Interfaces

 

The DC software package will interface to the following Gemini and NIFS subsystems:

 

-          NIFS instrument sequencer running on the NIFS components controller IOC. 

-          NIFS engineering interface running on a Sun Solaris workstation.

-          The SDSU-2 controller electronics.

-          Gemini data handling system and quick-look displays (DHS).

-          Gemini status and alarms database (SAD).

-          Gemini interlock bus.

-          Gemini time bus.

 

9.1.4.5 Spectrograph Engineering Interface

 

The engineering interface will be developed using edd/dm and will be a modified copy of the NIRI engineering interface for the IS and CC. New edd/dm screens will have to be developed for the DC.

 

The NIRI engineering interface consists of screens that can send commands to the OIWFS, IS, CC and DC independently.

 

9.1.5 Performance Requirements

 

The NIFS DC package is required to support the linear-fitting readout method (Chapman et al. 1990). Therefore it has to be able to process and deliver image data in a small enough time window so as to prevent data buffer overflow. The Fowler sampling method (Fowler and Gatley 1990) will also be supported, so enough buffer space has to be available to contain multiple reads of the detector.

 

9.1.6 Software Development Environment

 

NIFS software will be developed according to Gemini software development standards that are described in document SPE-C-G009/05 (Wright et al. 1997). These standards comprise the following elements:

 

·         Software Programming Standards

 

The Gemini standards require that all code developed adhere to rules governing language selection, coding practices and style, module layout and formatting and other related issues. For instance:

 

-          Language Selection

GNU C and C++ compilers are required for both Unix and VxWorks cross-development. The Tcl/Tk scripting tool is to be used for all interpreted applications.

 

-          Coding Practices

Rules for modular techniques, function and data declarations, include files, error handling, style and comments are defined.

 

-          GNU make

Code will be maintained and built using the GNU make utility.

 

·         EPICS

 

Gemini require that all VME-based applications be developed using EPICS. Specific requirements are:

 

-          the EPICS database creation tool required to be used is Capfast.

-          EPICS records must conform to the Gemini specified naming convention for the instrument. For NIFS this mean that all records should have the prefix “nifs:”

-          EPICS engineering screens will be created using dm (an EPICS extension tool).

-          EPICS programming should be done in either:

-          EPICS database code – for ease of reuse, to take advantage of existing client side tools and to utilize the documentation and structural aspects of Capfast.

-          C code encapsulated in record, device or driver support routines – for support of complex code and new hardware interfaces.

-          State-Notation-Language (SNL) – for ease of expressing database state transitions.

-       EPICS lock-sets – critical section handling. Use must be carefully thought through.

 

·         VxWorks with the PPC Board Support Package

 

VxWorks from WindRiver Systems is the IOC real-time operating system environment chosen by Gemini. All new Gemini IOCs will use the Motorola PPC single board computer, so the NIFS ICS will be developed for the PPC. The latest development environment is Tornado V2.0, though initially Tornado V1.0.1 will be used to ease transition to V2.0. NIRI has been developed using V1.0.1.

 

·         Solaris (Unix Sys V Rel 4, POSIX)

 

Sun Solaris is the Gemini operating system of choice for the user operating and software developer environment. The Tornado development environment will be run on Solaris for cross-development for the PPC.

 

·         The UAE Environment

 

All EPICS development will be within the Universal Application Environment UAE – see the Keck EPICS Programming manual. UAE provides a means for developing and releasing code in a fashion similar to the way EPICS code is developed.

 

·         External Software Libraries

 

Gemini uses the external software libraries SLALIB, ASTLIB, CFITSIO and TIMELIB.

 

·         Source Code Control

 

Developers are encouraged to use the GNU CVS source code control environment.

 

9.1.7 Testing and Simulation

 

9.1.7.1 Testing of NIFS Software During Development

 

During the NIFS development phase software will be developed in parallel to the NIFS hardware, so it will be necessary to build hardware emulators that can be used to fully test software in the absence of real hardware. These emulators are required for all of the software external interfaces, that is:

 

-          The Observatory Control System – provided with the engineering interface. The engineering interface will emulate the OCS by using the same EPICS channel access that the OCS will use and by providing all the commands expected from the OCS.

-          The Data Handling System – Gemini provides a test DHS at the IGPO for use by instrument developers.

-          The science detector – it is important to build a dummy software science detector that emulates the behavior of the real infrared array, so that full detector controller software testing can be carried out in the absence of the detector.

-          Optical mechanisms – NIRI have built emulators for the NIRI mechanisms, NIFS will make use of these.

 

9.2 Overall Software Design

 

9.2.1 Software Architecture

 

The overall software design of a Gemini instrument is illustrated in Figure 1, based on the NIRI software architecture detailed in the NIRI Architectural Design Document, Yamada (1999a).

 

Figure 1: NIFS software architecture.

 

The Instrument Sequencer (IS) and Components Controller (CC) will run on one ICS, while for performance reasons, the Detector Controller (DC) runs on a separate ICS.

 

9.3 OIWFS Software Design

 

9.3.1 Introduction

 

The OIWFS will be identical to the NIRI OIWFS – see the Near Infrared Imager (NIRI) and On-Instrument Wavefront Sensor (OIWFS) Detailed Design Document, Yamada (1999c), the A&G to NIRI/GNIRS On-Instrument Wavefront Sensors, Yamada (1999e) and the NIRI/GNIRS Science Instrument to On-Instrument Wavefront Sensor, Yamada (1999d).

 

The NIFS software team will take delivery of a functional version of the NIRI OIWFS software package and implement for NIFS.

 

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

 

9.4 Spectrograph Instrument Sequencer Software Design

 

9.4.1 Introduction

 

A conforming Gemini Instrument Control System (ICS) has three software components which 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 and Detector Controller (Figure 2). The IS shares the same IOC as the CC while the DC, having greater performance requirements, runs on a separate IOC.

 

Figure 2: ICS subsystems.

 

9.4.2 Spectrograph Instrument Sequencer Design - Based on NIRI

 

The NIFS IS will be a direct duplicate of the NIRI IS.

 

9.4.2.1 Specific NIFS Differences

 

We do not anticipate any differences to the NIRI IS. Of course, NIFS will have different configuration parameters but these will not affect the operation of the IS.

 

9.4.3 Implementation Detail

 

9.4.3.1 Instrument Sequencer Tasks

 

The NIRI IS uses the base CICS IS and consists of running EPICS sequencer tasks that implement the following (Table 1) state sets.

Table 1: NIRI IS State Sets (Tasks)

State Set Name (task)

Purpose

Description

 

 

 

c_ss

Manage CICS Instrument Sequencer

This state set initializes the system. It then monitors the CAD records associated with the INIT and RESET commands.

isAnd_ss

Combine CC and OIWFS wfsBeam values

Monitors two records, assumed to hold EPICS_TRUE and EPICS_FALSE, and combines them using a logical AND

 

 

9.4.3.2 Gemini CAD/CAR/APPLY Interface – EPICS Database

 

Configuration and status parameters will be provided in the parameter definition file required by Gemini.

 

9.4.3.3 Capfast Diagrams

 

The EPICS database will be built from the Capfast diagrams based on the NIRI arrangement, illustrated in the hierarchy of Figure 3.

 

Figure 3: Hierarchy of Capfast diagrams in NIRI IS design.

 

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

 

9.5 Spectrograph Components Controller Software Design

 

9.5.1 Introduction

 

The Components Controller is a module in a Gemini conforming Instrument Control System and is responsible for software control of all NIFS components. These components are:

 

·         focal plane mask wheel

·         order sorting filter wheel

·         grating wheel

·         environmental cover

 

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

 

Because of the above and the desire to fast-track the development of NIFS (§9.1.3), the simplest most economical software development procedure is to take the NIRI software made available by Gemini and adapt it to exclude NIRI specific components and include these NIFS components.

 

The NIRI software was developed using the CICS template and as the first instrument to complete this path, found there were complex software development issues to deal with. From their experience the NIRI developers have made recommendations for future software developers to make the road easier. We will consider these recommendations and keep a view of the further development of CICS but the imperative is for fast tracking, so a simple copy/modify of the existing NIRI package is planned here.

 

9.5.2 The NIRI CC Software Package

 

9.5.2.1 Basic Description

 

NIRI is based on the CICS. Whenever possible CICS commands have been duplicated and new commands, with their corresponding records, are similar to existing CICS commands where possible.

 

9.5.2.2 NIRI Developer’s Recommendations and NIFS Approach

 

Quoting directly from an email discussion with Hubert Yamada of the NIRI software team best describes how this will be approached. Hubert says:

 

“Klaus and I have discussed the NIFS software issue, and we think that the best solution would simply to give you the entire NIRI package, including the OIWFS. The only difference would be that the mechanisms would all be replaced by some generic mechanism (probably a filter wheel.). This would allow us to test the hardware and electronics, and give you a system that we know will drive test mechanisms. From what you say, the remaining work that you would have to deal with would be in the area of changing constants and customizing the control algorithms. Both of those are relatively simply, and don't require modification to the more complicated parts of the code.”

 

The NIFS team will proceed on the basis of the above advice.

 

9.5.3 Spectrograph CC Software Implementation Detail

 

9.5.3.1 Overall Architecture

 

The following Figure 4 illustrates the software architecture for NIFS – this is taken directly from the NIRI documentation and is reproduced here to provide context.

 

Figure 4: NIFS CC software architecture.

 

9.5.3.2 NIFS Specific Differences to NIRI

 

NIRI has support for more mechanisms than required for NIFS. Both systems use Hall-effect sensor controlled stepper motors. They will have different numbers of sensors and steps which are defined using software constants.

 

9.5.3.3 Components Controller Tasks

 

The NIRI CC uses the base CICS IS and consists of running EPICS sequencer tasks that implement the state sets listed in Table 2.

 

Table 2: NIFS CC State Sets (Tasks)

State Set Name (task)

Purpose

Description

compPseudo_ss (x4)

Manage mechanism operations.

This state set initializes the system. It then monitors the CAD records and triggers appropriate actions in the mechanism database.

eng_ss (x10, one for each mechanism)

Manage mechanism operations.

This state set initializes the system. It then monitors the CAD records and triggers appropriate actions in the motor simulation database.

cc_ss

Manage initialization of CICS Components Controller.

This state set initializes the system. It then monitors the CAD record associated with the INIT command and reinitializes the system when necessary.

datum_ss

Manage datumC CAR record of CICS Components Controller

This state set monitors the CAD record associated with the DATUM command and ensures the "datumC" CAR record is set BUSY and IDLE at the correct times. The actual datuming of the mechanisms is handled by the EPICS database, which reports its progress through the "compC" CAR record. The state set is necessary purely to ensure there is a "datumC" CAR record with the behaviour expected by the OCS.

park_ss

Manage parkC CAR record of CICS Components Controller

This state set monitors the CAD record associated with the DATUM command and ensures the "parkC" CAR record is set BUSY and IDLE at the correct times. The actual parking of the mechanisms is handled by the EPICS database, which reports its progress through the "compC" CAR record. The state set is necessary purely to ensure there is a "parkC" CAR record with the behaviour expected by the OCS.

engMode_ss

Manage WFS beam in engineering mode.

 

 

 

9.5.3.4 Gemini CAD/CAR/APPLY Interface – EPICS Database

 

This will be a duplicate of the NIRI design with appropriate changes for NIFS specific parameters. These are listed below:

 

9.5.3.4.1 Spectrograph Detector Parameter Definition File

 

Configuration and status parameters will be provided in the parameter definition file required by Gemini.

 

9.5.3.5 Capfast Diagrams

 

The NIRI Capfast diagrams are arranged in the hierarchy shown in Figure 5, which is expanded to lower levels in Figure 6.

 

Figure 5: Hierarchy of Capfast diagrams in NIRI CC design.

 

Figure 6: Lower level Capfast diagrams for NIRI CC.

 

We intend to modify these diagrams where necessary to support NIFS. This will involve removing specific NIRI mechanisms, modifying similar NIRI mechanisms, and adding a new mechanism for the Lakeshore temperature controller (see below).

 

Based on consultation with Hubert Yamada, the NIFS team anticipates that our mechanisms will fit the NIRI model so this task should be routine.

 

9.5.3.6 Intended Approach to Change NIRI Software

 

Here I will list the approach we will take to change the NIRI software. This is a broad-brush list that has been compiled from initial perusal of the current NIRI software (Release 1.0a6).

 

·         Remove superfluous NIRI mechanisms from the Capfast diagrams. Hubert might already have this mostly done with the supplied NIRI software copy with generic “filter” type mechanism.

·         Add Capfast mechanisms for each of the NIFS components, i.e., the focal plane mask wheel, the order sorting filter wheel and the grating wheel. Do this by duplicating the generic “filter” mechanism and adding appropriate labeling.

·         Add Capfast diagram for Lakeshore temperature control (probably modification of NIRI control, see below) that includes support for all NIFS sensors.

·         Modify EPICS sequencer files for NIFS, i.e., exclude unwanted NIRI sequences.

·         Adjust the control constants contained in lookup tables and device support code for the NIFS mechanisms, i.e., the focal plane mask wheel has twelve positions, the order sorting filter wheel has eight positions and the grating wheel carries seven gratings and one mirror.

·         Modify the engineering screens for NIFS mechanisms.

·         Modify SAD contents for NIFS.

·         Modify NIRI process variable files for NIFS.

·         Modify NIRI engineering scripts to suit NIFS (mostly used for debugging).

·         Apply Janet Tvedt’s motor record fixes if Hubert hasn’t already done so (see $NIRI/ENG/src/README.motor).

·         Write some documentation on how it all hangs together!

 

9.5.3.7 Temperature Control

 

The Lakeshore temperature controller will be used for NIFS (§7.2). Hubert Yamada says that:

 

“NIRI already has provisions for controlling an omega temperature controller, which uses a lakeshore chipset. It's possible that it will work without modification. In any case, this would require only a change to the device driver, which should be relatively minor.”

 

We will take his advice and use the hooks already provided. But this will require further study and therefore more time has been allowed to cover uncertainties.

 

9.5.4 Testing and Simulation

 

NIRI has mechanism emulation 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, therefore these are the modes that will be available for NIFS.

 

9.6 Spectrograph Detector Controller Software Design

 

9.6.1 Introduction

 

This section describes the detector controller software design for the Gemini NIFS instrument. The design 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 that the “thin EPICS layer” approach, adopted by the GMOS detector controller group, be copied. See the GMOS CCD Controller Software Manual, Wolff & Ruckle (1999), for a description of this approach. This will be coupled with a suitably modified copy of RSAA’s existing SDSU-2 controller interface software, to take advantage of code reuse.

 

This section details this approach and describes the rationale behind decisions taken.

 

9.6.2 Spectrograph Detector Controller Requirements

 

Refer to §9.1.4.4 for detail of the requirements for the NIFS Detector Controller Software.

 

9.6.3 Spectrograph Detector Controller Software Design

 

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

 

9.6.3.1 Overall Architecture

 

The DC architecture comprises a Gemini interface task, lets name this Control, that is responsible for interfacing to the Gemini systems using EPICS channel access. This task also passes 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 which signals readout progress to the Data task. Progress is monitored through the use of an interrupt service routine (ISR), executed in response to an interrupt generated by the SDSU VME interface card. The Data task will then transfer image data to the Gemini DHS for storage and quick look display. Figure 7 illustrates this architecture.

 

Figure 7: NIFS DC software architecture.

 

The architecture also shows five external systems and four internal data stores. Two of the data stores are EPICS databases for storing configuration and status information. There is also a shared memory area for storing status information before it is shifted to the EPICS SAD database. A shared memory area is again used for storing the detector image data at various stages of processing.

 

9.6.3.2 Gemini CAD/CAR/APPLY Interface – EPICS Database

 

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 in CAD records by the OCS but lower level code does the verification and performs the actions required. The EPICS layer simply passes parameters and commands, gets back status and does nothing else.

 

9.6.3.2.1 Spectrograph Detector Parameter Definition File

 

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 will be provided in the parameter definition file required by Gemini.

 

9.6.3.3 Capfast Diagrams

 

9.6.3.3.1 Shortcomings of Capfast – RSAA’s Approach.

 

It has been reported, by other instrument groups (Yamada & Beard 1999), that using Capfast for maintaining EPICS databases is difficult and tedious. Capfast was said to be an extremely time-consuming tool and, given the need to develop NIFS quickly, we have decided to reuse the Capfast diagrams produced for the Gemini CCD detector controller by the NOAO group. Of course some changes will be required for the NIFS detector controller, but these diagrams will serve as a useful starting point.

 

9.6.3.3.2 Capfast Diagrams Based on GMOS DC

 

The NIFS DC will maintain its EPICS databases using the GMOS DC hierarchy of Capfast diagrams as a basis. Refer to Wolff & Ruckle (1999) for a description of this hierarchy.

 

·         DC CAD/CAR database

 

Figure 8 shows the Capfast diagrams included in the GMOS DC design. Note that they are arranged according to similar grouping.

 

Figure 8: Hierarchy of Capfast diagrams in GMOS DC 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 INIT, TEST, REBOOT, SETUP, ROI, SETUPDHS, SETWCS, INITWCS, DEBUG, OBSERVE, PAUSE, CONTINUE, STOP, PARK and ABORT commands.

 

·         SAD database

 

The GMOS DC SAD has Capfast diagrams for DATA, HARDWARE and SYSTEM status information. Figure 9 shows this arrangement.

 

Figure 9: Hierarchy of Capfast diagrams in GMOS SAD design.

 

In summary, the GMOS DC design will be taken as a starting point for NIFS and developed to suit. Learning and using Capfast is considered a significant hurdle for the NIFS software developers, therefore taking short cuts such as this should help.

 

9.6.3.4 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 with both models 1 and 2. It makes sense, therefore, to take advantage of code already in use.

 

9.6.3.4.1 Code Reuse and Porting Issues

 

Reusing RSAA’s existing code does not come without complication. Some of the issues relate to porting the code for use in the Gemini prescribed environment, an environment that is significantly different, in both hardware and software, than the environment at RSAA. Table 3 summarizes these issues.

 

Table 3: Porting Issues

Porting Issue

Gemini

RSAA

Comments

 

 

 

 

Target operating system

VxWorks

Solaris

Mainly POSIX code in use

High level control software

OCS/EPICS

CICADA

Interface issues – isolate

SDSU-2 host interface

VME

SBUS

Isolate

Language

C

C/C++

Acceptable to Gemini

Exception handling

No

Yes

Advantages – interface with Gemini requirements

Template code

No

Yes

Overkill for Gemini requirements

Inter process communication

VxWorks

POSIX

POSIX available under VxWorks

 

These issues will be addressed individually and solutions proposed. One of the important drivers for reusing RSAA code is that existing software infrastructure will be available early on in the development cycle for use both by the NIFS electronics engineer and the software team.

 

9.6.3.4.2 SDSU-2 Code Already In Use At RSAA

 

The important gain out of using the current RSAA code is that it is currently in working order for CCD cameras. This could save significant development time for NIFS. An important feature of the RSAA code design is C++ inheritance. This feature is described further in §9.6.3.4.4.

 

9.6.3.4.3 What About The GMOS SDSU-2 Code?

 

The GMOS DC group has just developed an interface to the SDSU-2 camera for use by the GMOS CCD camera. This code has a number of similarities to the RSAA code but is somewhat more specific in implementation. It will be handy to take this code as a good example of how lower layer C code interacts with the upper EPICS layer required for Gemini. However, we feel that we will be better served by using the nice features of the C++ code design in RSAA’s SDSU-2 interface code.

 

Important advantages in this approach include:

·         code encapsulation and polymorphism. A by-product of the RSAA coding approach will be a reusable component.

·         handling of arbitrary region of interest definitions

·         handling of arbitrary detector configurations – readout unraveling

·         local experience

 

9.6.3.4.4 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 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 10 illustrates this hierarchical arrangement.

 

Figure 10: 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, such as power on, 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, in particular, these will be linear fitting of data during an exposure, double correlated 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.

 

9.6.3.4.4.1 Repackaging For The Gemini Environment

 

The repackaging work for the Gemini environment will include:

 

·         SDSU-2 VME bus instead of SBUS interface.

 

Currently the RSAA code works with the SBUS variant of the SDSU-2 host interface. A simple C++ constructor variant can be used to differentiate one interface from the other and then variant methods can be used when performing I/O.

 

Readout monitoring in the SBUS interface code is done by reading an SBUS SDSU device driver (astro) register. For the VME interface, VxWorks interrupt service routines will be used. The SDSU VME DSP code will interrupt at periodic times during the readout data transfer to signal transfer progress. An interrupt is also issued to indicate command completion and that a reply has been received. The VME variant I/O methods will respond to these interrupts in a way functionally equivalent to the read call to the SBUS driver.

 

·         Porting RSAA Code to VxWorks.

 

Because Sun Solaris and Solaris_X86 have been used as the platforms for current RSAA code, some work is required to build the Camera class hierarchy under VxWorks. Because VxWorks is a POSIX compliant operating system, as is Solaris, this work should be minimal. Currently POSIX semaphores and message queues are used in the Camera class for communication between the cooperating tasks – these are also available under VxWorks.

 

The following list describes some of the porting work required in more detail:

 

-          Isolating OS Dependent Code. Where code cannot be common between the two operating systems, the C style #define can be used to isolate the separate code. An example is the starting of the Readout task – see below.

 

-          The RSAA IPC Class Library. RSAA uses a C++ class library that provides a wrapper around Unix IPC facilities. These include message queues, semaphores and shared memory. This library has been modified to use the POSIX variants of these facilities, which are available in VxWorks. Interestingly, VxWorks foundation classes also have a similar IPC class library – if need be, the VxWorks foundation class can be used in isolated code sections.

 

-          C++ templates. These are used in the Camera class hierarchy for handling identical operations (for example, image unscrambling) on different data types, and even though not specifically needed for the NIFS instrument could remain in place without impact.

 

-          Exception handling. Instead of passing error codes back up the call chain, Camera uses C++ exception handling. This can remain in the class and be contained within the NIFS software architecture.

 

-          POSIX Threads to VxWorks Tasks. The RSAA Camera class does the actual starting of the Readout task and monitors its progress. This code will need to be different for VxWorks because of VxWorks’ different tasking nature.

 

·         Camera Configuration – EPICS.

 

The description and configuration of the Camera object is initially handled by passing a data structure to the constructor at object instantiation time. This methodology can be retained for Gemini but the data structure would be built from the EPICS CAD database when a PRESET is issued.

 

·         SDSU-2 DSP Code – Storage and Downloading.

 

SDSU-2 DSP code for the timing and VME boards needs to be downloaded to the controller during the initialization phase. These codes will have to be stored on an NFS file system in the Gemini environment but accessible to the IOC. Pathnames to the codes will be supplied as parameters in the CAD database.

 

·         Interface to the Camera object

 

The Slave task is responsible for instantiating the SDSU2_IR object. A pointer to this object will be maintained as a VxWorks global variable so that the Readout task can access it. The init sequence command will be used to prepare the SDSU2_IR object – this will include deleting any previously created object and then running the SDSU2_IR  init method. Parameters required for creating and configuring the object will be supplied through the CAD/CAR/APPLY interface.

 

·         Data Readout – synchronization issues

 

To support different readout modes (see below), the detector will need to be read out several times during an exposure. This presents problems with data buffer handling and readout synchronization. As the data are read out using the SDSU-2 DSP code running on the SDSU-2 timing and VME boards, the Readout task needs to keep track of readout progress so that intermediate data processing can be performed if required by the readout method. A way of signaling the Readout task is needed.

 

The RSAA SDSU class handles this by using a counter in the SBUS device driver for counting the number of pixels transferred. The counter can be monitored without affecting the DMA transfer currently in progress and used as a trigger for performing appropriate image processing.

 

The GMOS DC code handles this nicely also, by using interrupt service routines and interrupts generated by the VME DSP code. This same technique can be used for the NIFS readout methods.

 

·         Data Transfer – Gemini DHS

 

The Data task is responsible for transferring data to the Gemini Data Handling System and quick look displays. This code will be completely different to similar code in use at RSAA and, therefore, will be rewritten. The GMOS DC code can be used for the basis of this work.

 

9.6.3.4.4.2 Writing an SDSU2_IR Camera Class Derived from the SDSU2 Class

 

This section will describe in more detail the plan to build the SDSU2_IR class. In particular the algorithms for the two readout methods required will be explained.

 

·         SDSU2_IR Control Commands.

 

As explained above the SDSU class provides the functionality for most of the required control commands. However, the following commands need to be overridden for the SDSU2_IR class:

 

-             set_bias_number

 

This method will be used to change a video offset or DC bias supply voltage and takes a video processor board number, DAC number and voltage value as parameters.

 

-             set_DC_bias_supply_voltage

 

This method will reset the voltage codes in the appropriate SDSU-2 data memory for the DC bias and clock driver DACs to the initial timing code values.

 

-             do_power_off

 

Sets the clock and bias voltages to zero and turns the analog power off.

 

-             set_video_mode

 

Sets the video mode. One parameter indicates either mode on or off and the mode number. Video mode 1 performs a continuous sequence of reset, expose and read. Video mode 2 continuously resets, reads, exposes and reads. Exiting video mode (mode 0) will cause the array to be continuously reset.

 

-             set_operating_mode

 

NIFS will operate in one of two modes – either Idle or Run. In Idle mode, the controller will take transient data that will be sent to a DHS quick-look display. In Run mode, permanent data will be taken and sent to the DHS for storage and quick-look display.

 

-             readout

 

The readout method will initiate data taking depending on the operating mode set. This method will take parameters for setting the readout method (see below), exposure time, total number of reads and the regions of interest.

 

·         SDSU2_IR Specific Exposure and Readout Methods.

 

Three readout methods will be supported by NIFS, these are:

 

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

 

-             Fowler sampling

 

Fowler & Gatley (1990) show that read noise can be reduced by performing multiple non-destructive passes through the detector array 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 is 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.

 

-             Linear Fitting

 

In this method, the detector is first reset, then the array is read, non-destructively, N times over the total exposure period 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 M,

 

 

where Vi is the voltage of sample i, n is the total number of samples and dt is the time interval between samples. This is a much-simplified version of the general straight line fitting equation due to the constant value of 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 SV2 for each pixel, while the other terms are constant. Time needed for this processing is of the order of 2.5 s for the full detector size on the 366 MHz MVME2700.

 

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

 

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 the time a pixel saturates, in array S.

 

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

 

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

 

·         Detector Readout Linearity

 

Consideration has to be made of the linearity of the detector integration. This is discussed in §8.7.4, but is essentially a correction applied to each pixel using a calibrated parameter.

 

·         Subtracting out the sky.

 

The Readout task will subtract out the sky for each image. It does this by using a loaded sky frame for the particular operating mode Idle or Run. See §9.6.4.1.3 for a full description of this process.

 

·         NIFS specific image processing.

 

Because of the nature of the NIFS IFU some image processing needs to be performed before quick-look displays are useful to the astronomer. In addition to the raw data file (suitably unscrambled and fitted), the data needs to be crunched into an image cube representing the 29 IFU slits. These are then compressed along the spectral axis, over a user chosen interval, to form a final image of the object. This image is sent to the quick look display for preview. See the NIFS OCDD for detailed description of this process.

 

Time needed for this processing is of the order of 1 s for the full detector size on the 366 MHz MVME2700.

 

9.6.3.4.4.3 Internal Data Storage Requirements

 

To support the minimum data processing requirements for the NIFS readout methods the arrays described in Table 4 will be required:

 

Table 4: Data Storage Arrays – Linear Fitting

Array Name

Data Type

Size (MB)

Description

 

 

 

 

pix x 2

U16

16

Raw pixels – double buffering (V).

FitPix

R32

16

Fitted pixels (f(V)).

PixSum

U32

16

Sum of raw pixels (SV).

PixSqrSum

U32

16

Sum of raw pixels squared (SV2).

IPixSum

U32

16

Sum of iteration times raw pixel (SiV).

pixSumC

U32

16

Sum of raw pixels after a cosmic ray (SV2).

pixSqrSumC

U32

16

Sum of raw pixels after a cosmic ray (SV22).

iPixSumC

U32

16

Sum of iteration times raw pixel after a cosmic ray (SiV2).

cosmic

U8

4

Cosmic ray flags (C).

saturated

U8

4

Saturated pixels flags (S).

pixCumSum

R32

16

Cumulative sum for series of short exposures (Sf(V)).

skyIdle

R32

16

Sky image for idle mode.

skyScience

R32

16

Sky image for science mode.

intensity

R32

16

Fitted and unraveled pixels (F).

variance

R32

16

Variance for fitted pixels (E).

Total

 

216

 

 

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 §9.6.3.5.

 

For the double correlated and Fowler sampling methods, more than one pix array will be needed. Table 5 indicates the buffer requirements for N=16 (in Fowler sampling case).

 

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

Array Name

Data Type

Size (MB)

Description

 

 

 

 

Pix x N

U16

128

Raw pixels (V).

fitPix

R32

16

Fitted pixels ((SV)/N).

pixCumSum

R32

16

Cumulative sum for series of short exposures (Sf(V)).

skyIdle

R32

16

Sky image for idle mode.

skyScience

R32

16

Sky image for science mode.

saturated

U16

8

Saturated pixels flags (S).

intensity

R32

16

Fitted and unraveled pixels (F).

Total

 

216

N=16

 

 

Clearly, the NIFS detector controller will require the 256 MB version of the Motorola MVME2700 processor card as a minimum. To allow more headroom for processing, the later model Motorola MVME5100 with either the MPC7400 or MPC750 and 512MB RAM is preferred.

 

If saving of raw data from each of the methods is required the above storage quantities assume that data can be sent to the DHS in the time between filling of the pix arrays. That is, for linear fitting, the time between successive reads, and, for the other methods, the time for the whole exposure. These times will place a limitation on when raw data can be saved.

 

9.6.3.5 Regions of Interest and the RSAA Regions Class

 

Because the NIFS science detector will be read out from multiple amplifiers, pixels will arrive in an interleaved order. In addition, an arbitrary rectangular region can be specified as a “region of interest” (ROI) and because of the constraint that each readout has to clock exactly the same pixels, some data not in the ROI will have to be discarded.

 

9.6.3.5.1 General Code for Handling ROI on Multiple Amplifier Detectors

 

RSAA has developed a general code for handling this problem and is encapsulated in the C++ class Camera_Regions. This solution is described in Young et al (1999). For NIFS, Camera_Regions will have to be extended to handle:

 

·         Readout orientation.

 

At present Camera_Regions assumes that readouts are read out in detector row orientation, that is, pixels from row one (or N) are read first, followed by pixels from row two (or N-1). For NIFS, the detector is organized in four quadrants with one readout per quadrant. The readout orientation is rotated through ninety degrees from quadrant to quadrant, thus leaving two quadrants column-oriented and the other two row-oriented. This is illustrated in Figure 11.

 

Figure 11: NIFS detector readout arrangement.

 

Pixels will arrive from the detector in order

 

q11,1, q21,n, q3n,n, q4n,1, q12,1, q21,n-1, q3n-1,n, q4n,2, .. q1n-1,n, q2n,2, q32,1, q42,1, q1n,n, q2n,1, q31,1, q41,n

 

where a pixel is addressed by qNi,j with

 

qN           quadrant number N,

i,j             x and y location from the bottom left corner of each quadrant

 

 

·         Arbitrary sized readout dimensions (in the case where NIFS uses eight readouts per quadrant – see below).

 

This is not currently considered for NIFS so will not be discussed further here.

 

9.6.3.5.2 ROI Specification

 

A ROI is given in detector coordinates and is specified by four parameters – see Table 6.

 

Table 6: ROI Parameters

Parameter

Data Type

Description

 

 

 

regionXo

U16

offset to start of rectangular region in x direction

regionYo

U16

offset to start of rectangular region in y direction

regionWidth

U16

width of rectangular region

regionHeight

U16

height of rectangular region

 

As explained in Young et al (1999), this ROI specification is converted to SDSU-2 controller clockout sequence parameters. The controller is restricted in how it can handle ROI. Each quadrant must have identical clocking parameters set for it, so in cases where less than the whole detector is read, extra pixels will, sometimes, be clocked from unwanted areas. This can be best illustrated with an example. A common use for the NIFS spectrograph will be a readout of a strip across the detector – see Figure 12.

 

Figure 12: Region of Interest.

 

Now the Camera_Regions class calculates clockout parameters by overlaying all quadrants onto Quandrant 1 so that readout amplifiers are aligned. This is shown in Figure 13, where different shadings represent the ROI areas from different quadrants.

 

Figure 13: ROI calculation.

 

From this representation, distinct parallel and serial readout sections can be enumerated. These data are stored in the Camera_Regions member variables and specified with data structures defined in Table 7 for the global description.

 

Table 7: Clockout Global Parameters

Parameter

Data type

Description

 

 

 

nparSections

U16

number of parallel sections

 

Table 8 has data for each parallel section.

Table 8: Parallel Section Parameters

Parameter

Data type

Description

 

 

 

yo

U16

absolute starting row

height

U16

height of section

skip

U16

skip since last previous section

width

U16

sum of length of serial sections

nserSections

U16

number of serial sections in this parallel section

remain

U16

number of pixels remaining in serial register after last serial section is read

ampMask

U16

all the amps this parallel section has in it

regionMask

U16

all the sections this parallel section has in it

 

And Table 9 for each serial section.

Table 9: Serial Section Parameters

Parameter

Data type

Description

 

U16

 

xo

U16

absolute start of serial section in amplifier coordinates

skip

U16

number of pixels since last serial section

width

U16

width of this serial section

ampMask

U16

amplifier which this serial section belongs to

regionMask

U16

user region which this serial section belongs to

 

This information is loaded down to the controller and identical readouts are performed in parallel from each quadrant. Only the pixels in the heavily shaded area of Figure 14 are retained. The pixels in the hatched regions are discarded by using the pixel masks calculated above.

 

Figure 14: SDSU-2 readout areas.

 

For the example readout, there will be three parallel sections specified, with two serial sections in parallel section 1 and three serial sections in both parallel sections 2 and 3.

 

9.6.3.5.3 Detector Layout Specification

 

To enable calculation of ROI data as described above, the Camera_Regions class needs to know how the detector is laid out. That is, we need to specify the number, location, size, orientation and readout direction of each output amplifier. This information is passed to the Camera_Regions constructor in a structure with the following fields:

 

nAmps                                   Number of readout amplifiers

 

And for each amplifier

Table 10: Detector Layout Parameters

Parameter

Data type

Description

 

 

 

xo

U16

x offset of first pixel

yo

U16

y offset of first pixel

width

U16

number of columns

height

U16

number of rows

xdir

S16

direction of readout – columns

ydir

S16

direction of readout – rows

orientation

Boolean

orientation of readout – either row or column

 

9.6.3.6 Moving Data to the Gemini DHS and Quick-Look Displays

 

Data will be sent to the Gemini data handling system from the Data task:

 

·         At the end of the readout for final storage and display

·         To a quick-look display for viewing during the integration

·         To a quick-look display during idle mode

·         After an intermediate readout (depending on method), if raw data capture is required

 

9.6.3.6.1 The Data Transfer Task

 

The Data task waits on a signal from Readout that indicates an image is ready for sending to the DHS. Details of the image are given in an image header description and might be raw data, averaged data (from idle or Fowler sampling readout methods) or fitted data (from the linear fitting readout method). The data, which are already unscrambled and partly discarded (if required) by Readout, according to the region description, are placed in a final intensity array for transport to the DHS.

 

9.6.3.6.2 Unscrambling Pixels from a Multiple Amplifier Readout

 

The unscrambling algorithm used by the Readout task will work as described in the following pseudo-English code:

For each parallel section

   For each readout amplifier

         For each serial section

                If serial section is in mask for this amplifier

                      Compute the starting pixel address for this amplifier section

                      For each row/column in parallel section (depending on orientation)

                            Compute output row/column based on readout direction/orientation

                            Set index into input array to start of row/column

                            For each pixel in row/column

                                  Compute output column/row position based on readout direction/orientation

                                  Copy pixel from input location to output location

                                  Increment input pixel pointer by number of interleaved readouts

                            End loop over pixels

                      End loop over rows/columns

                End if

         End loop over serial section

   End loop over amplifier

End loop over parallel section

 

The RSAA Camera class implements this algorithm as a C++ template method so that different input and output data types are easily handled. And given the detector layout specification and requested readout region, this is a general solution to the ROI problem.

 

9.6.3.6.3 Viewing the Image as it is Being Built

 

For the linear fitting readout method it is possible to view the image periodically during the integration. As the detector will be read out non-destructively at regular intervals, a progressive image fit can be performed. These data will be sent to a quick-look display for viewing.

 

9.6.3.7 Writing Local FITS Files – the Fits Class

 

In the absence of the DHS or during testing and commissioning, it will be useful to record data by another method. RSAA has developed a C++ FITS class that can be used for this purpose. It is a general purpose FITS reader/writer and can be switched in when the DHS is unavailable. Whether or not this is done can be controlled by a CAD parameter.

 

The IOC should not be burdened with NFS writing. The GMOS DC code uses a FITS server process running on a Unix workstation for handling this. However, we will use the current CICADA dat_svc RPC process modified for Gemini.

 

9.6.3.8 Exposure Control

 

Timing of an exposure will be performed by the SDSU-2 timing card. The Slave task will periodically monitor an exposure’s progress by checking that the exposure is continuing and updating status with internally counted timing values. This will be handled by a loop that sleeps for short periods and checks progress and updates status every wakeup.

 

9.6.3.9 Gemini Status and Alarm Database

 

Status and alarms will be reported through the EPICS SAD database using the thin-layer approach described in §9.6.3.2. As for the GMOS DC design, the EPICS layer transfers information stored in global status buffers by the low-level tasks Slave, Readout and Data. These data are either dynamically changing or changed in response to a particular command, so updates to the SAD are made either periodically or at the completion of commands. Section 9.6.4.1.1 details how the Control task handles this activity.

 

9.6.4 Implementation Detail

 

This section will explore some of the implementation decisions that need to be made to implement the above design ideas. In particular the following issues will be looked at

 

·         Task structure and control flow

·         Data flows

·         Responsiveness

·         Performance

·         Throughput

·         Hardware issues

 

9.6.4.1 Detector Controller IOC Task Diagram and Data Flows

 

The proposed task structure suggested in §9.6.3.1 is a broad overview of the processing design for the NIFS DC. This is expanded further in Figure 15. This diagram concentrates on the inter-process communication (IPC) design of the system. It is a client-server task model with Gemini systems forming client requests for the NIFS DC server (which consists of the IOC tasks Control, Slave, Readout and Data).

 

Figure 15: NIFS DC task diagram.

 

9.6.4.1.1 The Control Task (Control)

 

The Control task is the hub of the design. It is started when the IOC boots up and should always be running. It initializes the lower level software environment and sets itself up to wait on commands delivered to its just created message queue. Its initial state is WAITING, that is, it is waiting to accept initial commands from the Gemini EPICS environment. The POSIX message queue facility is used and a signal handler is setup with the mq_notify call for notifying Control when a message is delivered by the EPICS CAD routines.

 

The first command needed, before anything else, is INIT, which is required for initialization and reinitialization of the system sub-tasks Slave and Data. Other commands will be rejected if an INIT has not been performed. An INIT puts the Control task into the READY state. From the READY state DC commands will put the task into RUNNING state except for the REBOOT command which will shutdown sub-tasks and return the system to its WAITING state. A timer is setup to periodically update the SAD database with dynamic status information maintained by all tasks in the system.

 

The following state diagram (Figure 16) illustrates the intended behavior of the Control task.

 

Figure 16: Control task state diagram.

 

A key requirement of the Control task is that it has to be responsive. It cannot block for unreasonable periods without checking and responding to messages delivered to its message queue. Hence the mq_notify facility is used to ensure that all EPICS CADs are responded to.

 

Updating the SAD will take a fixed period of time that could be interrupted by the arrival of a new command from the EPICS layer. This time will need to be short enough to meet the Gemini CAD responsiveness requirement. In addition, the dynamic updating of the SAD will need to be fast enough to meet Gemini requirements. This is planned to be set at a one second update interval.

 

9.6.4.1.2 The Camera Task (Slave)

 

The Control task starts the Slave task when it receives an INIT command. When Slave starts it will instantiate an SDSU2_IR camera object with constructor parameters set according to initial startup state information. Once created, the init method is invoked to perform necessary controller initialization. Depending upon initialization configuration options, the init method will initialize the VME controller interface, load the SDSU-2 DSP code and turn the power on.

 

The task then creates a message queue for receiving further commands from Control, it then sits in its READY state. As commands are received they are interpreted and requested actions are performed. The OBSERVE command will put the task into its observing MONITORING state where the observation sequence is monitored. Firstly the exposure is prepared using specified parameters, integration then proceeds along with required readouts (depending on readout mode). Readouts are performed by the Readout task that is started in the preparation phase. The following state diagram (Figure 17) illustrates this process:

 

Figure 17: Slave task state diagram.

 

Commands to the SDSU-2 are written directly into the VME interface board’s command buffer by either the Slave or Readout task. The task then awaits a semaphore to indicate a reply is ready. When a command is complete an interrupt is generated by the VME DSP code and an interrupt service routine (ISR) runs and gives the semaphore to the waiting task.

 

Monitoring is done in a loop that periodically sleeps for short intervals and then wakes to check if the exposure has completed. Status is updated with the exposure counter maintained using the VxWorks clock.

 

During this MONITORING state Slave needs to remain responsive to Control commands so that interrupts such as ABORT and REBOOT can be attended to.

 

9.6.4.1.3 The Detector Readout Task (Readout)

 

Readout is the task that sends the start exposure command to the SDSU-2 VME interface and waits while it proceeds. It is started by Slave and, depending on the readout method, prepares itself to run the exposure. It sets up an interrupt handler to be called in the case of either a REBOOT or ABORT command which will cause the task to exit after appropriate cleanup.

 

As a readout proceeds and data is accumulated in image buffers prepared in the initialization phase, the Data task is signaled when data is ready for transfer. These signals are generated when the SDSU-2 VME DSP code executes an IOC interrupt at predetermined phases of the readout. The ISR will place a message on the Readout task’s readout message queue and signal that a message is waiting. Readout reads the message, updates the status buffer, processes and unravels the data in the raw pix buffer placing the results in the fitpix array. It then gives a semaphore to Data to indicate data is ready for transfer.

 

Figure 18: Readout task state diagram.

 

Timing aspects of importance in this design are

 

-          Responsiveness to ISR messages

-          Speed of calculating and unraveling processed data

-          Handshaking with the Data task

 

These issues are discussed in §9.6.4.2.

 

9.6.4.1.4 The Data Transfer Task (Data)

 

Data is solely responsible for getting image data transferred out of the system. It handshakes with the Readout task on one side and either the DHS or a FITS server on the other. In between it prepares data for transfer by shifting it from fitpix memory to the DHS data structures. It also performs all necessary DHS data structure setup. Data also handles interaction with any quick-look displays that are in use.

 

Data is started by Control and waits for a semaphore to be handed it by Readout when a data buffer is ready for transfer. It interprets the contents of the data buffer by using image header information placed in the data structure in Table 11 by Readout. This table is just indicative of the sort of data that will be present in an image header and will be completed during the course of development.

 

Table 11: Preliminary Image Header Information

Parameter

Data type

Description

 

 

 

frameWidth

U16

Width of image frame

frameHeight

U16

Height of image frame

display

U8

True if required to display frame in quick look display

qlName

char

Name of quick look display

store

U8

True if required to permanently store frame as FITS file

 

Figure 19 illustrates the Data task’s states.

 

Figure 19: Data task state diagram.

 

There are potential bottleneck problems with this process that need to be considered. These bottlenecks can occur in two places:

 

-          Readout can be blocked while Data holds the image semaphore

 

This is unlikely as Data merely transfers the data from the fitpix array – already unscrambled by Readout – to the intensity array.

 

-          Data can be blocked by the DHS

 

Which, in turn, would cause a block further along the processing chain in Readout. If this happens, the blocked transfer will simply be missed and Readout will then proceed to its next step.

 

Both these potential blocks are discussed further in §9.6.4.2.2.

 

9.6.4.2 Performance Issues

 

Performance issues that need to be considered in the NIFS DC software model include:

 

-          Command responsiveness

-          Readout mode processing

-          Inter task communication

-          Data throughput

-          Quick look display performance

 

These are examined in turn.

 

9.6.4.2.1 Command Responsiveness

 

Gemini requires NIFS to respond to all CAD commands with a CAR record within 1 s (§9.6.4.1.1).

 

9.6.4.2.2 The Observe Command – Processing Timeline

 

The OBSERVE command, in linear fitting readout mode, proceeds according to the processing timeline illustrated in Figure 20.

 

Figure 20: Observe command processing timeline.

 

At even intervals during the exposure the array is read out, taking the specified 5 s (§8.3) to clock out all the pixels. At the end of this time (lets call it CT) an IOC interrupt is delivered by the SDSU-2 VME DSP code. The Readout task responds by processing the data and handing a semaphore to Data. This takes time RT. Data moves the data to the transfer buffers and relinquishes the semaphore, taking time ST. It then transfers the data to the DHS and the quick look display, taking times QT and DT. (Perhaps more than one quick look display will be used – complicating this story).

 

The periodic clock out of pixels will not pause, so for all the data clocked to be processed in time, the Readout task will need to be ready to go every CT seconds.

 

Some initial prototyping has revealed that RT = 3.5 seconds on the 366 MHz MPC750. This would mean that the Readout task has some headroom for processing the data in the most CPU intensive linear-fitting readout method.

 

To alleviate the potential bottlenecks with the Data task, the design could incorporate a double buffering technique with the pix and fitpix buffers to extend the time available for processing and transferring data. There will be a limit on how far this measure can be taken because of available memory. We plan to see how the system performs before implementing extra time saving techniques.

 

In the double-correlated and Fowler sampling readout modes this picture is slightly different. The time, lets say E, between reading out the array can reduce to zero for bright objects, so there is no time for the Readout task to perform any data processing. In this case it will be averaging (for Fowler sampling) and subtracting images. We will need to incorporate a second pix array that can be filled while the first one is processed – this will give us 5 seconds, i.e. greater than RT.

 

9.6.4.2.3 Data Transfer Throughput

 

9.6.4.2.3.1 Gemini DHS Performance Specification

 

We need to know how fast the DHS can take data delivered over the Fast Ethernet link. Fast Ethernet itself will restrict this rate to a maximum of around 8 MB/sec but this might well be an upper limit. Current information from IGPO indicates that the DHS has only been tested to handle 2MB/sec but it has not, as yet, been pushed any harder (Kotturi, priv. comm.).

 

9.6.4.2.3.2 Quick-Look Display Performance Specification

 

IGPO have informed us that the quick-look display can handle data at a rate of 2 MB/sec. NIFS can potentially produce data, for quick look display, at the rate of 1 frame every 5 seconds, i.e., 3.2 MB/sec (considering 2048´2048 floating point pixels). This is unlikely to be the case, as the data would merely be output from one NDR. More likely, for bright objects, there will be one data frame produced every 10 seconds, i.e., 1.6MB/sec at peak output.

 

9.6.4.2.3.3 IOC Quick-Look Display – Viewing Image During Exposure

 

NIFS will be able to send data to the DHS and quick-look display during a linear-fitting readout mode observation. This can, potentially, be done after every non-destructive read but will be limited by DHS data throughput. The frequency at which images are sent will be set by a DC CAD parameter.

 

9.6.4.2.4 Hardware Requirements

 

For the NIFS DC two areas are crucial to performance satisfaction.

 

-          The PPC VME Card

 

Does the 366 MHz PPC have enough power? As indicated in §9.6.4.2.2, the processing requirements of the linear-fitting readout method have been prototyped at 3.5 seconds, and as this fits within the readout time required for the whole array, i.e., 5 seconds, then this CPU should be adequate.

 

-          PPC RAM

 

As detailed in §0, 216 MB of memory is calculated to be enough to handle the NIFS DC design. Therefore the 256 MB version of the PPC processor will be required as a minimum (MVME2700). However, the 512 MB PPC option available with the MVME5100 is preferred. This board will only be available around June 2000. In the interim, the supplied MVME2700 will be used for early development.

 

9.6.5 Testing and Simulation

 

It is planned to develop RSAA’s CICADA software package[1] to support the HAWAII-2 infrared array from the beginning of the project, so that software will be available for detector characterization as early as possible. This will be done in the context of the Camera class discussed above, so software developed will be directly available for NIFS.

 

The CICADA package also supports simulation cameras that are used in the absence of real hardware. A simulation camera is directly derived from the Camera C++ class, so will be used for testing the NIFS software design during early development. The aim will be to have data processing and transfer code well developed, independently of the hardware. This code will form the basis of support for Gemini’s required simulation modes.

 

9.7 Software Risks

 

9.7.1 Porting CICADA Classes to the VxWorks IOC Environment

 

This work is already underway and has proceeded smoothly. Facilities used by the CICADA classes are available under the VxWorks environment, so this issue represents a minor risk.

 

9.7.2 Working with the Gemini DHS Server

 

Gemini provide a test DHS server at IGPO in Hilo for instrument developers to use. Extensive instructions have been provided for using this system and it is our intention to try it out. If bandwidth to Hilo from Australia becomes a problem, IGPO have provided access to the DHS source, so that it can be built and installed locally. As this requires access to SyBase database software there could be problems going this route. However, SyBase provide 60 day evaluation copies of their software and this should be enough time to sort out DHS access.

 

9.7.3 Climbing the EPICS Learning Curve – How Long?

 

Learning EPICS represents a major risk to the software aspects of this project. Talking to other Gemini developers provided an indication of how much time should be set aside to learn and become productive with EPICS. This task includes learning the EPICS development tools (e.g. Capfast, edd/dm, sequencer) as well as the database concepts. Time recommended by others ranged from nine to twelve months. Clearly this is not available in the NIFS context so every endeavor has been made to reduce and simplify the task. This includes reusing as much of other people’s work as possible and seeking out training/assistance.

 

It has been suggested by IGPO that a fast way to get on track with this would be for an EPICS specialist, from one of the Gemini development groups, visit RSAA for a short period of hands-on training. This would be most welcome and has been included as a contingency cost item.

 

9.7.4 EPICS and Capfast – How Easy Will it be to Adjust NIRI?

 

Because the NIFS control system will use the same type of components as are used in NIRI, this should be a straightforward task. This view has been supported by Hubert Yamada, who says that, because the NIFS mechanisms are motor driven wheels as are used in NIRI, existing code can be used.

 

9.7.5 Hardware Issues

 

Some effort has been made to prototype code and to size the problem so as to establish a good estimate of the hardware requirements for NIFS software. We feel confident that the recommended hardware, i.e., for the DC, the Motorola MVME2700 with 366 MHz MPC750 processor and maximum 256 MB RAM will be sufficient but there is not much head room with available RAM. An alternative to this specification would be Motorola’s new MVME5100 with 500 MHz MPC750 and 512 MB RAM, however a VxWorks BSP package is not yet available for this board. Inquiries have been made of Wind River Systems to see when this will (if ever) appear.

 

 

 

Home * Brief Description * NIFS OCDD * NIFS FPRD * CoDR Documentation

CoDR Presentations * System Design Notes * Performance Predictions * Management Plan * Picture Gallery * Team Members

Employment Opportunities * Document Archive * Internal Project Links * Subcontractor Information

Gemini Project Links * Instrumentation Links * Other IR Instruments

 


[1] http://www.mso.anu.edu.au/computing/cicada