NRAO Home  >  Green Bank  |  Wiki Topic:    GB > Software > PlanOfRecordC32006 > ModificationRequest1C306
   Changes | Index | Contents | Search | Statistics | Go

Complete Zpectrometer Manager

Modification Request 1C306 (C3 2006)

1. Introduction

This MR is for the creation of a M&C Manager for the Zpectrometer. By creating such a Manager, we will be able to fully integrate the Zpectrometer with the rest of the GBT M&C system, which will streamline observations with this instrument.

2. Background

The Zpectrometer is an ultra-wideband spectrometer being built by the University of Maryland for use with the GBT and its Ka-band receiver. For more information, see the NRAO Zpectrometer Wiki.

The details on integrating Zpectrometer data reduction into the GBT can be found at ModificationRequest4C406.

3. Requirements

The monitor and control of the Zpectrometer shall be integrated into the GBT system seamlessly.

A list of the keywords required for the WASP data product can be found in the "Keywords for WASP Data Product" document.

Of those keywords, only the following are of interest for integrating control of the Zpectrometer into the GBT and will translate directly into control parameters (explanations drawn from "Keywords for WASP Data Product":

The following keywords are important, but do not require control parameters. Instead, they will be read by the manager from the manager's configuration file and set through the 'waspset' utility.

4. Design

The Zpectrometer is controlled by a collection of individual command-line programs written at the University of Maryland for interactive use by expert users. The goal of the Zpectrometer manager is to act as a middle-ware component between the GBT M&C system and this wasp2 software interface. The consistent interface used by all wasp2 programs makes this practical.

The Zpectrometer manager will set the wasp2 keywords to their appropriate values and run these wasp2 programs to control the Zpectometer. In keeping with the M&C design philosophy, the Zpectrometer manager will be the master when it comes to setting up the keyword values for the wasp2 environment. It will do this by reading a base (or default) set of values from its configuration file, Zpectrometer.conf, setting up the wasp2 parameters database accordingly, and modifying these values as needed to perform observations.

4.1. WASP2 source

A revision of the wasp2 source tree will be placed in the M&C source tree, within the Zpectrometer manager source directory but under U. of Maryland CVS revision control until development stabilizes. Updates to the wasp2 software can be made by entering the 'gbt/devices/backends/Zpectrometer/UMD' source directory and typing 

$ make wasp2

This will cause an anonymous CVS connection to be made to the U. Md. CVS server to obtain/update the wasp2 source. The makefile then runs 'autoconf' to make a configure file, configures the make, and builds the tree.

Installation is accomplished by typing, in the same directory as above: 

$ make install

To clean the source tree and execute a fresh build: 

$ make clean && make wasp2

To remove the directory entirely: 

$ make remove

Typing make alone, with no target, is a NOP. This ensures that makes in this directory happen only when specifically intended, and not, say, during every nightly build of the M&C source tree.

4.2. WASP execution environment

The wasp2 executables are designed to work within a directory named wasp2. This directory will be installed in the /home/gbt/bin/Zpectrometer directory, and the WASP environment variable will be set to /home/gbt/bin/Zpectrometer.

4.3. NEMO library

The wasp2 software relies on the NEMO library to compile and to run. The NEMO library will be installed in the /home/gbt1 directory. This directory will be specified by the NEMO environment variable.

4.4. How does the wasp2 Software Work?

4.4.1. Wasp2 Interface

The wasp2 software, as mentioned above, consists of a suite of command line programs. These programs serve to set up the wasp2 hardware, calibrate the instrument, and conduct observations. In order to maintain state between calls to the various programs, the wasp2 software can save configuration values to a persistent database, in the flat ascii file $(WASP)/defs/parameters.

Wasp2 requires that the proper environment be set:

All the wasp2 programs are invoked using a syntax of 

  '<program> <key>=<value> <key>=<value> ...'
where program is the program name (waspset, totpwr, zero, etc.), key is the keyword name, and value is the keyword's value.

All of the programs will give a list of parameters accepted by it when the help parameter is given: 

  '<program> help'
or 
  '<program> help=h'
or 
  '<program> help=t'

The first will give a brief summary. The second and third will give a comprehensive list with descriptions, defaults, etc., but in different formats.

Keywords generally may be given to the wasp2 program directly on the command line, or saved first to the wasp2 database using the waspset program. In the latter case, the wasp2 program will obtain the value needed from the database. If the value is given directly, it will override the database value, but the new value will not be written to the database (this is done only by waspset).

There is a very small set of keyword/value pairs that can only be provided on the command-line, using the same syntax as given above; these are specific to the program and are not a part of the wasp2 set of keywords. For example, repeat=1 tells the particular program to run one iteration and exit.

4.4.2. WASP2 API class

The manager will communicate with the wasp2 software through a C++ class called WASP2. The WASP2 class' purpose is:

The WASP2 class communicates with the wasp2 system using the C library popen() function, providing parameters on the command line as needed, and reading the output and return value of the wasp2 programs.

A call to popen() blocks until the program called terminates. This makes it difficult to use the stop and abort features of the manager. To solve this problem, the WASP2 class runs all program requests except for waspset in separate threads. The manager may then call the WASP2 wait() or done() functions to synchronize with the WASP2 threads. These functions also throw exceptions if an error occurred. This arrangement allows the manager to operate its state sequencer during long scans, all the while checking on the progress of wasp2 operations.

If the manager is required to abort a scan, it terminates the wasp2 program currently running by sending it a SIGTERM signal and waiting for it to terminate.

On creation, the WASP2 class sets up the WASP, WASPDATA, and NEMO environment variables. (These values are obtained by the manager from its configuration file.) In addition, the WASPDATA variable is changed to reflect the current GBT project, to ensure that the wasp2 fits files are written to the proper project directory.

4.5. Control (Parameters)

These are the parameters used to control the manager's operation. Parameters in boldface italic are parameters inherited from the Manager base class and thus common to all managers. The parameter link may be followed to obtain more detailed information on the parameter.

4.6. Monitoring (Samplers)

The Zpectrometer backend micro-controllers provide 8 data monitor points via a TCP connection on port 5150. The way this functions is that the TCP client provides a string (any string will do, as long as it does not consist solely of a newline) to this port, and the micro-controller will respond with a string containing the data arranged in 8 fields. This string looks like this:

The manager will run a monitor task whose function is to request this information at regular intervals, parse the values from this message string, and post them to the system's Transporter through the Ygor sampling mechanism.

The sampler, BackendMonitorData, will consist of an array of 4 elements (1 based, one per backend), each element containing a structure of 8 floats; each field corresponding to a field in the micro-controller monitor string above. The sampler field names (with the Zpectrometer field names in parentheses) are:

For example, if one wished to access the correlator temperature value for the 3rd backendsampler using Grail's 'get_sampler_value()' API, one would specify the field as follows:

Likewise, to access it through Cleo DeviceExplorer, one would select the 'BackendMonitorData' sampler, and the '3,tCorl' field in the Sampler Field list-box.

The monitor rate used by the manager is controlled by the manager's backendMonitorRate parameter, an enumeration which supports sampling intervals of: 100, 200, 500 mS; 1, 2, 5, 10, 30 seconds; 1, 2, 5, 10, 30 minutes; and 1 hour.

4.7. Messaging

The Zpectrometer micro-controllers provide a message facility which can be available to a client through subscription over a UDP port. The manager may be upgraded in the future to use this facility if it is deemed necessary. Otherwise it is available through the wasp2 utility 'utelnet.'

4.8. Are the cals firing?

The gbtstatus application uses the cal_states array Parameter in order to determine if the cals for the receiver in use are firing. If any value in the cal_states array is "Noise," then the status for the cal will be "On."

4.9. Manager Configuration File

The manager has a configuration file called Zpectrometer.conf. Among other things, this configuration file serves these two purposes when the manager is started up:

There are no restrictions on the keyword/value pairs that can be placed in this configuration file, provided the keyword exists in the wasp2 parameters file; the manager reads them and dutifully passes them on to the waspset utility. For this reason, the sample configuration file above includes all known keywords and their default values. This provides a central, unique location to set up the Wasp2 database to an acceptable default state.

4.10. Manager States

The Manager inherits all its states from the parent class. The complete list of states are: Off Standby Ready Activating Committed Running Stopping Aborting NotInService. Only a subset of this list is of interest here.

4.10.1 Off

When in this state, the manager will not run the wasp2 software or participate in scans, nor will it communicate with the Zpectrometer backends in order to monitor voltages and temperatures. The manager placed in an 'Off' state when it is turned off. In Astrid, SetValues("Zpectrometer", {"state":"off"}).

4.10.2 Standby

When in this state, the manager will not run the wasp2 software or participate in scans, but it will monitor voltages and temperatures. The manager can be placed in 'Standby' from Astrid by calling SetValues("Zpectrometer", {"state":"standby"}).

4.10.3 Ready

When Ready, the manager can participate in scans, accept parameter updates, run the wasp2 software, and monitor voltages and temperatures. The manager is Ready when it is turned on. From Astrid, SetValues("Zpectrometer", {"state":"on"}).

4.10.4 Activating

When a scan is started (usually by the ScanCoordinator), the manager enters the Activating state. While activating, the manager computes its earliest start time and negotiates the actual start time with the ScanCoordinator. The ScanCoordinator will then issue the actual start time based on the latest starting time given to it by the managers that are included in the scan.

The Zpectrometer manager determines its earliest possible start time by allowing ~5 seconds for backend initialization. Once it gets its actual start time from the ScanCoordinator, it will immediately start the wasp2 observation program with the stime=SEC parameter, where SEC is the target start time in the standard Unix format of seconds since midnight, Jan 01 1970: 

totpwr stime=1165597218

The observation program, either 'dobs' or 'totpwr', will configure the backends and wait for the start time.

4.10.5 Running

The Manager will enter the Running state when the start time rolls around. During the running state it will check on the execution status of the wasp2 observation program it spawned, and will remain in the Running state until the observation program terminates.

4.10.6 Stopping

The Manager will enter the Stopping state when the wasp2 observation program it spawned terminates. While in the stopping state, the manager will copy the 'cwsigs' data file from the specified directory (see cwsigsLoc), if the observation program was 'totpwr' or 'dobs'.

4.10.7 Aborting

If, during the Running state, the manager terminates the scan abnormally, it will enter the Aborting state. This may happen for the following reasons:

The first occurs if one of the manager's parameter check functions detected an illegal value. The value should be corrected before attempting to start the manager again.

The second occurs if the the wasp2 program being run returns a non-zero value. This indicates that it experienced an error condition. The output from the wasp2 software is saved and printed to stderr or the device log file, and also sent as a message.

The third possibility is that the user wishes to terminate a scan prematurely. In this case, the manager kills the wasp2 observation program by sending it a SIGTERM signal.

4.11. Data

The Zpectrometer Manager does not have to generate FITS files. Instead, these are generated by the wasp2 software. The Zpectrometer Manager must however provide the full path and names of the desired FITS files. It will do this by setting the WASPDATA environment variable to the appropriate project directory, and by setting the FITSFILE keyword to the desired filename

4.11.1. WASP Data

The wasp2 software saves its data and calibration FITS files in a directory specified in the environment variable WASPDATA. This variable will be set by the Manager to the appropriate project directory at the start of each scan. The Manager will handle all calibration files as appropriate (see below).

By convention all data products of the GBT are stored in in a directory named the same as the Manager that produced them. This directory resides within a directory named after the project ID. This in turn resides within a directory indicated by the YGOR_DATA key found in the system.conf system configuration file. For the GBT system, this key is set to /home/gbtdata. Thus Zpectrometer data files will be found in a directory structured as follows: 

<YGOR_DATA>/<PROJ_ID>/Zpectrometer

A typical data directory: 

/home/gbtdata/T_ZPEC_29NOV06/Zpectrometer

4.11.2. CWSIGS Calibration

The manager allows the 'cwsigs' program to be run to do a frequency calibration of the Zpectrometer. The 'cwsigs' program controls the GBT's LO1B to produce a varying test tone during this procedure. The data produced by 'cwsigs' is then written to the current project directory, as with all other Zpectrometer measurements. The parameters to set to run 'cwsigs' are:

4.11.3. Using CWSIGS data

The manager allows the observer to specify which CWSIGS file to include in the data set for data reduction purposes. The observer specifies this by setting two fields in the 'cwsigsLoc' manager parameter. The fields are:

Once these names are specified, the manager will copy the specified file from the specified project directory to the current project directory at the end of a scan, unless:

  1. The file already exists in the current project directory, or
  2. The specified project directory and the current project directory are the same.

The manager will not copy any 'cwsigs' data files if either of these strings are either empty ('') or set to 'undefined').

5. Deployment Checklist

6. Test Plan

6.1 Development Testing

The interface between the manager and the wasp2 software allows a great deal of development testing to be done by inspection. When the manager is started in 'simulate' mode (see Zpectrometer.conf), the manager will print out the command lines that it would normally execute instead of executing them. These can be compared with the wasp2 documentation for correctness.

6.2 Simulator Testing

Prior to use with the real Zpectrometer instrument the manager will be tested as much as is possible on the SDD simulator. The wasp2 software itself allows a great deal of simulation; in addition, at least one simulated backend includes a Coldfire microprocessor board like the ones used in the actual backends.

6.3 Integration, Regression, and Sponsor Tests

The Zpectrometer is not yet a production instrument. Thus the manager will not receive integration, regression and sponsor tests in the same fashion that production managers do. Instead, the manager necessarily will be tested along with Zpectrometer hardware tests and wasp2 software tests. Because of this it is to be expected that the manager will be patched often as problems are found and new needs arise.

7. Additional Documentation

Signatures

APPROVED: I acknowledge that my request is fully contained in this MR, and if the SDD delivers exactly what I specified, I will be happy.

ACCEPTED: I acknowledge that I have validated the completed code according to the acceptance tests, and I am happy with the results.

Written ALERT! - RamonCreager - 5/17/2006
Checked symbol - name - date
Approved by Sponsor symbol - name - date
Approved by CCC symbol - name - date
Accepted/Delivered by Sponsor symbol - name - date

Symbols:

CCC Discussion Area

Appendix A - Parameter Reference

This section documents each of the managers parameters. Many parameters will not be of interest to the observer, but are included here for completeness.

Many of the manager's parameters operate simply by setting the appropriate wasp2 keyword. This will be indicated when this is the case, with the corresponding keyword given in UPPERCASE ITALICS. A better understanding of these parameters can be obtained by consulting "Keywords for WASP Data Product". In fact, many of the descriptions for these parameters are drawn from this document.

Where applicable, examples of how to set or read the parameters from Astrid scripts are given. Please consult the Observing Directives documentation carefully before using these examples. Of particular note is that the 'GetValue()' (note no 's') directive always returns a string. This must be converted to the proper type by the user of the observing script. Also note the syntax of the 'SetValues()' directive. Complex parameters must be set at the lowest field level. However, 'SetValues()' is capable of setting more than one value per call, using a dictionary to store the parameter fields and values to set them to. This example sets all the fields of the first two elements of the cwsigsParams parameter in one call: 

SetValues("Zpectrometer", {"cwsigsParams,1,enable":"true", \
                           "cwsigsParams,1,startFreq":25300, \
                           "cwsigsParams,1,endFreq":39900, \
                           "cwsigsParams,1,increment":8, \
                           "cwsigsParams,1,attenuation":15, \
                           "cwsigsParams,2,enable":"true", \
                           "cwsigsParams,2,startFreq":25300, \
                           "cwsigsParams,2,endFreq":39900, \
                           "cwsigsParams,2,increment":8, \
                           "cwsigsParams,2,attenuation":15})

Note the syntax used to specify the parameter field to set. This notation is also used to get a value using 'GetValue()'; note also the notation used to set a Python dictionary.

Most of the parameters are read/write, except where indicated. Therefore the 'SetValues()' and 'GetValue()' directives may both be used on the parameter. In those cases, the example given is usually a 'SetValues()' example.

asap

Type: bool
Unit: N/A
Values: 'false', 'true' or 0, 1
Array Count: N/A
Description: Controls whether the manager starts as soon as possible.
Example: SetValues("Zpectrometer",{"asap":"true"})

atten

Type: float
Unit: dB
Values: 0-63
Array Count: 4
Description: The value of the attenuator for each backend, set before a calibration load measurement. Each element in the array represents one backend and sets the corresponding ATTEN# keyword.
Example: SetValues("Zpectrometer", {"atten,1": 7})

backendMonitorRate

Type: Enum (Int)
Unit: N/A
Values: mr100MS mr200MS mr500MS mr1Sec mr2Sec mr5Sec mr10Sec mr30Sec mr1Min mr2Min mr5Min mr10Min mr30Min mr1Hr
Array Count: N/A
Description: Rate at which monitoring data is obtained from connected backends.
Example: SetValues("Zpectrometer", {"backendMonitorRate":"mr1Sec"})

beclip

Type: structure: Values: 1-9999
Array Count: 4
Description: Array of 4 structures, one per backend. Each structure has two int fields, rangeStart and rangeEnd. Backend active channel range. Assuming backend 2, rangeStart = 1, rangeEnd = 9999, sets the BECLIP# keyword to BECLIP2=1:9999
Example: SetValues("Zpectrometer", {"beclip,2,rangeStart":1, "beclip,2,rangeEnd":9999})

chopfreq

Type: double
Unit: Hz
Values:
Array Count: N/A
Description: Chopping frequency. Sets the CHOPFREQ keyword
Example: SetValues("Zpectrometer", {"chopfreq":0.1})

classout

Type: enum
Unit: N/A
Values: false, true or 0, 1
Array Count: N/A
Description: Determines whether wasp software outputs class compatible files. Sets the CLASSOUT keyword.
Example: SetValues("Zpectrometer", {"classout":"true"})

cwsigsLoc

Type: structure:
Array Count: N/A
Description: Specifies where the manager is to find the 'cwsigs' fits file. projDir specifies the name of the project directory where the data file resides, and fileName the filename of the data file. Absolute path names should not be givne in projDir. The manager assumes the location of the GBT data directory, and assumes that the file will be found within the "Zpectrometer" directory inside the project directory.
Example: SetValues("Zpectrometer", {"cwsigsLoc,projDir":"T_ZPEC_29NOV06", "cwsigsLoc,fileName":"2006_11_30_05:32:14.fits"})

cwsigsParams

Type: structure:
Array Count: 4
Description: An array of 4 structures. Each structure controls 'cwsigs' parameters for each backend. If all backends are set identically, the manager will run the 'cwsigs' program for all backends simultaneously. If any backend settings differ, the manager will run each backend separately.
Example: SetValues("Zpectrometer", {"cwsigsParams,2,enable":"true"})

cwsigsPower

Type: int
Unit: dBm
Values:
Array Count: N/A
Description: The power level that the LO1B synthesizer should be set to during a 'cwsigs' procedure
Example: SetValues("Zpectrometer", {"cwsigsPower":10})

debugLevel

Type: enum
Values: 'NoDebugLevel', 'BasicManagerDebug', 'TimingMethodsDebug', 'AllMethodsDebug', 'ManagerPerParameterDebug', 'InternalManagerDebug', 'AllPerParameterDebug'
Array Count: N/A
Description: Controls the level of debug printing in the manager. This is primarily intended for developer use.
Example: Don't use this.

defcold

Type: enum
Unit: N/A
Values: 'ambient', 'sky'
Array Count: N/A
Description: The cold type for TCOLD=-1, one of 'ambient' or 'sky'. Sets the DEFCOLD keyword.
Example: SetValues("Zpectrometer", {"defcold":"sky"})

defhot

Type: enum
Unit: N/A
Values: 'ambient', 'sky'
Array Count: N/A
Description: The hot type for THOT=-1, one of 'ambient' or 'sky'. Sets the DEFHOT keyword.
Example: SetValues("Zpectrometer", {"defhot":"ambient"})

diagout

Type: int
Unit: N/A
Values: 0, 1
Array Count: N/A
Description: Set to non-zero to trigger output of wasp2 diagnostic files. These files, with extension '.dpr' and '.tpr', will be output to the project directory. Sets the DIAGOUT keyword.
Example: SetValues("Zpectrometer", {"diagout":0})

diode

Type: int
Unit: N/A
Values:
Array Count: N/A
Description: Noise diode number to activate during "dobs" observations; a negative value implies "none". Data accumulated with the diode off will be archived with a value of -1 for this parameter and a scan number one greater than the matching diode-on integration. Example: SetValues("Zpectrometer", {"diode":-1})

exposure

Type: double
Unit: Seconds
Values: >0
Array Count: N/A
Description: Sets the effective integration time. exposure is dependent on which observing program is selected in obsProgram. If 'totpwr' or 'dobs' is selected, exposure will set the EXPOSURE keyword; if 'cwsigs' is selected, exposure will set the CAFTIME keyword; if 'zero', CAZTIME.
Example: SetValues("Zpectrometer", {"exposure":60})

genericKeyword

Type: structure:
Array Count: N/A
Description: genericKeyword is an interface to allow any arbitrary wasp2 keyword to be set from the manager. Its main use is to set keywords that have not been mapped to parameters in this manager. It is an 'auto' parameter, which means that as soon as it is set it will execute; no need to do a 'prepare' to set the value. What this means in practice is that every time this parameter is used a call to 'waspset' is made to set the keyword. Repeated use of this parameter with the same keyword/value pair is a good indication that this keyword should be mapped to a parameter.
Example: SetValues("Zpectrometer", {"genericKeyword,key":"atten2", "genericKeyword,value":"6"})

monitorBlanking

Type: enum
Unit: N/A
Values: 'false', 'true' or 0, 1
Array Count: N/A
Description: When set, this parameter inhibits monitoring of voltages and temperatures on all backends during a scan.
Example: SetValues("Zpectrometer", {"monitorBlanking":"true"})

nextScanNumber

Type: int
Unit: N/A
Values: 1-N
Array Count: N/A
Description: Scan number of next scan
Example: SetValues("Zpectrometer", {"nextScanNumber":800})

obsProgram

Type: enum
Unit: N/A
Values: 'zero', 'cwsigs', 'totpwr', and 'dobs' or 0-3
Array Count: N/A
Description: Specifies which wasp2 program to run on the next scan
Example: SetValues("Zpectrometer", {"obsProgram":"cwsigs"})

projectId

Type: char[16]
Unit: N/A
Values: N/A
Array Count: 16
Description: Project identifier string. During normal operations this parameter is not set by the observer, but by the ScanCoordinator.
Example: SetValues("Zpectrometer", {"projectId":"T_ZPEC_29NOV06"})

quadsw

Type: enum
Unit: N/A
Values: 'false', 'true', or 0, 1
Array Count: N/A
Description: Determines whether to use quadrature phase switching during the integration.
Example: SetValues("Zpectrometer", {"quadsw":"true"})

recipientNumber

Type: int
Unit: N/A
Values: N/A
Array Count: N/A
Description: Number of clients to the manager. This value is never set, only read, and is of interest to other programs or to developers.
Example: val = GetValue("Zpectrometer", "recipientNumber")

requestedStartTime

Type: structure:
Array Count: N/A
Description: Target start time of next scan if asap flag is clear
Example: don't use.

requestedStopTime

Type: structure:
Array Count: N/A
Description: Target stop time of next scan.
Example: don't use.

scanId

Type: string
Unit: N/A
Values: N/A
Array Count: 32
Description: Scan identifier string. Normally this is set by ScanCoordinator.
Example: SetValues("Zpectrometer", {"scanId":"10"})

scanLength

Type: structure:
Array Count: N/A
Description: Expected duration of next scan
Example: val = GetValue("Zpectrometer", "scanLength,seconds")

scanNumber

Type: int
Unit: N/A
Values: 1-N
Array Count: N/A
Description: Scan number of current or last scan.
Example: val = GetValue("Zpectrometer", "scanNumber")

scanlog

Type: string
Unit: N/A
Values: N/A
Array Count: 196
Description: List of paths to DAP FITS files. This is meant for use by the ScanCoordinator, which uses this to construct the ScanLog.fits file.
Example: val = GetValue("Zpectrometer", "scanlog")

source

Type: string
Unit: N/A
Values: N/A
Array Count: 32
Description: Source identifier string. Normally set by the ScanCoordinator.
Example: SetValues("Zpectrometer", {"source":"Jupiter"})

startTime

Type: structure:
Array Count: N/A
Description: Expected start time of the next scan
Example: val = GetValue("Zpectrometer", "startTime,seconds")

state

Type: enum
Unit: N/A
Values: 'Off', 'Standby', 'Ready', 'Activating', 'Committed', 'Running', 'Stopping', 'Aborting', 'NotInService'
Array Count: N/A
Description: Current operational state of the Manager. NOTE: although this is a read-only parameter on the manager, the Astrid observing directive 'SetState()' is programmed to recognize limited use of 'state' to allow the observer to cause a manager to change states (see Example below, and especially the Observing Directives documentation).
Example: val = GetValue("Zpectrometer", "state") SetValues("Zpectrometer", "state:on")

status

Type: enum
Unit: N/A
Values: 'clear', 'Info', 'Notice', 'Warning', 'Error', 'Fault', 'Fatal'
Array Count: N/A
Description: Summarizes the severity of the Message levels. For example, if the manager experienced a condition that caused it to issue a 'Warning' level message, this parameter will be set to 'Warning'.
Example: val = GetValue("Zpectrometer", "status")

tcaltype

Type: enum
Unit: N/A
Values: 'vane', 'hotcold'
Array Count: N/A
Description: Telescope calibration mechanism. Currently supported are VANE and HOTCOLD. Sets the TCALTYPE keyword.
Example: SetValues("Zpectrometer", {"tcaltype":"vane"})

tcold

Type: double
Unit: Kelvins
Values: N/A
Array Count: N/A
Description: Cold load temperature. Sets the TCOLD keyword.
Example: SetValues("Zpectrometer", {"tcold":50.0})

thot

Type: double
Unit: Kelvins
Values: N/A
Array Count: N/A
Description: Hot load temperature. Sets the THOT keyword.
Example: SetValues("Zpectrometer", {"thot":50.0})

verbose

Type: int
Unit: N/A
Values: 0, >0
Array Count: N/A
Description: Setting this parameter to non-zero causes the wasp2 output (from stdout & stderr) to be printed on the screen or in the log file as they occur, regardless of error condition.
Example: SetValues("Zpectrometer", {"verbose":1})

-- RamonCreager - 05 May 2006

Topic ModificationRequest1C306 . { Edit | Attach | Ref-By | Printable | Diffs | r1.20 | > | r1.19 | > | r1.18 | More }
Revision r1.20 - 08 Dec 2006 - 17:18 GMT - RamonCreager
Parents: PlanOfRecordC32006 		Content copyright © 1999-2007 by the contributing authors.
All material on this collaboration platform is the property of the contributing authors.