YGOR is the name of the Monitor and Control system software. The following, mostly written by Mark Clark and John Ford, are the basics of YGOR that you will need to know to make effective use of a CLEO application.
The setup and operation of all GBT devices are defined through a software module called a manager. Managers are used to control and coordinate everything on the telescope from I.F. electromechanical switches to the antenna servo system. Understanding how a manager works is understanding how software controls the GBT.
Each manager contains a set of values called parameters which may be set directly by the user, computed from other parameters, and/or loaded into the device itself. A useful analogy is a spreadsheet program where a manager is the spreadsheet and the parameters are the cells of the spreadsheet. A user defines the setup or use of a device by filling in values in the "higher-level" cells and the spreadsheet computes or translates these into the values needed by the device's various registries, RAMs, controllers, or other device interfaces. Control of the device is a matter of filling in values of the various cells. As far as user control is concerned, the only difference between devices is the set of cells or parameters defined within its spreadsheet or manager.
There exists a subset of parameters which are built into all managers. The most interesting common parameters are:
The various device subsystems that make up the GBT may be classified into two broad categories. First there are devices which sequence through a set of events or actions as a scan proceeds. These synchronous devices must respond to the onset of a scan and synchronize their activity to the scan as it progresses. Examples are backends, the tracking LO, and the antenna. Second are non-synchronous devices which merely have to be in the correct state by the beginning of a scan and remain so. Examples are electromechanical switches, static LOs, and receivers. Nominally, synchronous managers and their associated software may be thought of as "real-time" systems, while non-synchronous managers are not.
Different sets of parameters define the differences between managers, but there exist a whole set of commands which are common to all managers which may be accessed via widgets or menus in CLEO. Most of these have to do with controlling scans and thus the sequencing of manager states. A manager may be placed in Off, Standby, or Ready states by the commands off, standby, and on respectively. Off causes the manager, and indeed all software, to completely disconnect from the hardware. So, if one wished to turn off the hardware and not initiate a stream of error messages as the software detects that it is not getting the correct feedback from its digital interfaces, one would use off prior to turning the power off. Standby allows the software to continue monitoring the hardware, but not start scans or respond to any commands other than on or off. Ready denotes the system is ready to start a scan.
The commands start and prepare are the manager's activate commands which cause the software to actually command the hardware. The command start causes a scan to begin while prepare causes the manager to do everything possible to get ready for a scan (as specified by its parameters) short of actually starting the scan. The command start will cause a synchronous manager to pass from the state Ready through Activating and Committed to Running, and a non-synchronous manager to pass from the state Ready through Activating back to Ready. The values specified in the parameters are not loaded or used by the system until either of the activate commands are invoked. In fact, one can return the parameters to their value when the last activate command was given with the command revert. A manager's activate commands can only be invoked from the Ready state and if none of its parameters contain an illegal value (see parameter attributes below). The commands stop and abort cause a manager to return to Ready. The command abort is the much stronger version of the two and should not be used unless there are operational problems. Another command of interest is conform which forces the re-computation of all parameters as opposed to only those whose antecedent cells have been modified.
As commands are sent to a manager, and parameter values are set, computed, and loaded into the system (activated), each parameter acquires various attributes. The following two lists provide short descriptions of parameter types and attributes.
There are three types of parameters: control, feedback, and auto.
An example of how these types are used is the parameter used for setting the attenuators that control the input levels to the A/Ds in the downconverter drawers of the Spectral Processor. The value of the attenuator parameter is not dependent on any other parameters and the attenuators themselves are set during balancing. However, we would like the user to be able to set the attenuators manually. In all states, except Ready, the attenuator parameter is defined as a feedback parameter, so whenever the system changes the value of the attenuator, that value may be reflected back to any user-interface program. Therefore, the parameter performs only monitoring duties. In Ready however, the attenuator parameter becomes an auto parameter so the user can directly set the values of the attenuators independent of the operation of balancing. This scheme works because balancing takes place during Activating.
Each manager basically works independently except for the computation of a common start time for a scan. Every synchronous manager is able to compute its earliest guaranteed start time. This time may be used by an other manager designated to manage other managers which then computes the start time for the entire set of managers it is managing. That time is then commanded to all of its managed managers as the actual start time. The analogy is the old movie motif of planning a surprise attack, where the soldiers get together beforehand and are given their individual assignments, synchronize their watches, report when they can be in position to "attack", and then agree when the attack will begin. The same principle is used to coordinate the beginning of a scan. Notice that once everyone is agreed on what and when things take place, there is no need for further communication between the individuals; likewise, there is no software interaction between managers during a scan.
Throughout the YGOR programs are software "test points" or samplers which periodically read and time-tag values which can be tapped into by one of two programs: registries or the accessor. Registries accept sampler values continuously for purposes of creating log files. For example, the weather station software exists primarily to provide samplers for the WeatherRegistryMgr which keeps a perpetual log of recorded weather readings. The accessor, on the other hand, provides "on-demand" access to all samplers. For example, whenever a CLEO application displays a monitor component, it establishes a connection to the accessor to get a stream of sampled values which are displayed in the widget on the screen.
Messages -- strings of text -- are generated throughout the YGOR programs to describe all types of expected and unexpected events. All messages from all YGOR programs are sent via ethernet to a single program (currently messageMux). Every message has associated with it a severity level as well as what device produced the error, when the error occurred and when it was cleared.
A user starts up a YGOR program, messageWindow, to view the messages. To start messageWindow, you must specify the computer on which the messageMux is running. For example:
will use the messageMux found on vega. The messageWindow currently being used is a curses program.
In addition to messages being displayed in a messageWindow, the level of the severest messages from a manager is stored in the manager's status parameter. There are six levels of messages and manager status parameters:
There are two types of events described by messages: transient and state. Transient events are indicated merely by providing the time of the event followed by the string (TRANS). State events are indicated by two times: asserted and cleared.
Glish and segeste:
The Glish and segeste interpreters are the command-line and GUI interfaces to the managers and the Accessor. Glish, and it's GUI counterpart Glish/Tk, is the software behind not only the astronomer's interface developed by Rick Fisher, but Roger Norrod's Mockup test utilities and AIPS++ as well. Glish is solely an NRAO product.
Segeste is an NRAO extension of the popular Tcl/Tk programming language. CLEO, the engineers' and operators' interface to YGOR, is based on segeste and Tcl/Tk.
The TaskMaster program controls all of the YGOR programs running on a specified computer. These programs run continuously and provide a number of services from monitoring receiver temperatures, to logging the weather station readings, or to running the Spectral Processor. One can use TaskMaster to query the status of all or a specific process by passing it the query event, e.g.,
for each process you will get output like the following:
Some fields of interest are:
TaskMaster processes may be initiated to restart automatically which is indicated by the "LastAction" field containing the word "Start", or to restart only on-command which is indicated by the "LastAction" field containing the word "RunOnce". Processes which have a state which must be redefined by the use in case of an unexpected exit, need to be restarted manually so the user can properly initiate the program. Processes which require no input from the user can restart automatically.
The commands or events that may be sent via TaskMaster to a process are query, stop, start, suspend (like control-Z), continue (opposite of suspend). For example, to suspend and continue the logging of weather data temporarily:
or, to stop and restart the Spectral Processor control and data acquisition process:
Debug Monitor and remoteWindow:
The Debug Monitor is another access method that may be employed to monitor the values in a device. The Debug Monitor is accessed from a remote computer using the remoteWindow command.
This will produce a display on the terminal window of the 3 power supply
voltages of the X band receiver.
Copyright © 2000 Associated Universities, Inc. Washington