|
|
AUSTRALIAN
NATIONAL UNIVERSITY System Design Note 11.02 Created: 11 September 2001 Last modified: 11 September 2001 |
NIFS COMPONENTS CONTROLLER SOFTWARE DESIGN
Peter Young
Research School of Astronomy
and Astrophysics
Institute of Advanced
Studies
Australian National
University
Revision History
|
Revision No. |
Author & Date |
Approval & Date |
Description |
|
Revision 1 |
Peter Young 10 March 2000 |
Peter J. McGregor 05 September 2001 |
Original document. |
|
Revision 2 |
Mark Jarnyk 10 September 2001 |
Peter J. McGregor 10 September 2001 |
Revised after CDR. |
|
|
|
|
|
Contents
4 Components
Controller Software Implementation Detail
4.2 Specific
Differences to NIRI
4.3.2 Status and
Alarm Database
1 Purpose
The purpose of this document is to provide details of the software design for the Components Controller (CC) module of the Gemini Near-infrared Integral Field Spectrograph (NIFS). As described in the CICS Detailed Design Document, this subsystem is responsible for the mechanisms that define the optical path through the instrument and for controlling the instrument’s environment.
2 Applicable Documents
|
Document ID |
Source |
Title |
|
Cics_smb_041/10 |
IGPO |
CICS Detailed Design Document |
|
|
|
|
3 Introduction
The Components Controller is a module in a Gemini conforming Instrument Control System. It consists of an EPICS Capfast hierarchy, SNL code, and C support routines.
The Components Controller controls the instrument elements that are in the light path. These components are:
· Focal Plane Mask Wheel.
· Order Sorting Filter Wheel.
· Grating Turret.
· Environmental Cover.
· Flip Mirror.
As NIFS is an instrument designed to use a copy of the NIRI cryostat, the methods used to control and position these active elements are identical to those used in NIRI which have been developed at the IfA
4 Components Controller Software Implementation Detail
4.1 Overall Architecture
The Components Controller consists of four databases (Figure 1); the Components Controller CAD/CAR database where commands are issued, the Components Controller mechanism database that controls motors, the Components Controller temperature database which controls temperatures, and the Components Controller SAD. Sequencer code acts on commands, controlling the motors through the mechanism database, and transferring status and alarm information into the SIR records of the SAD.
Figure 1: Components Controller Architecture.
4.2 Specific Differences to NIRI
NIRI has support for more mechanisms than required for NIFS. Both systems use Hall effect sensor controlled stepper motors. The NIFS Components Controller databases were created by removing the extraneous mechanisms and adding a mechanism to handle the flip mirror. Each mechanism has a look-up table that defines the sensor positions. These are configured at set-up time.
At least one mechanism, the grating turret, requires greater precision than can be obtained currently with the NIRI datum strategy. Therefore, one Hall effect sensor on the grating turret will be employed for fine-tuning the datum, requiring a change to the Hall effect record, and the device support record. This change has yet to be implemented.
The grating turret also requires the ability to make small offset movements from the nominal position. To this end, we have added EngMoveOffset to the mechanism command set. This change has required small modifications to the eng_ss sequence and the comp1mCad schematic. No change to the underlying record or device support code was necessary. The focal plane mask wheel also uses this new facility.
4.3 Databases
4.3.1 CAD/CAR Database
The CC CAD/CAR database provides the means to control the mechanisms and temperature controllers of the Components Controller. All commands, whether system sequences or local commands (such as opening a cover), are processed by CAD records.
The complete hierarchy of Capfast schematics is shown in Figure 2.
Figure 2: Hierarchy of Capfast schematics in the CC CAD/CAR database design.
4.3.2 Status and Alarm Database
The CC Status and Alarm Database is a separate EPICS database, largely a collection of SIRs for each of the components, for each temperature sensor, and for each interlock. SNL code monitors these elements and updates the associated SIR.
The full hierarchy of Capfast diagrams for the CC SAD is shown in Figure 3. As can be seen, there is a schematic group for each of the components.
Figure 3: Hierarchy of Capfast schematics in the CC SAD design.
4.3.3 Mechanism Database
As shown in Figure 1 the hardware records are contained in databases that are separate to those containing the CAD and CAR records. SNL state sets transfer information between the CAD, CAR, and SIR records and their hardware counterparts.
The Components Controller mechanism database is detailed in Figure 4. Two records, with associated device handlers and drivers, were created for NIFS; the hallstep record and the hmotor record. These are described in detail in Yamada (1997). Neither of these records is accessed directly. Rather the user connects to the EPICS "mech" record.
Figure 4: Hierarchy of Capfast schematics in the CC mechanism database design.
4.3.4 Temperature Database
The Components Controller temperature database is a trivial database (Figure 5). In addition to the hmotor record, it uses three other records created for NIFS; the tsen, tcon, and cool records.
Figure 5: Hierarchy of Capfast schematics in the CC temperature database design.
NIRI employs three Omega CYC321-01 temperature controllers. NIFS replaces one of these with a Lake Shore Model 340 temperature controller, which, unlike the Omega CYC321-01, is a dual controller. To accommodate the new instrument, the tcon record has been changed, and a device handler and driver have been written. These changes and additions are detailed here.
4.3.4.1 Temperature Controller Record
In keeping with the EPICS’ philosophy of decoupling records from the hardware, we have not created a new temperature controller record specifically for the Lake Shore device. Rather, we have generalized the exisiting record (tcon) to handle both the Lake Shore and Omega controllers. The only change required has been the addition of a single input called LOOP. For the Lake Shore device handler, this specifies the control loop to which the command refers. The Omega device handler will ignore this input.
4.3.4.2 Device Support
The device handler code used as a starting point was the device handler code for the Omega controller, devOcyc. The new code uses a similar command set with a few additional commands to handle self-testing, set a settling time, and to handle readbacks (which are different to the Omega controller). It uses the LOOP parameter passed to it to select the appropriate loop of the Lake Shore temperature controller.
4.3.4.3 Device Driver
The device driver code is based closely on the driver code for the Omega controller, drvOcyc. Essentially, the only differences are the different command set.
4.4 SNL Code
State sets, written in SNL, are the means of implementing state machines within EPICS. They are not part of the database proper, but rather, coexist with it and are bound to it. In CICS, the state sets monitor the CAD records waiting for incoming commands to these records. Issuing a command changes a CAD record field and this change triggers a state set. The state set acts on the command, updating CAR records in the CC CAD/CAR database, changing fields in the CC mechanism database, and updating SIRs in the CC SAD.
The NIFS components controller employs six state sets:
cc_ss Manages the initialization of the CICS components controller.
datum_ss Process the "datum" command and manage "datumC" CAR records.
park_ss Process the "park" command and manage "parkC" CAR records.
eng_ss Process commands for one axis of a component issuing commands to the underlying mechanism database.
compPseudo_ss Handle BUSY state for one axis of a component.
engMode_ss Handles BUSY-IDLE state.
Each of these state sets, except for eng_ss, was adopted from the NIRI code without modification. Eng_ss was modified to handle the extra command, EngMoveOffset. The state transition charts of Figure 6 to Figure 11 illustrate each of these state sets. Note, particularly in reference to Figure 11, that there is an order in which each case is evaluated. The order for a particular state is indicated by a number in the diagram.
Figure 6: State transition diagram for the cc_ss state set.
Figure 7: State transition diagram for the compPseudo_ss state set.
Figure 8: State transition diagram for the datum_ss state set.
Figure 9: State transition diagram for the park_ss state set.
Figure 10: State transition diagram for the engMode_ss state set.
Figure 11: State transition diagram for the eng_ss state set.
There are multiple instances of each state set. For example, there are five mechanisms in the components controller, and so, there are five eng_ss state sets running, each responsible for its own mechanism. The state sets are configured at run-time. For example, the eng_ss state set controls the database record field {top}{mech}EngTol. At run-time, the state set for the Environmental Cover is loaded, thus:
seq &engSt, "name=ccCov, top=nifs:cc:, sadtop=nifs:cc:, eng=nifs:eng:cc:, sys=sys, mech=cov"
Therefore in the eng_ss state set (a state set in the engst file) the record field {top}{mech}EngTol becomes nifs:cc:covEngTol.
5 Testing and Simulation
NIFS has mechanism simulation provided – we will use this for testing software before any hardware is in place.
Gemini simulation modes are described in ICD 1a. The NIRI software supports FAST and FULL simulation modes, so these are the modes that will be available for NIFS.
Appendix A: List of Figures
|
Figure 1 |
figure.gif |
|
|
|