SDN0002

SYSTEM DESIGN NOTE

SDN0009.01 – Engineering Test Software Functional Requirements

Prepared by	Date	Approved by	Date	Rev.	Rev Date
Jay Elias	7/12/99	N. Gaughan	7/21/99

1. Introduction

The purpose of this document is to describe that functionality required of the engineering test software, which is to be used for testing GNIRS at NOAO.

2. Required Functionality

2.1 Mechanisms

2.1.1 Configuration

The software should be capable of reconfiguring the instrument. That is, it must move one or more mechanisms, each from a known position to another (specified) position. The mechanism motions should all be simultaneous (or nearly so) unless there are limitations set by motor driver power supplies or mechanical interference. If such limitations exist, the software should attempt to maximize efficiency by moving as many mechanisms simultaneously as possible.

Mechanism positions for this purpose are specified as numbered mechanism positions for discrete positions (e.g., filter 7 in filter wheel 2). For the two mechanisms which can be set continuously (focus and grating), the configuration is set as step from home for focus, and as grating ID plus steps from nominal for grating tilt (that is, grating 2, 12345 steps from nominal).

There is no requirement that configurations include automatic (look-up table) adjustments for focus or other small corrections. That is, if going from camera A to camera B requires a focus shift of 100 steps, the user would have to include that shift in the new configuration.

Ideally, the configuration would be a file or parameter set that is edited to specify parameters; the command to reconfigure then refers to file rather than specifying the details of the configuration.

2.1.2 Mechanism Control

The individual mechanism functionality outlined in SDN002.14 should be available. This includes the ability to find datum (home), check datum, use alternate datum, jog (adjust) position as well as basic positioning with backlash removal.

The basic algorithms developed for mechanism control must be coded and documented so that they can be used in the Gemini engineering software.

Control should include software checks of mechanism limits where they exist.

2.1.3 Initialize

A command to globally initialize the motors should be available.

2.1.4 Scripting

A limited ability to issue sequences of commands is required. It can be as basic as generating the sequence through text editor output into a file, and then executing the file. This implies the ability to wait until a command has completed before executing the next.

The ability to wait (“sleep”) a specified number of seconds during a script is extremely useful.

2.2 Sensors

2.2.1 Temperature

The software should have the ability to display the output from the temperature sensors located in the instrument. Output in volts is sufficient.

2.2.2 Pressure

The software should have the ability to display the output from the pressure gauge(s) in the instrument. Output in volts is sufficient.

2.2.3 Sensor Data Logging

The software should have the ability to log data from the sensors to a file. At a minimum, it would log the data from all sensors to a file at fixed time intervals, where the interval would be hard-coded. The ability to adjust the interval is strongly desired, but if the interval is fixed it should be a reasonable value – perhaps a minute.

2.3 User Interface

The user interface can be as simple as a command-line interface. Any effort expended on a more elaborate interface (GUI, data display screens) should be minimal (zero to first order) unless the code can be used in producing deliverable software (Gemini engineering software). A status screen would be more useful than a GUI.

3. Desirable Functionality

3.1 Mechanism Control

For the control of mechanisms, it would be desirable to specify grating tilt in degrees and not steps, focus in microns from home, and not steps, and to have the software return a position name from a look-up table for discrete positions. The look-up table could also contain the information on interference, if there is any. (The ability to edit this safety information is also a potential hazard, and one of the main reasons why there are mechanical limit switches.)

It would also be useful to be able to log configuration information in conjunction with the execution of scripts or logging of sensor data. This could take several forms. Recording the time and the mechanism positions whenever a mechanism or configuration commands was completed would be adequate.

Note that the Gemini engineering software must handle all the conversions from scientifically interesting positions (wavelength, filter names) to mechanism positions in steps, so it is worth including this level of functionality in the engineering test software, provided that the code can be re-used (or largely re-used) in the Gemini software.

3.2 Sensor Data

Useful options for sensor data logging would be the ability to log only a subset of the sensors (if the others are of no interest) and the ability to specify the time interval at which data are logged. The fastest rate at which data might be logged is once every few seconds (at most); the need for speed should not drive the software design.

3.3 Array Controller Interface

The requirements above do not include an interface to the array controller. Thus, in the minimum case, the user must issue commands to the instrument controller, wait for them to execute, then issue a command to the array controller, wait for that to execute, issue another command to the instrument controller, etc.

This lack of coordination may even be useful at times (one could do a long integration while scanning the grating turret to look for odd reflections, for example). For most testing, however, the ability to sequence commands to both controllers would be useful, in that it would allow execution of scripts that include data taking. (In the situation mentioned above, one would get greater sensitivity by scanning the grating in ½ degree steps and taking a 30 second exposure at each position – but one would just as soon not have to sit and issue individual commands for each step of the sequence.)

3.3.1 Header Information

For ease of analysis, it would be useful to include in the image header information on instrument configuration, including sensor data. For an initial implementation, it does not matter much if excess information is included (there are, after all, several megabytes in the image itself).