ICD 1.9f/3.1

 

"Near-infrared Integral Field Spectrograph (NIFS) to Observatory Control System"



Mark Jarnyk & Peter Young

Monday, September 10, 2001

 

 

 

 

 

Version: 1.0

 

Issued By: Mark Jarnyk & Peter Young

 

Date:

Approved By: __________________________ Group Manager _________

 

__________________________ Group Manager (if req) _________

 

__________________________ Systems Engineering _________

 

 

Revision Control

 

 

1. Revision Version # 1.0

Date: 22 March 2001

Revised by: Mark Jarnyk & Peter Young

Reason for / items changed: Original NIFS version as ICD 1.9f/3.1, modeled after NIRI ICD 1.9a/3.1.

Introduction

Description
Purpose

This Interface Control Document (ICD) serves the following purposes:

This document is based very closely on ICD 1.9a/3.1 See niri_hty_003, "ICD1.9a/3.1 Near IR Imager (NIRI) to Observatory Control System", Hubert Yamada, University of Hawaii, Institute for Astronomy, describing the OCS interface with NIRI, the basis of much of NIFS.

In addition to the documents mentioned in the previous paragraphs, the specific interfaces described in this document are governed by the following parent Interface Control Documents, which describe the general properties of particular kinds of interfaces:

The intended audience for this document is:

  • the NIFS reviewers;
  • the developers of the Gemini Observatory Control System (OCS).
Scope

This document describes only aspects of the NIFS software system which differ from, or are more specific than, the Gemini standard instrument, described in See cics_smb_013, "Science Instrument to Observatory Control System", Steven Beard, Royal Observatory Edinburgh.. It is assumed that the reader is familiar with that document.

This document does not describe the following:

Related Documents and Drawings
References
  1. "NIFS Conceptual Design Review Vol 1", Research School of Astronomy and Astrophysics, Australian National University
  2. "NIFS Critical Design Review Vol 1", Research School of Astronomy and Astrophysics, Australian National University
  3. niri_hty_008.fm "A&G to NIRI/GNIRS On Instrument Wavefront Sensor", Hubert Yamada, University of Hawaii, Institute for Astronomy.
  4. cics_smb_013, "Science Instrument to Observatory Control System", Steven Beard, Royal Observatory Edinburgh.
  5. cics_smb_039, "CICS Project Glossary and References", Steven Beard, Royal Observatory Edinburgh.
  6. gscg.kkg.009, "ICD 1a -- The System Command Interface" , Kim Gillies, NOAO.
  7. gscg.kkg.024, "ICD 1b -- The Baseline Attribute/Value Interface" , Kim Gillies, NOAO.
  8. gscg.kkg.010, "ICD 2 -- Systems Status and Alarm Interfaces" , Gemini 8m Telescopes Project.
  9. gscg.grp.025, "ICD 16 - The Parameter Definition Format", Steve Wampler, Gemini 8m Telescopes Project
  10. niri_hty_003, "ICD1.9a/3.1 Near IR Imager (NIRI) to Observatory Control System", Hubert Yamada, University of Hawaii, Institute for Astronomy
  11. gscg.grp.015 "ICD 7a - ICS Subsystem Interfaces" Steven Beard, Steve Wampler and Chris Mayer, Gemini 8m Telescopes Project
  12. "NIFS Software Maintenance Manual" - To be written, Research School of Astronomy and Astrophysics, Australian National University
  13. ocs.kkg.031, "Sequence Command Specifications" , Kim Gillies, Shane Walker & Steven Beard, NOAO/Gemini 8m Telescopes Project.
  14. "EPICS Channel Access Reference Manual" , J. O. Hill, Los Alamos National Laboratory
  15. gscg.grp.007, " ICD 3 -- Bulk Data Transfer" , Norm Hill, Severin Gaudet & Steven Beard, DAO.
Acronyms and Abbreviations

A&G Acquisition and Guidance

CAD Command Action Directive

CAR Command Action Response

CC Components Controller

CICS Core Instrument Control System

DC Detector Controller (software system)

DHS Data Handling System

EPICS Experimental Physics and Industrial Control System

FITS Flexible Image Transport System

ICD Interface Control Document

ICS Instrument Control System

ID Identifier

IOC Input Output Controller

IR Infrared

IS Instrument Sequencer

ISS Instrument Support Structure

LAN Local Area Network

N/A Not Applicable

OCS Observatory Control System

OIWFS On Instrument Wavefront Sensor

PDF Parameter Description File

SAD Status and Alarm Database

SDSU San Diego State University

SIR Status and Information Record

STP Stop command to the SDSU controller

TBD To Be Decided

TDL Test data link command to the SDSU controller.

TCS Telescope Control System

VSM Virtual system mode

WCS World Coordinate System

WFS Wavefront Sensor

 

Definitions
Action

The process started as a result of a See Command . For example, a command to select a new filter will start the filter wheel mechanism in motion. There can be a many-to-one correspondence between commands and actions. For example, several different filter commands can all result in the same filter wheel movement action. The status of an action is reported through a CAR record.

Attribute

An entity which describes some aspect of the configuration of a science instrument, such as the name of a filter or the tilt angle of a grating. Some attributes will be used by the Instrument Control System as command parameters. The OCS communicates with a science instrument by sending it sets of " See Attribute " and " See Value s".

Bulk data

Header and pixel data which is to be transferred to the DHS for display or storage. Bulk data is transmitted using the protocol of ICD/3, See gscg.grp.007, "ICD 3 -- Bulk Data Transfer", Norm Hill, Severin Gaudet & Steven Beard, DAO., rather than by EPICS channel access, See "EPICS Channel Access Reference Manual", J. O. Hill, Los Alamos National Laboratory. Compare with See Status information .

Combined readout

This refers to the data resulting from the combination (e.g. coadding) of several detector See Readout s.

Command

An instruction commanding the Instrument Control System to start some action. The action may result in a mechanism moving or some internal parameters being set to particular values. A command may have command parameters (aka "command arguments") which contain the details of the instruction to be obeyed. Commands are activated by means of CAD records, and the OCS maps each command arguments onto an " See Attribute ".

Components Controller (CC)

An instrument subsystem responsible for the various mechanisms (e.g. motors and heaters) contained in an instrument.

Control LAN

The Local Area Network in the Gemini system devoted to the transfer of commands, responses and status information.

Data label

A unique label for a See Data set assigned by the DHS or OCS which is used to identify data being sent to or requested from the DHS. When an instrument obeys an OBSERVE command, the See Data label for the See Data set generated is provided by the OCS. The See Data label for data generated spontaneously by a non-instrument data source, such as a wavefront sensor, is provided by the DHS.

Data LAN

The Local Area Network in the Gemini system devoted to the transfer of bulk data.

Data set

A self-contained collection of data generated as a result of an instrument obeying an OBSERVE command. Each OBSERVE command results in one and only one See Data set . All the data relating to one See Data set will be maintained by the DHS in a single container. A data set consists of some See Header data describing the See Data set plus one or more See Frame s.

Datum

The reference point used to define the coordinate system of a mechanism which does not have absolute encoders. Also knows as " See Index " and " See Home ".

Destructive read

A clocking out of the integrated signal recorded by a detector which results in that signal being discarded. A detector can only be read out once in such a mode.

Detector Controller (DC)

An instrument subsystem responsible for controlling a detector array and reading data from it. Note that this term has been used in Gemini documentation to refer both to the detector control electronics and the detector control software system . In the context of this software document the term refers to the detector control software system unless otherwise stated.

Dynamic Header

That part of the See Header data containing information about the See Data set which needs to be collected at a very precise time (such as the time at which the data collection started and finished). This part of the See Header data is typically provided by an instrument.

Encoder

A device used to sense the location of a mechanism. An absolute encoder gives a direct reading of the position of a mechanism. A relative encoder is used to count how far a mechanism has moved from its previous position.

Exposure

The array of data resulting from reading the detector during or after a single exposure of the detector array to light. An exposure is made by resetting the detector, exposing it to light, and reading it one or more times (e.g. once in a See Destructive read mode or several times in a See Non-destructive read mode).

Frame

An image or spectrum capable of being displayed or processed as a discrete entity (for example an image of all the coadded observations in one beam of an observation made in chop mode). A See Data set can be made of one or more frame (for example a See Data set in chop mode might consist of frames of coadded exposures in beams A and B). Each frame can consist of one or more See Exposure s.

Hall-effect Sensor.

An electronic component which is used to detect and to measure magnetic field strength.

Header data

A collection of attribute/value pairs which describe a See Data set or a See Frame within a See Data set .

Home

See " See Datum ".

Index

See " See Datum ".

Instrument Sequencer (IS)

That part of an Instrument Control System responsible for coordinating the actions of a Detector Controller and one or more Components Controllers. The A&G subsystem has a "Guidance and Beam Direction Sequencer" for coordinating its components.

Non-destructive read

A clocking out of the integrated signal recorded by a detector in a way which maintains that signal intact. The signal recorded by a detector can be sampled more than once in such a mode. This mode is often used to minimise the contribution from detector read noise.

Observation

An observation is a procedure, specified by the observer, designed to obtain scientific information from the light acquired from an object. To complete an observation, the OCS may need to issue several OBSERVE commands, which could result in several See Data set s. The term See Observation has also been used in the CICS documentation to refer to the act of accumulating light from a source on a detector.

Parameter Definition Format (PDF)

A document describing the commands and parameters recognised by a principal system, and the status information made available by that system.

Pointing origin information

This is the information which the instrument supplies to the TCS describing where on the telescope focal plane the light from a particular source object should be directed. This information can be used to position an object at a certain place on a detector array or at a certain place on the instrument's slit, for example. If not specified, the default pointing origin will be at the centre of the Cassegrain rotator axis.

Preset

The act of defining and testing a set of attributes to make sure they are valid before executing the command(s) associated with them.

Principal Systems

The Gemini Control System is made up of the OCS, TCS, DHS and one ICS for each instrument. These systems constitute the principal systems of the Gemini Control System.

Read

When used in the context of a detector controller, this refers to the read of a single pixel on the detector array.

Readout

When used as a noun to describe instrument data, this refers to the array resulting from a See Read of all the pixels on the detector inside a given region of interest (which may be the whole detector array). An See Exposure can be made from one or more readouts or See Combined readout s.

Region of interest

This is an area on the surface of a detector whose data are of interest. There may be one or more regions of interest on a detector array.

SDSU.

San Diego

Shack-Hartmann. A type of wavefront sensor in which the field is imaged onto a detector through an array of small lenslets, causing a star to be imaged as an array of spots. The relative location of the centroids of these spots can be used to determine the shape of the incoming wavefront.

Static header

That part of the See Header data containing information which changes little with time during an observation (such as the telescope target coordinates and name of the observer). This part of the See Header data is typically provided by the OCS, but some wavefront sensors may need to provide the information themselves.

Status information

Small quantities of information describing the configuration or status of a system. This information is usually stored in an EPICS database and communicated by channel access, See "EPICS Channel Access Reference Manual", J. O. Hill, Los Alamos National Laboratory. Compare with See Bulk data .

Sequence Commands

The set of standard commands mandated by the OCS which all instruments must obey. These are described in reference See ocs.kkg.031, "Sequence Command Specifications", Kim Gillies, Shane Walker & Steven Beard, NOAO/Gemini 8m Telescopes Project..

Status/Alarm Database (SAD)

This is an EPICS database containing the public status information for a Gemini principal system. For an Instrument Control System, the SAD would contain information about the configuration of the instrument's mechanisms, its current state and health, and information obtained from sensors.

Value

The value associated with an " See Attribute ".

VME

A real-time system obeying the ANSI/IEEE 1014-1987 Versatile Backplane Bus standard.

VxWorks

The Real Time Operating system from Wind River.

World Coordinate System (WCS) information

Information describing the transformation between pixel coordinates in the data array and (RA, Dec) coordinates on the sky.

 

Stylistic Conventions

References to documents are given like this [1].

Details of the NIFS to OCS Interface

Introduction
Physical System Interfaces
Mechanical Interface

Not Applicable for a software ICD.

Optical Interface

Not Applicable for a software ICD.

Electronic Interface

The system hardware architecture for the NIFS control software is described in See "NIFS Critical Design Review Vol 1", Research School of Astronomy and Astrophysics, Australian National University.

Mass/Balance

Not Applicable for a software ICD.

Thermal Interface

Not Applicable for a software ICD.

Software / Control Function Interface
Overview
Communications infrastructure

The communications infrastructure is the same as described in See cics_smb_013, "Science Instrument to Observatory Control System", Steven Beard, Royal Observatory Edinburgh..

Behavior

The behavior of the NIFS/OCS interface is the same as described in See cics_smb_013, "Science Instrument to Observatory Control System", Steven Beard, Royal Observatory Edinburgh..

Implementation

This section contains tables summarizing the EPICS records used for the interface. The next sections contain the details of what those records do.

It is assumed in all cases that the record names given in this document are prefixed by the string "nifs:". Records in the SAD database are prefixed by "nifs:sad:".

Command (CAD/CAR) records

The columns of the command record tables are as follows:

Description

A brief description of the command.

Attribute

The name of the attribute which the Observatory Control System associates with a particular parameter of a particular command. Component position names are listed separately in See Position Names (observing commands).

CAD record / CAD record.FIELD

The name of the EPICS CAD record (minus the "nifs:" prefix) together with the field in that CAD record associated with each parameter of the command (Note that if no field is specified, then EPICS uses the VAL field.)

CAD ordering number

The recommended order in which this command should be executed. CAD records should be connected to their associated APPLY record in the order 1, 2, 3, 4, 5, etc. CAD records within the same ordering number set can be connected to the APPLY record in any order in that set.

CAR record

The CAR record associated with the command. Note that several CAD records may share the same CAR record.

Sequence command CAD/CAR records

The NIFS sequencer recognizes all the OCS sequence commands and uses the CAD/CAR records specified in ICD 1b See gscg.kkg.024, "ICD 1b -- The Baseline Attribute/Value Interface", Kim Gillies, NOAO.. See also ICD 1a See gscg.kkg.009, "ICD 1a -- The System Command Interface", Kim Gillies, NOAO., for a description of what these commands do.

NIFS sequence command CAD/CAR records

Description

Attribute2

CAD record /
CAD record.FIELD
("nifs:" +)

CAD

ordering

number

CAR record3
("nifs:" +)

Test

(none)

test

1

testC

Initialize

(none)

init

2

initC

Datum mechanisms.

(none)

datum

3

datumC

Park

(none)

park

4

parkC

Verify

(none)

verify

7

verifyC

End verify

(none)

endVerify

8

endVerifyC

Guide

(none)

guide

5

guideC

End guide

(none)

endGuide

6

endGuideC

Observe

Observation ID

observe.A

9

observeC

Stop

(none)

stop

12

Abort

(none)

abort

13

Pause

(none)

pause

10

Continue

(none)

continue

11

End Observe

(none)

endObserve

14

endObserveC
General observing command CAD/CAR records

The commands in See NIFS general observing command CAD/CAR records are the only ones that are used during routine observation.

NIFS general observing command CAD/CAR records

Description

Attribute4

CAD record /
CAD record.FIELD

("nifs:" +)

CAD
ordering
number

CAR
record
("nifs:" +)

Select a filter in the filter wheel.

filter name

cc:filtSel.A

27

cc:filtC

Park the filter wheel.

(none)

cc:filtPark

26

Select a grating in the grating turret.

grating name

cc:gratSel.A

35

cc:gratC

Park the grating turret.

(none)

cc:gratPark

34

Offset the grating so that it is centred on a new wavelength (in μm)

central wavelength

cc:gratMoveOff.A

38

Select the flip mirror position

position name

cc:flipSel.A

51

cc:flipC

Park the flip mirror.

(none)

cc:flipPark

50

Select the focal-plane mask.

position name

cc:foplSel.A

19

cc:foplC

Park the focal-plane mask wheel.

(none)

cc:foplPark

18

Offset the focal plane mask as projected onto the detector. Offset is in units of displacement of arcseconds across the detector.

offset

cc:foplMoveOff.A

22

Select the window-cover position.

position name

cc:covSel.A

43

cc:covC

Park the window cover.5

(none)

cc:covPark

42

Setup readout sequence parameters for IDLE mode. A separate set of parameters are maintained for each NIFS mode (idle and run)

 

Read method (DCS | FOWLER)

Total integration time

Number of non-destructive reads

Non-destructive read period

Number of co-adds

Number of resets

Reset delay

Wavelength minimum6

Wavelength maximum

dc:seqIdle.A

dc:seqIdle.B

dc:seqIdle.C

dc:seqIdle.D

dc:seqIdle.E

dc:seqIdle.F

dc:seqIdle.G

dc:seqIdle.H

dc:seqIdle.I

11

dc:seqIdleC

Setup readout sequence parameters for RUN mode. A separate set of parameters are maintained for each NIFS mode (idle and run)

Read method (DCS | FOWLER | LINEAR)

Total integration time

Number of non-destructive reads

Non-destructive read period

Number of co-adds

Number of resets

Reset delay

Wavelength minimum

Wavelength maximum

Perform cosmic ray rejection?

Cosmic ray rejection threshold

Simulation rate of cosmic rays

dc:seqRun.A

 

dc:seqRun.B

dc:seqRun.C

dc:seqRun.D

dc:seqRun.E

dc:seqRun.F

dc:seqRun.G

dc:seqRun.H

dc:seqRun.I

dc:seqRun.J

dc:seqRun.K

dc:seqRun.L

12

dc:seqRunC

Setup DHS parameters for IDLE mode. Like the readout parameters, a separate set is maintained for each operating mode.

Send data to the DHS?

Raw data quick look display - QLD

Compressed image cube QLD

Subtract image from raw data?

Subtract image name

dc:dataIdle.A

dc:dataIdle.B

dc:dataIdle.C

dc:dataIdle.D

dc:dataIdle.E

13

dc:dataIdleC

Setup DHS parameters for RUN mode. Like the readout parameters, a separate set is maintained for each operating mode.

Send data to the DHS or FITS server?

Save to permanent storage?

Save each non-destructive read?7

Subtract image from raw data?

Subtract image name

Simulation input image name

Simulation image integration time

Save variance data?

Save quality data?

Bad pixel file name

Fits server port number

Fits server host name

dc:dataRun.A

 

dc:dataRun.B

dc:dataRun.C

dc:dataRun.D

dc:dataRun.E

dc:dataRun.F

dc:dataRun.G

dc:dataRun.H

dc:dataRun.I

dc:dataRun.J

dc:dataRun.K

dc:dataRun.L

14

dc:dataRunC

Set DHS quick look stream information for observe mode - this is a required Gemini CAD.

Raw data quick look stream

Compressed image cube quick look stream

DHS server name

DHS server IP address

dc:setDhsInfo.A

dc:setDhsInfo.B

 

dc:setDhsInfo.C

dc:setDhsInfo.D

15

dc:setDhsInfoC
Engineering command CAD/CAR records--System Commands

The following commands are used for engineering purposes, and are not expected to be used during observing. These are normally activated by the engineering user interface.

These commands affect the overall behavior of NIFS and the NIFS OIWFS. Note, in particular, that it is not possible to reboot the NIFS IS, CC and OIWFS separately.

NIFS system engineering command CAD/CAR records

Description

Attribute8

CAD record /
CAD record.FIELD
("nifs:" +)

CAD ordering number

CAR record

Reboot.

(none)

reboot

16

N/A

Select debug mode.

Debug mode

debug.A

15

immediate completions
CC Sequence command CAD/CAR records

The NIFS components controller control software recognizes all the OCS sequence commands and uses the CAD/CAR records specified in ICD 1b, See gscg.kkg.024, "ICD 1b -- The Baseline Attribute/Value Interface", Kim Gillies, NOAO.. See also ICD 1a, See gscg.kkg.009, "ICD 1a -- The System Command Interface", Kim Gillies, NOAO., for a description of what these commands do.

NIFS CC sequence command CAD/CAR records

Description

Attribute9

CAD record /
CAD record.FIELD
("nifs:" +)

CAD ordering number

CAR record
("nifs:" +)

Test.

(none)

cc:test

1

cc:testC

Initialize.

(none)

cc:init

2

cc:initC

Datum mechanisms.

(none)

cc:datum

3

cc:datumC

Verify

(none)

cc:verify

7

cc:verifyC

End verify (no action)

(none)

cc:endVerify

8

cc:endVerifyC

Guide

(none)

cc:guide

5

cc:guideC

End guide (no effect)

(none)

cc:endGuide

6

cc:endGuideC

Park

(none)

cc:park

4

cc:parkC

Reboot

(none)

cc:reboot

10

N/A

Set debug mode

debug mode

cc:debug

9

Immediate completion
Engineering command NIFS CC CAD/CAR records

 

The following commands are used for engineering purposes, and are not expected to be used during normal observing. Note that, although these commands are connected to the APPLY record, they are normally activated directly by the engineering user interface.

NIFS CC engineering command CAD/CAR records

Description

Attribute10

CAD record /
CAD record.FIELD
("nifs:" +)

CAD ordering number

CAR record

("nifs:" +)

Datum filter wheel.

(none)

cc:filtDatm

23

cc:filtC

Set the filter-wheel position using position numbers11.

position

cc:filtMove.A

29

Set the filter wheel position in engineering unitsb.

motor position

cc:filtEngMove.A

28

Confirm that the filter wheel has not lost its datum position.

(none)

cc:filtRdtm

24

Confirm that the filter wheel and its Hall-effect sensors are operational.

(none)

cc:filtDiag

25

Datum grating turret.

(none)

cc:gratDatm

31

cc:gratC

Set the grating turret position using position numberb.

position

cc:gratMove.A

37

Set the grating turret position in engineering unitsb.

motor position

cc:gratEngMove.A

36

Confirm that the grating turret has not lost its datum position.

(none)

cc:gratRdtm

32

Confirm that the grating turret and its Hall-effect sensors are operational

(none)

cc:gratDiag

33

Datum the focal-plane mask wheel.

(none)

cc:foplDatm

15

cc:foplC

Set the focal-plane mask wheel position using position numberb.

position

cc:foplMove.A

21

Set the focal-plane mask wheel position in engineering unitsb.

motor position

cc:foplEngMove.A

20

Confirm that the focal-plane mask wheel has not lost its datum position.

(none)

cc:foplRdtm

16

Confirm that the focal-plane mask wheel and its Hall-effect sensors are operational

(none)

cc:foplDiag

17

Datum the flip mirror

(none)

cc:flipDatm

47

cc:flipC

Set the flip mirror position12.

position

cc:flipMove.A

53

Set the flip mirror position in engineering unitsc.

motor position

cc:flipEngMove.A

52

Confirm that the flip mirror has not lost its datum position

(none)

cc:flipRdtm

48

Confirm that the flip mirror and its Hall-effect sensors are operational

(none)

cc:flipDiag

49

Datum the window cover.

(none)

cc:covDatm

39

cc:covC

Set the window-cover position.

position

cc:covMove.A

45

Set the window cover position in engineering units.

motor position

cc:covEngMove.A

44

Confirm that the window cover has not lost its datum position.

(none)

cc:covRdtm

40

Confirm that the window cover and its Hall-effect sensors are operational

(none)

cc:covDiag

41

 

 

DC Sequence Command CAD/CAR Records

The NIFS detector controller control software recognizes all the OCS sequence commands and uses the CAD/CAR records specified in ICD 1b, See gscg.kkg.024, "ICD 1b -- The Baseline Attribute/Value Interface", Kim Gillies, NOAO.. See also ICD 1a, See gscg.kkg.009, "ICD 1a -- The System Command Interface", Kim Gillies, NOAO., for a description of what these commands do. Some of these sequences are not used for NIFS and are handled by just cycling the corresponding CAR record from BUSY to IDLE without taking any further action. These are indicated by the "no-operation" label in See NIFS DC sequence command CAD/CAR records.

NIFS DC sequence command CAD/CAR records

Description13

Attribute14

CAD record /
CAD record.FIELD
("nifs" +)

CAD ordering number

CAR record
("nifs:" +)

Reboot.

(none)

dc:reboot

1

N/A

Initialize.

Simulation mode (NONE | VSM | FAST | FULL)

dc:init.A

2

dc:initC

Test. For ENGINEERING test mode, this sequence runs the SDSU TDL commands to test the communication links between the VME interface card and the controller electronics.

Test mode (NONE | ENGINEERING | FULL | SCIENCE)

SDSU TDL test value

Number of tests

dc:test.A

 

 

dc:test.B

dc:test.C

3

dc:testC

Park

(none)

dc:park

4

dc:parkC

Set debug mode

Debug mode (NOLOG | NONE | MIN | FULL)

dc:debug.A

5

Immediate

completion

Observe.

Observation ID

dc:observe.A

16

dc:observeC

Abort.

(none)

dc:abort

17

Stop.

(none)

dc:stop

18

Verify (no operation).

(none)

dc:verify

19

dc:verifyC

End verify (no operation).

(none)

dc:endVerify

20

dc:endVerifyC

Guide (no operation).

(none)

dc:guide

21

dc:guideC

End guide (no operation).

(none)

dc:endGuide

22

dc:endGuideC

End observe (no operation).

(none)

dc:endObserve

23

dc:endObserveC

Datum (no operation).

(none)

dc:datum

24

dc:datumC

Pause (no operation).

(none)

dc:pause

25

dc:pauseC

Continue (no operation).

(none)

dc:continue

26

dc:continueC

 

Engineering command NIFS DC CAD/CAR records

The following commands are used for engineering purposes, and are not expected to be used during normal observing. Note that, although these commands are connected to the APPLY record, they are normally activated directly by the engineering user interface.

NIFS DC engineering command CAD/CAR records

Description

Attribute

CAD record /
CAD record.FIELD
("nifs:" +)

CAD ordering number

CAR record

("nifs:" +)

Sets up the parameters for the SDSU detector controller. These parameters will only be applied when the initSDSU CAD is marked and applied.

 

Timing DSP code file name

VME DSP code filename

VINOFFSET1 - Video input 1 offset voltage

VINOFFSET2 - Video input 2 offset voltage

VINOFFSET3 - Video input 3 offset voltage

VINOFFSET4 - Video input 4 offset voltage

BIASGATE - Gate voltage of bias P-FET

VRESET - Control signal for resetting all the pixels

BIASPWR - Source voltage of bias P-FET

VDDA - Analog high power

VDD - Digital Power

Set power on/off

Set video mode (VD1 | VD2 | STP)

Number of samples of digital filtering

Number of reference samples

dc:setupSDSU.A

dc:setupSDSU.B

dc:setupSDSU.C

 

dc:setupSDSU.D

 

dc:setupSDSU.E

 

dc:setupSDSU.F

 

dc:setupSDSU.G

 

dc:setupSDSU.H

 

dc:setupSDSU.I

 

dc:setupSDSU.J

dc:setupSDSU.K

dc:setupSDSU.L

dc:setupSDSU.M

dc:setupSDSU.N

 

dc:setupSDSU.O

6

dc:setupSDSUC

Set SDSU IDLE mode.

Idle mode on/off

dc:idleSDSU.A

7

dc:setupSDSUC

Read SDSU memory location

Address to read

Memory bank to access

dc:rdmSDSU.A

dc:rdmSDSU.B

8

dc:setupSDSUC

Write SDSU memory location

Address to write

Memory bank to access

Value to write

dc:wrmSDSU.A

dc:wrmSDSU.B

dc:wrmSDSU.C

9

dc:setupSDSUC
Status Information Records

The following set of tables show the status information provided by NIFS, together with the subset of that information which is written to the FITS header. The tables distinguish status information provided by the Instrument Sequencer, Components Controller and, Detector Controller, but all the information shown is available over the OCS-to-NIFS interface. The tables have the following columns:

SIR record

The part of the name of the EPICS SIR record which follows the "nifs:sad:" prefix..

FITS Keyword

The FITS keyword that would be used if the item were included in a FITS header.

FITS Included

Indicates how the item is normally included in the FITS header. Items labelled "start" are sampled at the start of a data set observation; those labelled "end" are sampled at the end of a data set observation, and those labelled "never" are never written to the FITS header.

Type

The data type

Units / Values

The units in which the quantity is stored and / or the range of values that are taken.

  • Ustep refers to motor microsteps.
  • "User units" or "real-world" units refer to the units that are stored in the Units SIR variable.
Comments

A description of the item. The first paragraph of this will go into the SIR record description and also the comment field in the FITS header.

Note that only the type, units and comments are actually contained in the SIR records. The FITS keyword is provided by the DHS .

Compulsory Instrument Sequencer Status Information

See Compulsory Instrument Sequencer (IS) Status Information contains status information for all of NIFS, particularly, the instrument sequencer.

Compulsory Instrument Sequencer (IS) Status Information

SIR record
("nifs:sad:" )

FITS Keyword

FITS Included

Type

Units/Values

Comments

dcAbort

 

never

long

0/1

Shows that an abort is in progress

debugMode

 

never

string

 

Debugging mode [NOLOG | NONE | MIN | FULL]

health

 

never

string

 

Instrument health [GOOD | WARNING | BAD]

heartBeat

 

never

long

count

Heartbeat: Shows that IS is still alive by increasing at a steady rate

historyLog

 

never

array of char

 

History-log record15

issPort

INPORT

start

long

number

ISS port on which instrument is installed

label

 

never

string

 

The FDSC field describes the Instrument

name

 

never

string

 

Instrument Name

simMode

 

never

string

 

Instrument simulation mode [NONE | FULL | FAST | VSM]

state

 

never

string

 

Instrument state [BOOTING | INITIALIZING | RUNNING | CONFIGURING]

wfsBeam

 

never

long

 

Is the WFS detector unobstructed [0=YES | 1=NO]
Compulsory Components Controller Status Information

See Compulsory Components Controller (CC) Status Information contains the compulsory Components Controller SIRs.

Compulsory Components Controller (CC) Status Information

SIR record ("nifs:sad:" +)

FITS Keyword

FITS Included

Type

Units

Comments

cc:debugMode

 

never

string

 

Debugging mode [NOLOG | NONE | MIN | FULL]

cc:health

 

never

string

 

CC Health [GOOD | WARNING | BAD]

cc:heartBeat

 

never

long

count

Heart beat record: Shows that CC is still alive by increasing at a steady rate.

cc:historyLog

 

never

array of char

 

History log record16

cc:issPort

 

never

long

number

ISS port on which instrument is installed

cc:label

 

never

string

 

The FDSC field describes the Components Controller

cc:name

 

never

string

 

Components Controller Name

cc:simMode

 

never

string

 

Simulation mode [NONE | FULL | FAST | VSM]

cc:state

 

never

string

 

Instrument state [BOOTING | INITIALIZING | RUNNING | CONFIGURING]

cc:wfsBeam

 

never

long

0/1

Is the WFS detector unobstructed? [YES=0 | NO=1]17
The Components Controller Component Status Information

The following table summarizes the information for the various components.

Components Controller (CC) Component Status Information

SIR record ("nifs:sad:"+)

FITS
Keyword

FITS
Included

Type

Units

Comments

cc:covDatumed

 

never

long

0/1

Is the window cover datumed? [YES=0 | NO=1]

cc:covEngCyclic

 

never

long

0/1

Ignore limits for the window cover [YES=0 | NO=1]

cc:covEngMax

 

never

long

motor microsteps

The maximum position of the window cover in engineering units

cc:covEngMin

 

never

long

motor microsteps

The minimum position of the window cover in engineering units

cc:covEngName

 

never

string

 

Engineering name of the window cover position

cc:covEngPos

 

never

long

motor microsteps

The position of the window cover in engineering units

cc:covLabel

 

never

string

 

The FDSC field describes the window cover

cc:covMax

 

never

double

position number

The maximum position of the window cover in real-world units (position number).

cc:covMin

 

never

double

position number

The minimum position of the window cover in real-world units (position number).

cc:covName

 

never

string

 

User name of the window cover position

cc:covParked

 

never

long

0/1

Is the window cover parked? [YES=0 | NO=1]

cc:covPos

 

never

double

position number

The window cover position in real-world units (position number).

cc:covRdtmVal

 

never

long

motor microsteps

Returned value from the window cover redatum command

cc:covReject

 

never

long

0/-1

Combined window cover CAR state [GOOD=0 | REJECT=-1]

cc:covState

 

never

string

 

the window cover SNL state

cc:covUnits

 

never

string

 

Definition of real-world units for the window cover ("position number").

cc:filtDatumed

 

 

never

 

long

 

0/1

Is the filter wheel datumed? [YES=0 | NO=1]

cc:filtEngCyclic

 

never

long

0/1

Ignore limits for filter wheel? [YES=0 | NO=1]

cc:filtEngMax

 

never

long

motor microsteps

The maximum position of the filter wheel in engineering units

cc:filtEngMin

 

never

long

motor microsteps

The minimum position of the filter wheel in engineering units

cc:filtEngName

 

never

string

 

Engineering name of the filter wheel position

cc:filtEngPos

 

never

long

motor microsteps

The position of the filter wheel in engineering units

cc:filtLabel

 

never

string

 

The FDSC field describes the filter wheel

cc:filtMax

 

never

double

position number

The maximum position of the filter wheel in real-world units (position number).

cc:filtMin

 

never

double

position number

The minimum position of the filter wheel in real-world units (position number).

cc:filtName

FILTER

start

string

 

User name of the filter wheel position

cc:filtParked

 

never

long

0/1

Is the filter wheel parked? [YES=0 | NO=1]

cc:filtPos

FILTPOS

start

double

position number

The position of the filter wheel in real-world units (position number).

cc:filtRdtmVal

 

never

long

motor microsteps

Returned value from the filter wheel redatum command

cc:filtReject

FILTRJCT

start

long

0/-1

Combined filter wheel CAR state [GOOD=0 | REJECT=-1]

cc:filtState

 

never

string

 

Filter wheel SNL state

cc:filtUnits

 

never

string

 

Definition of real-world units for the filter wheel("pos num").

cc:gratDatumed

 

never

long

0/1

Is the grating turret datumed? [YES=0 | NO=1]

cc:gratEngCyclic

 

never

long

0/1

Ignore limits for the grating turret? [YES=0 | NO=1]

cc:gratEngMax

 

never

long

motor microsteps

The maximum position of the grating turret in engineering units

cc:gratEngMin

 

never

long

motor microsteps

The minimum position of the grating turret in engineering units

cc:gratEngName

 

never

string

 

The engineering name of the grating turret position

cc:gratEngPos

 

never

long

motor microsteps

The position of the grating turret in engineering units

cc:gratLabel

 

never

string

 

The FDSC field describes the grating turret

cc:gratMax

 

never

double

position number

The maximum position of the grating turret in real-world units (position number).

cc:gratMin

 

never

double

position number

The minimum position of the grating turret in real-world units (position number)

cc:gratName

GRATING

start

string

 

User name of the grating turret position

cc:gratParked

 

never

long

0/1

Is the grating turret parked? [YES=0 | NO=1]

cc:gratPos

GRATPOS

start

double

position number

The grating turret position in real-world units (position number)

cc:gratRdtmVal

 

never

long

motor microsteps

Returned value from the grating turret redatum command

cc:gratCurOffset

GRATCW

start

double

υm

Central wavelength of grating

cc:gratOffsetUnits

 

never

string

 

Units used for grating offset

cc:gratOffsetUnits.DESC

 

never

string

 

Describes the grating offset

cc:gratReject

GRATRJCT

start

long

0/-1

Combined grating turret CAR state [GOOD=0 | REJECT=-1]

cc:gratState

 

never

string

 

The grating turret SNL state

cc:gratUnits

 

never

string

 

Definition of real-world units for the grating turret ("pos num").

cc:foplDatumed

 

never

long

0/1

Is the focal-plane mask wheel datumed? [YES=0 | NO=1]

cc:foplEngCyclic

 

never

long

0/1

Ignore limits for the focal-plane mask wheel? [YES=0 | NO=1]

cc:foplEngMax

 

never

long

motor microsteps

The maximum position of the focal-plane mask wheel in engineering units

cc:foplEngMin

 

never

long

motor microsteps

The minimum position of the focal-plane mask wheel in engineering units

cc:foplEngName

 

never

string

 

The engineering name of the focal-plane mask wheel position

cc:foplEngPos

 

never

long

motor microsteps

The position of the focal-plane mask wheel in engineering units

cc:foplLabel

 

never

string

 

The FDSC field describes the focal-plane mask wheel

cc:foplMax

 

never

double

position number

The maximum position of the focal-plane mask wheel in real-world units (position number).

cc:foplMin

 

never

double

position number

The minimum position of the focal-plane mask wheel in real-world units (position number).

cc:foplName

APERTURE

start

string

 

User name of the focal-plane mask wheel position

cc:foplParked

 

never

long

0/1

Is the focal-plane mask wheel parked? [YES=0 | NO=1]

cc:foplPos

APPOS

start

double

position number

The focal-plane mask wheel position in real-world units (position number).

cc:foplRdtmVal

 

never

long

motor microsteps

Returned value from the focal-plane mask wheel redatum command

cc:foplCurOffset

APOFFST

start

double

arcseconds

Offset of mask from nominal position as projected onto the detector

cc:foplOffsetUnits

 

never

string

 

Units used by the offset

cc:foplOffsetUnits.DESC

 

never

string

 

Describes the focal plane mask offset.

cc:foplReject

APRJCT

start

long

0/-1

Combined the focal-plane mask wheel CAR state [GOOD=0 | REJECT=-1]

cc:foplState

 

never

string

 

the focal-plane mask wheel SNL state

cc:foplUnits

 

never

string

 

Definition of real-world units for the focal-plane mask wheel ("pos num").

cc:flipDatumed

 

never

long

0/1

Is the flip mirror datumed? [YES=0 | NO=1]

cc:flipEngCyclic

 

never

long

0/1

Ignore limits for the flip mirror? [YES=0 | NO=1]

cc:flipEngMax

 

never

long

motor microsteps

The maximum position of the flip mirror in engineering units

cc:flipEngMin

 

never

long

motor microsteps

The minimum position of the flip mirror in engineering units

cc:flipEngName

 

never

string

 

The engineering name of the flip mirror position

cc:flipEngPos

 

never

long

motor microsteps

The position of the flip mirror in engineering units

cc:flipLabel

 

never

string

 

The FDSC field describes the flip mirror

cc:flipMax

 

never

double

position number

The maximum position of the flip mirror in real-world units (position number).

cc:flipMin

 

never

double

position number

The minimum position of the flip mirror in real-world units (position number).

cc:flipName

FLIP

start

string

 

User name of the flip mirror position

cc:flipParked

 

never

long

0/1

Is the flip mirror parked? [YES=0 | NO=1]

cc:flipPos

FLIPPOS

start

double

position number

The flip mirror position in real-world units (position number).

cc:flipRdtmVal

 

never

long

motor microsteps

Returned value from the flip mirror redatum command

cc:flipReject

FLIPRJCT

start

long

0/-1

Combined flip mirror CAR state [GOOD=0 | REJECT=-1]

cc:flipState

 

never

string

 

The flip mirror SNL state

cc:flipUnits

 

never

string

 

Definition of real-world units for the flip mirror ("pos num").
Temperature Control and Monitoring Subsystem, Status Information

The following table summarizes the provided information for the temperature subsystem.

Components Controller (CC) Temperature Control and Monitoring Subsystem, Status Information

SIR record ("nifs:sad:" +)

FITS
Keyword

FITS
Included

Type

Units

Comments

cc:tmpC1Setp

 

never

double

K

OIWFS Set-point temperature

cc:tmpC1Tmp

 

never

double

K

OIWFS temperature

cc:tmpC2Setp

 

never

double

K

Cold work surface set-point temperature

cc:tmpC2Tmp

TCWS

start

double

K

Cold work surface temperature

cc:tmpC3Setp

 

never

double

K

Detector set-point temperature

cc:tmpC3Tmp

TDET

start

double

K

Detector temperature

cc:tmpC4Setp

 

never

double

K

Detector-housing set-point temperature

cc:tmpC4Tmp

TDETHOUS

start

double

K

Detector-housing temperature

cc:tmpCoolBusy

 

never

string

 

Cooling motor activity

cc:tmpCoolRate1

 

never

double

motor-microsteps / s

Cooling motor 1 rate

cc:tmpCoolRate2

 

never

double

motor-microsteps / s

Cooling motor 2 rate

cc:tmpLabel

 

never

string

 

The FDSC field describes the temperature Subsystem

cc:tmpS1Tmp1

 

never

double

K

The temperature on the first stage of the cryocooler, cooling the science detector

cc:tmpS1Tmp2

 

never

double

K

The temperature on the attachment of the coldstrap surface from the science detector cryocooler to the cold work surface

cc:tmpS1Tmp3

 

never

double

K

The temperature on the getter assembly which is connected to the second stage of the cryocooler not cooling the science detector.

cc:tmpS1Tmp4

 

never

double

K

The temperature at the edge of the cold work surface near the entrance window

cc:tmpS1Tmp5

 

never

double

K

An unused temperature-sensor channel (5)

cc:tmpS1Tmp6

 

never

double

K

An unused temperature-sensor channel (6)

cc:tmpS1Tmp7

 

never

double

K

An unused temperature-sensor channel (7)

cc:tmpS1Tmp8

 

never

double

K

An unused temperature-sensor channel (8)
Component Health Information

The following table summarizes the health information records. All records return one of the strings: "GOOD", "WARNING", or "BAD". Each record describes one aspect of the health of a component.

Components Controller (CC) Component Health Information

SIR record ("nifs:sad:" +)

FITS
Keyword

FITS
Included

Type

Units

Comments

cc:covDatumHealth

 

never

string

 

The health of the window cover datum state

cc:covHallHealth

 

never

string

 

The health of the window cover Hall-effect sensors

cc:covHealth

 

never

string

 

The overall health of Window Cover

cc:covModuleHealth

 

never

string

 

The health of the window-cover steppermotor driver module

cc:covPosErrHealth

 

never

string

 

The health of the window cover backlash correction

cc:covSnlHealth

 

never

string

 

The health of the window cover State code

cc:filtDatumHealth

 

never

string

 

The health of the filter wheel datum state

cc:filtHallHealth

 

never

string

 

The health of the filter wheel Hall-effect sensors

cc:filtHealth

 

never

string

 

The overall health of filter wheel

cc:filtModuleHealth

 

never

string

 

The health of filter wheel driver module

cc:filtPosErrHealth

 

never

string

 

The health of the filter wheel backlash correction

cc:filtSnlHealth

 

never

string

 

The health of the filter wheel state code

cc:gratDatumHealth

 

never

string

 

The health of the grating turret datum state

cc:gratHallHealth

 

never

string

 

The health of the grating turret Hall-effect sensors

cc:gratHealth

 

never

string

 

The overall health of the grating turret

cc:gratModuleHealth

 

never

string

 

The health of the grating turret driver module

cc:gratPosErrHealth

 

never

string

 

The health of the grating turret backlash correction

cc:gratSnlHealth

 

never

string

 

The health of the grating turret state code

cc:foplDatumHealth

 

never

string

 

The health of the focal-plane mask wheel datum state

cc:foplHallHealth

 

never

string

 

The health of the focal-plane mask wheel Hall-effect sensors

cc:foplHealth

 

never

string

 

The overall health of the focal-plane mask wheel

cc:foplModuleHealth

 

never

string

 

The health of the focal-plane mask wheel driver module

cc:foplPosErrHealth

 

never

string

 

The health of the focal-plane mask wheel backlash correction

cc:foplSnlHealth

 

never

string

 

The health of the focal-plane mask wheel state code

cc:flipDatumHealth

 

never

string

 

The health of the flip mirror datum state

cc:flipHallHealth

 

never

string

 

The health of the flip mirror Hall-effect sensors

cc:flipHealth

 

never

string

 

The overall health of the flip mirror

cc:flipModuleHealth

 

never

string

 

The health of the flip mirror driver module

cc:flipPosErrHealth

 

never

string

 

The health of the flip mirror backlash correction

cc:flipSnlHealth

 

never

string

 

The health of the flip mirror state code
The Temperature Control and Monitoring Subsystem Health Information

See Components Controller (CC) Temperature Subsystem Health Information summarizes the heath messages involving the temperature monitoring and control subsystem. All records return one of the strings: "GOOD", "WARNING", or "BAD".

Components Controller (CC) Temperature Subsystem Health Information

SIR record ("nifs:sad:" +)

FITS
Keyword

FITS
Included

Type

Units

Comments

cc:tmpC1Health

 

never

string

 

The health of temperature controller 1, controlling the On-Instrument Wavefront Sensor.

cc:tmpC2Health

 

never

string

 

The health of temperature controller 2, controlling the imager buffer mass.

cc:tmpC3Health

 

never

string

 

The health of temperature controller 3, controlling the detector temperature.

cc:tmpC4Health

 

never

string

 

The health of temperature controller 4, controlling the detector housing.

cc:tmpCoolModeHealth

 

never

string

 

The health of cooling motor on/off state

cc:tmpHealth

 

never

string

 

The overall health of the temperature subsystem

cc:tmpModeHealth

 

never

string

 

The health of Heater / motor mode

cc:tmpS1Health

 

never

string

 

The health of the temperature-sensor

cc:tmpTmpCheckHealth

 

never

string

 

The health of the temperature-in-range indicator

 

Position names

See Position Names (observing commands) contains a list of valid position names. Note that these names are case sensitive and must be entered exactly as presented here, including underscores. In addition to the listed positions, all mechanisms respond to the special names "datum" and "park" which may or may not be distinct from the listed positions.

Position Names (observing commands)

Component

Position Names

Engineering Position18

Comments

Window Cover

Open

(tbd)

 

Closed

(tbd)

 

Filter Wheel

Z

(tbd)

Z grating band pass filter

J

(tbd)

J grating band pass filter

H

(tbd)

H grating band pass filter

K

(tbd)

K grating band pass filter

Grid

(tbd)

K grating band pass filter and wire grid analyser

pos05

(tbd)

Blocked

pos06

(tbd)

Blocked

Blocked

(tbd)

Blocked

Grating Turret

Z

(tbd)

Z grating band pass filter

J

(tbd)

J grating band pass filter

H

(tbd)

H grating band pass filter

K

(tbd)

K grating band pass filter (2.00 - 2.42 μm)

Ks

(tbd)

K grating band pass filter (1.90 - 2.32 μm)

Kl

(tbd)

K grating band pass filter (2.10 - 2.52 μm)

Blank

(tbd)

Blank

Mirror

(tbd)

Mirror

Focal Plane Mask Wheel

Clear

(tbd)

Clear

0.1"

(tbd)

0.1" occulting disk

0.2"

(tbd)

0.2" occulting disk

0.5"

(tbd)

0.5" occulting disk

ND

(tbd)

Neutral density filter

Mask

(tbd)

Calibration slit mask

Hole

(tbd)

0.1" diameter pinhole

Slit

(tbd)

0.1" wide slit

Blocked

(tbd)

Blocked

pos09

(tbd)

Blocked

pos10

(tbd)

Blocked

pos11

(tbd)

Blocked

Flip Mirror

in

(tbd)

 

out

(tbd)

 
Compulsory Detector Controller Status Information

See Compulsory Detector Controller (DC) Status Information contains the same information as See Compulsory Instrument Sequencer (IS) Status Information, but for the Detector Controller.

Compulsory Detector Controller (DC) Status Information

SIR record

(instrument prefix +)

FITS keyword

FITS included?

Type

Units

Comments

dc:name

DCNAME

start

string

 

Detector Controller name

dc:state

DCSTATE

 

string

 

Detector Controller state

[BOOTING | INITIALISING | RUNNING | CONFIGURING]

dc:health

DCHEALTH

start

string

 

Detector Controller health

[GOOD | WARNING | BAD]

dc:historyLog

 

never

string

 

Detector Controller log message.

dc:heartBeat

 

never

integer

 

Continuously changing variable used to detect whether the system is still alive.

dc:prep

 

never

boolean

 

Flag to indicate that the Detector Controller is preparing to make an observation (e.g. the detector is preflashing, or it is waiting for the chopper to reach the right phase).

When this flag is TRUE the instrument beam and the detector array are both "busy".

dc:acq

 

never

boolean

 

Flag to indicate that the Detector Controller is doing whatever is necessary to make an observation (e.g. the detector is integrating upon the sky or is going through a sequence of short exposures). The instrument mechanisms should not be reconfigured during this period.

When this flag is TRUE the instrument light path is "busy" and cannot be changed.

dc:rdout

 

never

boolean

 

Flag to indicate that the Detector Controller is reading out its data. The instrument may reconfigure its mechanisms if acq is FALSE. The detector cannot observe again until this flag goes false.

When this flag is TRUE the detector array is "busy" and cannot start a new observation.

dc:debugMode

 

never

string

 

Debugging mode [NOLOG | NONE | MIN | FULL]

dc:simMode

DCSMODE

start

string

 

Simulation mode [NONE | FULL | FAST | VSM]

 

The Detector Controller Status Information

See Detector Controller (DC) Status Information contains the remaining status information for the Detector Controller.

Detector Controller (DC) Status Information

SIR record

(instrument prefix +)

FITS keyword

FITS included?

Type

Units

Comments

dc:initSDSUDone

 

never

boolean

 

Has the SDSU controller been initialized?

dc:detType

DETTYPE

start

string

 

Description of detector array type

dc:detID

DETID

start

string

 

Detector array chip identifier.

dc:timingDSP

TIMDSP

start

string

 

Name of DSP code for SDSU timing board

dc:timingDSPVersion

TIMDSPV

start

string

 

Version of DSP code for SDSU timing board

dc:VMEDSP

VMEDSP

start

string

 

Name of DSP code for SDSU VME board

dc:VMEDSPVersion

VMEDSPV

start

string

 

Version of DSP code for SDSU VME board

dc:vInOffset0

VINOFFS0

start

float

volts

Video input 1 offset voltage

dc:vInOffset1

VINOFFS1

start

float

volts

Video input 2 offset voltage

dc:vInOffset2

VINOFFS2

start

float

volts

Video input 3offset voltage

dc:vInOffset3

VINOFFS3

start

float

volts

Video input 4offset voltage

dc:biasGate

BIASGATE

start

float

volts

Gate voltage of bias P-FET

dc:vReset

VRESET

start

float

volts

Control signal for resetting all pixels

dc:biasPwr

BIASPWR

start

float

volts

Source voltage of bias P-FET

dc:vdda

VDDA

start

float

volts

Analog high power

dc:vdd

VDD

start

float

volts

Digital power

dc:videoMode

 

never

integer

 

SDSU idle video mode either VD1 | VD2 | STP

dc:nFilterSamples

FILTSAMP

start

integer

 

Number of digital filter samples

dc:nRefSamples

REFSAMP

start

integer

 

Number of reference samples

dc:replyStatus

 

never

integer

 

Status from last SDSU operation

dc:nTestErr

 

never

integer

 

Number of test (TDL) errors

dc:rdmVal

 

never

integer

 

Result of last RDM operation

dc:expMode

EXPMODE

start

string

 

Exposure mode

[DESTRUCTIVE | NONDESTRUCTIVE]

dc:timeLeft

 

never

float

seconds

Time remaining in current data set observation.

dc:nreads

NREADS

start

integer

 

Number of reads per exposure.

dc:readInterval

RDDELT

start

float

microseconds

Interval between reads.

dc:nresets

DETNRST

start

integer

 

Number of detector resets between each exposure.

dc:resetInterval

DETRSTD

start

float

microseconds

Time delay to allow detector to reset.

dc:ncoadds

DETNCOAD

start

integer

 

Number of detector co-adds for each exposure.

dc:exposedRQ

EXPRQ

 

float

seconds

Requested total integration time

dc:exposed

EXPTIME

end

float

seconds

Actual total integration time

dc:elapsed

ELAPSED

end

float

seconds

Total elapsed time

dc:daqState

 

never

string

 

Data acquisition state (IDLE | OBSERVING | READOUT)

dc:dpMode

DPMODE

start

string

 

Data processing mode used to calculate photon rate (DCS | FOWLER | LINEAR)

dc:nexpRQ

NEXPRQ

 

integer

 

Requested exposures per data set

dc:nexp

NEXP

end

integer

 

Actual exposures per data set

dc:dataLabel

DHSLABEL

start

string

 

Most recent DHS data label for data to be downloaded to the DHS

dc:calLabel

CALLABEL

 

string

 

Most recent DHS data label for calibration data uploaded from DHS

dc:nframes

NFRAMES

end

integer

 

Frames per data set

dc:svName

 

never

string

 

DHS server host name

dc:svAddr

 

never

string

 

DHS server IP address

dc:bunit

BUNIT

start

string

 

Data units

Units of quantity read from detector array (e.g. "ADU" or "Volts/S").

dc:utnow

 

never

 

TBD

UT now.

dc:utstart

UTSTART

start

string

TBD

UT at exposure start.

dc:utend

UTEND

end

string

TBD

UT at exposure end.

dc:qlStream1

 

never

string

 

Name of run mode Quick Look Display stream for spectral data

dc:qlStream2

 

never

string

 

Name of run mode Quick Look Display stream for NIFS compressed image cube

dc:idleQlStream1

 

never

string

 

Name of idle mode Quick Look Display stream

dc:idleQlStream2

 

never

string

 

Name of idle mode Quick Look Display stream for NIFS compressed image cube

dc:dhsConnected

 

never

boolean

 

Is DHS connected?

dc:dhsHealth

 

never

string

 

Health of DHS data connection. (GOOD | WARNING | BAD

 

Detailed Command Description

A general table of the commands accepted by the NIFS control software, together with their arguments, is given in See NIFS general observing command CAD/CAR records. This section contains a detailed description of each of the commands that can be sent between the OCS and the NIFS control software.

Any directive asserted on the top-level APPLY record will be forwarded to all the CAD records in the sequencer, CC, and DC (perhaps via lower-level APPLY records). Only the marked CAD records will respond. If the directive is accepted it will cause the NIFS control software to change its configuration. The "applyC" CAR record will go "BUSY" while the NIFS control software is changing its configuration and go to "IDLE" if completed successfully or to "ERR" if the configuration change fails.

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

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 VxWorks control tasks which are put into the READY state.

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.

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.

General Engineering Commands
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.

Temperature-controller commands

All temperature-controller commands are part of the engineering interface, and are not within the scope of this document.

NIFS Standard Mechanisms

NIFS has an environmental cover, a filter wheel, a grating turret, a flip mirror and a focal-plane mask wheel.

The following commands will act on all of the above mentioned mechanisms; however, as noted below, the use of certain commands with certain mechanisms is discouraged.

Sel--Select Position by Name

This is the principal interface for all continuous mechanisms. It is provided as a convenience for discrete mechanisms.

On receipt of this command, the NIFS CC control software will:

Ensure an observation is not taking place.

Translate desired position name into an engineering position with the aid of a look-up table.

Look up the expected value for the Hall-effect sensors at the desired position location.

Check to insure that protective interlocks are not set.

Wait until the number of active mechanisms drops below the number of mechanisms that the power supply can support.

Move the mechanism to the engineering position corresponding to the desired position.

Verify that the expected sensor value matches the measured value.

Move--Move to specified Position

This is the principal interface for all discrete components. It is available for continuous components, but is of limited use for normal use of the instrument19.

On receipt of this command, the NIFS CC control software will:

Ensure an observation is not taking place.

Check to insure that protective interlocks are not set.

Wait until the number of active mechanisms drops below the number of mechanisms that the power supply can support.

Move the focus mechanism to the engineering position corresponding to the desired focus.

For some mechanisms, compute the expected values for the Hall-effect sensors.

For some mechanisms, verify that the final hall effect sensors match the expected values.

Park--Park Mechanism

This command is used to prepare a mechanism for instrument shutdown.

On receipt of this command, the NIFS CC control software will:

Ensure an observation is not taking place.

Check to insure that protective interlocks are not set.

Wait until the number of active mechanisms drops below the number of mechanisms that the power supply can support.

Move the mechanism to its parking position.

Verify that the expected sensor value matches the measured value.

The park command is not needed for most NIFS components, and is provided for uniformity.

Datm--Datum mechanism

This command is used to find the datum (home) position which defines the mechanism locations.

On receipt of this command, the NIFS CC control software will:

Ensure an observation is not taking place.

Check to insure that protective interlocks are not set.

Wait until the number of active mechanisms drops below the number of mechanisms that the power supply can support.

Move the mechanism and search for its datum.

Set the hardware datum position.

MoveEng--Set position in engineering units

This command is used to move the component to locations using units that are convenient for working directly with the hardware.

On receipt of this command, the NIFS CC control software will:

Ensure an observation is not taking place.

Check to insure that protective interlocks are not set.

Wait until the number of active mechanisms drops below the number of mechanisms that the power supply can support.

Move the mechanism to the specified engineering position.

The Hall-effect sensors will not be used for confirmation.

 

MoveOff--Offset from current position

This command is used to move the component from its nominal selected position. The units used depend upon the component (and are described in the OffsetUnits SIR)

On receipt of this command, the NIFS CC control software will:

Ensure an observation is not taking place.

Check to insure that protective interlocks are not set.

Wait until the number of active mechanisms drops below the number of mechanisms that the power supply can support.

Offset the mechanism by the specified engineering offset.

The Hall-effect sensors will not be used for confirmation.

Rdtm--Redatum mechanism.

This command provides a quick test that will detect a loss of positioning. It will detect small positioning errors, but can underestimate large positioning errors. Note that for multi-axis components (e.g., the gimbal mirror), the command acts only on the individual mechanisms. It returns an estimate of the difference between the actual datum position and the current datum position (which can occur, e.g., if a mechanism is sticking, being driven too quickly, or being driven with too high an acceleration).

On receipt of this command, the NIFS CC control software will:

Ensure an observation is not taking place.

Check to insure that protective interlocks are not set.

Wait until the number of active mechanisms drops below the number of mechanisms that the power supply can support.

Move the mechanism and search for its datum.

The hardware datum position will be left unchanged. This command returns a value in the RdtmVal record for this mechanism.

This command is neither supported by the flip mirror nor the window cover, because those mechanisms use a home-finding algorithm which is incompatible with this command.

Diag--Diagnose mechanism

This is a quick test that will detect a loss of positioning. It will detect arbitrarily large positioning errors, but will fail to detect small positioning errors.

On receipt of this command, the NIFS CC control software will:

Ensure that an observation is not taking place.

Check to insure that protective interlocks are not set.

Wait until the number of active mechanisms drops below the number of mechanisms that the power supply can support.

Move the mechanism and attempt to verify that the motors and Hall-effect sensors are operating.

If an error is detected, the diagnose command will fail and will return an error code in its CAR record.

NIFS Detector Controller Engineering Commands

NIFS supports the following DC engineering commands:

initSDSU--Initialize the SDSU controller electronics

This command will initialize the SDSU controller electronics using the currently set SDSU parameters. This will include downloading timing and VME DSP codes, setting voltages, setting the video mode, setting the number of samples of digital filtering and turning the power on/off.

On receipt of this command, the NIFS DC control software will:

Ensure an observation is not taking place.

Stop IDLE mode if currently running.

Download the timing DSP code from disk file.

Download the VME DSP code from disk file.

Set voltages vInOffset1, vInOffset2, vInOffset3, vInOffset4, biasGate, vReset, biasPwr, vdda and, vdd.

Set the video mode to either VD1, VD2 or stop.

Set the number of samples to digitally filter.

Turn the power on/off.

Restart IDLE mode if required.

Place the SDSU status value in the replyStatus SIR.

idleSDSU--Start/stop IDLE mode

This command will set the NIFS DC video mode. If enabled, the NIFS detector will run a continuous sequence of, either, reset, expose and read, or reset, read, expose and, read, depending on the video mode. Data will be sent to the IDLE mode quick look displays, if the dataIdle.A CAD parameter is set.

On receipt of this command, the NIFS DC control software will:

If an observation is taking place, then flag IDLE mode as on or off.

Otherwise:

If currently in IDLE mode, then switch off if required.

Else, switch on if required.

Place the SDSU status value in the replyStatus SIR.

rdmSDSU--Read SDSU controller memory location

This command is used to read back a value from an SDSU controller memory location. It is used for confirmation of correct set up of the controller.

On receipt of this command, the NIFS DC control software will:

Ensure an observation is not taking place.

Stop IDLE mode if currently running.

Perform the SDSU RDM instruction for the required memory location and memory bank.

Place the SDSU status value in the replyStatus SIR.

Place the result in the rdmVal SIR.

Restart IDLE mode if required.

wrmSDSU--Write to an SDSU controller memory location

This command is used to write a value to an SDSU controller memory location. It is used for poking specific values to controller addresses directly for testing puposes.

On receipt of this command, the NIFS DC control software will:

Ensure an observation is not taking place.

Stop IDLE mode if currently running.

Perform the SDSU WRM instruction for the required memory location and memory bank.

Place the SDSU status value in the replyStatus SIR.

Restart IDLE mode if required.

Detailed Status information
General records
name

This record contains a string constant describing the name of the instrument. For NIFS this record will contain "NIFS".

state

This record will take the values BOOTING, INITIALISING, RUNNING and CONFIGURING20 and reflect the state of the NIFS control software while it is initializing. The activities corresponding to these states are

  • BOOTING -- the state during IOC Init and while any database default values are being set.
  • INITIALISING -- the NIFS control software is checking its own hardware and reading its hardware configuration files during this phase.
  • RUNNING -- the NIFS control software is ready to accept commands.
  • CONFIGURING -- the NIFS control software is ready to accept commands but it is busy configuring and unable to make observations.
health

This record will reflect the overall health of the NIFS control software (including the components controller and the detector controller). Expected values are GOOD, WARNING or BAD. If the overall health is BAD then the NIFS control software is unusable. If the Health is set to WARNING then the NIFS control software is able to execute some functions but not perhaps to specification.

historyLog21

The record used to contain messages to be recorded in the history log.

dcAbort

Indicates that an exposure is being aborted..

debugMode

This record contains a string indicating the current debugging mode.

heartBeat

This record is a simple incremental counter, whose changing value indicates that the IS is still alive.

issPort

The record which reports the ISS port on which the insturment is installed..

label

This record contains a string constant describing the name of the instrument. For NIFS this record will contain "NIFS". This is the same as the "name" record.

simMode

This record contains a string indicating the instrument's simulation mode.

wfsBeam

Indicates whether the OIWFS beam is obstructed or not..

 

Component Status Records
Datumed

This record indicates that a component has been datumed. For multi-axis components, this flag will only be set if all mechanisms have been datumed. This record takes on the following values:

  • 0 = Datumed
  • 1 = Not Datumed
EngCyclic

This record indicates that a mechanism may be set to a location beyond its physical limits (convenient for circular mechanisms like filter wheels). Note that this only affects the higher level commands; the low-level software may choose to ignore any invalid requests. This record takes on the following values:

  • 0 = Limits can be exceeded
  • 1 = Limits may not be exceeded

This record is for internal use by the NIFS software. Its value should not be changed. It is documented here only for completeness.

EngMax

This record contains the maximum position that the mechanism can be moved to, in engineering units.

EngMin

This record contains the minimum position that the mechanism can be moved to, in engineering units.

EngName

This record contains the engineering name of the current mechanism position. This represents a physical configuration of a component, and will never change (unlike the "Name" record which may change, if filters or other optical elements are replaced or rearranged). The names of the positions are:

  • park;
  • home;
  • pos00, pos01, pos02, ... , up to the maximum number of positions;
  • INVALID (if not in a standard location).
EngPos

This record contains the current position of a mechanism, in engineering units.

Label

The FDSC field of this record contains a text string which describes a component. This is convenient in providing a title string for edd/dm screens.

Max

This record contains the maximum position that the mechanism can be moved to, in real-world units. A text string describing the real-world units may be found in the Units record. For mechanisms such as a filter wheel in which there are no appropriate units, the position will typically be given as a position number, i.e., position 0 is 0.0, position 1 is 1.0.

Min

This record contains the maximum position that the mechanism can be moved to, in real-world units. A text string describing the real-world units may be found in the Units record. For mechanisms such as a filter wheel in which there are no appropriate units, the position will typically be given as a position number, i.e., position 0 is 0.0, position 1 is 1.0.

Name

This record contains the name of the current component position. This name typically describes a filter or other optical element and will be redefined if filters or other optical elements are replaced or rearranged (unlike the "EngName" record which describes a component's physical configuration).

Note that for multi-axis components, there will be a Name record for each individual mechanism, as well as for the component as a whole.

Parked

This record indicates that a component is in a parked state. For multi-axis components, this record will be set only if all mechanisms are parked. This field takes the values:

  • 0 = All mechanisms parked;
  • 1 = Not all mechanisms are parked.
Pos

This record contains the current position of a mechanism, in real-world units. A text string describing the real-world units may be found in the Units record. For mechanisms such as a filter wheel in which there are no appropriate units, the position will typically be given as a position number, i.e., position 0 is 0.0, position 1 is 1.0.

RdtmVal

This record contains the result of the last redatum command, in engineering units. (The redatum command returns an estimate of the how far the current mechanism datum position is from the actual datum position; it is useful in diagnosing hardware problems.)

Reject

This record contains a combination of the values of all CAD records for all mechanisms that make up a component. It contains the following values:

  • -1 = At least one CAD record is in a reject state;
  • 0 = No CAD records are in a reject state.

This record exists as a convenience for the user interface. There is no reason for the OCS to use it. It is documented here only for completeness.

State

This record contains a string which describes the current state of the mechanism-support code.

This record is for debugging the NIFS software. The possible values that this record may take may change, without notice. It is documented here only for completeness.

Units

This record contains a text string which describes the real world units (e.g., "mm" or "arc sec")

Component Health Records

All of these records return the standard health values: "GOOD", "WARNING", and "BAD".

DatumHealth

This record reports "WARNING" if a mechanism (or if any mechanism of a multi-axis component) is not datumed. It is cleared by successful execution of a datum command.

HallHealth

This record reports "WARNING" if a Hall-effect sensor has been disabled. (The sensors can only be disabled from the engineering user interface, and are normally disabled only to deal with a failed sensor.)

This record reports "BAD" if both sensors of a Hall-effect sensor pair have been disabled. Note that a mechanism is still usable if both sensors are disabled, but cannot be datumed. (The sensors can only be disabled from the engineering user interface, and are normally disabled only to deal with a failed sensor.)

Health

This record reports the most severe error value of all other health records.

ModuleHealth

This record reports "BAD" if the stepper-motor driver module has entered a fault state. This normally indicates a serious hardware problem. It may be possible to clear the error state by issuing a driver-reset from the engineering user interface. If it is not possible to clear the error, then the stepper-motor driver module or other related hardware has failed, and must be repaired.

PosErrHealth

This record reports "WARNING" if a mechanism (or if any mechanism of a multi-axis component) has been moved in such a way that proper backlash correction has not been made. In this case, the reported mechanism position may not be the actual mechanism position. This situation can arise if a movement command has been canceled while a motion is in progress; if a movement command failed to complete correctly, if certain low-level engineering commands are executed, and immediately after the control software has been rebooted. It is cleared by successful execution of any motion command.

SnlHealth

This record reports "BAD" or "WARNING" if the underlying mechanism support code detects an error while a mechanism is in motion. The only situation which is likely to arise is "WARNING", if an operation takes longer than expected.

Temperature Monitoring and Control Status Records
C1Setp, C2Setp, C3Setp, C4Setp

These records report the current set-point temperature which for each temperature controller.

C1Tmp, C2Tmp, C3Tmp, C4Tmp

These records report the current temperature which is reported by each temperature controller.

CoolBusy

This record returns one of the three strings: "Off", "High", or "Low", to indicate whether the cooling motors are off or operating at high or low speed.

CoolRate1

This record returns the rate of cold-cycle cooler 1, in microsteps per second.

CoolRate2

This record returns the rate of cold-cycle cooler 2, in microsteps per second.

Label

The FDSC field of this record returns a string describing the temperature control and monitoring system, for use in the title of edd/dm screens.

S1Tmp1, S1Tmp2, S1Tmp3, ... , S1Tmp8

These records report the current temperature which is reported by each temperature sensor which is connected to the temperature-sensor controller.

Temperature Monitoring and Control--Health Records

All of these records return the standard health values: "GOOD", "WARNING", and "BAD".

C1Health, C2Health, C3Health

This record will report "BAD" if a temperature controller is not functioning properly. This can indicate either a communications problem, a hardware failure with the temperature controller, or a faulty temperature sensor.

CoolModeHealth

This record will report "BAD" if the cooling motors are off, when the instrument should be cold, or if the cooling motors are on, when the instrument should be warm.

Health

This record combines all of the other heath records for the temperature control and monitoring subsystem, and reports the most severe condition.

ModeHealth

This record will report "BAD" if the external mode-selector connector is not in the appropriate position for normal operation. (If the connector is in the "warm-up mode", the motors cannot be operated.)

S1Health

This record will report "BAD" if the temperature sensor unit is not functioning properly. This can indicate either a communications problem or a hardware failure with the temperature sensor unit.

TmpCheckHealth

This record will report "BAD" if any temperature is unreasonably high while the system is expected to be cold or if a temperature is too low, while the system is expected to be warm.

Detector Controller Status Records
Prep

This record indicates that the DC is preparing to make an observation.

Acq

This record indicates that the DC is making an observation. The instrument mechanisms should not be reconfigured during this period.

Rdout

This record indicates that the DC is reading out its data. If acq is also set to TRUE then the detector is also still exposing otherwise the instrument may reconfigure its mechanisms.

detType and detID

For NIFS these will be a strings like "Rockwell Hawaii II, SDSU II" and "TBD".

timingDSP and timingDSPVersion

The name and version number of the current timing DSP code filename..

VMEDSP and VMEDSPVersion

The name and version number of the current VME DSP code filename..

vInOffset0-4

Video input channel offset voltages for channels 1-4.

vReset

Control signal for resetting all pixels.

biasGate and biasPwr

Gate and source voltages of bias P-FET.

vdda and vdd

Analog high and digital power voltages.

videoMode

NIFS idle video mode. This will be either be VD1, VD2 or, STP (stopped).

VD1. The detector will be continually reset, exposed and, read.
VD2. The detector will be continually reset, read, exposed and, read.
STP. The detector will be truly idle.
nFilterSamples

Number of ADC conversion samples per pixel to use for multiplexer glow (read noise) reduction.

nRefSamples

Number of reference circuit samples per row (or column) to use for residual drift reduction.

replyStatus

Each SDSU command results in either a DON or ERR status. This is recorded here for the latest SDSU command..

nTestErr

For the TEST sequence, SDSU controller to VME communications can be tested using the SDSU TDL command. This record holds the number of errors recorded in the last TDl sequence..

rdmVal

This record hold the value read back from the specified SDSU controller memory location.

expMode

This will be always "NONDESTRUCTIVE" for NIFS.

timeLeft

Time remaining in current exposure.

nreads and readInterval

Number of non-destructive reads (NDR) per exposure and the period between each NDR.

nresets and resetInterval

Number of detector resets between each exposure and the time delay to allow detector to reset.

ncoadds

Number of NDRs that are co-added before performing the next exposure mode processing step.

exposedRQ, exposed and elapsed

The requested total exposure time, actual exposure time recorded and the elapsed time between the detector reset at the beginning of the exposure and the finish of the final NDR. For NIFS exposed should equal elapsed.

daqState

Current state of the detector - either IDLE, OBSERVING or, READOUT. Depending on the NIFS run mode and on whether IDLE videoMode is set on, this record will cycle as follows:

IDLE mode with videoMode set to VD1 or VD2
IDLE - READOUT - IDLE - READOUT ...
RUN mode
IDLE - OBSERVING - READOUT - OBSERVING - READOUT ... IDLE
dpMode

This is the mode that is used to produce the final image intensities. NIFS supports double-correlated sampling, Fowler sampling and linear fitting (i.e., DCS | FOWLER | LINEAR). Refer to See "NIFS Conceptual Design Review Vol 1", Research School of Astronomy and Astrophysics, Australian National University and See "NIFS Critical Design Review Vol 1", Research School of Astronomy and Astrophysics, Australian National University for a complete description of each mode.

nexpRQ and nexp

The requested number of exposures (NDRs) and the actual number of exposures recorded for the data set.

dataLabel and calLabel

Most recent DHS data label that has been downloaded to the DHS. And the most recent calibration label requested from the DHS for using in producing the compressed spatial image for quick-look display. calLabel is also used by the raw-image quick look tool for subtracting from dataLabel.

nframes

The number of frames in a NIFS dataset - this will be always be 16, including 4 frames for each quadrant of the detector. These will be intensity, variance, quality and reference frames.

svName and svAddr

Host name and IP address of the DHS server.

utnow, utstart and utend

UT now, UT at exposure start and UT at exposure end.

qlStream1, qlStream2, idleQlStram1 and idleQlStream2

Quick-look streams for RUN and IDLE modes. qlStream1 for each mode is used for the NIFS spectral data display. It will be set to subtract calLabel from each NIFS raw image. qlStream2 for each mode is used to display the compressed spatial image.

dhsConnected

This will be set TRUE if the DHS is being used and connected.

Detector Controller Health Records

All of these records return the standard health values: "GOOD", "WARNING", and "BAD".

Health

This record reports the most severe error value of all other health records.

dhsHealth

This record reports the health of the DHS connection.

Alarm conditions

The following situations will generate an alarm.

  • Hall effect sensor disabled
  • Motor-control module fault
  • Mechanism not datumed
  • Mechanism not backlash corrected
  • Problem detected by SNL code (time-out)
  • Temperature changing
  • Temperature out of range
Debugging and Maintenance

This interface can be tested and debugged by means of an engineering user interface supplied as part of the NIFS.

Debugging Modes

The NIFS control software will have the standard debugging modes described in ICD 1a, See gscg.kkg.009, "ICD 1a -- The System Command Interface", Kim Gillies, NOAO..

Calibration

If a Hall effect sensor fails or if a mechanism must be disassembled for maintenance, the sensors will need to be recalibrated. A separate program is provided for this purpose. Calibration procedures are described in a separate document See "NIFS Software Maintenance Manual" - To be written, Research School of Astronomy and Astrophysics, Australian National University.

Simulation

The Gemini simulation modes are described in ICD 1a, See gscg.kkg.009, "ICD 1a -- The System Command Interface", Kim Gillies, NOAO.. The NIFS control software will use the FAST and FULL modes, and by default it begins in "NONE" mode. VSM mode may be supported, if time permits.

Safety Issues

It is necessary to avoid moving NIFS components while the mechanical components are not at thermal equilibrium. NIFS uses records to provide a temperature interlock.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

This page intentionally left blank

1. All interlock commands are available from within the components controller, by using a nifs:cc: prefix, instead of the nifs:wfs: prefix.

2. "(none)" means that there are no arguments

3. Currently, it is required to have separate TestC, InitC, etc. CAR records. There is some disagreement over this requirement, and all of these CAR records may disappear, to be replaced by the global applyC.

4. "(none)" means that there are no arguments

5. Equivalent to closing the window cover.

6. Used for performing image cube compression over a selected wavelength range.

7. The detector is read out a number of times during the integration, this parameter allows each readout to be saved temporarily to the DHS or FITS server.

8. "(none)" means that there are no arguments.

9. "(none)" means that there are no arguments.

10. "(none)" means that a command accepts no arguments

11. Only the standard positions (excluding datum and park) are repeatable.

12. This is strongly discouraged . Only the standard positions (excluding datum and park) are repeatable. The predefined locations are only stable when approached in the correct fashion.

13. "(no operation)" means that this command is accepted but no action is performed,

14. "(none)" means that there are no arguments.

15. This record is not particularly useful, because of various EPICS limitations.

16. This record is not useful, because of various EPICS limitations.

17. The cc:wfsBeam record only indicates whether any components controller mechanisms are obstructing the wavefront sensor. For most purposes, wfsBeam (which combines cc:wfsBeam and wfs:wfsBeam) should be used.

18. "(tbd)" means that the mapping from user positions to engineering positions has yet to be determined.

19. For discrete mechanisms, the units are position numbers; i.e., the first position is at 1.0, the second position is at 2.0.

20. Currently unimplemented

21. Currently unusable