Jeffrey W Percival
|1.1||05-Mar-2003||Update reconfig times, add discussion of parallelism|
Table of Contents
This note describes the software design for the PFIS control system.
PFIS uses 9 mechanisms in support of its observing states. These mechanisms use a total of 8 stepper motors and 16 pneumatic actuators.
The software must provide the following capabilities:
The PFIS Control System software runs on a standard Windows (currently Windows 2000) PC. The software is written in the National Instruments (NI) graphical programming language LabVIEW. Windows is required for at least part of the control system software because although LabVIEW is supported on Mac OS and Linux, National Instruments currently supports motion control only under Windows.
We choose a client/server design, in which the user interface is the client, and the server runs the hardware. Each is a stand-alone piece of software, and they communicate over a network using LabVIEW's data socket server (DSS) function. The DSS provides a simple network communications function, and allows both client and server to run on the same CPU or different CPUs without modification of the software.
We also choose the format of the commands passing from the client to the server to be simple text strings (e.g. "mask fetch" or "grating insert"). This allows scripting in a natural way. Human-readable observing scripts will be generated in advance using web-based perl CGI scripts. The PFIS user interface (the client) can then simply read these scripts and forward the commands to the server. The server doesn't need to know about the source of the commands, and no script-dependent software will reside in the server.
Note that choosing a client design that does not use any LabVIEW motion control modules means that the client does not suffer the same operating system restriction that the server does. The client can run on Linux, or Mac OS.
The server runs on PCON, a Windows PC with a NI MXI fiber interface card in its backplane. This is the communications link to the payload. The server module is driven by a vocabulary of simple text strings. The strings represent commands at three different hierarchies of abstraction:
This figure shows the server block diagram.
The PFIS user interface reflects this hierarchy, and uses LabVIEW tabbed controls to reveal the desired level of control at the right time.
Screen shots of the prototype GUI are shown in SALT-3140AE0023.
PFIS is designed with hardware interlocks sufficient to protect the instrument from damaging itself, and to prevent exposing humans to electrical shock or harm from actuators. See SALT-3140AS0015 in the PFIS CDR package. The server, however will also enforce the interlocks in software, with the goal of never actually invoking a hardware interlock.
We will implement the software interlocks at the lowest level, by "wrapping" each actuator inside a LabVIEW VI module. The VI will be responsible for check that the interlock conditions have been met before actually sending the control signal outinto the hardware. If the conditions are not met, the wrapper VI will fail and pass an error cluster up the hierarchy that describes what condition was not met.
We define these modes for the PFIS server.
|Off||All power off|
|Standby||PCON on, PXI Chassis on|
|Init||Includes sensing the instrument configuration|
|Ready||Waiting for command input|
|Busy||Processing a command|
|Error||Any detected error, including sensor error, interlock error, or actuator hangup.|
The normal sequence of mode transitions is 1-2-3-4-5-6-7.
The Error state is entered in three different ways:
PFIS will spend most of its time in one of two states: Ready or Standby. PFIS will seldom go to Off because if the PXI box is turned off, then no sensor data are available during the day, and the PFIS control computer must be rebooted each time the PXI box is turned on.
In a combinatorical sense, PFIS has a huge number of possible states. It offers imaging, spectroscopy, polarimetry (3 kinds), 2 resolution regimes of Fabry Perot narrow band imaging, 3 types of CCD readout modes, and optional interactions with the telescope during an observation. The combinatoric explosion is controlled, though, by pruning whole sections of the configuration state tree according to which states are useful, and which are nonsensical.
This figure shows the useful PFIS configuration states. There are 3 main states (S1-S3), with 3 variants that select polarimetric modes (S4-S6). This figure shows the possible state transitions, and the time it takes to execute them.
This state -space approach lends itself to a simple but powerful software implementation. We will control the PFIS configuration with a table-driven state machine. What is this?
|+T1, S2||+T3, S3||+T2, S4||+T1, S2||+T3, S3|
|-T1, S1||-T1, S1||-T2, S5||-T1, S1|
|s3||-T3, S1||-T3, S1||
|-T3, S1||-T3, S1||+T2, S6|
|s4||-T2, S1||-T2, S1||-T2, S1||
|+T1, S5||+T3, S6|
|s5||-T2, S2||-T2, S2||-T2, S2||-T1, S4||
|s6||-T2, S3||-T2, S3||-T2, S3||-T3, S4||-T3, S4||
Example: Suppose you are in state S5 (Spectropolarimetry), and you want to be in state S3 (Fabry-Perot Imaging) for the next observation.
This table-driven approach has many advantages over a procedural approach. For example, in the example given above, one made the move from S5 to S3 by:
If, for some operational reason, one wanted a different order, say:
then one has merely to update the state table. No procedures have to be written or modified. This approach has been used before at the Space Astronomy Laboratory, in Jeff Percival's amazing astrometric kernal, the "Telescope Pointing Machine" (TPM). The state diagram and detailed documentation are available on the web.
The PFIS configuration state table also represents a higher, 3rd level of interlock protection. The state table entries ensure that the instrument will be moved through a tested and well-known sequence of states. The hardware interlocks are shadowed by the low-level LabVIEW software interlocks, ensuring that the hardware interlocks will not be tripped. Likewise, the low-level interlocks are shadowed by the state table entries, ensuring that the software interlocks will not be tripped!
One might complain that using a table-driven state machine precludes the possibility of saving time by operating mechanisms in parallel. We point out, though, that the two longest configurations, the etalons and the camera articulation, are mutually exclusive in a mechanical sense, and therefore cannot be done in parallel. Moreover, the three reconfigurations that don't result in a state change (slit masks, gratings, and filters) can be donein parallel, and we will use LabVIEW's parallel execution capabilities to do so.
PFIS commands are organized into a 3-level hierarchy, allowing access at the actuator, mechanism, or procedure level. We want to avoid controlling PFIS observing sequences by sending large numbers of low-level commands from the client (user interface) to the server. The knowledge of how to execute an observing sequence should lie in the server.
We have identified the observation sequences that make sense for each of the configuration states. These are discussed in the Operational Concepts Definition Document (SALT-3170AE0002).
We will manage errors using the standard error management tools in LabVIEW. Each VI will take an error input and provide an error output. The error flow will be wired up, one VI after another, in LabVIEW fashion. Each VI will inspect its error input, and decline to act if an error is indicated. If action is declined, then the input error will be passed on. If action is taken and an error is produced, then that error cluster will be passed on.
The error cluster will contain a specific description of the error: the interlock code, the sensor responsible for the failure, and so on.
Combined with a hierarchical set of VIs, this method will allow errors to flow up to the top, then over to the client interface.
Data and Command Management
All PFIS commands (text strings) and data clusters will be defined as LabVIEW "type def" clusters. The typedef clusters will all live in a single directory, allowing a convenient way of inspecting or using them en masse.
Communication with Other SALT Subsystems
PFIS must communicate with two other SALT subsystems: the SAAO CCD subsystem (PDET) and the Telescope Control System (TCS).
It sends set-up commands to PDET for configuring the CCD for exposures, and trades information with PDET for handshaking, slit mask peakup exposures, and FITS header keywords. No raw image data are exchanged; the interactions will be conducted using text strings. The vocabulary will be built up during the fabrication phase by the SAAO and PFIS teams.
PFIS interacts with the TCS to do slit mask peakups, and for the shuffle-and-nod observing procedures. These interactions will also use text strings. The vocabulary will be built up during the fabrication phase by the TCS and PFIS teams.