4.0 SYSTEM MODEL

4.3 Data Flow

TABLE 4-1. UISC Data Flow Drawing Tree
1.1 UI1.1.1 Setup & Acquisition  
 1.1.2 Operator UI  
  1.1.2.1 Loop Control 
   1.1.2.1.1 Main Loop Control
   1.1.2.1.2 Auxiliary Loop Control
   1.1.2.1.3 Alignment Verification
  1.1.2.2 Exception 
  1.1.2.3 Characterize & Optimize 
 1.1.3 Engineering UI  
  1.1.3.1 System Status 
  1.1.3.2 Subsystem Engineering 
  1.1.3.3 Alignment & Calibration 
  1.1.3.4 Simulator Control 
    
1.2 SC1.2.1 Off-loading Control Loops  
  1.2.1.1 Tilt Off-loading 
  1.2.1.2 Segment Tilt Off-loading 
  1.2.1.3 Coma Off-loading 
  1.2.1.4 Focus Sensor Off-loading 
  1.2.1.5 WFS Focus Off-loading 
 1.2.2 Compensation Control Loops  
  1.2.2.1 NIRC-2 Alignment Compensation 
  1.2.2.2 ADC Beam Deviation Compensation 
  1.2.2.3 Pupil Rotation Compensation 
  1.2.2.4 LGS Focus Position Compensation 
  1.2.2.5 WFS Offset Vector Calculations 
 1.2.3 Process Control  
    
    
 

 

   
    
    

TABLE 4-2. OBS Data Flow Drawing Tree
2.1 Rotational Tracking   
 2.1.1 Image Rotator  
 2.1.2 IR-ADC  
 2.1.3 Visible ADC  
2.2 OBS Sensors   
 2.2.1 Wavefront Sensor  
  2.2.1.1 Field Steering Mirrors 
  2.2.1.2 WFS Camera Stage 
  2.2.1.3 WFS Focus Stage 
  2.2.1.4 WFS Pupil Relay Lens Stage 
  2.2.1.5 WFS Setup 
   2.2.1.5.1

WFS Lenslet Stage

   2.2.1.5.2

WFS Field Stop

 2.2.2 Tilt / Focus Sensor  
  2.2.2.1

Tilt/Focus XY Stage

 
  2.2.2.2

Tilt/Focus Z Stage

 
 2.2.3 Acquisition Cam.  
2.3 Diagnostics   
 2.3.1 Diagnostics Camera  
 2.3.2 NIRC-2 Alignment  
 2.3.3 Telescope. Simulator  
 2.3.4 WFS White Light  
 2.3.5 DM Interferometer  
 2.3.6 Environmental Monitors  
2.4 Bench Setup   
 2.4.1 IR/VIS Beamsplitter  
 2.4.2 IR-ADC in/out Stage  
 2.4.3 Sodium Dichroic  
 2.4.4 Science Instrument Fold Mirror  
    
    

FIGURE 4-1. Data Flow Drawing Symbol Legend

FIGURE 4-2. AO System Context Diagram

Comments on FIGURE 4-2., "AO System Context Diagram"

1. This shows that the only way for image information to get from the Science instrument to the AO system (for image sharpening, etc.) is through files.

2. Remember that during image sharpening, we (AO) may want only a subset of the image pixels. Not the whole image. This implies an AO/SI command that specifies a sub window of the science detector to be written to file.

FIGURE 4-3. AO System Context Diagram with Subsystems Shown

Comments on FIGURE 4-3., "AO System Context Diagram with Subsystems Shown"

1. The WFC and LS data flow diagrams are not in this document, but are contained in the documentation for those subsystems. They are shown here only to make the context diagram complete, they will not be expanded here.

2. As is implied by this drawing, we have elected not to have a direct connection from WFC to Science instrument for the purpose of an image quality alarm. The Science instrument can monitor the RMS wavefront error from the SC and make decisions based on that. The RMS wavefront error from the SC can be time averaged, while the WFC values are instantaneous values. Therefore it is probably better for decision making to look at the SC supplied RMS error.

FIGURE 4-4. Data Flow Diagram 1.0 - UI/SC

Comments on FIGURE 4-4., "Data Flow Diagram 1.0 - UI/SC"

1. This drawing shows a little of the division of labor between the UI and SC. In particular, the UI is responsible for the Science Instrument Interface, the SC is the only subsystem that needs to talk directly to ACS.

FIGURE 4-5. Data Flow Diagram 1.1 - UI

Comments on FIGURE 4-5., "Data Flow Diagram 1.1 - UI"

1.

2.

3.

FIGURE 4-6. Data Flow Diagram 1.1.1 - UI Setup and Acquisition

Comments on FIGURE 4-6., "Data Flow Diagram 1.1.1 - UI Setup and Acquisition"

1. We decided not to show any humans on this DFD, it is certainly understood that the human causes the events that in turn cause SKY or the handpaddle to take some action. The human is also the "destination" for any data flowing out of FACSUM.

2.

3.

FIGURE 4-7. Data Flow Diagram 1.1.2 - UI Operator User Interface

Issues on FIGURE 4-7., "Data Flow Diagram 1.1.2 - UI Operator User Interface"

1. Note that the reason there are no output data flows drawn leaving the Exception Handling and Characterize &Optimize bubbles is that they result in informational displays only. The human is the intended destination of this information.

2.

FIGURE 4-8. Data Flow Diagram 1.1.2.1- UI Operator User Interface - Loop Control

issues on FIGURE 4-8., "Data Flow Diagram 1.1.2.1- UI Operator User Interface - Loop Control"

1. Exactly which SC Commands are sent out of the loop control screen?

FIGURE 4-9. Data Flow Diagram 1.1.3 - UI Engineering User Interface

Issues onFIGURE 4-9., "Data Flow Diagram 1.1.3 - UI Engineering User Interface"

1. Is my view of the simulators as telemetry generators accurate?

2. What scripting tool allows both keyword control and image analysis?

3.

FIGURE 4-10. Data Flow Diagram 1.2 - Supervisory Control

Comments on FIGURE 4-10., "Data Flow Diagram 1.2 - Supervisory Control"

1. The divisions on this drawing are somewhat arbitrary. Some of the off-loading control loops and the compensation controls loops can be placed into either category. It is not the category that is significant.

2.'Process Cmnds' going into 1.2.3 could include DCS handshake commands like " DCS Requests permission to offset telescope", etc.

3. I don't see any LS commands coming out of any SC bubbles, is this right?

Also, no WFS or LS telemetry flowing into some SC bubbles?

3.

5.

FIGURE 4-11. Data Flow Diagram 1.2.1 - SC Off-loading Control Loops

issues on FIGURE 4-11., "Data Flow Diagram 1.2.1 - SC Off-loading Control Loops"

1.

2.

FIGURE 4-12. Data Flow Diagram 1.2.1.1 - SC Tilt Off-loading Control Loops (aka tilt off-loading from TTM to DCS)

Comments on FIGURE 4-12., "Data Flow Diagram 1.2.1.1 - SC Tilt Off-loading Control Loops (aka tilt off-loading from TTM to DCS)".

1. What frequency is this done at? (What is XX Hz?)

2. The Off-load Control bubble must take care of the coordinate system conversions.

3. A loop gain is not shown on this drawing because it is not applied by AO, but is applied by DCS.

4. It helps some people to think of this control loop as an analogy to guiding. It will fill that role as a by-product of it's more generic role.

General Description of Segment Tilt Offloading

The AO system will be able to provide the ACS with feedback about primary mirror segment errors. Each segment covers approximately 6 subapertures in the WFS. The time averaged data from those subapertures can be used to determine the tilt errors associated with each segment. These tilt errors will be sent to ACS for correction.

FIGURE 4-13. Data Flow Diagram 1.2.1.2 - SC Segment Tilt Off-loading Control Loop

Notes on FIGURE 4-13., "Data Flow Diagram 1.2.1.2 - SC Segment Tilt Off-loading Control Loop"

1. CSTO stands for Closed loop Segment Tilt Off-loading.

2. OSTO stands for open loop Segment Tilt Off-loading.

3. OSTO and CSTO are mutually exclusive. Since one is for use when the DM loop is closed and one is for use when the DM loop is open, then only one can be enabled at any given time.

4. 1. There was some discussion as to whether we time average the WFS centroid vector or extract the segment tilt information and time average that. As you can see from the drawing, we decided to time average the centroid vector.

5. What exactly does the segment mapping table look like?

6. 4. What magic is going on inside 1.2.1.3.1 and 1.2.1.3.2 that derives a vector of segment tilts from a DM signal vector or a WFS Centroid vector?

7. Should this drawing be re-done in light of the decision to off-load more than just segment tilts? We need to show segment tilt and focus mode. Break out more detail in the segment mapping tables yielding avg. segment positions then going through another bubble that does the same stuff as PCS FINE SCREEEN, then out of that bubble comes the tip/tilt vector and the focus mode coefficient. These are then sent to ACS. (once per min.?)

8. Need to include consideration of the "command complete" response from ACS to initiate a new integration.

9. k2:ao:dm:state is supplied to the off-load control process to indicate whether the DM loop is closed, thus indicating which of the two off-loading flavors is enabled at a given instant in time.

FIGURE 4-14. Data Flow Diagram 1.2.1.3 - SC Coma Off-loading Control Loop

Notes on FIGURE 4-14., "Data Flow Diagram 1.2.1.3 - SC Coma Off-loading Control Loop"

1. CCO stands for Closed loop Coma Off-loading.

2. OCO stands for open loop Coma Off-loading.

3. OCO and CCO are mutually exclusive. Since one is for use when the DM loop is closed and one is for use when the DM loop is open, then only one can be enabled at any given time. k2:ao:wc:dm:state is used to indicate whether the DM loop is open or closed at any point in time, and thereby indicate which of the mutually exclusive loops is enabled.

4. The pupil orientation is used to map the coma corrections onto the telescope secondary. Which of the three secondary actuators need to be moved how much is a function of pupil orientation.

FIGURE 4-15. Data Flow Diagram 1.2.1.4 - SC Off-loading Control Loops - focus sensor off-loading (LGS Mode)

issues on FIGURE 4-15., "Data Flow Diagram 1.2.1.4 - SC Off-loading Control Loops - focus sensor off-loading (LGS Mode)"

1. What frequency is this done at?

2. To allow maximum flexibility, this control loop can be run with or without a separate open loop focus correction for elevation dependence. What are the implications for the two focus corrections to FCS interfering with each other?

3. Should I mention the fact that this is used in LGS mode only?

4. Have I got this right? The EL dependence on LGS focus goes to the FCS and therefore is on this drawing?

5. Should I mention that the T/FS is looking at an NGS, just as a reminder?

6.

FIGURE 4-16. Data Flow Diagram 1.2.1.5 - SC Off-loading Control - WFS Focus Off-loading

Comments on FIGURE 4-16., "Data Flow Diagram 1.2.1.5 - SC Off-loading Control - WFS Focus Off-loading"

1. What is the conversion from Zernike coefficient. to mm of Secondary Piston motion?

2. What Frequency will this be done at? (What is XX hz.?)

FIGURE 4-17. Data Flow Diagram 1.2.2 - SC compensation control

issues on FIGURE 4-17., "Data Flow Diagram 1.2.2 - SC compensation control"

1. 1. We do not show the WFS offset vector being involved in Pupil rotation compensation. Our current plan is that the WFS offset vectors should not have to change as the pupil rotates. It may be that we use/ignore the offsets for different subapertures based on pupil orientation. but that would not change the offset vector itself.

2. 2. In the pupil rotation commands to the WFC, we may need to load a DM control block with changes and then command the WFC to use that control block. This will be a slightly different set of commands than listed in this figure, but the result will be the same.

3. TSS is involved in these in LGS mode.

FIGURE 4-18. Data Flow Diagram 1.2.3 - SC Process Control loops

Comments on FIGURE 4-18., "Data Flow Diagram 1.2.3 - SC Process Control loops"

1. should there be a bubble labeled "self test", if not on this page, then where?

Should it be from the UI?

2.

3.

FIGURE 4-19. Data Flow Diagram 2.0 - OBS

issues on FIGURE 4-19., "Data Flow Diagram 2.0 - OBS"

1. We discussed several different ways of organizing the OBS data flow. One obvious way was to follow the same categories as used in some other documentation. (science path, wavefront sensing path, etc.). While that organization would certainly have it's benefits, the draw back was that it would have separated devices that seemed to belong together (for example the VDC and the IDC would have been in different categories.) We instead elected to group devices that were more similar in function and base our grouping less on bench geography.

Keep in mind that these divisions used are more for the convenience of drawing DFD's than they are for software architectural hierarchy.

2.

FIGURE 4-20. Data Flow Diagram 2.1 - OBS Rotational Tracking Devices

Comments on FIGURE 4-20., "Data Flow Diagram 2.1 - OBS Rotational Tracking Devices"

1. Time? It comes from OBS VME crate. But what about the time stamped demand? Should I show that as coming from somewhere else?

wlupton notes: I would show time stamp as coming with demand and current time ad direct input to mechanism; implication is that mechanism interpolates demand to current time [we have a generic EPICS interpolation record which should do the job.

2. How is image rotator position demand generated, and by whom. If it is calculated by the same code as currently used within the TCS, then it will automatically take into account the telescope anomalies.

wlupton notes: If DCS knows tracking mode "position angle" and generate rotator demands directly; this allows it to account for telescope imperfections, especially near zenith. It could send a corrected parallactic angle and the AO could co the calculation; not sure which is best...

FIGURE 4-21. Data Flow Diagram 2.2 - OBS Sensors

Comments on FIGURE 4-21., "Data Flow Diagram 2.2 - OBS Sensors"

1. Some of the devices on the OBS that might be considered 'sensors' are place in the Alignment, Calibration and Diagnostic section. The sensors on this DFD are those that are used as an integral part of AO system operation.

2. Wavefront Sensor in this context is much more than the GTRI wavefront sensing camera. Here it means the camera, it's focus stage, camera mounting stage,

3. Should I show TAT here? Time Avg. Tilt used for measuring nods.

FIGURE 4-22. Data Flow Diagram 2.3 - OBS Diagnostic Devices

Comments on FIGURE 4-22., "Data Flow Diagram 2.3 - OBS Diagnostic Devices"

1. Perhaps the telescope simulator should receive AZ/EL from DCS for the purpose of controlling the rotating pupil mask.

2.

FIGURE 4-23. Data Flow Diagram 2.4 - OBS Bench Setup

Issues on DFD FIGURE 4-23., "Data Flow Diagram 2.4 - OBS Bench Setup"

1. We made a conscious decision to put the IN/OUT motion of the IR ADC on this DFD. Note that the other 2 degrees of freedom are on diagram 2.1. rotatiional tracking devices. They are separated because obvious differences in use. The rotational degrees of freedom are used during closed loop operation, and the in/out degree of freedom is only used during bench set-up.

2.

FIGURE 4-24. Data Flow Diagram 2.2.1 - OBS Sensors - Wavefront Sensing

Questions on FIGURE 4-24., "Data Flow Diagram 2.2.1 - OBS Sensors - Wavefront Sensing"

2. Which bubble owns the AFM/SOD device?

3. do Xim, Yim come into the FSM over the "command" arrow? or directly from somewhere?

4. nodding (offsetting) and diff. tracking inputs to FSMs?

5. NIRC2 z shifts should appear as an arrow into FCS? and TSS?

6. What about focus shifts due to AFM beam splitter presence/absence?

Does that focus shift also go to FCS and TSS?

7. The FCS moves in response to the DC portion of the focus as sensed by the WFS looking at the laser spot. The SC is the one that controls this? Therefore those commands will come in through the FCS CMDS?

8. Where do Xim, Yim come from.

9. for LGS mode, if the focus stage is being driven open loop to follow elevation, what is the sodium layer height used? (h0) Where does it come from?

FIGURE 4-25. Data Flow Diagram 2.2.1.5 - OBS Sensors - Wavefront Sensing Setup

Comments on FIGURE 4-25., "Data Flow Diagram 2.2.1.5 - OBS Sensors - Wavefront Sensing Setup"

FIGURE 4-26. DFD 2.2.2 OBS Sensor - Tilt/Focus

Notes on FIGURE 4-26., "DFD 2.2.2 OBS Sensor - Tilt/Focus"

1. The TSS config file set must include the field dependent error correction calibration file.

2. The Neutral Density Filter wheel is not shown on this drawing. Remember that it is under the control of the WFC, but through the UISC/WFC interface, we have some measure of control. Probably that control will come from the SC though, not really from the OBS computer.

3. "enable field dependent error corrections" should come over the command line. Remember to include it.

FIGURE 4-27. Data Flow Diagram for NGS Closed Loop Operation

Issues on FIGURE 4-27., "Data Flow Diagram for NGS Closed Loop Operation"

FIGURE 4-28. Data Flow Diagram for closed loop LGS operation

Comments on FIGURE 4-28., "Data Flow Diagram for closed loop LGS operation"

1. I attempted to keep the lines on this drawing from crossing, but I was unable to do so. As people commented on the drawing, and additional lines were drawn that were previously omitted, the problem became even worse. Sorry.

2. I show the TTO data originating from the TTM instead of the T/FS.

TABLE 4-3. File Library
Library Name Files list
AO Configuration 
.......LS Configuration Files 
........OBS Configuration Files 
 Diagnostic (Diag.) Configuration
 Tracking Devices (TD) Configuration
 Sensor Component (OS) Configuration
  
  
  
  
  
........UISC Configuration Files 
........WFC Configuration Files 
  
  

AO Software Design Book - 25 FEB 1997

Generated with Harlequin WebMaker

Back to the Keck Home Page
Back to the Keck AO Page