|
|
AUSTRALIAN
NATIONAL UNIVERSITY System Design Note 11.08 Created: 9 May 2002 Last modified: 9 May 2002 |
NIFS HANDLING OF THE FOCAL PLANE MASK WHEEL
Mark Jarnyk
Research School of Astronomy
and Astrophysics
Institute of Advanced
Studies
Australian National
University
Revision History
|
Revision No. |
Author & Date |
Approval & Date |
Description |
|
Revision 1 |
Mark Jarnyk 15 August 2001 |
Peter Young 20 August 2001 |
Original document. |
|
Revision 2 |
Mark Jarnyk 9 May 2002 |
Peter Young 9 May 2002 |
Changed ccCoord_ss |
Contents
4.1 Can the
Components Controller Database be Changed to Handle This?
4.2 Can eng_ss be
Changed to Handle This?
1 Purpose
The purpose of this document is to describe how the Gemini Near-infrared Integral Field Spectrograph (NIFS) software handles the special movement of the focal plane mask wheel.
2 Applicable Documents
|
Document
ID |
Source |
Title |
|
|
RSAA |
NIFS Critical Design Review documentation |
|
|
|
|
3 Introduction
When the Gemini Near-infrared Integral Field Spectrograph (NIFS) focal plane mask wheel is in an occulting position and it is moved, it is possible that the detector could be exposed to a bright star and, hence, saturate. Persistence of this image could prevent further observations for several hours. To avoid this problem, the NIFS CC software has been modified from the original NIRI code, to utilize the filter wheel's "blocked" position as a shutter. Thus, whenever the focal plane mask wheel is to be moved, the filter wheel first moves to the blocked position, waits until the focal plane mask wheel is at its destination, and then either returns to its previous position, or continues with its interrupted motion.
4 The Problem
The NIFS CC, IS, and OIWFS software are a close copy of the corresponding NIRI software. The observatory control system writes directly to the CADs. When the associated APPLY record, issues the START directive, sequence code is triggered, which writes to the mechanism database. Just how this works in operation is best illustrated by an example. A command from the OCS is issued by writing a value to one of the CAD records and marking the CAD. If the grating turret is to be moved to the H position, then the grating turret's "select" CAD is marked, and the value "H" written to the A field of that CAD. A "START" directive is then issued to the topmost APPLY record which causes the CAD record to verify its input ("H") and if all of the marked CADs verify their arguments successfully, the value is written to the CAD's output. This causes the grating turret's eng_ss sequence code to be triggered. This eng_ss sequence code writes the new position to the grating turret's hallstep record, updates the grating turret's CAR record, and waits for the motion to stop. In practice, all components move simultaneously.
Figure 1 shows this architecture of the NIRI software. An implicit assumption in this architecture is that all components are equal and independent. However, with the blocking scheme outlined above where the filter wheel acts as a shutter whenever the focal plane mask wheel is moved, all components are not equal and are not independent. Indeed, the filter wheel is a slave to the focal plane mask wheel. So, how should the software be modified to accommodate this new architecture?
4.1 Can the Components Controller Database be Changed to Handle This?
In the database, all marked components move. This means, that in effect, all components move simultaneously. As the CADs are modified directly by the observatory control system, there is no way of sequencing the order of component movement in the database above the CAD level: the CADs represent the operator level.
Figure 1: Architecture of NIRI database.
It may be thought that it is possible to rearrange the APPLY records to handle this sequencing of events, since it is the APPLY records, which initiate an action through the START directive. This is not possible without adding intermediate records between the cascaded APPLYs. A record could be created that was positioned between cascaded APPLYs, with its purpose to hold up any pending action on the part of the filter wheel. This would require the creation of a special record and its attendant record support routines. This change would only be necessary for the CC database, but since the OIWFS database uses the same schematics, the OIWFS database would be changed as a side effect. This would require a variant of the new record especially for the OIWFS. Thus the particular record support would need to be specified as a label within the database at a high level where the OIWFS and CC databases differ, and then carried throughout all lower schematics. This would necessitate many changes to the databases.
In addition, such a scheme does not allow for the resumption of an interrupted operation on the part of the filter wheel, since the operation is specified at a lower level, the CAD level.
In general changing the database is difficult and very time consuming and, hence, costly. Solutions that minimize the impact on the database are highly desirable.
4.2 Can eng_ss be Changed to Handle This?
Eng_ss is a general sequence that handles the motion of any component. In the database, one eng_ss sequence runs for each component. The component that any eng_ss sequence controls is set up at run-time. One solution would be to modify the eng_ss code for the focal plane mask wheel, i.e., have a sequence that is a superset of the eng_ss code with additional states to handle its special motion. However, the eng_ss code instantiated for the focal plane mask wheel would need to control the filter wheel as well. Whilst it could write to the snl records which trigger the filter wheel's eng_ss code, a complication immediately arises when the focal plane mask wheel interrupts any existing motion of the filter wheel (which is the normal case, especially in queue observing), because, once the blocking motion of the filter wheel is over, it should continue with the interrupted operation. This could not be controlled from within the eng_ss of the focal plane mask wheel, since it has no knowledge of the filter wheel’s motion. Therefore it would be necessary to have a special eng_ss to handle the motion of the filter wheel as well. This eng_ss would have to remember the current operation when it was interrupted, but how would it distinguish between an interruption from the focal plane mask wheel and an interruption from the operator? If the operator interrupts, it is probably not desirable to resume the interrupted command once the new command is complete. The operator may find this action surprising. And even in the case when a blocking motion interrupts the original command, the filter wheel should not resume the original command immediately that it completes the blocking motion: it can only do this when the focal plane mask wheel has completed its motion. Clearly the eng_ss of the filter wheel and the focal plane mask wheel would need to communicate in some way, leading to two special cases of the eng_ss code. So, this scheme requires two special instances of the eng_ss code, in addition to the standard version! A simpler, cleaner solution is available.
5 The Solution
The solution employed was to add a coordinating level of sequence code, called ccCoord_ss (Figure 2), leaving the eng_ss code untouched. This coordinating layer is a single instance of sequence code, rather than an instance for each component. It is triggered by the same collection of records that previously triggered the eng_ss code. For the case of the filter wheel, grating turret, flip mirror, and environmental cover, this coordinating sequence code simply copies the appropriate fields from the triggering records to the new engSnl records which in turn trigger the eng_ss code in the normal way. The focal plane mask wheel gets special attention. Whenever it receives a command, it interrupts any movement of the filter wheel and causes the filter wheel to move to the blocked position. Once there it moves the focal plane mask wheel to its desired position, and then, if the filter wheel was interrupted, it returns to the interrupted movement or if the filter wheel was stationery, it returns to the position from which it came. Because all motion commands pass through the ccCoord_ss code, it knows what commands have been issued to the filter wheel and can resume them.
Figure 2: NIFS database architecture.
The full coordination sequence code is illustrated by the state transition diagram of Figure 3.
A few details are worth noting:
· An offset of the focal plane mask wheel does not cause the filter wheel to block.
· Moving the focal plane mask wheel to the current position does not cause the filter wheel to block (this is expected to be the typical command issued to the focal plane mask wheel, especially when queue observing).
· If the filter is not datumed, then you cannot move the focal plane mask wheel (except when datuming the focal plane mask wheel).
A major advantage of this scheme is that it requires only small changes to the database (renaming the group of records that trigger eng_ss and adding four new records) and a small change to the eng_ss code (renaming the same group of records that trigger it). Otherwise, the existing software was not touched. Furthermore, the only change required of the OIWFS is to have its own version of the ccCoord_ss code, called wfsCoord_ss. As the wavefront sensor does not require any special coordination of its components, the sequence code simply transfers values between its snl records and its engSnl records. This is illustrated by the state transition diagram of Figure 4.
Figure 3 State transition diagram for ccCoord_ss.
Figure 4 State transition diagram for wfsCoord_ss and lockCoord_ss.
The interlock system for both the components controller and the wavefront sensor uses pseudo components. As the interlocks employ the same schematics as real components it was necessary to write coordinating snl code for the interlocks. This code is identical in structure to the wavefront sensor coordinating code (Figure 4), but different in the detail of the specific component records accessed. This illustrates an important point: as the coordinating layer, by its very nature, must know the names of the components it handles, it must be written to handle these explicitly, unlike the eng_ss code, which is configured at run time.
6 Bugs, Flaws and Limitations
The CAR record is meant to indicate when the component is busy. It is the eng_ss code that controls the state of the CAR record. When it is triggered, it sets the CAR state to BUSY, moves the component, and then when the component has finished moving, it clears the CAR record. A problem arises with the focal plane mask wheel, since when it is moved its first action is to move the filter wheel. The user will see the filter wheel go BUSY, but not the focal plane mask wheel.