project documentation document spec-0181 revision draft

D R A F T

Project Documentation

Document SPEC-0181

Revision DRAFT

Wavefront Correction Control System Critical Design Definition

Erik Johansson, Keith Cummings, Mark Drobilek, Scott Gregory, Luke Johnson, Kit Richards,

Friedrich Wöger

WFC Group

January 2015

D R A F T


SPEC-0181, Revision A Page ii

REVISION SUMMARY:

1. Date: January 2015 Revision: DRAFT Changes: Initial draft.

D R A F T


SPEC-0181, Revision A Page iii

Table of Contents

1 OVERVIEW ........................................................................................................... 1

1.1 DOCUMENT SCOPE ................................................................................................. 1

1.2 DELIVERABLES ....................................................................................................... 1

1.3 RELATED DOCUMENTS ............................................................................................ 1

1.3.1 Related DKIST Project Documents.............................................................................. 1

1.3.2 Interface Control Documents and Drawings .............................................................. 1

1.3.3 Other Documents and References .............................................................................. 2

1.4 DEFINITIONS AND TERMINOLOGY .............................................................................. 2

1.5 COMPLIANCE MATRIX .............................................................................................. 3

2 OVERVIEW ........................................................................................................... 4

3 USE CASES .......................................................................................................... 6

3.1 STARTUP................................................................................................................ 7

3.2 IDLE ....................................................................................................................... 8

3.3 CALIBRATE............................................................................................................. 8

3.4 DIFFRACTION LIMITED OBSERVING ........................................................................... 9

3.5 SEEING LIMITED ON DISK OBSERVING ...................................................................... 9

3.6 SEEING LIMITED CORONAL OBSERVING .................................................................... 9

3.7 LIMB TRACKING ...................................................................................................... 9

3.8 SHUTDOWN ............................................................................................................ 9

4 DETAILED DESIGN ............................................................................................ 10

4.1 WCCS CONTROLLER............................................................................................ 10

4.1.1 Attributes .....................................................................................................................10

4.1.2 Properties ....................................................................................................................14

4.1.3 Extended and Custom Methods .................................................................................14

4.2 CALIBRATION SEQUENCER .................................................................................... 14

4.2.1 Attributes .....................................................................................................................15

4.2.2 Properties ....................................................................................................................16

4.3 EVENTS ................................................................................................................ 16

4.3.1 Events Subscribed to by the WCCS ...........................................................................16

4.3.2 Events Published by the WCCS .................................................................................16

4.4 HEADER DATA PUBLISHED BY THE WCCS ............................................................. 17

4.5 INTERLOCKS ......................................................................................................... 18

D R A F T


SPEC-0181, Revision A Page iv

4.6 LOGGING .............................................................................................................. 18

4.7 HEALTH AND ALARMS ........................................................................................... 18

4.7.1 Health ...........................................................................................................................18

4.7.2 Alarms ..........................................................................................................................19

5 GUI SCREENS .................................................................................................... 20

5.1 WCCS STATUS SCREEN ....................................................................................... 20

5.2 CONTEXT VIEWER DISPLAY ................................................................................... 20

5.3 HOAO ENGINEERING SCREENS ............................................................................. 21

5.4 LOWFS SCREENS................................................................................................ 21

5.5 CONTEXT VIEWER SCREENS .................................................................................. 21

5.6 AO ENGINE SCREENS ........................................................................................... 21

5.7 LIMB TRACKER SCREENS ...................................................................................... 21

6 USE CASE DETAILS .......................................................................................... 36

6.1 STARTUP.............................................................................................................. 36

6.2 IDLE ..................................................................................................................... 36

6.3 DIFFRACTION LIMITED ON-DISK (WFC-OPM1) ...................................................... 37

6.4 SEEING LIMITED ON DISK OBSERVING (WFC-OPM2) ............................................. 38

6.5 SEEING LIMITED CORONAL OBSERVING (WFC-OPM3) ........................................... 39

6.6 LIMB OCCULTING WITH IMAGE STABILIZATION (WFC-OPM4) .................................. 40

6.7 CALIBRATIONS ..................................................................................................... 41

6.7.1 Dark Calibrations .........................................................................................................41

6.7.2 Gain Calibrations .........................................................................................................43

6.7.3 Boresight Alignment Calibration ................................................................................44

6.7.4 Context Viewer Calibrations .......................................................................................45

6.7.5 Field Steering Mirror Calibrations ..............................................................................47

6.7.6 High Order / Low Order Focus Calibrations ..............................................................48

6.7.7 Subaperture Offset Calibrations .................................................................................49

6.7.8 Non-Common Path Offset Calibrations .....................................................................50

6.7.9 Wavefront Sensor Field Size and Rotation Calibrations ...........................................51

6.7.10 HOWFS DM Registration Calibration .........................................................................52

6.7.11 HOAO System Matrix Calibrations .............................................................................52

6.7.12 m2Zero .........................................................................................................................53

6.7.13 pupilStabilization .........................................................................................................53

D R A F T


SPEC-0181, Revision A Page v

6.7.14 WFC-Assisted Alignment ............................................................................................54

6.7.15 Routine Alignments .....................................................................................................54

6.7.16 Special ..........................................................................................................................54

6.7.17 Limb Tracker ................................................................................................................54

6.8 SHUTDOWN .......................................................................................................... 55

7 HARDWARE REQUIREMENTS ......................................................................... 56

D R A F T


SPEC-0181, Revision A Page 1 of 56

1 OVERVIEW

1.1 DOCUMENT SCOPE

This document describes the design of the Wavefront Correction Control System (WCCS), the top-level

control interface for the DKIST Wavefront Correction System (WFC). The WCCS is the main control

interface through which the WFC is operated during normal observing. The WCCS is a subsystem of the

Telescope Control System (TCS) and receives its normal operating configurations from the TCS. The

WCCS may also be operated independently of the TCS using the WCCS Engineering GUIs; however,

this is normally done only for engineering and troubleshooting purposes. The requirements for the WCCS

are specified in SPEC-0124, the WCCS DRD, and flow from SPEC-0058 and SPEC-0129.

1.2 DELIVERABLES

The deliverables for the WCCS critical design are contained in three documents:

SPEC-0181, the WCCS Critical Design Document (this document)

SPEC-0124, the WCCS Design Requirements Document

ICD 2.3-4.4 WCCS to TCS

The DRD contains all the WCCS design requirements. The requirements are captured and summarized in

the WCCS compliance matrix, CMX-0020.

1.3 RELATED DOCUMENTS

1.3.1 Related DKIST Project Documents

SPEC-0001, Science Requirements Document (SRD)

SPEC-0005, Software and Controls Requirement, (SCR)

SPEC-0012, ATST Acronym List and Glossary

SPEC-0013, Software Concepts Definitions

SPEC-0014, Software Design

SPEC-0022, Common Services Framework Reference Design (CSF)

SPEC-0036, Operational Concepts Definitions

SPEC-0058, Wavefront Corrections (WFC) Systems Specifications Document (WSRD)

SPEC-0063, Interconnects and Services

SPEC-0129, Wavefront Correction Operational Concepts Model, (WOCD)

SPEC-0147, High Order Adaptive Optics Critical Design Definition (CDD)

SPEC-0180, Wavefront Correction Context Viewer CDD

SPEC-0176, Wavefront Correction Active Optics Engine CDD

SPEC-0168, Limb Tracker CDD

SPEC-0142, Low Order Wavefront Sensor CDD

1.3.2 Interface Control Documents and Drawings

ICD 2.3 – 4.4 WCCS to TCS

ICD 2.3 – 4.3 WCCS to DHS

ICD 1.2 – 2.3 M1 Assembly to WCCS

ICD 1.3 – 2.3 TEOA to WCCS

ICD 1.5 – 2.3 Feed Optics Assembly to WCCS

D R A F T



1.3.3 Other Documents and References

Scilab 1.3.3.1

Scilab web pages:

http://en.wikipedia.org/wiki/Scilab

www.scilab.org

www.scilab.org/scilab/about

http://help.scilab.org/docs/5.5.1/en_US/index.html

Scilab documents:

Computation in Scilab (Scilab_Computation.pdf)

Introduction to Scilab (introscilab.pdf)

1.4 DEFINITIONS AND TERMINOLOGY

Acronym Meaning

DKIST

CSF

DIQ

Advanced Technology Solar Telescope

Common Services Framework

Delivered Image Quality

DRD

FTT

Design Requirements Document

Fast Tip-Tilt

ms millisecond, 10-3

second

nm nanometer, 10-9

meter

OCD Operational Concepts Definition

SRD

WCCS

WFC

Science Requirements Document

Wavefront Correction Control System

Wavefront Correction System


http://www.scilab.org/

http://www.scilab.org/scilab/about

http://help.scilab.org/docs/5.5.1/en_US/index.html

D R A F T



1.5 COMPLIANCE MATRIX

The requirements in this document all trace back to the WCCS DRD, SPEC-0124, through the WCCS

compliance matrix, CMX-0020, which exists as a separate document.

The WCCS compliance matrix traces requirements to the original source documents; these requirements

are only found in the WCCS compliance matrix (not in the body of the DRD) and serve as a mechanism

to flow requirements through the DRD into the CDD. Each top-down requirement in the WCCS

compliance matrix contains references the DRD requirement which it flows down to and the CDD

implementation that satisfies the requirement.

The DRD also develops additional requirements, found in the various body sections of the DRD. The

compliance matrix traces all design requirements developed in the DRD to the body of the CDD.

Bottom-up requirements also contain references to the CDD section which justify them, the DRD section

that they flow to, and the higher level requirements that they derive from. In this way, all requirement

flows, both top-down and bottom-up, are traceable through the WCCS compliance matrix.

D R A F T



2 OVERVIEW

The WCCS is the top-level control system for the DKIST Wavefront Correction System (WFC). It is a

first-light deliverable along with the first-light WFC subsystems: the High Order Adaptive Optics

(HOAO), Low Order Wavefront Sensor (LOWFS), Context Viewer (CV) and Active Optics Engine (aO).

The WCCS is the entity through which the WFC is controlled during normal observing operations. It is a

subsystem of the Telescope Control System (TCS), which is responsible for its configuration. The TCS

controls the WFC primarily through the use of the WFC Mode parameter, as defined in SPEC-0129,

WFC Operational Concepts Definition. The modes are off, idle, calibrate, diffractionLimited,

seeingLimitedOnDisk, seeingLimitedCoronal, and limbTracking. The WCCS responds to the receipt of a

new WFC Mode by configuring the WFC subsystems as required for the mode and forwarding any

additional parameters received to the appropriate subsystems.

The WCCS is also responsible for receiving and processing AO Lock Points from the TCS via the OCS

Target Selection Tool. The lock points are sent to the HOAO and/or LOWFS subsystems as required and

used to position the field steering mirrors for these legs to center the lock point on the particular

wavefront sensor. Moreover, the WCCS is also responsible for receiving requests from the TCS to

perform centroid computations in support of nighttime pointing map updates and limb finding in support

of daytime coordinate system initialization. Finally, the WCCS is responsible for sequencing the WFC

through all of its calibrations in an automated fashion. The WCCS may directly configure the optical

sources, targets and pinholes in the GOS when performing these automated calibration procedures by

sending configurations directly to the Polarimetry, Analysis and Calibration (PA&C) system.

With the exception of the CPUs on which the WCCS and its GUIs are deployed, it is entirely a software

control system. The WCCS does not contain nor has direct control over any hardware, optics, mechanical

mounts, stages or servo control equipment. Control of any of these items in the WFC is performed by the

respective WFC subsystems. The WCCS software consists of three fundamental areas: a top-level

controller, a calibration sequencer, and a set of GUIs. The WCCS software will be implemented using the

DKIST Common Services Framework as specified in SPEC-0022, Common Services Framework: Users’

Manual, and will be written according to DKIST software concepts and requirements as outlined in

SPEC-0005, Software and Controls Requirements, and SPEC-0013, Software Concepts Definition.

Figure 1: WCCS System Context

Observatory Control System

(OCS)

Telescope Control System (TCS)

Wavefront Correction Control

System (WCCS)

Limb Tracker (LT)Context Viewer

(CV)

Low-Order Wavefront Sensor

(LOWFS)aO Engine

High Order Adaptive Optics

(HOAO)

D R A F T



The WCCS is the top-level control interface for the WFC system, which is illustrated above in Figure 1.

A context diagram of the WCCS software is illustrated below in Figure 2. The WCCS is normally

commanded through CSF configurations from the OCS via the TCS. When a configuration is received,

the WCCS acts on it accordingly and configures its subsystems appropriately for the desired mode of

operation. Configurations may also be submitted to the WCCS from the WCCS Engineering GUI screens.

During calibrations the WCCS may send configurations to the PA&C to control the GOS sources and

targets used in the WFC calibration procedures. Finally, WFC calibrations may be executed by scripts in

the WCCS Calibration Sequencer, which will connect and submit configurations as required to the WFC

subsystems or the PA&C as required.

Figure 2: WCCS high-level control software context diagram.

D R A F T



3 USE CASES

During normal operation the WCCS receives commands (configurations) from the TCS originated by

operator action at the OCS. It may also be controlled by the WFC Specialist from the WCCS Engineering

GUI. The operational mode of the WCCS is primarily determined by the WFC Mode parameter as

discussed earlier. A detailed description of the modes is given in Section 2.2 of SPEC-0129, Wavefront

Correction Operational Concepts Definition, and is not repeated here. An abbreviated summary is shown

in the table below. In general, the WCCS needs only to forward the WFC Mode parameter along with any

other relevant parameters it receives to the WFC subsystems. Each subsystem responds with the correct

behavior for the requested mode.

WFC Mode Meaning for the WCCS

off In off mode all WFC subsystems have executed their shutdown procedures and

are powered off.

idle The WFC is standing by but is not performing any wavefront correction or

actively controlling any telescope mirrors. All subsystems are powered on and

operational. M5 and M10 are commanded to their static mid-range positions.

Normal status events are published and CV images are available to be

displayed.

calibrate The WCCS will execute the requested calibration procedure(s).

diffractionLimited M5 and M10 are driven to actively correct the wavefront on the HOWFS.

Pupil position measurements and DM low order modes are sent to the aO

Engine for offloading and correction using M1, M2, M3 and M6.The LT is

idle. The CV continually displays images.

seeingLimitedOnDisk M10 is driven to its static position. M5 is driven to actively correct tip-tilt

using the HOWFS. Pupil position measurements from the HOAO and low

order modes from the LOWFS are sent to the aO Engine for offloading and

correction using M1, M2, M3 and M6. The LT is idle. The CV continually

displays images.

seeingLimitedCoronal The WFC is standing by but is not performing any wavefront correction or

controlling any telescope mirrors. All subsystems are powered on and

operational and M5 and M10 are commanded to their static positions. Normal

status events are published and CV images are available to be displayed.

limbTracking The WFC is standing by but is not performing any wavefront correction. M5

and M10 are driven to their static positions. The LT subsystem is active and

driving the M2 FTT stage based on input from the limb sensor. Normal status

events are published and CV images are available to be displayed.

Table 1: A summary of the various WFC modes overall system behavior for each mode.

In addition, the WFC provides support for night time pointing map calculations and daytime telescope

coordinate system initialization. These tasks are treated as calibrations and specified in a similar manner

as other WFC calibration procedures. Overviews of the various use cases are described below. Detailed

descriptions of the actions taken in each use case are described in detail in Section 6.

D R A F T



A UML Use-Case diagram for the WCCS is shown below.

Figure 3: WCCS Use Case diagram.

3.1 STARTUP

The WCCS starts up automatically when its host computer is powered on and booted. The power on can

be initiated from the OCS during the facility startup task or from the WCCS Engineering Screens. This

will cause the CSF environment to be started up, all WCCS software components to be deployed and

sequenced through their lifecycle initialization states (this does not include the WCCS sub-systems).

When this is complete, all of the WCCS software components will be deployed and running. The host

computer that runs the WCCS software will be specified such that the system will be operational and

ready to receive and act upon commands within 5 minutes of a cold power-off start.

D R A F T



At this point, the WCCS software is up and running, but the WCCS as a system must still be started up.

To accomplish this, the TCS sends a CSF Configuration instructing the WCCS to go to the idle WFC

mode, which is discussed in more detail below.

3.2 IDLE

The idle mode may be entered form any other mode. When transitioning to the idle mode, the WCCS

instructs all the WFC subsystems to go to the idle mode as well. If the WCCS has just been initialized, it

will also forward a startup command to each WFC subsystem. Each subsystem then performs its own

startup procedure, initializing all devices to their default states as specified in the CSF Property Database

and preparing itself for normal operation.

3.3 CALIBRATE

The calibrate mode is used to command the WCCS to perform desired calibrations. The calibrate mode

may be entered from any mode except off. The following calibrations are available:

Automated calibrations:

o Dark

o Gain

o Boresight Alignment

o Context Viewer Focus

o LOWFS Field Steering Mirror Centering

o LOWFS Field Size and Rotation

o LOWFS Focus

o LOWFS Subaperture Offsets

o HOWFS Field Steering Mirror Centering

o HOWFS Field Size and Rotation

o HOWFS Focus

o HOWFS Subaperture Offsets

o DM Registration

o HOAO System Matrix

o HOWFS Internal NCP Correction

o LOWFS Internal NCP Correction

o M2 Zero Point

o Pupil Stabilization

o WFC-Assisted Alignment

o WFC Routine Calibration

Manual calibrations:

o LOWFS Field Stop Alignment

o HOWFS Field Stop Alignment

o TTM Interaction Matrix Calibration

Automated calibrations are specified using the calibrate attribute (described later later). Some of the

calibrations involve invoking other calibrations at the WFC subsystem level. The WCCS accomplishes

this by forwarding the WFC Mode parameter (set to calibrate) along with a calibrate parameter indicating

the calibration to be performed to each subsystem as required. Initially calibrations will be implemented

by running scripts in the WCCS Calibration Sequencer (described below in the software design section).

This gives us the freedom to modify the calibration routines as needed without having to recompile the

D R A F T



WCCS controller source codes. Later, as we gain more experience with the calibrations, some of the

processes may be converted to Java code and incorporated as part of the WCCS controller or the WFC

subsystems. The manual calibrations may require personnel access to the WFC optical bench in the coudé

area and are only performed in special circumstances (not as part of a daily routine calibration). The

details of these calibrations are listed in Section 6.7 below.

3.4 DIFFRACTION LIMITED OBSERVING

The diffractionLimited mode is used to command the WFC to operate in Diffraction Limited On-Disk

mode (WFC-OPM1) as described in SPEC-0129. The WCCS accomplishes this by forwarding the WFC

Mode parameter to all the WFC subsystems along with any additional parameters for each subsystem

provided by the TCS.

3.5 SEEING LIMITED ON DISK OBSERVING

The seeingLimited mode is used to command the WFC to operate in Seeing Limited On-Disk mode

(WFC-OPM2) as described in SPEC-0129. The WCCS accomplishes this by forwarding the WFC Mode

parameter to all the WFC subsystems along with any additional parameters for each subsystem provided

by the TCS.

3.6 SEEING LIMITED CORONAL OBSERVING

The seeingLimitedCoronal mode is used to command the WFC to operate in Seeing Limited Coronal

mode (WFC-OPM3) as described in SPEC-0129. This mode is essentially the same as the idle mode, but

is treated separately so that the WFC behavior in this mode may be changed in the future if needed. The

WCCS commands the WFC to go into this mode by forwarding the WFC Mode parameter to all the WFC

subsystems along with any additional parameters for each subsystem provided by the TCS.

3.7 LIMB TRACKING

The limbTracking mode is used to command the WFC to operate in Limb Occulting with Image

Stabilization mode (WFC-OPM4) as described in SPEC-0129. The WCCS accomplishes this by

forwarding the WFC Mode parameter to all the WFC subsystems along with any additional parameters

for each subsystem provided by the TCS.

3.8 SHUTDOWN

Shutdown of the WCCS may be initiated from the OCS or from the WCCS Engineering GUI by sending

a CSF configuration with the WFC Mode attribute set to off. During shutdown the WCCS will perform

the following actions:

Command all the WFC subsystems to go to the idle mode

Once all subsystems are in the idle state, they are commanded to go to the off state

All of the WFC computers and systems may now be powered off.

D R A F T



4 DETAILED DESIGN

4.1 WCCS CONTROLLER

The WCCS Controller is the top-level controller for the WFC and is responsible for managing the overall

operation of the WFC System. It is an extension of the CSF/Base Java Management Controller class. The

CSF device name for the WCCS controller is atst.tcs.wccs and the controller itself is referred to as simply

the WCCS controller.

The TCS controls the behavior of the WFC by sending CSF Configurations to the WCCS instructing it to

configure the WFC for the desired mode of operation. Only a few attributes are required for the WCCS to

control the operation of the WFC system. These attributes are defined in ICD 2.3-4.4, Wavefront

Correction Control System to Telescope Control System, which is the defining document for the control

interface of the WCCS (the public interface, or API, for the WCCS). The full set of attributes available

for each WFC subsystem is described in detail in the Critical Design Document for that subsystem. The

public interface for the WCCS is only a small subset of these attributes, many of which have default

values that are downloaded from the CSF Property Database when the WCCS and its subsystems are

initialized. These default values may be overridden by including the particular attributes in the CSF

Configuration sent to the WCCS. The WCCS forwards these attributes to the appropriate WFC

subsystems, which act on them accordingly. The sets of parameters commonly used to control the

operational modes of the WFC System are listed in the detailed description of the use cases presented in

Section 5 below.

During calibration mode, the WCCS will forward its configurations to the Calibration Sequencer for

processing. The sequencer will download the appropriate calibration script from the CSF Script Store and

execute the desired calibration, forwarding any additional attributes received in the original configuration

to the WFC subsystems as required. This is discussed in further detail below in Section 4.2 on the

Calibration Sequencer.

Finally, all parameters required to control the WCCS are also available through the WCCS Engineering

GUI, which has access to the full set of attributes for the entire WFC system.

4.1.1 Attributes

The following attributes are received and acted upon by the WCCS controller.

The top-level WCCS attributes are the minimum set of attributes required to operate the WFC. The

WCCS and all WFC subsystems maintain their internal states so configurations need only be sent to the

WCCS when a change in the operational state of the WFC is required. As a result, all of the attributes

listed below are optional. However, as noted in the detailed descriptions below, the calibrate attribute

requires either the current WFC mode to be calibrate or they must be accompanied by a command to go

to the calibrate mode. All of the WFC subsystem attributes are optional.

Name Type Units Range Comment

atst.tcs.wccs

mode String Choice See below The desired WFC operational mode

calibrate String[] None See below List of specific calibration tasks to be

performed

hoaoLockPoint Real[2] Arc-sec ±30 The HOAO lock point

lowfsLockPoint Real[2] Arc-sec ±30 The LOWFS lock point

D R A F T



hoao.<attribute name> Varies Varies Varies Attributes for the HOAO subsystem of the

WFC

lowfs.<attribute name> Varies Varies Varies Attributes for the LOWFS subsystem of the

WFC

cv.<attribute name> Varies Varies Varies Attributes for the CV subsystem of the WFC

ao.<attribute name> Varies Varies Varies Attributes for the AO Engine subsystem of the

WFC

lt.<attribute name> Varies Varies Varies Attributes for the LT subsystem of the WFC

mode 4.1.1.1

Data Type: String

Units: Choice

Valid Values: off | idle | calibrate | diffractionLimited | seeingLimitedOnDisk | seeingLimitedCoronal

| limbTracking

Default Value: None

This attribute determines the operational mode of the WFC as described previously. This attribute is

optional. If this attribute is not present, other attributes in the configuration will be sent to the appropriate

WFC subsystems, but the overall mode of the WFC does not change. If a subsystem is not able to process

the attributes forwarded by the WCCS, it will result in an error response that is propagated back up to the

WCCS and, finally, the TCS.

calibrate 4.1.1.2

Data Type: String[]

Units: N/A

Valid Values: Name(s) of calibration procedures to be run

Default Value: None

This attribute contains a list of names of calibration procedures to be executed by the WCCS in the

specific order given in the array. The available calibrations are shown in the table below. This parameter

is required if the accompanying mode attribute in the configuration is set to calibrate. It is ignored

otherwise and a warning will be logged. Some calibrations require special actions: sources or targets

inserted at the GOS or random TMA motion. WFC calibrations are described in detail in Section 6.7.

Note: the special calibration is used to download and execute a calibration script from the CSF Script

Database. In the case of special, the next value in the calibrate array is used as the name of the script to be

downloaded from the CSF Script DB and executed.

Name Meaning

lowfsDark Perform a dark calibration on the LOWFS

howfsDark Perform a dark calibration on the HOWFS

cvDark Perform a dark calibration on the CV

D R A F T



allDark Perform simultaneous dark calibrations on the LOWFS,

HOWFS and CV

lowfsGain Perform a gain calibration on the LOWFS

howfsGain Perform a gain calibration on the HOWFS

cvGain Perform a gain calibration on the CV

allGain Perform simultaneous gain calibrations on the LOWFS,

HOWFS and CV

boresight Perform a telescope boresight alignment

cvFocus Perform a focus calibration on the CV

cvNightTime Perform a nighttime centroid calculation using the CV

cvLimbFinding Perform a daytime limb finding calculation using the CV

lowfsFSM Perform a FSM centering calibration on the LOWFS

lowfsFocus Perform a focus calibration on the LOWFS

lowfsSubapOffset Perform a subaperture offset calibration on the LOWFS

lowfsNCP Perform an internal NCP calibration on the LOWFS

howfsFSM Perform a FSM centering calibration on the HOWFS

howfsFocus Perform a focus calibration on the HOWFS

howfsSubapOffset Perform a subaperture offset calibration on the HOWFS

howfsNCP Perform an internal NCP calibration on the HOWFS

howfsDmReg Perform a DM registration calibration on the HOWFS

hoaoSysMatZonal Perform a zonal HOAO system matrix measurement

hoaoSysMatModal Perform a modal HOAO system matrix measurement

hoaoDmGain Perform a DM actuator gain calibration

instrumentNCP Perform an instrument NCP calibration

m2Zero Perform an M2 zero pointing calibration

pupilStabilization Perform pupil stabilization

wfcAssistCal Perform a WFC-assisted alignment

routine Performs the full set of routine daily calibrations

special Perform a special WFC calibration. The next value in the

calibrate array is used as the name of the calibration script to

be downloaded from the CSF Script DB and executed.

hoaoLockPoint 4.1.1.3

Data Type: Real[2]

Units: Arc-seconds

Valid Values: -30 to +30 arc-seconds

Default Value: [0, 0]

This attribute defines the location of the HOAO Lock Point as an (x, y) offset in arc-seconds from the

telescope boresight in the coordinate system of the WFC Context Viewer. The WCCS forwards this

attribute to the HOAO subsystem, which moves the HOWFS field steering mirror so that the specified

lock point is centered on the optical axis of the HOWFS. The lock point will only be accepted by the

WCCS when the WFC is in an operational mode other than diffractionLimited or seeingLimitedOnDisk.

The lock point is actively used in these modes and cannot be changed without impacting the performance

of the WFC and the quality of the wavefront delivered to the instruments. If a lock point is received when

D R A F T



the WCCS is in one of these two modes it will be rejected with an error. The lock point attribute may,

however, be sent to the WCCS in the same configuration as the mode attribute when transitioning to one

of these two modes. The lock point parameter is optional; if it is not included in a configuration then the

previous lock point remains in effect (i.e., the HOWFS FSM remains in its current position). The default

value for the lock point is the telescope boresight: (0, 0).

lowfsLockPoint 4.1.1.4

Data Type: Real[2]

Units: Arc-seconds

Valid Values: -30 to +30 arc-seconds

Default Value: [0, 0]

This attribute defines the location of the LOWFS Lock Point as an (x, y) offset in arc-seconds from the

telescope boresight in the coordinate system of the WFC Context Viewer. The WCCS forwards this

attribute to the LOWFS subsystem, which moves the LOWFS field steering mirror so that the specified

lock point is centered on the optical axis of the LOWFS. The LOWFS lock point will be accepted by the

WCCS in any operational mode. The lock point attribute may be sent to the WCCS in the same

configuration as the mode attribute when transitioning to a different WFC mode. The lock point

parameter is optional; if it is not included in a configuration then the previous lock point remains in effect

(i.e., the LOWFS FSM remains in its current position). The default value for the lock point is the

telescope boresight, (0, 0).

hoao.<attribute name> 4.1.1.5

These are attributes to control various features of the HOAO WFC subsystem. The full set of HOAO

attributes are documented in SPEC-0147, the HOAO CDD. These attributes are forwarded by the WCCS

or the Calibration Sequencer to the HOAO Controller for processing.

lowfs.<attribute name> 4.1.1.6

These are attributes to control various features of the LOWFS WFC subsystem. The full set of LOWFS

attributes are documented in SPEC-0142, the LOWFS CDD. These attributes are forwarded by the

WCCS or the Calibration Sequencer to the LOWFS Controller for processing.

cv.<attribute name> 4.1.1.7

These are attributes to control various features of the CV WFC subsystem. The full set of CV attributes

are documented in SPEC-0180, the CV CDD. These attributes are forwarded by the WCCS or the

Calibration Sequencer to the CV Controller for processing.

ao.<attribute name> 4.1.1.8

These are attributes to control various features of the AO Engine WFC subsystem. The full set of AO

Engine attributes are documented in SPEC-0176, the AO Engine CDD. These attributes are forwarded by

the WCCS or the Calibration Sequencer to the AO Engine Controller for processing.

D R A F T



lt.<attribute name> 4.1.1.9

These are attributes to control various features of the LT WFC subsystem. The full set of LT attributes are

documented in SPEC-0168, the LT CDD. These attributes are forwarded by the WCCS or the Calibration

Sequencer to the LT Controller for processing.

4.1.2 Properties

The CSF properties associated with the WCCS Controller will be identified and documented during

implementation. They will include the following:

Typical CSF parameters such as csf:threadModel, csf:numThreads, csf:maxThreads,

csf:fullThreadAction, etc.

Any default values needed by the WCCS Controller when it first starts up.

To meet its availability requirements, the WCCS Controller will be implemented using a CSF

threadModel of “growable”, with the upper bound on threads to be determined during lab integration and

testing.

4.1.3 Extended and Custom Methods

In order to implement the WCCS controller, some methods of the ManagementController class will have

to be overridden. There are currently no plans for adding custom methods, although that may change

during implementation if it is deemed necessary. The following methods will be overridden for the

reasons listed:

doSubmit() 4.1.3.1

The doSubmit() method will be overridden to implement configuration validation.

Posting TAB, getEventTable() 4.1.3.2

The WCCS controller publishes a periodic status event, so a PostingTAB must be added to the controller

and the getEventTable() method must be implemented to populate the event table.

makeConfig() 4.1.3.3

The makeConfig() method must be overridden to provide custom behavior in how configurations are

distributed to the WCCS subsystems and the Calibration Sequencer.

4.2 CALIBRATION SEQUENCER

The Calibration Sequencer is responsible for sequencing the WCCS through the various steps required to

perform calibrations for the entire WFC system. Calibrations are performed when the WCCS is in the

calibrate mode and it receives a CSF configuration containing the calibrate attribute set to the specific

calibration tasks to be performed. Alternatively, if the WCCS is not in the calibrate mode, calibrations

may be performed if it receives a configuration containing both the WFC mode attribute set to calibrate

and the calibrate attribute set to the specific calibration tasks to be performed (i.e., a command to change

the current WCCS mode to calibrate accompanied by the specific calibrations to be performed).

D R A F T



If the above conditions are met, the WCCS controller will immediately forward the configuration to the

Calibration Sequencer for execution. The Calibration Sequencer will execute the proper procedures based

on the particular calibration task identified in the calibrate attribute. The controller will submit various

commands through CSF configurations to the WFC subsystems to cause them to achieve a desired state at

each point in the procedure.

The Calibration Sequencer will be implemented using an extension of the CSF Base Script Interpreting

Controller. This will allow the calibration procedures to be implemented, tested and debugged using

scripts which can be edited and re-run without the need for recompiling the controller or bringing the

WCCS down. The particular script to be run will be downloaded from the CSF script database or read

from a local file at run time (for development purposes), based on the particular calibration to be

performed. After the scripts have matured, some functions may be implemented in Java for performance

improvements, if desired.

An open source software package called Scilab will be used to implement the scripting engine for the

Calibration Sequencer. It is easily integrated into the existing CSF scripting framework and has support

for advanced numerical and scientific computation. It also allows access to Java objects from within

scripts, which means scripts will have full access to the capabilities of CSF as well. The Scilab package

will also be used for the Calibration Sequencers in the WFC subsystems. More information about Scilab

is available at www.scilab.org and http://en.wikipedia.org/wiki/Scilab.

4.2.1 Attributes

The following attributes are received and acted upon by the Calibration Sequencer. During development

we may add additional attributes for some of the commonly used parameters used in the various

calibration routines, as needed.

Name Type Comment

atst.tcs.wccs

.calibrate String[] The name(s) of the particular calibration tasks to be

accomplished

.calibrate 4.2.1.1

Data Type: String[]

Units: N/A

Valid Values: As defined in Section 4.1.1.2

Default Value: None

The .calibrate attribute is used to indicate the particular calibration tasks to be performed. The values of

the attribute must correspond to the values listed above in Section 4.1.1.2. Each array value represents the

name of a script to be downloaded from the CSF Script DB and executed by the Calibration Sequencer.

When the value is “special”, the next value in the array is used as the script name to be downloaded,

which allows for custom script execution.

http://www.scilab.org/


D R A F T



When the Calibration Sequencer is transitioned from a Jython script controller to a pure Java controller,

this attribute will be used to determine the specific calibration method to be called in the controller.

4.2.2 Properties

The CSF properties associated with the Calibration Sequencer will be identified and documented during

implementation. They will include the following:

Typical CSF parameters such as csf:threadModel, csf:numThreads, csf:maxThreads,

csf:fullThreadAction, etc.

Any default values needed by the Calibration Sequencer when it first starts up.

If additional attributes are added during development, default properties for these attributes will

be added to the property database as well.

4.3 EVENTS

4.3.1 Events Subscribed to by the WCCS

The WCCS subscribes to the following WFC subsystem status events. Please consult the WFC subsystem

CDDs for the details.

Name Rate Comment

atst.tcs.wccs

hoao.cStatus 1 Hz The HOAO subsystem status event

lowfs.cStatus 1 Hz The LOWFS subsystem status event

cv.cStatus 1 Hz The CV subsystem status event

ao.cStatus 1 Hz The AO Engine subsystem status event

lt.cStatus 1 Hz The LT subsystem status event

The WCCS does not subscribe to external events from the TCS or other observatory systems, although

the WFC subsystems do. Readers should consult the WFC subsystems CDDs for information on events to

which the WFC subsystems subscribe (this is also discussed in ICD 2.3/4.4 WCCS to TCS).

4.3.2 Events Published by the WCCS

The WCCS publishes a status event containing the general status of the WCCS and the WFC subsystems.

The status event and its fields are described in the tables below.

Name Rate Comment

atst.tcs.wccs

cStatus 1 Hz The general WCCS status event

D R A F T



cStatus 4.3.2.1

Field Name Type Units Range Comment

timestamp String N/A N/A A timestamp expressed as a valid

AtstDate format

cMode String N/A

off | idle | calibrate |

diffractionLimited |

seeingLimitedOnDisk |

seeingLimitedCoronal

| limbTracking

The current mode of the WCCS/WFC

inPos Boolean true | false

A flag indicating whether the WCCS is

“in position” or not. The WCCS is in

position if the WCCS and all the WFC

subsystems are in their requested or

desired configurations or states.

hoaoLockPoint Real[2] Arc-sec ±30 The HOAO lock point

lowfsLockPoint Real[2] Arc-sec ±30 The LOWFS lock point

status String N/A N/A

A string providing additional status

information (e.g., a list of subsystem(s)

that are not in position, error

information, etc.).

The inPos attribute is calculated as the logical AND of the inPos attributes from all of the WFC

subsystem status events. If any of the WFC subsystems are not in their desired state, including the desired

mode, the WCCS inPos attribute will be false.

4.4 HEADER DATA PUBLISHED BY THE WCCS

The only explicit requirement the WFC has to publish data to the header database is for the value of r0

that is computed by the telemetry processor in the HOAO (see SPEC-0058, Section 4.1.4.6, requirement

2.1.1-0055). However, there are meta-data values listed in SPEC-0122, DKIST Data Model, which are

required to be available in the header database (see Table 1-g, p 20). It is unclear what system is

responsible for posting this data to the header database. It is also unclear whether the data should be

published using the associated FITS keywords or the more descriptive attribute names. In order to

proceed with the design, we assume for now that the WCCS and its subsystems are responsible for

publishing this data to the header database. This data is summarized in the table below.

Published by WFC

Subsystem Attribute Name Type

FITS

Keyword FITS Comment

HOAO preFilterFWHM Real WFC_001 [nm] PreFilterFWHM

HOAO r0 Real AO_001 HOAOFriedParameterVals

HOAO dmLock Boolean AO_002 HOAODMLockStatus

D R A F T



HOAO ttLock Boolean AO_00X HOAOTTFLockStatus

HOAO wfsReconMat String WFC_003 HOAOReconstructionMatrixID

WCCS hoaoLockPointX Real AO_003 [arcs] HOAOLockOffPointingX

WCCS hoaoLockPointY Real AO_004 [arcs] HOAOLockOffPointingY

LT occultingOffset Real AO_005 [arcs] LimbSensorRadialSetPos

LT sensorFrameRate Real AO_006 [Hz] LimbSensorRate

4.5 INTERLOCKS

The WCCS does not respond to any Global Interlock System interlock events. If an interlock event

occurs, the WCCS and all WFC subsystems will automatically reject configurations submitted on their

public interfaces; this is automatically accomplished by CSF.

4.6 LOGGING

General status logging to the log database is accomplished automatically by CSF for the following

categories of events:

lifecycle changes

health changes

connection changes

commands and responses

alarms

In addition we will incorporate logging of debug messages using varying debug levels as outlined in

SPEC-0022, Section 6.3, Debug Messages:

Level 1: at the entry/exit of major code sections (code modules),

Level 2: at the entry/exit of methods and procedures (unless these are expected to be called within

tight loops) and in object constructors (with the same caveat),

Level 3: at key points within methods and procedures (again, outside of tight loops), and

Level 4: within tight loops (should be small messages with critical information only).

These debug messages are intended for diagnostic and engineering purposes.

4.7 HEALTH AND ALARMS

4.7.1 Health

WCCS components will set their health according to the guidelines outlined in SPEC-0022. We use the

following general in the WCCS and throughout the WFC subsystems:

Health is only reported when a component’s health status changes state

If a component is operating normally, its health is GOOD

All WCCS components will set their health to GOOD upon startup and initialization

If a WFC subsystem does not transition to its desired state in response to a WCCS command, or if

a WFC subsystem changes its state without being commanded by the WCCS, the WCCS will set

its overall health to ILL.

D R A F T



If the WCCS determines it is unable to operate properly or detects that one of the WFC

subsystems is not responsive to commands, it will set its health to BAD.

If a component detects a failure within itself or in a hardware component under its direct control

and it is still able to operate, but at a reduced capability, it will set its health to ILL

If a component detects a failure within itself or in a hardware component under its direct control

and it is no longer able to operate, the component will set its health to BAD.

If a component is able to recover from a failure and operate normally, whether by internal means

or by external intervention from the operator, it will return its health to GOOD.

4.7.2 Alarms

Alarms are to be used when operator notification and possible action are required to report equipment

danger or failure, or when continued operation in a malfunctioning state will result in bad data being

recorded either by the system in question or by other systems or instruments impacted by the

malfunctioning system.

We have analyzed the possible failure scenarios for the WCCS, resulting in the following table of failures

and WCCS alarm responses.

Failure Alarm Response

A WFC subsystem reports

it is out of position for an

extended period

If the subsystem is critical to the

performance of the WFC in the

current or requested mode, the WCCS

will raise an alarm.

A call to a CSF service by

a WCCS component fails

If the service is critical to the proper

functioning of the WCCS and to the

viability of the WFC wavefront

measurements, the component in

question will raise an alarm.

A component detects an

internal SW resource

problem

If the resource failure can result in

bad WFC wavefront measurements

being produced, or a cessation of

wavefront measurements, the

component will raise an alarm.

D R A F T



5 GUI SCREENS

The WCCS provides a number of Engineering GUI screens for the operation of the WFC that include the

following:

An engineering screen for each WFC subsystem containing:

o Tabs for controlling the subsystem in each operational WFC mode

o A tab that provides direct control capability for all the devices in the subsystem, with

sub-tabs organized by function and component

o A tab for controlling the logging settings for the subsystem

o A tab for accessing and setting the CSF properties associated with the subsystem

A comprehensive WFC status display screen

A special display screen for the full-size Context Viewer images

These screens are for use by the WFC Specialist or for engineering purposes only. A subset of the

capabilities in these screens will be included in the OCS GUI to provide the main operator interface for

the WFC. In the screen images included below, the items that are shown in “greyed out” format will not

be available from the OCS.

The WFC AO Scientist has provided a number of conceptual GUI screen mockups which are shown in

the following sections. These screens will be used as the starting point for the WCCS/WFC GUI designs.

During development these designs will be implemented and tested and additional features and displays

will be added as needed. These screens will be shared with the appropriate DKIST Science and HLS

personnel as well as the AO operators at the Dunn Solar Telescope and the designs updated based on their

feedback. This process will be iterated during the development cycle until an acceptable set of screens

have been designed.

Each of the basic screens is described in the sections that follow. It must be emphasized that these mock

ups are preliminary and will change during development as they mature and we gain experience operating

the system.

5.1 WCCS STATUS SCREEN

There will be a main status screen for the WCCS that shows the status of the LOWFS, HOWFS, DM and

TTM. The HOWFS display area will include real-time displays of selected subaperture shift vector power

spectra and a modal decomposition of the residual wavefront error. Similarly, the DM display area will

include a real-time display of power spectra for selected actuators, showing either the actuator command

spectra or the residual wavefront error spectra (the residual wavefront error expressed in actuator space),

based on user selection. Finally, the display will include a status image or plot for the M5 tip-tilt mirror. If

possible, the status screen will be implemented using JES. If we are unable to implement the desired

features in JES, we will consider other options (e.g., the display capability in Scilab) to implement the

screen. A mock-up of the status screen is shown below in Figure 4.

5.2 CONTEXT VIEWER DISPLAY

The full-size CV display will be implemented using the new 4k Ultra HD standard, which supports 3840

x 2160 pixels. A mock-up of the CV display using the 4k format is shown below in Figure 5. The 2048 x

2048 image display is centered in the right 2160 x 2160 pixel portion of the screen. The remaining space

on the left is used for basic CV status information: the current time stamp, the current field of view and

plate scale, the current target location in heliocentric coordinates (if this is available), the current HOAO

lock point position as an offset from the boresight in arc-seconds in the WFC coordinate system, and a

D R A F T



histogram of the current image. The boresight of the telescope is the center of the image display and is

highlighted by a dashed reticle with a circle at the center shown in light blue. The target location is shown

by a dashed red circle. The size of the circles is 2”. The histogram will update in real-time with the

updating image.

5.3 HOAO ENGINEERING SCREENS

Mock-ups of the he HOAO Engineering Screens are shown below in Figure 6 - Figure 12. The screens

have main tabs for the WFC Mode, Direct Control, Logging and Properties DB as follows:

WFC Mode: Shows parameter options organized around each particular mode. The calibration

mode has sub-tabs for the HOAO calibrations.

Direct Control: Shows parameter options organized around each component and its various

devices (e.g., the Mechanisms tab shows parameters for controlling all the various HOAO

motorized stages). The Direct Control tab allows the user to control all of the devices in the

HOAO system.

Logging: Shows parameter options associated with turning various logging features on and off

throughout the HOAO system. Note: A screen for the logging tab is not shown in the examples

below.

Properties: Shows options for setting all of the various properties for the HOAO control system

and all its devices. Note: A screen for the Properties DB tab is not shown in the examples below.

5.4 LOWFS SCREENS

Mock-ups of the LOWFS Engineering Screens are shown below in Figure 13 - Figure 15. The

organization of the LOWFS screens is similar to that described above for the HOAO sub-system screens.

5.5 CONTEXT VIEWER SCREENS

Mock-ups of the CV Engineering Screens are shown below in Figure 16 - Figure 17. The organization of

the CV screens is similar to that described above for the HOAO sub-system screens.

5.6 AO ENGINE SCREENS

Mock-ups have not yet been generated for the AO Engine sub-system. Please refer to the AO Engine

CDD for a description of the functionality to be implemented in the AO Engine Engineering Screens.

5.7 LIMB TRACKER SCREENS

Mock-ups have not yet been generated for the LT sub-system. Please refer to the LT CDD for a

description of the functionality to be implemented in the LT Engineering Screens.

D R A F T



Figure 4: A mock-up of the WCCS status screen

D R A F T



Figure 5: A mock-up of the Context Viewer display.

2160pixels

3840 pixels

2160 pixels

2048pixels

UTC: 2019-07-23 18:03:27.542

FOV: 30” Plate Scale: 0.01465”/pixel

Target: Lock Point:

X: 0.99503 X: -8.01

Y: -0.08252 Y: 7.59

Z: 0.05576

Contrast:

Auto

Manual:

0 100

Histogram:

1680 pixels

D R A F T



Figure 6: A mock-up of the HOAO Engineering screen showing the Run Modes tab with the Diffraction Limited On-Disk mode sub-tab selected.

D R A F T



Figure 7: A mock-up of the HOAO Engineering screen showing the Run Modes tab with the Calibrate and Dark calibration sub-tabs selected.

D R A F T



Figure 8: A mock-up of the HOAO Engineering screen showing the Run Modes tab with the Calibrate and gain calibration sub-tabs selected.

D R A F T



Figure 9: A mock-up of the HOAO Engineering screen showing the Run Modes tab with the Calibrate and Focus calibration sub-tabs selected.

D R A F T



Figure 10: A mock-up of the HOAO Engineering screen showing the Run Modes tab with the Calibrate and DM registration calibration sub-tabs selected.

D R A F T



Figure 11: A mock-up of the HOAO Engineering screen showing the Direct Control tab with the Mechanisms and Objective Lens sub-tabs selected.

D R A F T



Figure 12: A mock-up of the HOAO Engineering screen showing the Direct Control tab with the Real-Time Controller sub-tab selected.

D R A F T



Figure 13: A mock-up of the LOWFS Engineering screen showing the LOFWS Modes tab selected.

D R A F T



Figure 14: A mock-up of the LOWFS Engineering screen showing the Direct Control tab with the Mechanisms and Objective Lens sub-tabs selected.

D R A F T



Figure 15: A mock-up of the LOWFS Engineering screen showing the Direct Control tab with the Image Processing Manager sub-tab selected.

D R A F T



Figure 16: A mock-up of the CV Engineering screen showing the CV Modes tab selected.

D R A F T



Figure 17: A mock-up of the CV Engineering screen showing the Direct Control tab with the Mechanisms and 30” Objective Lens sub-tabs selected.

D R A F T



6 USE CASE DETAILS

This section contains detailed descriptions of how WCCS will behave in each of the following use cases.

Note that in general, this behavior is already captured in the WFC subsystem documents. All that is

required to operate the WFC is to send the WFC mode attribute to the WCCS and the rest is automatic.

The WCCS sends the mode attribute to all the subsystems and they respond accordingly. The

explanations are to be included here for completeness and ease of understanding the operation of the

WCCS.

6.1 STARTUP

The daily startup and initialization of the WCCS/WFC is assumed to be initiated by a script in the OCS

which will power-up the WCCS host CPU and all the WFC sub-system CPUs in the proper sequence. The

script will deploy and start the CSF Containers throughout the WCCS/WFC system and then deploy and

start all the CSF Components and Controllers in the system. Each WFC sub-system will ensure all its

controllable devices are powered up during its initialization sequence. This startup sequence may also be

initiated from the WCCS Engineering Screens. We will provide scripts for the WCCS and each of the

WFC sub-systems to implement the behavior described above. These scripts may be adapted for use by

the OCS.

6.2 IDLE

In idle mode, the WFC is standing by. It is not performing active wavefront corrections. The DM and Tip-

Tilt Mirror (TTM) are at their nominal mid-range positions (this may include static offsets at the DM to

correct for non-common path wavefront errors). The CV is publishing images to the BDT.

The following sequence of events is executed by the WCCS to configure the WFC for this mode of

operation:

The WCCS receives and validates a configuration from the TCS containing the WFC mode

attribute set to idle.

The WCCS distributes the mode attribute to all the WFC subsystems. In addition, any other

attributes received in the configuration are passed along to the appropriate subsystems.

The WCCS monitors the cStatus events from all of the WFC subsystems to verify that each

subsystem transitions to idle and shows an in position status of true. The overall WCCS in

position status remains false until all the subsystems attain their desired state.

If any of the WFC subsystems are unable to attain the requested mode within a timeout period,

the overall health of the WCCS is set to ILL.

The WFC subsystems respond to the idle mode with the following behavior:

The HOAO stops actively driving the DM and TTM and commands them to their static mid-

range positions.

The HOAO stops sending TTM offload events to the TCS.

The HOWFS and LOWFS continue to send wavefront and pupil position data to the aO Engine.

The aO Engine stops processing modal wavefront and pupil position data from the HOWFS and

LOWFS.

The CV continues to publish images to the BDT.

D R A F T



The LT goes to idle mode and ceases sending fast tip tilt commands to the M2 hexapod.

All WFC mechanisms and stages remain in their current positions.

All WFC status events and telemetry continue to be published.

6.3 DIFFRACTION LIMITED ON-DISK (WFC-OPM1)

In Diffraction Limited On-Disk mode, the M1CS, TEOACS and FOCS operate in active mode, where

they receive periodic position updates from the WFC Active Optics Engine (aO) to correct for quasi-static

wavefront errors. The TCS configures these subsystems prior to placing the WFC in this mode. The aO

uses pupil position measurements and low order mode measurements from the HOWFS to calculate

corrections for M1, M2, M3, and M6.


operation:


attribute set to diffractionLimitedOnDisk.




subsystem transitions to diffractionLimitedOnDisk and shows an in position status of true. The

overall WCCS in position status remains false until all the subsystems attain their desired state.



The WFC subsystems respond to the diffractionLimitedOnDisk mode with the following behavior:

HOAO:

o Positions its Field Steering Mirror for the new lock point (if needed).

o Sends low-order modal wavefront data and pupil position data to the aO Engine for

processing (the data is sent at all times when the HOAO is operating and the aO Engine

decides whether or not to use the data based in its configuration).

o Attempts to achieve AO lock by actively driving the DM and FTT mirrors to correct for

the wavefront errors measured by the HOWFS.

o If the number of shift vectors that exceed the out of bounds conditions for AO lock are

exceeded, the HOAO returns the DM and FTT to their static mid-range positions and

waits for a specified number of frames before attempting to lock again. This procedure is

described in detail in SPEC-0147, HOAO CDD.

o The HOAO will continue to attempt to achieve AO lock until it is successful or until it is

canceled by the WCCS.

o The WCCS will monitor the lock status of the HOAO and will set alarms and health as

required to notify the operator if the HOAO fails to achieve lock within a user-defined

time period, or if the HOAO loses lock.

o The HOAO telemetry processor sends offload events to the TCS to keep the average

TTM position at mid-range.

o The HOAO continues to publish all status and telemetry data to CSF events and the BDT.

D R A F T



LOWFS:


o Sends low-order modal wavefront data to the aO Engine for processing (the data is sent at

all times when the LOWFS is operating and the aO Engine decides whether or not to use

the data based in its configuration).

o Publishes all normal status and telemetry data to CSF events.

aO Engine:

o Once AO lock is achieved, the aO Engine begins to process low order wavefront and

pupil position data from the HOWFS and sends wavefront correction information to the

M1, M2, M3 and M6 mirror control systems.

The CV continues to publish image data to the BDT and normal status events to CSF.

The LT does nothing and is essentially in idle mode.

6.4 SEEING LIMITED ON DISK OBSERVING (WFC-OPM2)

In Seeing Limited On-Disk mode, the M1CS, TEOACS and FOCS operate in active mode, where they

receive periodic position updates from the WFC Active Optics Engine (aO) to correct for quasi-static

wavefront errors. The TCS configures these subsystems prior to placing the WFC in this mode. The aO

uses low order wavefront measurements from the LOWFS to calculate corrections for M1 and M2 and

pupil position measurements from the HOWFS to calculate corrections for M3, and M6.


operation:


attribute set to seeingLimitedOnDisk.




subsystem transitions to seeingLimitedOnDisk and shows an in position status of true. The overall

WCCS in position status remains false until all the subsystems attain their desired state.



The WFC subsystems respond to the seeingLimitedOnDisk mode with the following behavior:

HOAO:

o Stops actively driving the DM and commands it to its static mid-range position.

o Sends pupil position data to the aO Engine for processing (the data is sent at all times

when the HOAO is operating and the aO Engine decides whether or not to use the data

based in its configuration).

o Attempts to achieve AO lock by actively driving the FTT mirror to correct for the tip-tilt

errors measured by the HOWFS.

o If the number of shift vectors that exceed the out of bounds conditions for AO lock are

exceeded, the HOAO returns the FTT to its static mid-range positions and waits for a

D R A F T



specified number of frames before attempting to lock again. This procedure is described

in detail in SPEC-0147, HOAO CDD.

o The HOAO will continue to attempt to achieve AO lock until it is successful or until it is

canceled by the WCCS.

o The WCCS will monitor the lock status of the HOAO and will set alarms and health as

required to notify the operator if the HOAO fails to achieve lock within a user-defined

time period, or if the HOAO loses lock.

o The HOAO telemetry processor sends offload events to the TCS to keep the average

TTM position at mid-range.

o The HOAO continues to publish all status and telemetry data to CSF events and the BDT.

LOWFS:


o Sends low-order modal wavefront data to the aO Engine for processing (the data is sent at

all times when the LOWFS is operating and the aO Engine decides whether or not to use

the data based in its configuration).

o Publishes all normal status and telemetry data to CSF events.

aO Engine:

o Once AO lock is achieved, the aO Engine begins to process low order wavefront data

from the LOWFS and pupil position data from the HOWFS and sends wavefront

correction information to the M1, M2, M3 and M6 mirror control systems.

The CV continues to publish image data to the BDT and normal status events to CSF.

The LT does nothing and is essentially in idle mode.

6.5 SEEING LIMITED CORONAL OBSERVING (WFC-OPM3)

In Seeing Limited Coronal Observing mode, the M1CS, TEOACS and FOCS operate in passive mode,

using predefined look-up tables to compensate for quasi-static wavefront errors. The TCS configures

these subsystems prior to placing the WFC in this mode. The aO Engine does not process any wavefront

or pupil position measurements from the LOWFS or HOWFS.


operation:


attribute set to seeingLimitedCoronal.




subsystem transitions to seeingLimitedCoronal and shows an in position status of true. The

overall WCCS in position status remains false until all the subsystems attain their desired state.



The WFC subsystems respond to the seeingLimitedCoronal mode with the following behavior:

D R A F T




range positions.




LOWFS.


The LT goes to idle mode and ceases sending fast tip tilt commands to the M2 hexapod.


All WFC status events and telemetry continue to be published.

6.6 LIMB OCCULTING WITH IMAGE STABILIZATION (WFC-OPM4)

In Limb Occulting with Image Stabilization mode, the M1CS, TEOACS and FOCS operate in passive

mode, using predefined look-up tables to compensate for quasi-static wavefront errors. The TCS

configures these subsystems prior to placing the WFC in this mode. The aO Engine does not process any

wavefront or pupil position measurements from the LOWFS or HOWFS. The LT processes limb sensor

data to command the M2 hexapod in fast tip-tilt to stabilize the limb position on the limb sensor. The

position of the GOS occulter may be changed to adjust the specific amount of over- or under-occultation.


operation:


attribute set to limbTracking.




subsystem transitions to limbTracking and shows an in position status of true. The overall WCCS

in position status remains false until all the subsystems attain their desired state.



The WFC subsystems respond to the limbTracking mode with the following behavior:


range positions.




LOWFS.



D R A F T



The LT goes into limbTracking mode and begins processing data from the limb sensor and

sending commands to the M2 fast tip-tilt to stabilize the limb position on the sensor.

The LT listens for changes to the limb occulter position from the OCS or WCCS LT GUI screens

and forwards the appropriate commands to the PA&C to move the occulter.

All WFC status events continue to be published. The high speed WFC telemetry to the BDT is

disabled during limbTracking mode.

6.7 CALIBRATIONS

Calibrations are performed when the WCCS receives a configuration with the WCCS mode attribute set

to calibrate and an accompanying calibrate attribute set to the name of the calibration script to be

executed. The WCCS passes the entire configuration to its Calibration Sequencer which downloads the

calibration script from the CSF script store and executes the script. The required calibrations for the WFC

and their sequencing are discussed in SPEC-0129, WFC OCD, in Section 4.

Some of the calibrations require the WFC to configure the sources, targets, pinholes and dark slide at the

GOS. This will be done by sending configurations directly to the PA&C from the calibration script.

Scripts that require this functionality will have the suffix “GOS” appended to the end of the script name to

make it perfectly clear to the person selecting the script that the script will configure the GOS.

The calibrations identified earlier in Section 4.1.1.2 are discussed in detail in the sections that follow.

Some of the calibrations are included as part of the routine daily calibrations and are identified as such.

The steps that are listed assume that the script has already been downloaded and is being executed in the

WCCS Calibration Sequencer (CS).

Many of the scripts discussed below rely on the WFC subsystems to perform part or all of a particular

calibration sequence. In many cases, these calibrations rely on parameters to control the logic of the

execution (number of camera frames, iterations, confidence threshold, etc.). These parameters are all

defined with default values in the CSF Property DB and are initialized at startup. These default values are

normally used to control the calibrations, but may be overridden by including new values in the

configuration sent to the WCCS or by using values hardcoded in the WCCS calibration script (note that

hardcoding is not recommended).

The Limb Tracker calibrations are listed separately at the end of the section, as they require a different

TCS configuration from the other calibrations and will not be done in sequence with the others.

6.7.1 Dark Calibrations

Dark calibrations are used to measure the bias due to dark current in the WFC detectors so they may be

subtracted from the measured images at run time. The LOWFS and HOWFS legs are able to block the

light beam using their pinhole stages. The CV is not able to block its beam and must have the dark slide at

the GOS closed prior to performing a calibration. To simplify the procedure at the HOWFS and LOWFS

legs, they will always block their beams when performing dark calibrations. This eliminates the need to

distinguish between when blocking of the beam is required and when it is not.

LOWFS Dark Calibration 6.7.1.1

The lowfsDark script will execute a dark calibration on the LOWFS subsystem. The following steps will

be taken:

D R A F T



The script sends a configuration to the LOWFS controller containing the following attributes:

o atst.tcs.wccs.mode = “calibrate”

o atst.tcs.wccs.lowfs.calibrate = “dark”

o Any other LOWFS attributes included in the configuration received by the WCCS

The LOWFS receives and validates the configuration

The LOWFS performs a dark calibration as described in SPEC-0142, LOWFS CDD

The result status of the dark calibration is passed up the submit chain to the script in the WCCS

calibration sequencer. If a failure occurs the status is passed up to the WCCS which will set

health and alarms as appropriate, depending on the nature of the failure.

HOWFS Dark Calibration 6.7.1.2

The hofwsDark script is identical to the lowfsDark script except that it is executed at the HOAO controller

and configures the corresponding HOAO devices.

CV Dark Calibration 6.7.1.3

The dark calibration of the WFC Context Viewer is slightly different from the LOWFS and HOWFS dark

calibrations in that it requires the dark slide (shutter) at the GOS to be closed (the LOWFS and HOWFS

legs each have a pinhole stage that can be used to block the light). The following steps are taken:

The script sends a configuration to the PA&C to close the dark slide at the GOS

The script sends a configuration to the CV controller containing the following attributes:


o atst.tcs.wccs.cv.calibrate = “dark”

o Any other CV attributes included in the configuration received by the WCCS

The CV receives and validates the configuration

The CV performs a dark calibration as described in SPEC-0180, CV CDD

The script sends a configuration to the PA&C to open the dark slide at the GOS.

The result status of the dark calibration is passed up the submit chain to the script in the WCCS



Simultaneous Dark Calibrations 6.7.1.4

The allDark script will execute simultaneous dark calibrations on each of the three WFC legs: LOWFS,

HOAO and CV. The following actions will be taken:

The script sends a configuration to the PA&C to close the dark slide at the GOS

The script submits separate configurations to the three top-level controllers, LOWFS, HOAO and

CV, instructing them to perform dark calibrations. The submits are asynchronous, so they may be

done very quickly one after the other (essentially simultaneously).

The script monitors the completion status of each of the calibrations and percolates the result

status up the chain to the WCCS, which takes any required action depending on the result.

D R A F T



The script sends a configuration to the PA&C to open the dark slide at the GOS.

6.7.2 Gain Calibrations

Gain calibrations are used to measure the non-uniform pixel response across the WFC detectors so they

may be compensated at run time. These calibrations require sunlight and either random motion of the

TMA or random motion of the LOWFS and HOWFS Field Steering Mirrors (FSMs). The CV does not

have a FSM, and must rely on the random motion of the TMA. When random motion of the TMA is

required, it must be configured by the OCS before the gain calibration is initiated at the WCCS.

The naming of the LOWFS and HOWFS gain calibration scripts is used to distinguish between which

type of random motion is assumed by the script. For random TMA motion the scripts are named

lowfsGainTMA and howfsGainTMA, and for random FSM motion the scripts are named lowfsGainFSM

and howfsGainFSM. Since the CV does not have a FSM, no special script naming is required.

LOWFS Gain Calibrations 6.7.2.1

The lowfsGain scripts will execute a gain calibration on the LOWFS subsystem. The following steps will

be taken:



o atst.tcs.wccs.lowfs.calibrate = “gainTMA” or “gainFSM”, as required



The LOWFS performs a gain calibration as described in SPEC-0142, LOWFS CDD

The result status of the gain calibration is passed up the submit chain to the script in the WCCS



HOWFS Gain Calibrations 6.7.2.2

The hofwsGain script is identical to the lowfsGain script except that it is executed at the HOAO controller


CV Gain Calibrations 6.7.2.3

The gain calibration at the CV is implemented using a single script (cvGain) that assumes random motion

of the TMA. The following steps are taken:



o atst.tcs.wccs.cv.calibrate = “gain”



The CV performs a gain calibration as described in SPEC-0180, CV CDD

D R A F T



The result status of the gain calibration is passed up the submit chain to the script in the WCCS



Simultaneous Gain Calibrations 6.7.2.4

The allGain script will execute simultaneous gain calibrations on each of the three WFC legs: LOWFS,

HOAO and CV. It assumes the use of random motion at the TMA. The following steps will be taken:

The script submits separate configurations to the three top-level controllers, LOWFS, HOAO and

CV, instructing them to perform the appropriate gain calibrations (i.e., no FSM motion for the

LOWFS and HOWFS). The submits are asynchronous, so they may be done very quickly one

after the other (essentially simultaneously).



6.7.3 Boresight Alignment Calibration

The Telescope Boresight Alignment Calibration is used to calibrate the positions of M3 and M6 for

optimal alignment of the telescope. This is different from the boresight alignment correction performed

by the aO Engine, which applies offsets to M3 and M6 in near-real-time to keep the boresight aligned

during normal operation. The procedure requires both the image position measurement capability of the

CV and the pupil sensing capability of the HOAO, with the final computation performed in the aO

Engine. Because it requires the simultaneous use of the HOAO, CV and aO Engine, the procedure is

scripted from the WCCS. At the aO Engine, pupil position measurements are received from the HOAO

and image position measurements are received from the CV. These measurements are asynchronous with

respect to each other. When both measurements have been received, the aO Engine processes them to

produce the corrections for M3 and M6 in the FOCS. The corrections are sent to the FOCS using a CSF

event. This procedure is repeated as needed. A point source must be inserted at the GOS to perform this

procedure. The boresight calibration is performed using the boresight script.

The following steps are taken:

The script sends a configuration to the PA&C to insert the proper point source at the GOS

The script sends a configuration to the aO Engine controller containing the following attributes:


o atst.tcs.wccs.ao.calibrate = “boresight”

o Any other aO Engine attributes included in the configuration received by the WCCS

The aO Engine receives and validates the configuration

The aO Engine starts the boresight calibration as described in SPEC-0176, aO Engine CDD,

waiting patiently for a pupil position measurement from the HOWFS and a centroid calculation

from the CV.

The script sends a configuration to the HOAO controller containing the following attributes:


o atst.tcs.wccs.hoao.calibrate = “pupilStab”

o Any other HOAO attributes included in the configuration received by the WCCS

D R A F T



The HOAO receives and validates the configuration

The HOAO executes the pupil stabilization calibration, which continually sends pupil position

measurements to the aO Engine.



o atst.tcs.wccs.cv.calibrate = “boresight”



The CV executes the boresight calibration, which computes a centroid calculation on an average

CV image and posts the result to a CVS event.

The ao Engine receives the pupil position measurement and the centroid calculation result and

computes the new positions for M3 and M6, posting them to a FOCS event.

The script repeats the aO Engine calibration and CV centroid measurement as needed until the

desired boresight alignment is achieved.

The script sends configurations to the HOAO, CV and aO Engine with their respective calibrate

attributes set to “none”, which terminates their calibration activities.

The result status of the boresight calibration is passed up the submit chain to the script in the

WCCS calibration sequencer. If a failure occurs the status is passed up to the WCCS which will

set health and alarms as appropriate, depending on the nature of the failure.

The script sends a configuration to the PA&C to remove the point source at the GOS.

6.7.4 Context Viewer Calibrations

Focus 6.7.4.1

The cvFocus script adjusts the position of the objective lens for the selected CV FOV to optimize the

focus of the CV image plane. A point source must be inserted at the GOS for this procedure. The

following steps are taken:




o atst.tcs.wccs.cv.calibrate = “focus”

o atst.tcs.wccs.cv.fov = <30 | 60>



The CV performs a focus calibration as described in SPEC-0180, CV CDD


D R A F T



The result status of the focus calibration is passed up the submit chain to the script in the WCCS



TCS Pointing Map Update Support 6.7.4.2

The WCCS will be used to assist in the computation of TCS pointing map updates. For this application,

the CV camera must be configured with the appropriate exposure time and frame rate for night time

operation to achieve a good SNR on bright stars. Dark and gain corrections must be applied as well. The

steps to be performed are expected to be something like this:

The TCS configures the WCCS to be in calibrate mode

The TCS configures the AO Engine to perform an aoZero to clear all the AO offsets used by M1,

M2, M3 and M6

The TCS configures the CV camera for night time operation and performs CV dark and gain

calibrations as required.

The TCS moves the telescope to a bright star

The TCS configures the CV to perform a centroid calculation averaging over a specified number

of image frames. This is done by executing the cvNightTime calibration script in the WCCS.

The CV performs the centroid calculation and publishes the offset from the boresight in a CSF

event (atst.tcs.wccs.cv.centroid)

The TCS subscribes to the event and receives the offset information

This process is repeated until the desired set of stars has been processed

The array of offsets are used to compute new pointing kernel parameters

At the WCCS, the following steps are taken in the cvNightTime script:



o atst.tcs.wccs.cv.calibrate = “nightTime”



The CV performs a nighTime calibration as described in SPEC-0180, CV CDD

The result status of the nightTime calibration is passed up the submit chain to the script in the



TCS Coordinate Initialization Support 6.7.4.3

The WCCS will be used to support the establishment of the heliocentric coordinate system when bringing

the telescope up each morning. This involves moving the telescope to several different limb locations

around the sun (e.g., N, S, E and W) and calculating the position of the limb in a CV image for each case.

The position of the limb is calculated by the CV and returned in a CSF event as the vector orthogonal to

the limb of the sun from the boresight of the telescope (see SPEC-180, CV CDD, for the details of the

algorithm). The steps to be performed are expected to be something like this:

D R A F T



The TCS configures the WCCS to be in calibrate mode

The TCS configures the AO Engine to perform an aoZero to clear all the AO offsets used by M1,

M2, M3 and M6

The TCS points the telescope at a desired limb location on the sun

The TCS configures the CV to perform limb finding on an average CV image

The CV performs the limb finding and publishes the result as the vectror from the boresight in a

CSF event (atst.tcs.wccs.cv.limbFinding)

The TCS subscribes to the event and receives the limb position information

This process is repeated until all the desired limb positions have been processed

The limb positions calculated by the CV are used by the TCS to update its pointing reference

At the WCCS, the following steps are taken in the cvLimbFinding script:



o atst.tcs.wccs.cv.calibrate = “limbFinding”



The CV performs a limbFinding calibration as described in SPEC-0180, CV CDD

The result status of the limbFinding calibration is passed up the submit chain to the script in the WCCS

calibration sequencer. If a failure occurs the status is passed up to the WCCS which will set health and

alarms as appropriate, depending on the nature of the failure.

6.7.5 Field Steering Mirror Calibrations

The Field Steering Mirror (FSM) calibrations are used to calibrate the center FSM positions such that the

residual tilts measured in the HOWFS and LOWFS are minimized. The calibrated positions are used to

update the named center positions. A point source must be inserted at the GOS in order to perform these

calibrations.

LOWFS FSM Calibration 6.7.5.1

The lowfsFSM script will execute a FSM calibration on the LOWFS subsystem. The following steps will

be taken:




o atst.tcs.wccs.lowfs.calibrate = “centerFSM”



The LOWFS performs a centerFSM calibration as described in SPEC-0142, LOWFS CDD


D R A F T



The result status of the centerFSM calibration is passed up the submit chain to the script in the



HOWFS FSM Calibration 6.7.5.2

The hofwsFSM script is identical to the lowfsFSM script except that it is executed at the HOAO controller


Simultaneous FSM Calibrations 6.7.5.3

The holoFSM script will execute simultaneous FSM calibrations on the LOWFS and HOWFS. The

following actions will be taken:


The script submits separate configurations to the LOWFS and HOWFS controllers, instructing

them to perform FSM calibrations. The submits are asynchronous, so they may be done very

quickly one after the other (essentially simultaneously).



The script sends a configuration to the PA&C to remove the point source at the GOS.

6.7.6 High Order / Low Order Focus Calibrations

The High Order / Low Order focus calibrations are used to adjust the position of the LOWFS and

HOWFS objective lenses along the beam to minimize the focus measured by the wavefront sensor. A

point source or focus target must be inserted at the GOS in order to perform these procedures.

LOWFS Focus Calibration 6.7.6.1

The lowfsFocus script will execute a focus calibration on the LOWFS subsystem. The following steps

will be taken:

The script sends a configuration to the PA&C to insert the proper point source or focus target at

the GOS



o atst.tcs.wccs.lowfs.calibrate = “focus”



The LOWFS performs a focus calibration as described in SPEC-0142, LOWFS CDD

The script sends a configuration to the PA&C to remove the point source or focus target at the

GOS

The result status of the focus calibration is passed up the submit chain to the script in the WCCS



D R A F T



HOWFS Focus Calibration 6.7.6.2

The hofwsFocus script is identical to the lowfsFocus script except that it is executed at the HOAO

controller and configures the corresponding HOAO devices.

Simultaneous Focus Calibrations 6.7.6.3

The holoFocus script will execute simultaneous focus calibrations on the LOWFS and HOWFS. The

following actions will be taken:

The script sends a configuration to the PA&C to insert the proper point source or focus target at

the GOS


them to perform focus calibrations. The submits are asynchronous, so they may be done very

quickly one after the other (essentially simultaneously).



The script sends a configuration to the PA&C to remove the point source or focus target at the

GOS.

6.7.7 Subaperture Offset Calibrations

The subaperture offset calibrations are used to measure the residual wavefront error at the LOWFS and

HOWFS that is due to internal WFC optical errors. The measured shift vectors are used as offsets during

normal wavefront sensor operation to compensate for these errors. Sunlight or a GOS light source is

required to perform these calibrations.

LOWFS Subaperture Offset Calibration 6.7.7.1

The lowfsSubapOffset script will execute an internal subaperture offset calibration on the LOWFS

subsystem. The following steps will be taken:

The script sends a configuration to the PA&C to insert the proper light source at the GOS, if

required



o atst.tcs.wccs.lowfs.calibrate = “internalSubapOffset”



The LOWFS performs an internal subaperture offset calibration as described in SPEC-0142,

LOWFS CDD

The result status of the subaperture offset calibration is passed up the submit chain to the script in

the WCCS calibration sequencer. If a failure occurs the status is passed up to the WCCS which

will set health and alarms as appropriate, depending on the nature of the failure.

The script sends a configuration to the PA&C to remove the light source at the GOS, if required

D R A F T



HOWFS Subaperture Offset Calibration 6.7.7.2

The howfsSubapOffset script is identical to the lowfsSubapOffset script except that it is executed at the

HOAO controller and configures the corresponding HOAO devices.

Simultaneous Subaperture Offset Calibrations 6.7.7.3

The holoSubapOffset script will execute simultaneous internal subaperture offset calibrations on the

LOWFS and HOWFS. The following actions will be taken:


required


them to perform internal subaperture offset calibrations. The submits are asynchronous, so they

may be done very quickly one after the other (essentially simultaneously).




6.7.8 Non-Common Path Offset Calibrations

The non-common path (NCP) offset calibrations are used to measure the subaperture offsets that must be

added to the HOWFS and LOWFS wavefront measurements to compensate for 1) internal non-common

path wavefront errors in the WFC, and 2) non-common path errors at an instrument.

Internal WFC NCP Calibrations 6.7.8.1

The internal NCP offset calibrations require the insertion of special optics and equipment downstream of

the WFC BS1 beam splitter and a reflective sphere at the GOS, so it is not a routine calibration. It also

requires personnel access to the WFC optical benches on the coudé floor. The following steps are taken:

An interferometer is installed in the beam path at the exit of BS1 feeding the instruments.

A reflective sphere is installed at the GOS

The shape of the DM is adjusted by adding Zernike modes to the actuator offsets until the

residual wavefront error measured at the interferometer is minimized. This is a manual iterative

process of changing the mirror shape and making interferometer measurements.

The WCCS executes thelowfsNCP, howfsNCP, or holoNCP calibration scripts which run the

appropriate automated calibration steps in the LOWFS and/or HOWFS to measure the

subaperture offsets associated with the DM shape. Please refer to the HOAO and LOWFS CDDs

for details on the particular steps performed for the subsystem NCP calibration procedures.

These offsets are saved to the Bulk Data Service so they can be loaded at startup.

Instrument NCP Calibrations 6.7.8.2

There is no automated procedure for performing an instrument NCP calibration. The WCCS supports the

optimization of the wavefront at an instrument by allowing the telescope operator or WFC Specialist to

send an array of Zernike modes to be applied to the DM actuator offsets while the WCCS is in idle mode

(i.e., not actively driving the DM). The DM offsets may be updated as needed to produce a desired

wavefront at the instrument. It is up to the instrument team to determine how to measure their wavefront

and derive the correct wavefront expressed as Zernike modes to be applied to the DM.

D R A F T



Once the wavefront has been optimized, the WCCS will be instructed to execute the howfsNCP, lowsNCP

or holoNCP calibration scripts to measure the wavefront sensor subaperture offsets associated with the

NCP correction applied to the DM and then save it to the Bulk Data Service for future use.

The WCCS supports applying the NCP correction for a particular instrument by loading the previously

saved subaperture offsets and applying them to the HOWS and/or LOWFGS, as required.

6.7.9 Wavefront Sensor Field Size and Rotation Calibrations

The wavefront sensor field size and rotation calibrations are used to measure the orientation of the lenslet

array with the detector in the LOWFS and HOWFS. The LOWFS and HOWFS focus calibrations must be

run prior to these calibrations. Either sunlight or a point source at the GOS may be used for these

calibrations. No automated adjustment is performed by these calibrations. If either the calibrations fail,

the WFC Specialist or an engineer from the FWC team must go into the coudé lab to align the particular

wavefront sensor optics.

LOWFS Field Size and Rotation Calibration 6.7.9.1

The lowfsFieldSize script will execute a LOWFS field size and rotation calibration. The following steps

will be taken:


required



o atst.tcs.wccs.lowfs.calibrate = “fieldSizeRotation”



The LOWFS performs field size and rotation calibration as described in SPEC-0142, LOWFS

CDD

The result status of the field size and rotation calibration is passed up the submit chain to the

script in the WCCS calibration sequencer. If a failure occurs the status is passed up to the WCCS

which will set health and alarms as appropriate, depending on the nature of the failure.


HOWFS Field Size and Rotation Calibration 6.7.9.2

The howfsFieldSizeRotation script is identical to the lowfsFieldSizeRotation script except that it is

executed at the HOAO controller and configures the corresponding HOAO devices.

Simultaneous Field Size and Rotation Calibration 6.7.9.3

The holoFieldSizeRotation script will execute simultaneous field size and rotation calibrations on the

LOWFS and HOWFS. The following actions will be taken:


required

D R A F T




them to perform field size and rotation calibrations. The submits are asynchronous, so they may

be done very quickly one after the other (essentially simultaneously).




6.7.10 HOWFS DM Registration Calibration

The HOWFS DM registration calibration measures and adjusts the alignment of the HOWFS relative to

the DM. A point source is required at the GOS for this procedure. Predefined calibration shapes are

placed on the DM and the HOWFS shift vectors analyzed to measure the registration between the DM

and the HOWFS lenslet array. If the registration exceed specifications, the HOAO will adjust the position

of the lenslet array as required. The howfsDmReg is used to execute the calibration. The following steps

are taken:




o atst.tcs.wccs.hoao.calibrate = “dmToLensletReg”



The HOAO performs the DM to lenslet registration calibration as described in SPEC-0147,

HOAO CDD

The result status of the HOWFS DM Registration Calibration is passed up the submit chain to the

script in the WCCS calibration sequencer. If a failure occurs the status is passed up to the WCCS

which will set health and alarms as appropriate, depending on the nature of the failure.

The script sends a configuration to the PA&C to remove the point source at the GOS

6.7.11 HOAO System Matrix Calibrations

The HOAO system matrix calculations are used to measure the HOAO influence matrix (system matrix).

Either zonal or modal measurements may be made. This is not a routine calibration and it is expected to

be performed very rarely (e.g., after a realignment or change to the WFC optical bench). A point source is

required at the GOS for these procedures. The resulting system matrices are saved to the Bulk Data

Service for off-line analysis and processing to generate new HOAO reconstruction matrices.

Zonal System Matrix 6.7.11.1

A zonal system matrix is computed by applying Hadamard patterns to the DM and measuring the

response at the HOWFS. The hoaoSysMatZonal script is used to perform this procedure. The following

steps are taken:




D R A F T



o atst.tcs.wccs.hoao.calibrate = “sysMatZonal”



The HOAO performs the zonal system matrix calibration as described in SPEC-0147, HOAO

CDD

The result status of the calibration is passed up the submit chain to the script in the WCCS




Modal System Matrix 6.7.11.2

A modal system matrix is computed by applying Zernike modes to the DM and measuring the response at

the HOWFS. The hoaoSysMatModal script is used to perform this procedure. The following steps are

taken:




o atst.tcs.wccs.hoao.calibrate = “sysMatModal”



The HOAO performs the nodal system matrix calibration as described in SPEC-0147, HOAO

CDD





6.7.12 m2Zero

Needs discussion with Luke…

6.7.13 pupilStabilization

The Pupil Stabilization calibration is used to hold the pupil steady while the DM and FTT are held at their

static positions. It is not a WFC calibration, but is used to assist instrument calibrations and telescope

alignment. Sunlight is required to perform this calibration. The pupilStabilization script is used to perform

this procedure. The following steps are taken:



o atst.tcs.wccs.hoao.calibrate = “pupilStab”


D R A F T




The HOAO performs the pupil stabilization calibration as described in SPEC-0147, HOAO CDD




6.7.14 WFC-Assisted Alignment

The WFC-Assisted Alignment calibration is used to correct for wavefront errors induced by gravitational

flexure and thermal distortions that occur between the calibration of the WFC and the calibration of the

instruments. The DM and FTT loops of the HOAO are locked on a target (either sunlight or a GOS point

source). Once the loops have stabilized, the DM and FTT actuator commands are averaged over a period

of one second, the loops are opened and the average values applied to the mirrors to hold the correction in

place. The mirrors are held in these positions until a new configuration is received by the WCCS that

sends new commands to the DM or FTT.

The wfcAssistCal script is used to perform this procedure. The following steps are taken:



o atst.tcs.wccs.hoao.calibrate = “dmAsstAlign”



The HOAO performs the WFC assisted alignment calibration as described in SPEC-0147, HOAO

CDD




6.7.15 Routine Alignments

The routine alignment script is a concatenation of all the routine daily alignments so that they may be

invoked using a single calibration configuration sent from the OCS or WCCS Engineering screen.

6.7.16 Special

When the calibrate attribute is set to “special”, the next value in the attribute array is used as the name of

a script to be downloaded from the script store and executed by the Calibration Sequencer. This allows

the WCCS to easily run custom scripts or easily debug copies of existing scripts. The remaining attributes

in the configuration are sent to the script so they may be used as parameters.

6.7.17 Limb Tracker

The Limb Tracker calibration scripts are TBD, but will likely consist of standard dark, gain and sensor

calibrations.

D R A F T



6.8 SHUTDOWN

The daily shutdown of the WCCS/WFC is assumed to be initiated by a script in the OCS which sends the

WFC mode attribute set to off which initiates the shutdown sequence of the WCCS/WFC. Upon

completion of the shutdown sequence, the script will shut down (unload) the CSF components and

containers and power down the WFC subsystem CPUs. The subsystem components are powered down

during the individual subsystem shutdown sequences. We will provide scripts for the WCCS and each of

the WFC sub-systems to implement the behavior described above. These scripts may be adapted for use

by the OCS.

D R A F T



7 HARDWARE REQUIREMENTS

The WCCS Computer is responsible for the top-level management of the WFC system. The aO Engine

and Limb Tracker HLS controller are implemented on this computer as well. The WCCS computer will

deploy the following CSF controllers:

1 Management Controller

o The top-level WCCS Controller

1 Script Interpreting Controller

o The Calibration Sequencer

1 Custom Base Controller

o The aO Engine

1 Hardware Controller

o The Limb Tracker Controller

These controllers will be implemented using a CSF client with four cores allocated for this purpose. We

will allocate an additional two cores to the aO Engine and an additional core for the Calibration

Sequencer as a safety precaution. Therefore, the WCCS computer can be implemented using a single

processor 8-core Xeon server or better. The computer will require at least two 1Gb Ethernet ports: one for

the DHS/BDT interface and the other for the CSF control LAN. An ABMX model 114X9+ 1U server is

an example of a computer that will meet these requirements.

A deployment diagram showing the CSF components and container in the WCCS is shown below.