Wavefront Correction Context Viewer Critical Design Definition · The requirements in this document...

Project Documentation Document SPEC-0180

Revision A

Wavefront Correction Context Viewer

Critical Design Definition

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

Wöger

WFC Group

December 2017

CV CDD

SPEC-0180, Rev A Page i

REVISION SUMMARY:

1. Date: August 2013 Revision: Draft Changes: Initial document

2. Date: December 2017 Revision: A Changes: Initial formal release prior to CDR.

CV CDD

SPEC-0180, Rev A Page ii

Table of Contents

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

1.1 SCOPE OF THE DOCUMENT ...................................................................................... 1

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

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

1.4 RELATED DKIST PROJECT DOCUMENTS .................................................................. 2

1.5 INTERFACE CONTROL DOCUMENTS AND DRAWINGS .................................................. 2

1.6 SPECIFIC DEFINITIONS AND TERMINOLOGY ............................................................... 2

1.7 COMPLIANCE MATRIX .............................................................................................. 3

2 INTRODUCTION TO THE CV DESIGN ................................................................ 4

3 CV ALGORITHMS ................................................................................................ 5

3.1 CV CENTROIDING ................................................................................................... 5

3.2 CV LIMB FINDING ................................................................................................... 9

3.3 CV STREHL CALCULATION .................................................................................... 11

3.4 CV PLATE SCALE CALCULATION ........................................................................... 12

3.5 CV FOCUS CALIBRATION ...................................................................................... 14

4 CV OPTICAL DESIGN ........................................................................................ 16

4.1 CV OPTICAL DESIGN REQUIREMENTS .................................................................... 16

4.2 CV OPTICAL PERFORMANCE ................................................................................. 17

4.3 OPTICAL TOLERANCE ANALYSIS ............................................................................ 20

4.3.1 ZEMAX Tolerance Model .............................................................................................20

4.3.2 Monte Carlo Results ....................................................................................................22

4.4 OPTICAL ALIGNMENT ............................................................................................ 22

5 CV HARDWARE DESIGN .................................................................................. 23

5.1 OVERVIEW OF COUDÉ WFS LAYOUT ...................................................................... 23

5.2 OVERVIEW OF WFS OPTO-MECHANICAL LAYOUT ................................................... 25

5.3 CV OPTO-MECHANICAL DESIGN ............................................................................ 27

5.3.1 30-Arcsecond Objective Lens Assembly ...................................................................29

5.3.2 30-Arcsecond Objective Lens Analysis .....................................................................31

5.3.3 60-Arcsecond Objective Lens Assembly ...................................................................36

5.3.4 60-Arcsecond Objective Lens Analysis .....................................................................38

5.3.5 CV Filter Assembly ......................................................................................................42

5.3.6 CV Camera Assembly .................................................................................................44

5.4 CV CAMERA ......................................................................................................... 45

6 THERMAL SYSTEMS ......................................................................................... 47

6.1 CV CAMERA THERMAL CONTROL .......................................................................... 47

7 CV CONTROL SOFTWARE DESIGN................................................................. 49

7.1 OVERVIEW ............................................................................................................ 49

CV CDD

SPEC-0180, Rev A Page iii

7.2 USE CASES .......................................................................................................... 51

7.2.1 Startup ..........................................................................................................................53

7.2.2 Observing Related Modes ...........................................................................................53

7.2.3 Calibrations..................................................................................................................54

7.2.4 Shutdown .....................................................................................................................58

7.3 DETAILED DESIGN................................................................................................. 58

7.3.1 CV Controller ...............................................................................................................58

7.3.2 Camera Controller .......................................................................................................60

7.3.3 Mechanism Controller .................................................................................................66

7.3.4 Motion Controllers .......................................................................................................68

7.3.5 Calibration Sequencer ................................................................................................70

7.3.6 Events Published by the CV and its components .....................................................74

7.3.7 Events subscribed to by the CV and its components ...............................................78

7.3.8 Headers ........................................................................................................................78

7.3.9 Interlocks .....................................................................................................................78

7.3.10 Logging ........................................................................................................................78

7.3.11 Health and Alarms .......................................................................................................79

7.3.12 GUI Screens .................................................................................................................80

7.3.13 Use Case Details .........................................................................................................84

7.4 HARDWARE REQUIREMENTS .................................................................................. 89

CV CDD

SPEC-0180, Rev A Page 1 of 90

1 OVERVIEW

1.1 SCOPE OF THE DOCUMENT

The Context Viewer (CV) Critical Design Definition (CDD) describes the design of the DKIST CV as

conceived and developed by the Wavefront Correction (WFC) team. The design is based on requirements

in the CV Design Requirements Document (DRD) which flow from SPEC-0058, Wavefront Correction

Specifications. SPEC-0058 captures the necessary wavefront correction performance requirements that

will enable DKIST to meet top-level science requirements set forth in SPEC-0001, DKIST Science

Requirements.

1.2 DELIVERABLES

The deliverables for the CV final design are primarily contained in two documents: SPEC-0179, the

DRD, and SPEC-0180, the CDD. In addition, the Interface Control Documents (ICD) describe interfaces

between the CV and other telescope systems.

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

compliance matrix, CMX-0019.

The CDD, this document, contains detailed descriptions of the CV design, including the following

deliverables,

CV optical design

o Optical tolerance analysis

o Optical alignment plan

o ZEMAX optical design and analysis

CV hardware design

o Motion stages

o Optical mounts

o CV camera

Software design

o Use cases

o Interfaces

o Algorithms

o Detailed design

1.3 RELATED DOCUMENTS

[1] Roberts, L. C., Perrin, M. D., Marchis, F., Sivaramakrishnan, A., Makidon, R. B., Christou, J. C.,

Macintosh, B. A., Poyneer, L. A., van Dam, M. A., and Troy, M., “Is that really your Strehl ratio?”,

Proc SPIE 5490, p. 504-515 (2004)

[2] Cox, “Allen’s Astrophysical Quantities”, 2000

[3] Canny, J., “A Computational Approach To Edge Detection”, IEEE Trans. Pattern Analysis and

Machine Intelligence, 8(6):679–698, 1986.

[4] Duda, R. O. and P. E. Hart, "Use of the Hough Transformation to Detect Lines and Curves in

Pictures," Comm. ACM, Vol. 15, pp. 11–15

[5] http://scikit-image.org/docs/dev/api/api.html

[6] Otsu, N., "A threshold selection method from gray-level histograms", IEEE Trans. Sys., Man., Cyber.

9: 62-66, 1979.

http://scikit-image.org/docs/dev/api/api.html

CV CDD


[7] Mir, Hashim, Peter Xu, and Peter Van Beek. "An extensive empirical evaluation of focus measures

for digital photography." IS&T/SPIE Electronic Imaging. International Society for Optics and

Photonics, 2014.

1.4 RELATED DKIST PROJECT DOCUMENTS

SPEC-0001, Science Requirements Document

SPEC-0005, Software and Controls Requirement

SPEC-0012, DKIST Acronym List and Glossary

SPEC-0013, Software Concepts Definitions

SPEC-0014, Software Design

SPEC-0022, Common Services Framework Reference Design

SPEC-0036, Operational Concepts Definitions

SPEC-0037, Risk Management Plan

SPEC-0045, Contingency Management Plan

SPEC-0058, Wavefront Corrections Systems Specifications Document

SPEC-0063, Interconnects and Services

SPEC-0061, Hazard Analysis Plan

SPEC-0068, M5 Tip Tilt Module Specification

SPEC-0070, DKIST Standard Environmental Conditions

SPEC-0109, M5 Tip Tilt Mirror Specification

SPEC-0111, M10 Deformable Mirror Specification

SPEC-0125, High Order Adaptive Optics Real Time FPGA Firmware Specification

SPEC-0129, Wavefront Correction Operational Concepts Model

SPEC-0179, WFC CV DRD

SPEC-0202, Wavefront Correction System Telemetry Specification

TN-0185, WFC CV Camera Trade Study

TN-0188, WFC Context Viewer Software Issues

TN-0193, WFC Context Viewer Camera Test Report

TN-0289, WFC System Power Sequencing

PROC-0261, WFC Alignment Plan

1.5 INTERFACE CONTROL DOCUMENTS AND DRAWINGS

ICD 2.3 – 4.4 WCCS to TCS

1.6 SPECIFIC DEFINITIONS AND TERMINOLOGY

Acronym Meaning

CDD

CSF

CV

DKIST

Critical Design Document

Common Services Framework

Context Viewer

Daniel K. Inouye Solar Telescope

DRD Design Requirements Document

CV CDD


FOV

GOS

HOAO

HOWFS

ICD

LOWFS

Field-of-view

Gregorian Optical Station (at Gregorian focus of telescope)

High-Order Adaptive Optics

High-Order Wavefront Sensor

Interface Control Document

Low Order Wavefront Sensor

OCD

QE

Operational Concepts Definition

Quantum Efficiency

SRD

WCCS

WFC

Science Requirements Document

Wavefront Correction Control System

Wavefront Correction System

1.7 COMPLIANCE MATRIX

The requirements in this document all trace back to the CV DRD, SPEC-0179, through the CV

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

The CV compliance matrix traces top-down requirements to the original source documents. Direct

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

mechanism to flow requirements through the DRD into the CDD. Other top-down requirements appear in

the body of the DRD and reference the higher requirements that generate them. Each top-down

requirement in the CV compliance matrix references the CDD implementation which satisfies the

requirement.

The DRD also develops bottom-up 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 contain references to the CDD section which justify them, the DRD section that they

flow to, and any necessary higher-level requirements. In this way all requirement flows, both top-down

and bottom-up, are traceable through the CV compliance matrix.

CV CDD


2 INTRODUCTION TO THE CV DESIGN

The CV is a first-light subsystem of the DKIST WFC. The CV delivers visible-light images of the center

of the DKIST field of view to a display screen where they can be viewed. The CV also defines the

telescope boresight position, so it is essential to DKIST operation, especially with regards to

determination of the telescope coordinate system. The CV will also assist in WFC calibration activities,

telescope pointing corrections, and image quality evaluation.

The CV is designed to image the central 30 arcseconds of the DKIST field of view, sampled at the

diffraction limit. An alternative objective lens can be inserted to increase the field of view to 60

arcseconds, however, this decreases the pixel sampling by a factor of two so diffraction-limited sampling

is not possible with a 60 arcsecond field of view. Images from the CV camera are sent to the operator

display screen at a rate of 10 frames per second or greater, allowing the operator to visually determine the

pointing and performance of DKIST in close to real-time.

The CV also serves as the telescope pointing reference. The center of the CV field of view is defined to

be the center of the telescope field of view, providing a reference point for boresight alignment and

telescope pointing maps. Due to its position in the DKIST coudé room, the CV will experience little

gravitational flexure or thermal expansion, making it a stable reference from which to measure telescope

flexure.

The CV will also be used for image quality evaluation during engineering time to ensure that the WFC

system is well calibrated and operating within requirements. This ability to determine image quality will

also be used for validation during assembly, testing, and integration of the WFC system. When observing

point sources, the CV is sampled at just above the Rayleigh criterion. This means that we expect its Strehl

estimation to contain 5-10% error relative to the true Strehl[1].

The CV design follows all manufacturing, design, fabrication, drawing, documentation, electrical,

structural, environmental, and materials requirements as defined in DKIST project documents. These

requirements are enumerated in the CV compliance matrix and will be verified by internal design review,

inspection, and test where necessary.

In addition to the design presented in this document, manuals for proper maintenance will be presented

along with the final product. Manuals will follow all project documentation requirements and clearly

explain all information related to normal operations and procedures, emergency operations and

procedures, normal maintenance and procedures, emergency maintenance and procedures, spare parts,

warranties, wiring diagrams, inspection procedures, performance curves, shop drawings, product data,

and similar applicable information.

CV CDD


3 CV ALGORITHMS

This section discusses selected algorithms that will be used as part of CV calibration and operation.

Wherever it is useful for clarification, a step by step procedure will be outlined. Additionally,

mathematical expressions will be used to define quantities that must be calculated as part of each

procedure. Where possible, matrix algebra representations will be used for the sake of clarity.

Please note that the procedures and mathematics that appear in this section are meant more as a

conceptual explanation of the algorithms and are optimized for readability, not for computational

efficiency. Actual implementation in software will only rely on matrix operations where necessary and

will precompute any fixed quantities.

3.1 CV CENTROIDING

The CV will be able to locate the brightest point source in the CV image and find the location of its

optical center relative to the center pixel of the CV camera. CV centroiding will be most commonly used

at night as a way to locate bright stars as part of refining the telescope pointing map. However, other

WFC activities, such as boresight alignment and HOWFS/LOWFS plate scale calibration will also make

use of the same centroiding algorithm.

When using the CV centroiding algorithm, the CV assumes the object of interest is the brightest point

source in the image. To locate the brightest point source, the CV uses a matched filter approach by

convolving the CV image with the expected point source image, which will be retrieved from a database

that is accessible on the DKIST internal network.

For different applications, different point source images will be used. For example, night pointing

calibrations will use a Gaussian or Lorentzian point source references of varying width, boresight

alignment will use a simulated image of the GOS inverted pinhole, and HOWFS and LOWFS platescale

images will use a simulated image of the GOS pinhole. As such, the CV centroiding calculation will

require a reference point source image to be provided as input. The size of the reference image may

change between applications so the CV centroiding algorithm must be able to take reference images of

varying size. The maximum size of the reference image will be 256 x 256 pixels.

The first step in the source location algorithm is hot pixel removal. Hot pixels are detected by applying a

hot pixel filter to the CV image,

𝐼𝑎𝑑𝑗 = 𝐼𝑝𝑟𝑜𝑐 ∗1

8[1 1 11 0 11 1 1

]

𝐼ℎ𝑜𝑡 = 𝐼𝑝𝑟𝑜𝑐 − 𝐼𝑎𝑑𝑗

where 𝐼𝑝𝑟𝑜𝑐 is the dark and gain-corrected CV image, 𝐼ℎ𝑜𝑡 is the filtered CV image, 𝐼𝑎𝑑𝑗 is an image

where the pixel values of 𝐼𝑝𝑟𝑜𝑐 have been replaced with the average of their adjacent pixels, and ∗ is the

convolution operator.

All pixels in 𝐼𝑝𝑟𝑜𝑐 which correspond to pixels in 𝐼ℎ𝑜𝑡 that are above the hot pixel threshold (default value:

750) are replaced by their corresponding values in 𝐼𝑎𝑑𝑗.

𝐼𝑝𝑟𝑜𝑐,ℎ𝑜𝑡 = {𝐼𝑝𝑟𝑜𝑐, 𝐼ℎ𝑜𝑡 < 750

𝐼𝑎𝑑𝑗, 𝐼ℎ𝑜𝑡 ≥ 750

where 𝐼𝑝𝑟𝑜𝑐,ℎ𝑜𝑡 is the CV image with all hot pixels removed.

The next step in source location is matched filtering,

𝐼𝑓 = 𝐼𝑝𝑟𝑜𝑐,ℎ𝑜𝑡 ∗ ℎ𝑝𝑠𝑓

CV CDD


where 𝐼𝑓 is the source identification image, ℎ𝑝𝑠𝑓 is the reference psf image, and * is the convolution

operator. The location of the maximum pixel in 𝐼𝑓 is the location of the brightest point source in the CV

image.

The final step is to apply quadratic interpolation to 𝐼𝑓 to locate the center of the point source to subpixel

accuracy.

𝑥𝑓𝑖𝑛𝑎𝑙 = 𝑥𝑚 +2𝑎2𝑎5 − 𝑎4𝑎6

𝑎62 − 4𝑎3𝑎5

𝑦𝑓𝑖𝑛𝑎𝑙 = 𝑦𝑚 +2𝑎3𝑎4 − 𝑎2𝑎6

𝑎62 − 4𝑎3𝑎5

where [𝑥𝑚, 𝑦𝑚] is the location of maximum pixel in 𝐼𝑓 and,

𝑎2 =1

2(𝐼𝑓[𝑥𝑚 + 1, 𝑦𝑚] − 𝐼𝑓[𝑥𝑚 − 1, 𝑦𝑚])

𝑎3 =1

2(𝐼𝑓[𝑥𝑚 + 1, 𝑦𝑚] − 2𝐼𝑓[𝑥𝑚, 𝑦𝑚] + 𝐼𝑓[𝑥𝑚 − 1, 𝑦𝑚])

𝑎4 =1

2(𝐼𝑓[𝑥𝑚, 𝑦𝑚 + 1] − 𝐼𝑓[𝑥𝑚, 𝑦𝑚 − 1])

𝑎5 =1

2(𝐼𝑓[𝑥𝑚, 𝑦𝑚 + 1] − 2𝐼𝑓[𝑥𝑚, 𝑦𝑚] + 𝐼𝑓[𝑥𝑚, 𝑦𝑚 − 1])

𝑎6 =1

4(𝐼𝑓[𝑥𝑚 + 1, 𝑦𝑚 + 1] − 𝐼𝑓[𝑥𝑚 − 1, 𝑦𝑚 + 1] − 𝐼𝑓[𝑥𝑚 + 1, 𝑦𝑚 − 1] + 𝐼𝑓[𝑥𝑚 − 1, 𝑦𝑚 − 1])

The centroiding algorithm will be implemented via Python script. The hot pixel threshold is set within the

script. The number of frames to average is set by the attribute

“atst.tcs.wccs.cv.calibCtrl.centroidNumImages”, and the ID of the reference image is set by the attribute

“atst.tcs.wccs.cv.calibCtrl.refPsfId”.

We have simulated this algorithm to demonstrate its effectiveness in detecting and centroiding point

sources on simulated night images. The simulation begins by creating a synthetic image consisting of one

bright point source and multiple background point sources placed randomly throughout the image.

The photon flux arriving at the top of Earth’s atmosphere is calculated using standard flux models for a

given apparent magnitude, assuming 5500 K star temperature. Atmospheric transmission in the visible is

estimated from “Allen’s Astrophysical Quantities”[2] and transmission through DKIST to the CV camera

is estimated using theoretical or as-built (where available) coating response curves.

The final CV image is calculated by convolving the perfect point source image with a long-exposure

atmospheric PSF modeled as a Lorentzian with full-width-half-max equal to 𝜆 𝑟0⁄ . Shot noise and read

noise are added to the image based on measured CV camera parameter and hot pixels are added by

randomly setting a user-adjustable number of pixels to their max value, 1023.

The above algorithm is then applied to the noisy image and the error between the measured centroid and

the actual star position is calculated over 100 iterations.

Simulation results are shown in Figure 1. The top two images show a simulated magnitude 4.0 star with

five randomly-positioned background stars that are each half its apparent magnitude. For these

simulations, we assume that the CV filter has been removed. Using the 60-arcsecond field of view, a one

second CV exposure time, and no binning, the stars are all easily visible to the eye and the centroiding

algorithm is able to locate the brightest star to within 5 milli-arcseconds.

CV CDD


The bottom two images show a different image generated with an 8.0 magnitude star. In this case, the

brightest star is very difficult to identify by eye but the centroiding algorithm is able to locate the center

of the bright star to within 0.04 arcseconds. This result demonstrates the power of a matched filter

approach. As seen in Figure 2, the matched filter clearly identifies the stars in the image, even with a

reference PSF that is a different shape and width of the actual PSF. For these simulations, we use a

Lorentzian PSF for the true telescope PSF and our reference PSF is a Gaussian with half the width of the

actual telescope PSF.

Figure 1: Simulated images: [top left] mag 4.0 star [top right] mag 4.0 star with noise [bottom left] mag 8.0 star [bottom

right] mag 8.0 star with noise

CV CDD


Figure 2: Output of the matched filter on the noisy image from the bottom of Figure 1

Figure 3: Estimated CV centroiding error both with and without the CV filter in place

Figure 3 shows the estimated performance of the CV centroiding algorithm as a function of star

brightness. The plot was made using the same estimation methods described in TN-0185. Results of the

full centroiding simulation described earlier agree closely with the results shown in Figure 3.

For night-time imaging with the filter in place, the limiting magnitude is approximately 5.0 for a

centroiding accuracy of 0.1 arcseconds. With the filter removed, the limiting magnitude is increased to

approximately 8.5. These results suggest that it may be possible to do night-time pointing maps with the

CV filter in place, however, removing the filter will provide much better performance.

CV CDD


The CV filter is designed to be easily removable by hand and will not shift the beam when replaced so we

recommend removing the CV filter for night-time pointing map calculations.

3.2 CV LIMB FINDING

The CV will be able to locate the solar limb position as part of the procedure for establishing the

heliocentric coordinate system. The limb finding algorithm works by identifying the most prominent line

in the CV image using a combination of the Canny edge detection algorithm and Hough line transform.

Before running the solar limb image through the Canny and Hough algorithms, the dark and gain-

corrected CV image will be downsampled to reduce the computational complexity of the problem and

average out noise. Based on simulations, the default downsampling will be by a factor of 8. The

downsampling factor may be adjusted during IT&C based on on-sky results.

The Canny edge detection algorithm [3] is a non-linear image processing method that uses gradients to

identify edge features in images. Its output is a binary image with ones representing edge pixels. We will

use the “canny” function in the scikit-image package for Python[5] to implement the Canny edge detection

step of this algorithm. The Canny filter parameters are set within the Python script and can be easily

adjusted by the WFC specialist.

After processing with the Canny edge filter, the resulting binary image is run through a Hough line

transform. The Hough line transform maps points in image space to sinusoids in Hough space, a space

parameterized by the polar coordinates of a vector normal to lines in image space. If a strong line feature

exists in the image, the sinusoids produced in Hough space by the line pixels will all intersect at a

common point, which defines the vector normal to the line feature. The Hough transform will identify the

most prominent line in the CV image, which should be the solar limb.

For this algorithm, we will use the “hough_line” and “hough_line_peaks” functions in the scikit-image

package[5] to implement the Hough transform.

When using the CV limb finding calibration, the accuracy will be improved if the CV is set to the 30

arcsecond field of view so that the solar limb is better fit by a line.

We have simulated this algorithm using a synthetic image of the solar limb. The synthetic image was

generated using the solar limb darkening function at 550 nm from “Allen’s Astrophysical Quantities”[2],

𝐼(𝜓)

𝐼(0)= 1 − 0.47(1 − cos 𝜓) − 0.23(1 − cos 𝜓)2

where 𝐼 is the intensity, 𝜓 is the angle of incidence from the emitting surface to the observer. Using the

small angle approximation,

cos 𝜓 ≈ √1 − (𝜃

sin Ω)

2

where 𝜃 is the angle from the center of the sun to the observed point on the sun and Ω is the angle from

the center of the sun to the limb of the sun.

CV CDD


Figure 4: Simulated limb images [left] noiseless image [right] with detector noise and atmospheric blurring. Heat map

stretch shows intensity values at 550 nm.

Figure 5: [left] Canny edge detector output [right] Hough transform results

A simulated 30-arcsecond image of the solar limb with no noise and no diffraction effects is shown in

Figure 4. After the limb image is generated, it is convolved with an atmospheric PSF, created using the

same process as in the previous section, and random photon noise and read noise are added. For noise

purposes, we assume that the CV exposure time has been adjusted so the maximum non-saturated pixel is

approximately 80% of the detector’s full well depth.

Figure 5 shows the result of applying the Canny edge detector and then a Hough line transform to the

limb image. The global maximum in the Hough transform results identifies the position of the solar limb.

Using this method, we are able to detect the solar limb position to an accuracy better than 0.1 arcseconds

and a repeatability better than 0.05 arcseconds. There is some bias in the measurement because the solar

limb is actually an arc rather than a line. As a result of this, using the smallest field of view possible will

give the best accuracy when finding the solar limb.

CV CDD


If the CV is required to identify the solar limb to better than 0.1 arcseconds accuracy then we may need to

alter this algorithm. One way to improve its accuracy would be to apply a correction factor to find the

difference between the solar limb position and the linear approximation to the limb.

It’s also possible that the accuracy could be improved by using the Hough circle transform instead of the

Hough line transform. The Hough circle transform is generally applied to circles that fit fully within the

image. However, since we are able to tightly constrain the circle’s radius, we should be able to accurately

identify the solar center point based on a limb image.

3.3 CV STREHL CALCULATION

The CV will need to estimate the Strehl ratio of a point source for use during fabrication and laboratory

integration before being shipped to the telescope.

When Strehl ratio measurement is enabled, the CV will grab the most recent image from the CV camera,

perform a Strehl measurement, and report the measured Strehl value. The Strehl measurement routine will

perform a user-defined number of measurements and return the mean Strehl and the standard deviation of

the Strehl measurements.

The Strehl ratio measurement procedure will estimate the Strehl ratio of the brightest point source in the

CV image using the following procedure, which is very similar to method 2b from Roberts, et al[1].

1. The centroiding algorithm from section 3.1 will be used to estimate the position of the brightest

point source in the image. The reference PSF used for the centroiding algorithm and the reference

PSF used later in the Strehl calculation will be the same array. Reference PSF arrays will be

calculated offline and loaded from a database when the Strehl calculation is requested. The

reference PSF to use will be loaded based on both the current CV field of view and the current

calibration target in use.

2. The CV image is translated, using Shannon interpolation, by the negative of the error vector

measured in the previous step. The center pixel of the detected point source should now be

aligned with the center pixel of the CV detector.

3. The CV image will be cropped to a square image encompassing the central 171 by 171 pixels of

the full CV image.

4. The median value of all pixels outside a 68 pixel radius from the center of the cropped image will

be calculated and subtracted from all pixels of the cropped image.

5. All pixels in the cropped image within a 68 pixel radius of the center will be summed together

and all pixels in the cropped image will be divided by this summed value.

6. The same procedures in steps 4 and 5 will be applied to the reference PSF. If the reference PSF is

larger than the cropped PSF, the central 171 by 171 pixel region of the reference PSF will be

cropped before applying these procedures.

7. The Strehl ratio will be estimated by dividing the maximum value of the processed image from

step 5 by the maximum value of the processed reference image from step 6.

When generating reference PSF images, we will account for pixel size by generating a PSF from

analytical methods at a resolution at least 4x the final resolution, then downsampling to the resolution of

the CV.

The Strehl calculation is performed by a Python script. The script can be easily modified to change the

values of the window size (step 3), the radii of the background subtraction region (step 4), and the PSF

normalization radius (step 5).

CV CDD


Reference PSFs will be generated offline and loaded into the bulk database. An attribute in the CV

controller (atst.tcs.wccs.cv.calibCtrl.refPsfId) indicates which reference PSF is to be used in the

calibration script.

3.4 CV PLATE SCALE CALCULATION

The CV will need to estimate its plate scale as part of the routine WFC calibration process. The CV

platescale is used for calibrating the telescope pointing and the HOWFS and LOWFS offpointing

positions.

The CV platescale will be calibrated using a line grid target at the GOS focal plane of the telescope. The

line grid target will contain horizontal and vertical lines with a known constant spacing between them.

When the CV is configured to perform a plate scale calibration, it will image the line grid target, calculate

the distance between the grid lines in pixels, and use knowledge of the line grid spacing to estimate the

CV platescale.

The key calculation to this algorithm is the determination of the line spacing in the CV image. For this

step we rely on the Hough line transform. Similar to section 3.2, we will use the scikit-image function

“hough_line” in this algorithm as well. In Hough space, the grid of lines corresponds to two columns of

points, with the space between points in one column representing the pixel distance between grid lines in

the horizontal direction, and the space between points in the other column representing the pixel distance

between grid lines in the vertical direction.

We calculate the spacing between points by extracting the column of points, finding its autocorrelation,

and determining the distance from the center of the autocorrelation to its first maximum.

One note on this procedure is that the GOS targets will rotate relative to the CV based on the telescope

altitude, azimuth, and coudé angles. Therefore, it is unlikely that the horizontal and vertical grid lines will

be aligned with the x and y axes of the CV unless the coudé platform is specifically rotated for this

purpose. Additionally, the GOS grid target may have an alignment target obscuring the grid lines in the

central 20 arcseconds

In order to perform this calibration with a centrally-obscured, non-aligned grid, we first do a rough

calculation of the grid angle, then mask out the center of the image with a square of the appropriate size

and rotation. We then perform the plate scale calculation, and finally we rotate the calculated plate scales

from the target grid horizontal-vertical coordinates into the CV x-y coordinates.

The full procedure is as follows,

1. Identify which field-of-view is currently selected for the CV

2. Acquire a CV image that has been dark and gain-corrected.

3. Calculate the Otsu threshold of the image[6] using the scikit-image function “threshold_otsu[5]”.

Set all pixels with intensity value above the Otsu threshold to zero and all pixels with intensity

value equal to or below the Otsu threshold to one.

4. Perform a low-resolution (angular resolution ~0.5 degrees) Hough transform on the thresholded

image using the scikit-image “hough_line” function over angles -45 to +45 degrees.

5. Sum along the radial values (columns) of the resulting Hough accumulator and find the maximum

value, corresponding to the rotation angle of the target grid.

6. Create a square mask the size of the known obscuration in the center of the grid target, at a

rotation angle equal to the rotation angle calculated in step 5. The size of the mask will depend on

the selected CV field of view. Set all pixel values of the image obtained in step 2 within the

masked area equal to the mode of the intensity values in that same image.

CV CDD


7. Calculate the Otsu threshold of the masked image[6] using the scikit-image function

“threshold_otsu[5]”. Set all pixels with intensity value above the Otsu threshold to zero and all

pixels with intensity value equal to or below the Otsu threshold to one.

8. Calculate a high-resolution Hough line transform (angular resolution < 0.05 degrees) to the

thresholded image from step 7 using the scikit-image function “hough_lineError! Reference source not f

ound.” for angles between -90 and +90 degrees.

9. Search the columns of the Hough space image that correspond to angles between -45 and +45

degrees for the column that has the largest summed value. Extract that column and all columns to

the left and right of it corresponding to angles ±5 degrees of the maximum column. The exact

number of columns to extract may change during IT&C based on the width of the grid lines on

the target.

10. Average across rows of the extracted columns from the previous step to form a 1-D array.

Calculate the autocorrelation of this array. Find the gradient of the autocorrelation.

11. Ignoring the peak near zero, calculate the first zero-crossing where the gradient of the

autocorrelation goes from positive to negative. Use quadratic interpolation to find the zero-

crossing value to subpixel precision.

12. The zero-crossing value is the number of pixels between grid lines in the horizontal direction.

13. Set the values in all columns extracted in step 9 to zero and search all columns in the Hough

image for the column with the largest summed value. Check that this new maximum column is

approximately 90 degrees from the maximum column found in step 9. Extract the new maximum

column and all columns to the left and right of it corresponding to angles ±5 degrees of the

maximum column. The exact number of columns to extract may change during IT&C based on

the width of the grid lines on the target.

14. Repeat steps 10-12, with the columns extracted in step 13. The zero-crossing value from this

second set of columns is the pixel spacing between grid lines in the horizontal direction.

15. Using the known spacing of the target grid lines, project the measured horizontal and vertical grid

spacings into the CV x and y coordinate plane and calculate the CV plate scale in x and y

directions.

We have simulated this algorithm to verify that it meets accuracy requirements. Note that there are

additional steps in the algorithm that are not detailed in the above steps. The additional steps deal with

how to handle maxima near the edge of the Hough accumulator, smoothing to improve detection of the

zero-crossing in steps 11 and 14, and a fix to prevent the projection of grid spacing to CV x and y

coordinates from blowing up when the grid is rotated at 45 degrees.

The test image of the line grid was simulated based on line grid images from the DST that were

dynamically rescaled to match the line grid spacing at the DKIST. The 30-arcsecond CV field of view

was simulated, since the obscuration from the central Air Force target is more pronounced in that

configuration.

CV CDD


Figure 6: [clockwise from top left]: Grid image, thresholded image, Hough transform, Extracted column average.

Figure 6 shows the DST image used in our simulations, rescaled to the 30 arcsecond CV platescale. The

center 21 arcseconds of the image has been cut out to approximate the proposed GOS target. The

proposed GOS target has an Air Force resolution target obscuring the center 21 arcseconds of the grid, so

that area of the image is unusable for platescale calculations. In our simulations, we were able to identify

the CV platescale to an accuracy of 0.0002 arcseconds per pixel.

Further testing was run with the CV camera in the lab, using a printed grid target. The printed grid target

was used to test that the algorithm was robust for variable grid spacing, thickness, and rotation.

3.5 CV FOCUS CALIBRATION

The CV will need to optimize its focus as part of the routine WFC calibration process.

The CV Focus Calibration uses an iterative search to maximize the squared image gradient, a criteria

shown to repeatably find the best focus position for a variety of image structures[7].

The full procedure is as follows,

1. Identify the objective lens currently in use by the CV

2. Move the z-axis motor of the active CV objective lens to its “default” named position.

CV CDD


3. Read the current “default” named position from the current motor position and set it as the center

of the current focus-finding iteration. Set the step size of the current focus-finding iterations as

the default step size. The default step size is set through an attribute of the CV camera controller.

4. Move the z-axis motor of the active CV objective lens to the position, ‘center – step size’.

5. Acquire a CV image that has been dark and gain-corrected and calculate the squared sum of the

image gradients in x and y directions,

𝑔𝑡𝑜𝑡 = 𝑔𝑥 + 𝑔𝑦

where,

𝑔𝑥 = ∑ ∑(𝐼(𝑥 + 1, 𝑦) − 𝐼(𝑥, 𝑦))2

𝑁−2

𝑦=0

𝑀−1

𝑥=0

𝑔𝑦 = ∑ ∑(𝐼(𝑥, 𝑦 + 1) − 𝐼(𝑥, 𝑦))2

𝑁−2

𝑦=0

𝑀−1

𝑥=0

6. Repeat steps 4 and 5 for the positions ‘center’ and ‘center + step size’.

7. Fit a polynomial to the squared gradients calculated for the three z positions and find the z-

position that corresponds to the maximum squared gradient.

8. If the z-position corresponding to the maximum squared gradient is bracketed by ‘center – step

size’ and ‘center + step size’ then define the center of the next iteration as the z-position

corresponding to the maximum squared gradient and divide the step size by two.

9. If the z-position corresponding to the maximum squared gradient is outside the range searched by

the previous steps, then define the center of the next iteration as ‘center – step size’ if the best z-

position is less than ‘center – step size’. Otherwise define the center of the next iteration as

‘center + step size’. Do not change the step size.

10. Check convergence criteria. If the maximum number of iterations has been reached or the

difference between the center of the next iteration and the center of the current iteration is less

than the minimum step size, proceed to the next step. The maximum number of iterations is set

through an attribute of the CV controller. The minimum step size is set in the CV Focus

calibration script.

If the convergence criteria has not been met, continue to the next focus-finding iteration by

repeating steps 4-10 with the new center position and step size.

11. Move the z-motor of the active objective lens to the position corresponding to the maximum

squared gradient.

12. Enable position saves on the current z-axis motor and save the current position as the “default”

named position.

We have tested this algorithm in the lab on a variety of test targets to verify that it meets accuracy and

repeatability requirements.

CV CDD


4 CV OPTICAL DESIGN

This section presents the CV optical design and analysis supporting its ability to meet all design

requirements. The optical layout of the CV elements is shown in Figure 7. The optical interface to the CV

is defined by the transmissive surface of the LOWFS beam splitter.

The two CV objective lenses are mounted on motorized translating stages so that they can be moved

perpendicular to the optical path. Using these motorized stages, either of the objective lenses can be

moved into or out of the beam path, providing either a 30 arcsecond field of view or a 60 arcsecond field

of view.

A flat-top filter with 530 nm central wavelength and 10 nm bandpass will be placed in the converging

beam between the objective lens and the final image.

When DKIST is observing in diffraction-limited mode, the CV will receive diffraction-limited images.

Consequently, the final image must be sampled finely enough to resolve fine structures in the observed

objects and the CV optics must not significantly degrade the image quality. These aspects of the CV

design are captured in the CV design requirements.

Figure 7: CV optical layout

4.1 CV OPTICAL DESIGN REQUIREMENTS

The following are the requirements used to create and tolerance the CV optical design.

1. Central wavelength: 530 nm

CV CDD


2. Bandpass: 10 nm

3. Field of View switchable between 30 arcseconds and 60 arcseconds (square)

4. Strehl performance (30 arcsecond FoV): minimum 0.7 over full field

5. Strehl performance (60 arcsecond FoV): minimum 0.4 over central 45 arcseconds,

minimum 0.3 over remainder of FoV

6. Final image plate scale (30 arcsecond FoV): 1.980 arcseconds/mm

7. Final image plate scale (60 arcsecond FoV):3.960 arcseconds/mm

8. Maximum track length: 3.2 meters measured from LOWFS beam splitter

Optical design requirements 1-3 flow down directly from SPEC-0058. Optical design requirement 4

derives from engineering requirements to use the CV for validating WFC Strehl performance.

Requirement 5 derives from the operational need to display images of the telescope FoV without

significantly degrading the image quality.

Requirements 6 and 7 are driven by requirement 3 in combination with SPEC-0058, which sets

requirements on the pixel sampling of the CV. The chosen CV camera has 7.4 micron pixels and an active

area that is 2048 x 2048 pixels square. As a result, we desire the final pixel scale to be,

30 𝑎𝑟𝑐𝑠𝑒𝑐𝑜𝑛𝑑𝑠

2048∗0.0074 𝑚𝑚= 1.980 𝑎𝑟𝑐𝑠𝑒𝑐𝑜𝑛𝑑𝑠/𝑚𝑚,

for the 30 arcsecond field of view and, similarly, 3.959 arcseconds/mm for the 60 arcsecond field of view.

Final plate scale is a function of system focal length:

𝑃 =206265

𝑓

where P is the platescale in arcseconds/mm and f is the effective focal length in mm. In order to achieve

the desired platescales, we require a focal length of 104.20 meters for the 30-arcsecond CV and 208.40

meters for the 60-arcsecond CV. Given the system’s numerical aperture of 4 meters, these focal lengths

correspond to an effective F/# of 26.050 for the 30-arcsecond CV and 13.025 for the 60-arcsecond CV.

The expected plate scales yield a final resolution of 1.87 pixels per resel for the 30-arcsecond FoV and

0.93 pixels per resel for the 60-arcsecond FoV, with a resel defined as the CV central wavelength divided

by the telescope aperture. This sampling meets the top-level resolution requirements in SPEC-0058.

Requirement 8 is an engineering requirement to ensure all the optics fit on the table space allocated.

4.2 CV OPTICAL PERFORMANCE

Figure 8 and Figure 10 show spot diagrams from the baseline optical design of the 30-arcsecond and 60-

arcsecond CV configurations. Spots are shown at the center and at each edge of the field of view.

CV CDD


Figure 8: Spot diagram of center and corners of the 30-arcsecond CV.

Figure 9: Strehl map for as-designed 30-arcsecond CV

CV CDD


Figure 10: Spot diagram of center and corners of the 60-arcsecond CV.

Figure 11: Strehl map for as-designed 60-arcsecond CV

CV CDD


4.3 OPTICAL TOLERANCE ANALYSIS

ASE Optics performed the tolerance analysis for the WFC relay optics, including the CV. Requirements

for performing this analysis are given in section 4.1. Results from the full WFC Relay Optics tolerance

analysis are discussed in DKIST project document TN-0189.

4.3.1 ZEMAX Tolerance Model

Table 1 contains the parameters used by ASE Optics to run the tolerance analysis for the CV with the 30

arcsecond objective selected. The parameters used for the 60 arcsecond CV are identical to those for the

30 arcsecond CV except for the change in position of the objective lens, which causes the airspace

compensator for the 60 arcsecond CV to be reduced by about half.

Table 1: ZEMAX model tolerance inputs for WFC relay optics with 30 arcsecond CV

# Type Surf Nominal Min Max Comment

1 TOFF - - - - ** Compensator

2 COMP 101 -1905.1 -20.0 20.0 Airspace, triplet to image plane

3 CPAR 102 -1.3039 -2.00 20.0 Image Plane, Theta-X Tilt

4 CPAR 102 0.0000 -2.00 20.0 Image Plane, Theta-Y Tilt

5 TOFF - - - -

6 TWAV - - 0.6328 - Default test wavelength.

8 TOFF - - - - ** Homogeneity Tolerances:

9 TEZI 84 0.0000 -2.54E-5 2.54E-5 HOAO Splitter

10 TEZI 91 0.0000 -2.54E-5 2.54E-5 LOAO Splitter

11 TEZI 97 0.0000 -2.00E-5 2.00E-5 Triplet, L1

12 TEZI 98 0.0000 -3.00E-5 3.00E-5 Triplet, L2

13 TEZI 99 0.0000 -2.00E-5 2.00E-5 Triplet, L3

14 TOFF - - - - ** Power Tolerances:

15 TFRN 84 0.0000 -0.100 0.100 HOAO Splitter Front

16 TFRN 85 0.0000 -0.100 0.100 HOAO Splitter Back

17 TFRN 91 0.0000 -0.100 0.100 LOAO Splitter Front

18 TFRN 92 0.0000 -0.100 0.100 LOAO Splitter Back

19 TFRN 97 0.0000 -0.500 0.500 Triplet

20 TFRN 98 0.0000 -0.500 0.500

21 TFRN 99 0.0000 -0.500 0.500

22 TFRN 100 0.0000 -0.500 0.500

23 TOFF - - - - ** Thickness tolerances:

24 TOFF - - - - ** Airspaces

25 TTHI 87 -174.60 -0.500 0.500 HOAO Splitter to LOAO Splitter

CV CDD


26 TTHI 94 -175.40 -0.500 0.500 LOAO Splitter to Triplet

27 TOFF - - - - ** Glass Thickness

28 TTHI 84 -25.400 -0.150 0.150 HOAO Splitter

29 TTHI 91 -25.400 -0.150 0.150 LOAO Splitter

30 TTHI 97 -10.000 -0.150 0.150 Triplet, L1

31 TTHI 98 -15.000 -0.150 0.150 Triplet, L2

32 TTHI 99 -10.000 -0.150 0.150 Triplet, L3

33 TOFF - - - - ** Surface Tilt Tolerances:

34 TSTX 84 0.0000 -1.39E-3 1.39E-3 HOAO Splitter

35 TSTY 84 0.0000 -1.39E-3 1.39E-3

36 TSTX 91 0.0000 -1.39E-3 1.39E-3 LOAO Splitter

37 TSTY 91 0.0000 -1.39E-3 1.39E-3

38 TSTX 97 0.0000 -1.67E-3 1.67E-3 Triplet L1 Front

39 TSTY 97 0.0000 -1.67E-3 1.67E-3

40 TSTX 98 0.0000 -1.67E-3 1.67E-3

41 TSTY 98 0.0000 -1.67E-3 1.67E-3

42 TSTX 99 0.0000 -1.67E-3 1.67E-3

43 TSTY 99 0.0000 -1.67E-3 1.67E-3

44 TSTX 100 0.000 -1.67E-3 1.67E-3 Triplet L3 Back

45 TSTY 100 0.0000 -1.67E-3 1.67E-3

46 TOFF - - - - ** Element decenter & tilt tolerances:

47 TEDX 97 0.0000 -0.025 0.025 Triplet

48 TEDY 97 0.0000 -0.025 0.025

49 TETX 97 0.0000 -8.33E-3 8.33E-3

50 TETY 97 0.0000 -8.33E-3 8.33E-3

51 TOFF - - - - ** Element Tilt within triplet

52 TETX 97 0.0000 -1.67E-3 1.67E-3 Triplet L1

53 TETY 97 0.0000 -1.67E-3 1.67E-3

54 TETX 99 0.0000 -1.67E-3 1.67E-3 Triplet L3

55 TETY 99 0.0000 -1.67E-3 1.67E-3

56 TOFF - - - - ** Irregularity tolerances:

57 TIRR 84 0.0000 -0.100 0.100 HOAO Splitter Front

58 TIRR 85 0.0000 -0.100 0.100 HOAO Splitter Back

CV CDD


59 TIRR 91 0.0000 -0.100 0.100 LOAO Splitter Front

60 TIRR 92 0.0000 -0.100 0.100 LOAO Splitter Back

61 TIRR 97 0.0000 -0.500 0.500 Triplet

62 TIRR 98 0.0000 -0.500 0.500

63 TIRR 99 0.0000 -0.500 0.500

64 TIRR 100 0.0000 -0.500 0.500

65 TOFF - - - - ** Index tolerances:

66 TIND 84 1.4585 -5.00E-4 5.00E-4 HOAO Splitter

67 TIND 91 1.4585 -5.00E-4 5.00E-4 LOAO Splitter

68 TIND 97 1.5225 -2.00E-4 2.00E-4 Triplet L1

69 TIND 98 1.4388 -2.00E-4 2.00E-4 Triplet L2

70 TIND 99 1.5225 -2.00E-4 2.00E-4 Triplet L3

71 TOFF - - - - ** Abbe number tolerances:

72 TABB 84 67.821 -0.339 0.339 HOAO Splitter

73 TABB 91 67.821 -0.339 0.339 LOAO Splitter

74 TABB 97 59.835 -0.120 0.120 Triplet L1

75 TABB 98 94.946 -0.190 0.190 Triplet L2

76 TABB 99 59.835 -0.120 0.120 Triplet L3

4.3.2 Monte Carlo Results

A Monte Carlo analysis was used to evaluate the likelihood of the manufactured CV design to meet Strehl

requirements based on the defined manufacturing and alignment tolerances. 1000 simulations were run

for each CV setup. For the 30 arcsecond CV, 92% if the Monte Carlo results met requirements, and for

the 60 arcsecond CV, 99% of the Monte Carlo results met requirements.

4.4 OPTICAL ALIGNMENT

Installation and alignment of the CV will be done after the WFC relay optics, up to and including the

LOWFS beamsplitter, have been installed and aligned. The 30 arcsecond objective lens will be installed

first and the facility CMM will be used to position it. Next, the filter assembly will be installed. A facility

wavefront sensor (4D PhaseCam) will be used to fine-tune the decenter and tilt of the 30 arcsecond

objective lens. The 30 arcsecond objective will then be moved out of the beam and the 60 arcsecond

objective will be installed, aligned with the CMM, and then fine-tuned using the wavefront sensor.

Finally, the camera will be installed and aligned using the CMM and fine-tuned using the GOS pinhole to

center and focus the camera. An extended source at the GOS, such as an air force target or grid, will be

used to fine-tune the camera tilt. Additional alignment details will be documented in PROC-0261, WFC

Alignment Plan, and will be included with the documentation delivered with the system.

CV CDD


5 CV HARDWARE DESIGN

5.1 OVERVIEW OF COUDÉ WFS LAYOUT

The following few images give a perspective of the overall CV design in the coudé room and relative

position to the other associated coudé instrumentation.

A top down view of the overall coudé instrumentation optical layout is shown in Figure 12. The location

of the wavefront correction optical system is shown in brown in the upper left quadrant.

Figure 12: Overhead view of coudé instrumentation

Figure 13 shows an overhead view of the wavefront correction system and how it is fed by the main

telescope light feed. Figure 13 also shows a closer overhead view of the wavefront correction system as it

is laid out on optical tables in the coudé instrument lab.

CV CDD


Figure 13: Light feed to WFC optics (left), WFC bench closeup (right)

Figure 14 shows the wavefront correction system and telescope feed optics with the major components

labeled, along with the High Order WFS, Context Viewer and Low Order WFS channels.

Figure 14: WFC system with optical paths labeled

CV CDD


5.2 OVERVIEW OF WFS OPTO-MECHANICAL LAYOUT

Figure 15 shows an overview of the WFC opto-mechanical system layout. The WFC feed optics and

Context Viewer are depicted in the yellow light path, while the HOWFS is shown in the red light path and

the LOWFS is shown in the green light path.

Figure 15: Opto-mechanical layout of WFC, CV path shown in yellow.

A detailed drawing of the wavefront correction system components is shown in Figure 16 along with an

identification of each major subsystem item in Table 2.

CV CDD


Figure 16: WFC detail with all components labeled.

Table 2: WFC component list

Item # Description

1 M10 - Deformable Mirror

2 BS1 - WFS Beam Splitter

3 OAA1 - Off Axis Asphere #1

4 FM1 - Fold Mirror

5 FM2 - Fold Mirror

6 OAA2 - Off Axis Asphere #2

7 HOWFS BS - High Order Beam Splitter

8 LOWFS BS - Low Order Beam Splitter

9 CV 30 OL - Context Viewer 30 arcsecond Objective Lens

10 CV 60 OL - Context Viewer 60 arcsecond Objective Lens

11 CV Filter

12 CV Camera

CV CDD


Item # Description

13 HO FSM – High Order Field Steering Mirror

14 HO OL – High Order WFS Objective Lens

15 HO FS – High Order WFS Field Stop

16 HO PL – High Order WFS Pupil Lens

17 HO LA – High Order WFS Lenslet Array

18 HO RL1 – High Order WFS Relay Lens #1

19 HO F – High Order WFS Filter

20 HO RL2 – High Order WFS Relay Lens #2

21 HO Camera

22 LO FSM – Low Order WFS Field Steering Mirror

23 LO OL – Low Order WFS Objective Lens

24 LO FS – Low Order WFS Field Stop

25 LO PL – Low Order WFS Pupil Lens

26 LO LA – Low Order WFS Lenslet Array

27 LO RL1 – Low Order WFS Relay Lens #1

28 LO F – Low Order Filter

29 LO RL2 – Low Order WFS Relay Lens #2

30 LO Camera

5.3 CV OPTO-MECHANICAL DESIGN

A summary of the CV opto-mechanical layout is shown in Figure 17. The following subsections provide

detailed design descriptions of each of the CV assemblies.

CV CDD


Figure 17: CV opto-mechanical overview

Table 3: CV motions and part numbers

The required CV motions and associated mechanism part numbers are listed above in Table 3.

Motorized Micrometer Manual Stage MFR Stage Model Motor MFR Motor Model Micrometer MFR Micrometer Model

WFC CV

HR Objective Lens

X Parker 404200XRMS__D2H7L7C1M12E1B1P1R1 Parker SM232BE-NPSN

Y NSO Newport SM-50

Z Parker 40450XRMS__D2H7L7C5M3E1B1P1R1 Parker SM232BE-NPSN

α NSO

β NSO

LR Objective Lens

X Parker 404200XRMS__D2H7L7C1M12E1B1P1R1 Parker SM232BE-NPSN

Y NSO Newport SM-50

Z Parker 40450XRMS__D2H7L7C5M3E1B1P1R1 Parker SM232BE-NPSN

α NSO

β NSO

Filter

Z Newport

Camera Mount

X Newport M-426 Newport SM-25

Y Newport M-426 Newport SM-25

Z Newport M-426 Newport SM-25

β NSO Newport AJS100-1

Common to Filter & Camera

Dovetail Rail Newport PRL-12

Dovetail Carrier Newport M-PRC-3

Dovetail Carrier Newport M-PRC-3

Filter Holder Newport FH-2R

CV CDD


5.3.1 30-Arcsecond Objective Lens Assembly

Figure 18: CV 30 arcsec objective lens assembly

CV CDD


The 30-arcsecond objective lens assembly is a mount consisting of motorized stages for translation in the

x and z axes, a manual micrometer for translation in the y axis, and a tip/tilt adjustable lens cell. The

assembly is shown in Figure 18.

The motorized x-axis stage is used for placing the lens into or out of the optical path. The motorized z-

axis stage is used for positioning the lens along the optical path for focus. These stages are 404XR series

manufactured by Parker and the motors are Parker SM23 series brushless servo motors with closed loop

encoder feedback.

The y-axis adjustment is a manual micrometer used for positioning the height of the lens in the optical

path above the bench. The adjustment is accomplished by means of a micrometer driven wedge and

locked in place with a clamping dovetail slide. This adjustment is for alignment purposes and would

remain locked in place at all other times. The micrometer is a Newport SM-50 with 1µm Vernier scale

resolution.

The lens cell is tip/tilt adjustable. The pivot point is a spherical bearing and the tip/tilt is performed by

turning two spring loaded adjusting screws that can be locked with opposing setscrews. This adjustment

is used for alignment purposes and would be locked in place during normal operations.

Table 4: 30 arcsec objective lens requirements & actual performance specs

Requirement Actual

X-axis Automated Motorized

Resolution: x-axis 5 µm 5 µm

Repeatability: x-axis 5 µm 3 µm

Accuracy: x-axis 25 µm 20 µm

Range: x-axis 100 mm 200 mm

Velocity: x-axis 25 mm/s 300 mm/s max

Z-axis Automated Motorized

Resolution: z-axis 5 µm 5 µm

Repeatability: z-axis 5 µm 3 µm

Accuracy: z-axis 25 µm 12 µm

Range: z-axis ±10 mm 50 mm

Velocity: z-axis 1 mm/s 300 mm/s max

Y-axis Manual Adjust Micrometer

Resolution: y-axis 5 µm 4.7 µm/10 µm micrometer div

Range: y-axis ±10 mm ±11.6 mm

Lockable: y-axis

Tip/Tilt Resolution 1 arcminute 3.9 arcsec/° adj screw

Tip/Tilt Range ±5 arcmin 23.3 arcmin/turn adj screw

Lockable: Tip/Tilt

CV CDD


Table 5: 30 arcsec objective lens COTS datasheets

COTS Datasheets for 30 arcsec Objective Assy

Parker 404XR series stages 34001-Parker-XR_SeriesStages.pdf

Parker SM series motors 34002-Parker-SM_SeriesMotor.pdf

Newport SM series micrometers 34003-Newport-SM_Series Micrometers.pdf

The requirement to motorize the 30-arcsecond objective lens assembly in x flows from the SPEC-0058

requirement that the CV provide a selectable field of view between 30 arcseconds and 60 arcseconds.

Tolerance analysis results show that this objective lens must be centered to an accuracy of 25 microns in

x, y, and z translation. This drives the minimum increment as well as the repeatability of the x and z

motors, and the manual adjust increment in the y-axis micrometer. The necessary ranges for these three

mechanisms are 10 mm in order to accommodate all the alignment cases generated by Monte Carlo

analysis with a safety factor of 3.

The objective lens also must be aligned to within 60 arcseconds accuracy tip and tilt, which sets a

requirement on the lens mounting stability. The tip and tilt range must be 5 arcminutes in order to

accommodate all the alignment cases generated by Monte Carlo analysis with a safety factor of 3.

Finally, the objective lens assembly must be able to be removed from the optical beam completely

without causing any vignetting. This imposes an additional requirement that the x-translation motor be

capable of, at minimum, 100 mm of translation.

5.3.2 30-Arcsecond Objective Lens Analysis

The analysis requirements for the 30-Arcsecond Objective Lens optical flexure was determined by

looking at multiple material and design constraints regarding the following: 1) the allowable optical

surface error as determined by the system engineering optical tolerance analysis, 2) stress limits of the

optic, 3) stress limits of the flexure, 4) predetermined lateral stability requirements up to 0.5 G while

preventing optic-to-cell gapping, and 5) maximizing flexure deformation tolerances.

Actual results of the optical surface errors have been calculated using nodal displacements from finite-

element analysis by Hofstadter Analytical Services. Dan Hofstadter’s analysis report details the unit

optical surface errors, the optical/flexure interface, as well as survivability of specific subassemblies. The

unit optical surface errors were used to determine the maximum allowable RMS surface deformation per

total applied load which defines the maximum preload.

By comparison, stresses calculated by the finite-element software were not used in the immediate area of

line contact between flexure and optical element. The nature of the finite-element model resulted in

unrealistically high stresses in the optic along the line contact. Instead, Hertzian stresses were calculated

manually by means of a linear loading analysis using a guideline of 4.4kN/m as the maximum allowable

contact line load. In all cases, the calculated line load is an order of magnitude or more under this limit.

Refer to Hofstadter’s analysis report, more specifically reference #3 - Strength of Glass from Hertzian

Line Contact, for more details.

All cases involving larger optics, such as the 30-Arcsecond Objective Lens, are deformation limited

instead of stress limited; therefore maximum preloads were determined by the wavefront error

requirements of the optic. Minimum preloads were determined by maximizing the loading conditions to

abate gapping, yet allow for manageable flexure tolerances during fabrication and assembly. The optical

flexure was analyzed via ANSYS finite element analysis (FEA) at the minimum and maximum preloads

to determine flexure displacements at both extremes and verify stresses were below allowable limits.

CV CDD


The flexure for the 30-Arcsecond Objective Lens is identical to the High Order and Low Order Objective

Lens flexure. The flexure is sized to accommodate a minimum loading of 0.70G without axially gapping

the optic/cell interface while lateral stability up to 1.2G is maintained with annealed brass pins located

+/50 degrees from nadir. The overall shape of the flexure has been optimized for imparting minimal

optical wavefront errors to meet the 24.8nm RMS requirement, from the thicker continuous inner ring

helping to distribute the load more effectively, to the long flexure fingers helping to maximize the

allowable axial tolerances for ease of manufacturing the flexure and cell. This particular flexure has been

designed and analyzed for an allowable axial deflection of 0.490 – 1.225 mm which corresponds to the

following specific design constraints: 1) minimum deflection of 0.490mm at a preload of 8N restrains the

optic axially a minimum of 0.7G, while 2) the maximum deflection of 1.225mm at a preload of 20N is

well below the acceptable stress limits of the glass and just below acceptable optical wavefront errors

using a safety factor of 2. The optic thickness and diameter has been measured to match machine the cell

to get as close as possible to nominal preload. In addition, shims at various thicknesses are used to

improve the position of the flexure as needed. Monitoring fastener torque during assembly as well as

interferometer testing will guarantee acceptable preloads and wavefront errors.

The analysis methodology to determine the appropriate flexure design is as follows. Per Hofstadter

Analytical Services, unit optical surface errors were used to determine the maximum allowable RMS

surface deformation per total applied load for each size optic. Size class of the optics is listed in Table 6

below, 30” Objective Lens Preliminary Preload Estimates. Additionally, the table below highlights the

flexure design preloads at the MIN and MAX requirements. Due to the surface error requirement of

24.8nm RMS focus removed, the maximum design preload derived from this requirement is 20N, which

corresponds to the optical surface deformation limit as shown in the table below. The minimum preload

was reduced to 8N which prevents gapping of the optic up to an axial load of 0.7G.

MIN Preload Requirement (No Axial Gapping @ .7G) = 8N

MAX Preload Requirement (Design Load) = 20N

CV CDD


Table 6: 30” Objective Lens Preliminary Preload Estimates

FEA ANSYS results shown in Figure 19 below verify flexure stresses and deformations to be at

acceptable levels at the MAX preload listed above. Margin of safety calculated below.

CV CDD


Figure 19: FEA analysis of 30” Objective Lens mounting flexure

Calculate the Margin of Safety (MOS) of the stress in the flexure based on material properties and safety

factors listed below as well as the design parameters and load/deflection of the ANSYS analysis output

listed above:

Flexure Material: Phosphor Bronze C51000 H08 Spring Temper, Flexure Thickness = 2.03mm

Material Strength: Yield = 551 MPa, Tensile = 690 MPa

Safety Factors: 1.5 Ultimate (Tensile Strength), 1.25 Yield

Predicted Stress @ Design Load of 20N = 171 MPa

MOS = (551 MPa / (171 MPa * 1.25)) - 1 = 1.6 (MOS ≥0 is acceptable)

Calculate the MOS (Margin of Safety) of the optical wavefront errors based on maximum allowable

errors as determined by the system engineering optical tolerance analysis and actual wavefront errors as

documented in Dan Hofstadter’s analysis report and scaled to this particular optic (size class 1 as shown

in the table below with the column titled “Surf nm/N”).

MAX Allowable Surface Error, Focus Removed = 24.8nm RMS

Safety Factor = 2.0

Predicted Surface Error @ MAX Flexure Preload, Focus Removed = 12nm RMS

MOS = (24.8nm RMS / (12nm RMS * 2.0)) - 1 = .03 (MOS ≥0 is acceptable)

Axial gapping of the optic is analyzed as follows to determine if the impact loads at 2G is within

acceptable limits. Using FEA, a representative optical mount was analyzed for stiffness to quantify the

optic displacement during a seismic event to calculate an effective spring rate. Impact velocity is

calculated using fundamental equations of dynamics which in turn gives you the kinetic energy at impact

which is converted into a maximum displacement. Maximum acceleration is derived from the stiffness of

the assembly, its maximum displacement, and the mass of the system, which ultimately calculates the

force on the optic in terms of a linear line load. The maximum allowable linear line load at impact is

4.4kN/m. This analysis assumes any load half the maximum, 2.2kN/m or less, is acceptable. All optics

pass in this regard; the 30-Arcsecond Objective Lens is no exception. Results are shown in Table 7

below.

CV CDD


Table 7: 30” Objective Lens mount axial gapping analysis

CV CDD


5.3.3 60-Arcsecond Objective Lens Assembly

Figure 20: CV 60 arcsec objective lens assembly

CV CDD


The 60-arcsecond lens assembly is essentially the same as the 30-arcsecond lens assembly, except that the

two lenses themselves are different thicknesses.

The 60-arcsecond objective lens assembly is a mount consisting of motorized stages for translation in the

x and z axes, a manual micrometer for translation in the y axis, and a tip/tilt adjustable lens cell. The

assembly is shown in Figure 20.

The motorized x-axis stage is used for placing the lens into or out of the optical path. The motorized z-

axis stage is used for positioning the lens along the optical path for focus. These stages are 404XR series

manufactured by Parker and the motors are Parker SM23 series brushless servo motors with closed loop

encoder feedback.

The y-axis adjustment is a manual micrometer used for positioning the height of the lens in the optical

path above the bench. The adjustment is accomplished by means of a micrometer driven wedge and

locked in place with a clamping dovetail slide. This adjustment is for alignment purposes and would

remain locked in place at all other times. The micrometer is a Newport SM-50 with 1µm Vernier scale

resolution.

The lens cell is tip/tilt adjustable. The pivot point is a spherical bearing and the tip/tilt is performed by

turning two spring loaded adjusting screws that can be locked with opposing setscrews. This adjustment

is used for alignment purposes and would be locked in place during normal operations.

Table 8: 60 arcsec objective lens requirements & actual performance specs

Requirement Actual

X-axis Automated Motorized

Resolution: x-axis 5 µm 5 µm

Repeatability: x-axis 5 µm 3 µm

Accuracy: x-axis 25 µm 20 µm

Range: x-axis 100 mm 200 mm

Velocity: x-axis 25 mm/s 300 mm/s max

Z-axis Automated Motorized


Repeatability: z-axis 5 µm 3 µm

Accuracy: z-axis 25 µm 12 µm

Range: z-axis ±10 mm 50 mm

Velocity: z-axis 1 mm/s 300 mm/s max

Y-axis Manual Adjust Micrometer

Resolution: y-axis 5 µm 4.7 µm/10 µm micrometer div

Range: y-axis ±10 mm ±11.6 mm

Lockable: y-axis

Tip/Tilt Resolution 1 arcminute 3.9 arcsec/° adj screw

Tip/Tilt Range ±5 arcmin 23.3 arcmin/turn adj screw

CV CDD


Lockable: Tip/Tilt

Table 9: 60 arcsec objective lens COTS datasheets

COTS Datasheets for 60 arcsec Objective Assy

Parker 404XR series stages 34001-Parker-XR_SeriesStages.pdf

Parker SM series motors 34002-Parker-SM_SeriesMotor.pdf


The requirement to motorize the 60-arcsecond objective lens assembly in x flows from the SPEC-0058

requirement that the CV provide a selectable field of view between 30 arcseconds and 60 arcseconds.

Tolerance analysis results show that this objective lens must be centered to an accuracy of 25 microns in

x, y, and z translation. This drives the minimum increment as well as the repeatability of the x and z

motors, and the manual adjust increment in the y-axis micrometer. The necessary ranges for these three

mechanisms are 10 mm in order to accommodate all the alignment cases generated by Monte Carlo

analysis with a safety factor of 3.

The objective lens also must be aligned to within 60 arcseconds accuracy tip and tilt, which sets a

requirement on the lens mounting stability. The tip and tilt range must be 5 arcminutes in order to

accommodate all the alignment cases generated by Monte Carlo analysis with a safety factor of 3.

Finally, the objective lens assembly must be able to be removed from the optical beam completely

without causing any vignetting. This imposes an additional requirement that the x-translation range be

capable of up to 100 mm of translation.

5.3.4 60-Arcsecond Objective Lens Analysis

The 60-Arcsecond Objective lens is similar to the 30-Arcsecond Objective lens, but it is slightly thicker

and heavier, however the optic is located in the cell with the same custom designed flexure. The analysis

requirements for the 60-Arcsecond Objective Lens flexure still look at the same material and design

constraints. Optical wavefront errors are identical which results in slightly lower axial gapping loads for

the same preload. Lateral stability is still achieved in the form of two annealed brass pins at +/-50

degrees from nadir.

The 60-Arcsecond Objective Lens flexure is designed to accommodate a minimum loading of 0.65G

without axially gapping the optic/cell interface versus 0.7G with the 30-Arcsecond Objective Lens. Both

are optimized to meet optical wavefront errors of 24.8nm RMS maximum. The 60-Arcsecond flexure has

the same allowable axial deflection of 0.490 – 1.225mm which corresponds to the following specific

design constraints: 1) minimum deflection of 0.490mm at a preload of 8N restrains the optic axially a

minimum of 0.65G while 2) maximum deflection of 1.225mm at a preload of 20N is well below the

acceptable stress limits of the glass and just below acceptable optical wavefront errors using a safety

factor of 2. Shims at various thicknesses are used to improve the position of the flexure as needed to

optimize the preload.

The minimum and maximum preloads corresponding to minimum and maximum requirements are

highlighted in Table 10 below. These preloads correspond to known displacements which will be verified

during assembly and test.

MIN Preload Requirement (No Axial Gapping @ .65G) = 8N

MAX Preload Requirement = 20N

CV CDD


Table 10: 60” Objective Lens Preliminary Preload Estimates

FEA ANSYS results shown in Figure 21 below verify flexure stresses and deformations to be at

acceptable levels at the MAX preload listed above. Margin of safety calculated below.

CV CDD


Figure 21: FEA results for the 60” Objective Lens mount flexure

Calculate the MOS (Margin of Safety) of the stress in the flexure based on material properties and safety

factors listed below as well as the design parameters and loads/deflections of the ANSYS analysis output

listed above:

Flexure Material: Phosphor Bronze C51000 H08 Spring Temper, Flexure Thickness = 2.03mm

Material Strength: Yield = 551 MPa, Tensile = 690 MPa

Safety Factors: 1.5 Ultimate (Tensile Strength), 1.25 Yield

Predicted Stress @ Design Load of 20N = 171 MPa

MOS = (551 MPa / (171 MPa * 1.25)) - 1 = 1.6 (MOS ≥0 is acceptable)

Calculate the MOS (Margin of Safety) of the optical wavefront errors based on maximum allowable

errors as determined by the system engineering optical tolerance analysis and actual wavefront errors as

documented in Dan Hofstadter’s analysis report and scaled to this particular optic (size class 1 as shown

in the table below with the column titled “Surf nm/N”):

MAX Allowable Surface Error, Focus Removed = 24.8 nm RMS

Safety Factor = 2.0

Predicted Surface Error @ MAX Flexure Preload, Focus Removed = 12nm RMS

MOS = (24.8nm RMS / (12nm RMS * 2.0)) - 1 = .03 (MOS ≥0 is acceptable)

Axial gapping of the 60-Arcsecond Objective Lens optic is analyzed the same as the 30-Arcsecond

Objective Lens to determine if the impact load at 2G is within acceptable limits. The linear line loading is

slightly greater for the 60-Arcsecond Lens due to its greater mass. See 5.3.2 for a description of the

analysis. It is shown in Table 11 below that loads on this optic are less than half the maximum allowable

linear line loading guideline of 4.4kN/m, therefore impact loads due to axial gapping is deemed

acceptable.

CV CDD


Table 11: 60” Objective Lens axial gapping analysis

CV CDD


5.3.5 CV Filter Assembly

Figure 22: CV filter assembly

The filter holder assembly and camera stage assembly are mounted on a common Newport dovetail rail

and riser block. See Figure 24. The dovetail rail allows manual positioning of the filter holder assembly

along the z-axis. The filter holder is a standard Newport FH-2R filter holder mounted to a stand, which is

in turn mounted to a Newport dovetail carrier, as shown in Figure 22. The filter can easily be placed into

or out of the beam using the dovetail carrier clamp.

Table 12: Filter assembly requirements & actual performance specs

Requirement Actual

Resolution: x-axis 1 mm Located by CMM arm as required

Lockable: x-axis Clamped to optical bench

Resolution: y-axis 1 mm Shim as required

Lockable: y-axis Bolted to dovetail carrier

Resolution: z-axis 1 mm Located by CMM arm as required

Lockable: z-axis

Table 13: Filter assy COTS datasheets

COTS Datasheets for Filter Assy

Newport dovetail rail components 34004-Newport-Dovetail Rail Components.pdf

CV CDD


Newport filter holders 34005-Newport-Filter Holders.pdf

The CV is required to have a central wavelength of 530 nm with a bandpass of 10 nm. This will be

accomplished by inserting a bandpass filter into the beam after the objective lens. The filter will be in a

converging beam and its surface quality must be /2 P-V total surface irregularity and /4 P-V surface

irregularity with focus removed.

A COTS solution for the CV filter has been found, the Chroma ZET532/10x has a central wavelength of

532 nm and a bandwidth of 10 nm. The filter response, shown in Figure 23, does contain significant

transparency at wavelengths longer than 1000 nm. However, the camera quantum efficiency at 1000+ nm

is below 4%, as shown in Figure 25, so we do not expect a significant performance impact from the red

excess of the filter. In case the red excess does prove to be problematic, an additional filter can be added

to block the red light.

Figure 23: Chroma ZET532/10x transmission curve

CV CDD


5.3.6 CV Camera Assembly

Figure 24: CV camera and filter assembly

The camera stage assembly and filter holder assembly are mounted on a common Newport dovetail rail

and riser block. See Figure 24. The dovetail rail allows manual positioning of the camera stage assembly

along the z-axis. The camera is mounted to a series of stacked Newport M-426 crossed roller bearing

linear translation stages that give micrometer adjustment for the x-y-z translations. The micrometers are

Newport SM-50 models. The datasheets for the COTS components are found in 34007-Newport-Crossed

Roller Linear Stages.pdf, 34004-Newport-Dovetail Rail Components.pdf and 34003-Newport-SM_Series

Micrometer.pdf.

Table 14: Camera mount requirements & actual performance specs

Requirement Actual

Resolution: x-axis 7.4 µm 1 µm

Range: z-axis 10 mm ±12.5 mm

Lockable: z-axis

CV CDD


Resolution: y-axis 7.4 µm 1 µm


Lockable: z-axis



Lockable: z-axis

Resolution: β rotation 1 arcminute 1 arcsec/° adjusting screw

Range: β rotation ±5° ±6°

Lockable: β rotation

Table 15: Camera mount COTS datasheets

COTS Datasheets for Camera Mount Assy


Newport dovetail rail components 34004-Newport-Dovetail Rail Components.pdf

Newport crossed roller linear stages 34007-Newport-Crossed Roller Linear Stages.pdf

The CV camera is required to image the full 30 or 60 arcsecond image formed by the CV optical system.

In order to properly align the camera to within one pixel accuracy, the x and y micrometer adjustment

must have a minimum increment of 7.4 microns in each axis and lock into place so that it remains stable

at the desired position. The camera stage must also be adjustable in horizontal tilt (tilt about the y-axis) to

allow adjustment of the image plane tilt. The horizontal tilt manual adjustment must have a minimum

increment of 60 arcseconds and a range of at least 5 degrees. The default horizontal tilt angle is -1.30

degrees. Default tilt in the vertical direction is zero but some vertical tilt may be necessary to correct for

optical manufacturing defects, in which case shims will be used for compensation. The z-axis manual

adjustment of the camera stage must have a minimum increment of 25 microns.

A square aperture mask is located just in front of the camera and cooling enclosure. The aperture opening

measures 18.0mm on each side. It can be translated ±1mm in the x and y axes. Slight rotation about the

z-axis is accommodated by adjusting the four opposing set screws accordingly.

5.4 CV CAMERA

We have selected a COTS camera, based on the Truesense Imaging KAI-04070 CCD sensor, as the

camera for the CV. The KAI-04070 provides performance sufficient to meet or exceed all daytime and

nighttime requirements on the CV and cameras based around this sensor cost much less than other

cameras with similar performance.

A complete discussion of the trade study that selected this sensor can be found in DKIST project

document TN-0185 – AO CV Camera Study. We explored two COTS cameras based around this sensor,

the Illunis RMV-4070 and the Imperx Bobcat B2021. We procured a loaner version of the Bobcat B2021

to be tested in-house and confirmed that it meets performance and usability requirements for the WFC

CV. The full acceptance test report can be found in DKIST project document TN-0193 AOCV Camera

Test Report. Due to difficulties with procuring a test model from Illunis, the RMV-4070 was not

evaluated and the Bobcat B2021 has been chosen as the CV camera.

CV CDD


The Bobcat B2021 operates over a gigabit ethernet interface so no frame grabber is needed.

Table 16: Summary of Imperx B2021 camera test report

Test Requirement Test result Pass/Fail Comments

Frame rate

(full frame)

10 fps 12 fps Pass Camera capable of 10-12 fps full

frame over GigE interface

Gain N/A 10.65 e- per DN N/A

Read noise <30 e- rms 17 e- rms Pass

Dark current <10 e-/sec/pix 1.16 e-/sec/pix Pass

Linearity < 2.0% error 0.93% error Pass

Defective pixels 0 dead pixels

<0.1% defective

pixels

0 dead pixels,

0.026% defective

pixels

Pass defective pixels do not affect

imaging performance

Sensor well

depth

>40,000 e- 44,000 e- Pass

Figure 25: B2021 sensor quantum efficiency

CV CDD


6 THERMAL SYSTEMS

6.1 CV CAMERA THERMAL CONTROL

The CV camera, as delivered from the supplier, does not meet the SPEC-0063 requirement for surface

temperature in the coudé room. The camera itself generates approximately 5 W of heat energy while

operating, which will be vented by enclosing the camera in an airtight box and using a facility-provided

vacuum line to draw out the heated air.

This method of thermal management will also be used for the LOWFS and HOAO cameras. A full

discussion of the WFC approach to controlling camera surface temperature as well as test results

demonstrating its efficacy is presented in the HOAO CDD, SPEC-0147.

Figure 26: CV camera mount and thermal enclosure

CV CDD


Figure 27: Detail of CV camera thermal enclosure

CV CDD


7 CV CONTROL SOFTWARE DESIGN

7.1 OVERVIEW

The AO CV software consists of three basic functions: control of the AO CV camera, publishing of the

real time image data to the Bulk Data Transport (BDT) and control of the motorized stages in the CV

optics. The AO CV 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 28: AO CV System Context

The AO CV is one of the five subsystems of the Wavefront Correction Control System (WCCS), which is

illustrated above in Figure 28. A context diagram of the AO CV software is illustrated below in Figure

29.

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)

CV CDD


Figure 29: AO CV high-level control software context diagram.

The high-level control software is implemented in a hierarchical fashion with a CSF Management

Controller at the top (named after the subsystem it controls, which is common usage in CSF) and two

main branches: one for the control of the Motion Control Subsystem, which includes control of all the

motorized stages, and the other for the control of AO CV camera. The controller in the middle, the

Calibration Sequencer, is responsible for sequencing the AO CV system through its calibration routines.

A block diagram of the Motion Control Subsystem is shown below in Figure 30.

Figure 30: A context diagram for the Motion Control Subsystem of the AO CV control software.

The control of the motorized stages is accomplished using a CSF Management Controller, named the

Mechanism Controller (MC), along with CSF/Base Motion Controllers for each stage where automated

control is required. The use of the MC relieves the top-level AO CV controller from the task of managing

these devices and also allows for the encapsulation of various common mechanical configurations and

CV CDD


any particular sequencing required through a single common interface. The stages control the positioning

of the 30 arc-sec and 60 arc-sec objective lenses with in/out linear stages in x and focus adjustment linear

stages in z. The low-level motion control is implemented using a Delta Tau Power PMAC motion control

system. The CSF/Base software provides the necessary driver support and Motion Controller class to

easily integrate the above devices into the AO CV control system software. It should be noted that each

device controller outputs a status report to the CSF Event Network that is subscribed to by the MC, which

is the reason it shows an Event Network input. It was too crowded to show these event outputs in the

block diagram, so they have been left out. The MC uses these status reports to ascertain the status of each

device in the creation of its summary status event.

The camera will be controlled either using the DKIST Camera Systems Software (CSS) or custom camera

control software that leverages the software to be developed for the HOAO and LOWFS cameras. This is

discussed in more detail in the section on camera control below.

7.2 USE CASES

In describing the use cases for the CV, it is important to understand that the CV is just one component of

the larger WCCS system. It receives commands from the WCCS originated by operator action at the OCS

level or from the WCCS GUI. Technically this makes the operator the “actor” for these use cases, but it is

conceptually simpler to illustrate and discuss these use cases from the perspective that the WCCS is the

actor. During normal operation the CV responds only to commands and configurations sent by the WCCS

(for engineering purposes it can also be controlled from its engineering GUI). Its operational mode is

based on the overall WFC mode of the WCCS, as defined in SPEC-0129, WCCS Operational Concepts

Definition. . The mode is passed down to each WCCS subsystem using the attribute

atst.tcs.wccs.<subsystem>.mode, where <subsystem> represents one of the 5 WCCS subsystems shown

above in Figure 28 (in the case of the Context Viewer, this attribute is atst.tcs.wccs.cv.mode). The seven

WFC modes are: off, idle, calibrate, diffractionLimited, seeingLimitedOnDisk, seeingLimitedCoronal, and

limbTracking. How the CV behaves in these WFC modes is shown in the table below.

WFC Mode Meaning for the AO CV

off The CV subsystem is initialized but is not active.

idle The CV system is initialized and set to its default configuration. The CV

display is updated. CV images may be saved to the DHS upon command.

calibrate The CV system may perform its focus calibration and support the telescope

boresight calibration and other AO system calibrations. The CV display is

updated. CV images may be saved to the DHS upon command.

diffractionLimited The CV camera is running and the CV display is updated. CV images may be

saved to the DHS upon command.

seeingLimitedOnDisk The CV camera is running and the CV display is updated. CV images may be


seeingLimitedCoronal The CV camera is running and the CV display is updated. CV images may be


limbTracking If there is sufficient light, the CV may be used in Limb Tracking mode. As

with the other operational modes, the CV camera is running and the CV

display is updated. CV images may be saved to the DHS upon command.

Table 17: The meaning of the various WFC modes for the AO CV.

CV CDD


The main purpose of the CV is to provide a real-time image of the telescope boresight. It is used for both

visual and automated performance analysis of the AO system. The CV images are also used by the OCS

for the selection of AO Lock Points (this may be done from the WFC Engineering display as well). CV

images may be saved to the DHS on command for engineering purposes. The CV may be used for

alignment and calibration purposes as well, including the support of night time pointing map

measurements and as a pointing reference for the establishment of the heliocentric coordinate system. The

CV is running in almost all of the WFC modes and supports basic startup and shutdown activities. These

use cases are discussed in further detail in this section.

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

Figure 31: AO CV Use case diagram

CV CDD


7.2.1 Startup

The power state of the CV computer is managed through its Intelligent Platform Management Interface

(IPMI) port and sequenced from a script running on the parent WCCS system. The initial power on

command is initiated by the OCS, TCS or from the WFC Engineering GUI by remotely executing a

power sequencing script on the WCCS. The details of this power sequencing process are TBD and will be

documented in TN-0289 WFC System Power Sequencing. Upon power-up, the CV computer will

automatically boot and start any necessary system services. No CSF containers or components have been

deployed yet.

The lifecycle of the WFC system is normally managed by the TCS, but for laboratory and engineering

purposes may also be managed from the WFC Engineering GUIs. The top-level WCCS controller is

managed directly by the TCS or Engineering GUI and the WCCS in turn manages the lifecycles of its

subsystem top-level controllers.

The following basic steps are accomplished to bring up the CV system:

The CV system is powered up as described above

The TCS loads and starts all of the containers used by the WCCS and its subsystems using the

WCCS Deployed Logical Units that have been defined for this purpose. This includes the

container for the CV.

The TCS issues a lifecycle init command to the WCCS which forwards it to the CV subsystem as

well. The CV then loads its components and initializes them. At this point the CSF components

are loaded but are not yet running.

Next, the TCS issues a lifecycle startup command to the WCCS which it forwards to the CV

subsystem. The CV components and controllers execute their startup sequences and transition to

the running state. At this point the CV is running and ready to accept commands and

configurations on its public interface.

During the startup command processing the CV configures the camera to its default settings and

starts publication of image data to the BDT. This allows for image data to be viewed on the GUI

screens as the system is coming up. Note: the camera is configured to free-run and does not

require software or hardware triggers for normal operation.

Finally, the TCS sends a configuration to the WCCS commanding it to the “idle” state. The

WCCS forwards this to the CV as well. The CV commands all of its motors to go through their

indexing/homing sequences and then commands them to their default operating positions.

The CV is now operating normally.

The host computer that runs the Context Viewer 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 (the

computer specifications for the WFC System are listed in Section 4.5.5 of SPEC-0178, WFC Common

Items CDD).

7.2.2 Observing Related Modes

The CV is active for all the WFC modes associated with observing (diffraction-limited, seeing-limited on-

disk, seeing-limited coronal, and limb tracking). The WCCS instructs the CV to transition to one of these

modes by sending a CSF configuration containing the WFC mode attribute set to the desired mode. The

objective lenses are moved to their appropriate default positions for particular mode selected. In all of

these modes, the CV camera runs at the default or requested frame rate and exposure time and publishes

image data to the BDT for display at the operator’s console and/or the WFC Engineering GUI. Image data

CV CDD


may be saved to the BDT by sending the appropriate commands to the CV Camera Controller (CC).

Image data will continue to be saved indefinitely until manually stopped by the operator.

7.2.3 Calibrations

The CV supports several types of calibrations: dark, gain, focus, boresight alignment, Strehl calculation,

plate scale, non-automated alignments, night time pointing map updates, and limb finding. Overviews of

each calibration are presented in this section. Detailed discussions of some of the calibrations are

presented later in the section on Use Cases. In general, calibrations are implemented using Python scripts

executed by the Calibration Sequencer. Some calibrations (e.g., boresight) require the use of multiple

WFC subsystems and must be sequenced at the WCCS level. Moreover, some calibrations require the

PA&C to be in a particular configuration. This is accomplished by the OCS commanding the TCS to

configure the PA&C or by the OCS putting the TCS in aoCalibrate mode, which allows the WCCS to

command the PA&C directly. For the purposes of the discussions in the section it does not matter which

method is used and we simply note how the GOS must be configured and assume that it is configured

properly for the particular calibration to be executed. There is also one calibration (gain) that requires the

TCS to perform random steering of the telescope. This is initiated from the OCS. In general, to perform

calibrations the CV must be sent a configuration from the OCS/TCS or from the WCCS or CV

Engineering GUIs with the WFC mode attribute set to “calibrate”. Other parameters supporting the

particular calibration task to be accomplished are also included in the configuration. Additional details are

presented in the section on the Calibration Sequencer.

7.2.3.1 Dark Calibration

The beam must be blocked at the GOS in order to accomplish this calibration. Once the beam is blocked,

the CV performs the following steps:

Sets the CV camera parameters appropriate for recording a dark field

Sets the number of frames to be summed

Turns off dark and gain correction

Sums the raw uncorrected images.

Divides the resulting image sum by the number of frames.

Analyzes the new dark correction array to ensure it valid and has not been modified by offset

level compensation in the camera. An error is returned if the dark distribution is invalid.

Loads the new dark correction array as the current dark correction array.

Saves the new dark correction array in the calibration database.

All the steps of this procedure can be performed within the CV except for blocking the beam.

7.2.3.2 Gain Calibration

Random telescope steering is required in order to accomplish this calibration. Once the random steering is

in progress, the CV performs the following steps:

Sets the number of frames to be summed.

Turns off dark and gain correction

Computes the gain correction array as follows:

o Sums the raw uncorrected images.

o Computes an average from the sum

o Corrects it by the current dark correction array

CV CDD


o Calculates the minimum value of the corrected array to ensure there is no division by

zero. If zero pixels are present, the corrected array is set to all ones and a warning is

logged.

o Computes the reciprocal of the result

o Normalizes the result by the mean of the corrected average.

o The resulting gain distribution is analyzed to ensure there are no outliers beyond a user

defined threshold. An error is returned if the gain distribution is invalid.

Loads the new gain correction array as the current gain correction array.

Saves the new gain correction array in the calibration database.

All the steps of this procedure can be performed within the CV except for the random telescope motion.

7.2.3.3 Focus Adjustment

The focus of the CV is checked and adjusted as needed. A line target (USAF, grid, etc.) must be inserted

at the GOS in order to accomplish this calibration. The CV Focus Calibration uses an iterative search to

maximize the squared image gradient, a criteria shown to repeatably find the best focus position for a

variety of image structures. The CV performs the following steps (see Section 3.5 for more details):

The current objective lens is moved to its default z-axis position, which we call “center”

The step size is set to the default step size

The following steps are iterated:

o The objective lens is moved to position center – step size.

o A dark and gain corrected image is recorded and the squared sum of the image gradients

is computed

o The previous two steps are repeated for lens positions center, and center + step size.

A polynomial fit to the three points is performed and the z position corresponding to the

maximum squared gradient is computed.

If the position of maximum gradient is bracketed by the three points, the new position is used for

center, and step size is divided by two.

If the maximum gradient position is not bracketed, then the end point that is closest to the

computed position is chosen as the new center and the step size is unchanged.

The convergence criteria are checked along with the maximum number of iterations allowed. If

the algorithm has converged or the max iterations have been reached, then go to the next step.

Otherwise, continue iterating the steps above starting from the new position, moving there if

needed.

If the maximum iterations have been reached and the convergence criteria have not been satisfied,

then return an error and log a warning.

If the algorithm converged then set the new position as the default position for the z-axis (updates

the property database).

All the steps of this procedure can be performed within the CV except for inserting the line target at the

GOS.

7.2.3.4 Boresight Alignment

The Boresight Alignment procedure is used to align the boresight of the telescope and uses both the CV

and the pupil sensing capability of the HOAO. A point source is required at the GOS for this calibration.

CV CDD


Because the alignment requires inputs from multiple AO subsystems, the procedure is scripted from the

WCCS level. As part of the procedure, the WCCS requests a centroid measurement from the CV. At the

CV level, the following steps are accomplished:

An average CV image is calculated.

The centroid of the spot is computed using the match filter algorithm described in Section 3.1.

The offset error in arc-sec from the boresight (center of the CV detector) is published in a CSF

event.

The aO Engine subscribes to the event, receives the result, and computes how to adjust M3 and M6 to

center the spot on the CV and the center the pupil in the HOAO (this requires input from the HOAO as

well). The process is repeated until both the spot and the pupil are centered to an acceptable level. These

steps require coordination with other AO subsystems and the TCS subsystems and must be scripted from

the WCCS.

7.2.3.5 Strehl Calculation

The Strehl calculation will be used in the laboratory to verify the proper alignment of the optics and to

compare to the Strehl estimates based on telemetry data from the HOAO. There are no point sources that

are small enough spatially to perform this calculation at the summit, so it is used only in the laboratory.

The following steps are taken:

A point source of sufficient brightness is placed in the beam and the CV camera parameters are

adjusted until the desired spot intensity is achieved.

CV images are recorded and the calculation is performed as described in Section 3.3.

A matplotlib plot showing the results will be generated and saved, as well as the results of the

calculation will be written to the log database.

Once the source has been set up, the remainder of the procedure can be scripted form the CV.

7.2.3.6 Plate Scale Calibration

The plate scale calibration will be run as part of the routine calibration set. A line grid target must be

placed in the beam at the GOS for this calibration. The procedure outlined in Section 3.3 is executed in a

Python script. The procedure is quite complicated, so the steps are not listed here. With the exception of

placing the line grid target into the beam, the entire procedure can be scripted within the CV.

7.2.3.7 Non-Automated Calibrations

A number of the alignments for the AO system may not easily be automated, or may be performed so

infrequently that it is not worth automating them. These are most likely adjustments initiated by an

operator at the WCCS or CV Engineering GUIs, although they may require configuration of the PA&C as

well. The CV will likely be used to support these calibrations. The following steps are typically

performed:

The PA&C is configured for the calibration source or target as required.

The AO system is placed in calibrate mode.

The various AO optical devices are configured as desired for the calibration to be performed.

These actions are performed from the WCCS Engineering GUI.

Various measurements are performed and data are taken and analyzed (including CV images).

CV CDD


The appropriate optical devices are adjusted as required. These actions are performed from the

WCCS Engineering GUI.

These steps are repeated until the desired level of alignment is achieved.

At operator request, the new positions of the affected devices are saved as new default or named

positions.

The new positions of the affected devices are saved as the new default and/or named position values for

each device.

7.2.3.8 Night Time Pointing Map Updates

The CV will be used to assist in the computation of night time 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

centroid capability used in the boresight calibration will be reused to support this feature. The steps to be

taken are expected to be something like this, sequenced from the TCS:

The TCS configures the WCCS to be in idle mode

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

M2, M3 and M6

The TCS instructs the CV to configure the camera for night time operation

The TCS moves the telescope to a bright star

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

image frames

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

event

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 CV level, the following steps are taken:

The camera is configured for night time operation (this is only done once)

An average CV image is calculated using the requested number of frames

The centroid of the spot is computed and the offset error in arc-sec from the boresight is

published in a CSF event

7.2.3.9 Limb Finding

The CV will be used to support updates to the TCS pointing when bringing the telescope up each

morning. This involves moving the telescope to several different limb positions around the sun (e.g., N, S,

E, W) and calculating the position of the limb in a CV image for each case. The position of the limb is

calculated by performing a Canny edge detection followed by a Hough line transform to obtain a

parametric description of the line representing the edge of the limb relative to the boresight. The x and y

position of the orthogonal vector from the boresight to the line is returned to the TCS in a CSF event. The

procedure is described in detail in Section 3.2. The steps to be taken are expected to be something like

this, sequenced from the TCS:

The TCS configures the WCCS to be in idle mode

CV CDD


The TCS instructs 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 position

The TCS requests the CV to perform limb finding on a CV image

The CV performs the limb finding algorithm and publishes the result in a CSF event

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

7.2.4 Shutdown

The shutdown of the CV is accomplished using the following steps:

A configuration with WFC mode attribute set to “off” is sent from the OCS, TCS or WCCS

Engineering GUI. As part of the transition to off the CV motors are all moved to their “stow”

positions

The TCS sends the lifecycle commands shutdown, uninit, and unload to the WCCS, which

forwards them to the CV (this may also be initiated from the WCCS engineering GUIs). During

these lifecycle transitions the following steps are taken:

o The image acquisition from the CV camera and all publications to the BDT are halted

o All events published by the CV are halted.

o All CV event subscriptions are cancelled

o All software resources in use are freed

The TCS executes the remote power shutdown script on the WCCS, which in response executes

the appropriate power shutdown sequence for the CV.

At this point the CV is powered down and inoperative.

7.3 DETAILED DESIGN

7.3.1 CV Controller

The CV Controller is the top-level controller for the CV sub-system and is responsible for managing the

overall operation of the CV subsystem. It is an extension of the CSF/Base Java Management Controller

class. The CSF device name for the CV controller is atst.tcs.wccs.cv and the controller itself is referred to

as the CV Manager Controller.

The typical use case for the CV is any of the normal observing modes, with the possible exception of limb

tracking, where its use is dependent on how much light is available. In these modes the CV is designed to

be used with a minimum of operator interaction. The operator typically specifies only the WFC mode and

any particular calibrations to be performed. The remainder of the parameters required to operate the CV

are downloaded from the CSF Property Database during startup. However, all parameters required to

operate the CV are accessible through its public interface via the CV Engineering GUI.

7.3.1.1 Attributes

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

CV CDD


Name Type Comment

atst.tcs.wccs.cv

.mode String The current WFC mode

.calibrate String The specific calibration task to be performed

.calibCtrl.<attribute name> Varies Attributes for the Calibration Sequencer

.mc.<attribute name> Varies Attributes for the Mechanism Controller subsystem of the

CV

.cc.<attribute name> Varies Attributes for CV Camera Controller

7.3.1.1.1 .mode

Data Type: String

Units: N/A

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

| limbTracking

Default Value: None

The .mode attribute represents the current operational mode of the WCCS and is used to control the

behavior of the CV.

7.3.1.1.2 .calibrate

Data Type: String

Units: N/A

Valid Values: dark | gain | boresight | focus | manual | nightTime | limbFinding | none

Default Value: None

The .calibrate attribute is used to indicate what particular type of calibration is to be performed. If this

attribute is present, the entire configuration is submitted to the Calibration Sequencer for processing if a)

the WFC mode is set to calibrate (normal WFC calibrations) or b) the WFC mode is set to idle and the

.calibrate attribute is set to “nightTime” or “limbFinding” (for TCS applications).

7.3.1.1.3 .calibCtrl.<attribute name>

These are attributes for the Calibration Sequencer for the CV system. These attributes are forwarded by

the CV controller directly to the Calibration Sequencer.

7.3.1.1.4 .mc.<attribute name>

These are attributes for the Mechanism Controller subsystem of the CV and are intended for the MC itself

or for one of the devices managed by the MC. These attributes are forwarded by the CV controller

directly to the MC.

CV CDD


7.3.1.1.5 .cc.<attribute name>

These are attributes are for the CV Camera Controller and are used to configure the CV camera. These

attributes are forwarded by the CV controller directly to the CC.

7.3.1.2 Properties

All of the attributes used in the public interface for the CV will be backed by properties in the property

database. In addition there are many other properties that are not public that are used by the system. All of

the properties will be documented as part of the final user documentation for the system.

7.3.1.3 Sequencing

In general, all the run-time specific parameters for the CV will be sent from the Observatory Control

System (OCS) to the Telescope Control System (TCS) and then on to the WCCS and CV. Moreover,

these parameters are all sent at once in a single CSF configuration. Because of this, the CV must know

how to properly sequence these parameters to its components. In general, the following rules will apply:

If the WCCS .mode attribute is set to calibrate and the CV .calibrate attribute is present, the

entire configuration is sent to the Calibration Sequencer for processing. The particular calibration

script to be executed is responsible for sequencing the various actions in the proper order.

In addition, to support night time pointing map calibrations and daytime limb finding for

coordinate system initialization, the entire configuration is sent to the Calibration Sequencer for

processing if the WCCS .mode attribute is set to idle and the CV .calibrate attribute is present

and set to nightTime or limbFinding.

If no specific calibration is to be processed, parameters for configuring the motorized stages and

the CV camera are sent to the MC and the camera controller, respectively.

7.3.2 Camera Controller

The Camera Controller (CC) implements the functionality required to configure the CV camera, retrieve

dark and gain images from the Bulk Data Store (BDS), perform dark and gain corrections on the real-time

image stream from the camera and publish image data to the BDT. The control of the camera is

implemented using a low level C++ interface and the Pleora camera driver supplied by the manufacturer.

The low level interface is wrapped with JNI and exposes a Java interface that is used by the CC. The CC

implements a separate thread that performs the dark and gain corrections. Because the correction thread is

part of the Camera Controller, it receives the camera images directly from camera interface. After

performing the dark and gain corrections it passes the resulting images on to both the Calibration

Sequencer and the BDT network. The correction thread is also responsible for turning on/off the flag

indicating that the data should be saved to the BDT. Moreover, the CC implements a dedicated thread to

perform automatic exposure time adjustment to ensure we are using an appropriate percentage of the

CCD well depth. The auto exposure control is user selectable and has several parameters to control its

operation (see SPEC-0179, Section 5.8 for details on the algorithm used). The passing of image data to

the calibration sequencer is done using a pass box, which is a synchronized queue of size one whose

contents may be overwritten by the source if the subscriber has not yet used the data. The BDS interface

to the CC is used for the downloading of dark and gain images. The CC is implemented using an

extension of the CSF/Base Java Hardware Controller class.

CV CDD


Figure 32: A block diagram illustrating the CV Camera Controller design. The box with the dashed outline indicates that

the dark and gain corrections thread and the auto exposure adjustment thread are part of the Camera Controller.

7.3.2.1.1 Attributes

The following attributes are received and acted upon by the CC controller for the design based on a

custom CSF controller.

Name Type Comment

atst.tcs.wccs.cv.cc

.ldDarkName String The name of the dark image to be used

.ldDarkVersion String The version ID of the dark image to be used

.ldGainName String The name of the gain image to be used

.ldGainVersion String The version ID of the gain image to be used

CV CDD


.darkCorrect Boolean Turns dark correction on/off

.gainCorrect Boolean Turns gain correction on/off

.publishData Boolean Turns the publishing of data to the BDT on/off

.saveData Boolean Turns the saving of data to the BDT on/off

.configSetup String Instructs the CC to setup the camera with its default

parameters for either daytime or night time use

.frameRate Float Sets the frame rate in Hz

.expTime Int Sets the exposure time in µsec

.expControl String The camera exposure control method

.expUpdate Real The time between exposure updates

.expMin Int The minimum count threshold

.expMax Int The maximum count threshold

7.3.2.1.1.1 .ldDarkName

Data Type: String

Units: N/A

Valid Values: N/A

Default Value: N/A

The .ldDarkName attribute is used to specify the name of the existing dark image to be downloaded from

the calibration store for use in the dark correction.

7.3.2.1.1.2 .ldDarkVersion

Data Type: String

Units: N/A

Valid Values: N/A

Default Value: N/A

The .ldDarkVersion attribute is used to specify the unique version ID of the existing dark image to be

downloaded from the calibration store for use in the dark correction.

7.3.2.1.1.3 .ldGainName

Data Type: String

Units: N/A

Valid Values: N/A

Default Value: N/A

CV CDD


The .ldGainName attribute is used to specify the name of the existing gain image to be downloaded from

the calibration store for use in the gain correction.

7.3.2.1.1.4 .ldGainVersion

Data Type: String

Units: N/A

Valid Values: N/A

Default Value: N/A

The .ldGainVersion attribute is used to specify the unique version ID of the existing gain image to be

downloaded from the calibration store for use in the gain correction.

7.3.2.1.1.5 .darkCorrect

Data Type: Boolean

Units: N/A

Valid Values: True | False

Default Value: True

The .darkCorrect attribute is used to indicate whether dark corrections are to be performed or not.

7.3.2.1.1.6 .gainCorrect

Data Type: Boolean

Units: N/A


Default Value: True

The .gainCorrect attribute is used to indicate whether gain corrections are to be performed or not.

7.3.2.1.1.7 .publishData

Data Type: Boolean

Units: N/A


Default Value: False

The .publishData attribute is used to indicate whether image data should be published to the BDT or not.

The WFC system shares a camera line with the CryoNIRSP instrument (which also blocks the light beam

to the WFC) and should not publish to the BDT when the CryoNIRSP is in use. This attribute takes

CV CDD


precedent over the .saveData attribute. Even if the saving of data is turned on, if this attribute is set to

false, no data will be published, and therefore, no data will be saved.

7.3.2.1.1.8 .saveData

Data Type: Boolean

Units: N/A



The .saveData attribute is used to indicate whether image data published to the BDT should be saved or

not. The saving of data occurs in the correction thread. Once the saving of data has been started it will

continue until a configuration is received by the CC containing the .saveData attribute set to false.

7.3.2.1.1.9 .configSetup

Data Type: String

Units: N/A

Valid Values: day | night

Default Value: false

The .configSetup attribute is used to indicate that the CC should load the default camera parameters

required for day or night time operation, as specified by the value of the attribute, from the property

database and use them to configure the camera.

7.3.2.1.1.10 .frameRate

Data Type: Real

Units: Frames/sec

Valid Values: 1 – 16.65

Default Value: 10

The .frameRate attribute is used to get or set the frame rate of the CV camera. Note that the frame rate

and exposure time are inter-dependent and must be set to mutually compatible settings. When a frame rate

change is requested, the Camera Controller checks to see if the new frame rate is compatible with the

current exposure time. If necessary, the exposure time will be truncated to the maximum allowed for the

new frame rate.

7.3.2.1.1.11 .expTime

Data Type: Int

Units: µsec

Valid Values: 1 – 1.6e7 µsec

CV CDD


Default Value: TBD

The .expTime attribute is used to set the exposure time of the camera. Note that the frame rate and

exposure time are inter-dependent and must be set to mutually compatible settings. This attribute will be

checked to ensure it does not exceed the maximum allowable exposure time for the current frame rate and

will be clipped to the maximum value if necessary.

7.3.2.1.1.12 .expControl

Data Type: String

Units: Choice

Valid Values: auto | manual

Default Value: manual

The .expControl attribute is used to turn the automatic exposure control on and off.

7.3.2.1.1.13 .expUpdate

Data Type: Real

Units: Seconds

Valid Values: 1 - 300

Default Value: TBD

The .expUpdate attribute determines the time in seconds between exposure updates.

7.3.2.1.1.14 .expMin

Data Type: Int

Units: DN

Valid Values: 0 – 4094, expMin < expMax

Default Value: 800 (~20% of well depth)

The .expMin attribute is the lower bound on the acceptable level of maximum average intensity in the

reference subaperture. When the maximum average intensity drops below this level, the exposure time

will be increased.

7.3.2.1.1.15 .expMax

Data Type: Int

Units: DN

Valid Values: 1 – 4095, expMax > expMin

Default Value: 3300 (~80% of well depth)

CV CDD


The .expMax attribute is the upper bound on the acceptable level of maximum average intensity in the

reference subaperture. When the maximum average intensity rises above this level, the exposure time will

be decreased.

7.3.2.2 Properties

All of the attributes used in the public interface for the Camera Controller will be backed by properties in

the property database. In addition there are many other properties that are not public that are used by the

system. All of the properties will be documented as part of the final user documentation for the system.

The CC will be implemented with a maximum of at least two CSF action threads to allow ample

resources for both configuring camera parameters and loading or saving files to the calibration store. Note

that these CSF threads are in addition to the special thread used to perform the dark and gain corrections

(which is not a CSF thread).

7.3.3 Mechanism Controller

The Mechanism Controller (MC) is responsible for managing all the motion control devices in the CV. It

relieves the burden of the top-level CV controller of managing these resources. The Mechanism

Controller is implemented as an extension of the CSF/Base Java ManagementController class, which is

designed to automatically manage the control functions and lifecycles of a number of subordinate

controllers. It also allows for the implementation of custom motion sequencing or encapsulation of

custom configurations managed through a single interface. For example, by commanding the MC to go to

a hypothetical configuration called “Configuration_A”, only a single CSF attribute need be sent to the

MC. The MC then translates the name “Configuration_A” into the appropriate set of commands to its

subordinate motion controllers to move them to the desired positions, allowing a single attribute to be

used to indicate the desired configuration of all the motorized stages.

All values used to communicate with the MC are maintained in the same data format as those used in the

motors so that type conversion errors do not reduce the native accuracy of the motors.

As of this writing, there are two special functions that have been identified: automatically moving the

objective lenses in response to the selection of a desired field of view, and the ability to save the current

position of a device as either the default position or as a named position. Custom methods will be added

to the MC to implement these capabilities. These functions are described in further detail below.

The CSF device name for the MC is atst.tcs.wccs.cv.mc. The table below describes the naming scheme

for the MC and its subordinate controllers. Each subordinate controller is discussed in detail below.

Name Description

atst.tcs.wccs.cv.mc

.fov The field of view selection

.savePosition Update the Property DB using the current position of a

device

.objLens30X 30” Objective lens horizontal position

.objLens30Z 30” Objective lens axial (focus) position

.objLens60X 60” Objective lens horizontal position

.objLens60Z 60” Objective lens axial (focus) position

CV CDD


7.3.3.1 Objective lens positioning based on FOV selection

While the ability to command each objective lens separately is needed as a lower level control capability,

during operations only one lens is used at a time while the other lens is out of the beam. This is how the

two separate FOVs are achieved. When the 30” FOV is selected, the 30” objective lens is positioned in

the beam and the 60” objective lens is moved out of the beam. When the 60” FOV is selected, the

opposite takes place. We automate this functionality using an MC attribute for the FOV. When the MC

receives this attribute it knows to move each of the objective lenses to its proper position based on the

particular FOV selected. The attribute for this functionality is atst.tcs.wccs.cv.mc.fov.

7.3.3.1.1 .fov

Data Type: Int

Units: Size of the FOV in arc-sec

Valid Values: 30 | 60

Default Value: 30

7.3.3.2 Saving the current position of a device

The MC implements the capability to update the Property DB information for a selected device and

named position. This functionality will be used during alignments and calibrations to update the defined

positions as needed. The functionality is invoked using the .savePosition attribute, which is a unique

string indicating the device name and the particular named position to be updated (“default” is a named

position) . A special method will be added to the MC to implement this capability.

7.3.3.2.1 .savePosition

Data Type: String[]

Units: N/A

Valid Values: objLens30XIn | objLens30XOut | objLens30ZDefault | objLens60XIn objLens60XOut

| objLens60ZDefault

Default Value: None

7.3.3.3 Properties

All of the attributes used in the public interface for the Mechanism Controller will be backed by

properties in the property database. In addition there are many other properties that are not public that are

used by the system. All of the properties will be documented as part of the final user documentation for

the system.

Two of the attributes used in the mechanism controller are .objLens30PlateScale and

.objLens60PlateScale. These attributes are used to store the values of the 30-arcsecond plate scale and the

60-arcsecond plate scale. They can be modified manually through the CV Property Editor or by a Python

script, such as the plate scale calibration script.

The MC will be implemented using at least 2 CSF action threads so that each motor may be commanded

independently.

CV CDD


7.3.4 Motion Controllers

All motion controllers will be implemented using the Java MotionController class provided by the

CSF/Base software. The MotionController class provides a standard interface for motion control and has

driver support for the Delta Tau PPMAC system. It provides support for absolute moves, relative moves,

named positions, and automatic conversion between user units and the underlying raw units of each stage.

At the time of this writing, the raw units have not been defined for these stages; they will be determined

during the implementation of the motion control system. The descriptions below discuss the absolute

position and named position attribute details for each device. The absolute position attribute allows for

positioning of the device anywhere in its range, while the named position attribute allows for positioning

the device to one or more pre-defined positions with a user-assigned name. The named positions represent

the default or typical calibrated user positions for these devices.

The DeltaTau support uses the DeltaTauConnection and DeltaTauChannel classes in CSF/Base to connect

to the underlying PPMAC hardware and control the various motorized stages. If special indexing is

required for any of the stages, the DeltaTauConnection class will be extended to override the index()

method as needed. Moreover, special PPMAC motion programs may be required to implement custom

sequencing to implement the indexing. The need for this will be determined on a case by case basis as we

integrate the motion control system for the CV.

WFC motion control design is detailed in the WFC Common Items CDD, SPEC-0178. As discussed in

the Common Items CDD, the CV will share the use of a single Delta Tau PPMAC chassis with the other

WCCS subsystems. A single CPU will be used to support the motion control software for all the movable

devices in the entire AO system. Standard CSF/Base Motion Controllers are used to support each device.

The remainder of this section describes the devices controlled by the MC. The full attribute names for

these devices are found by combining the fully qualified device name as given in the paragraph with

either a .pos or .namedPos suffix. For example, to set the absolute position of the 30” objective lens

along the x axis, the full attribute name is: atst.tcs.wccs.cv.mc.objLens30X.pos.

7.3.4.1 30” Objective Lens

Each objective lens has two separate axes of motion combined on a single mount. The x motor axis

represents the lateral position of the lens with respect to the beam path, while the z axis represents the

position of the lens along the beam path. The CSF device names for these stages for the 30” objective lens

are atst.tcs.wccs.cv.mc.objLens30X and atst.tcs.wccs.cv.mc.objLens30Z, respectively. The attributes

defined for these stages are shown below.

7.3.4.1.1 objLens30X.pos

Data Type: Real

Units: mm

Valid Values: 0 – TBD

Default Value: None

7.3.4.1.2 objLens30X.namedPos

Data Type: String

Units: N/A

Valid Values: Default | In | Out

CV CDD


Default Value: Default

7.3.4.1.3 objLens30Z.pos

Data Type: Real

Units: mm


Default Value: None

7.3.4.1.4 objLens30Z.namedPos

Data Type: String

Units: N/A

Valid Values: Default


7.3.4.2 60” Objective Lens

The 60” objective lens has attribute definitions that are identical to the attributes used for the 30”

objective lens. The CSF device names for these stages for the 60” objective lens are

atst.tcs.wccs.cv.mc.objLens60.x and atst.tcs.wccs.cv.mc.objLens60.z, respectively. The attributes

defined for these stages are shown below.

7.3.4.2.1 objLens60X.pos

Data Type: Real

Units: mm


Default Value: None

7.3.4.2.2 objLens60X.namedPos

Data Type: String

Units: N/A

Valid Values: Default | In | Out


7.3.4.2.3 objLens60Z.pos

Data Type: Real

Units: mm

CV CDD



Default Value: None

7.3.4.2.4 objLens60Z.namedPos

Data Type: String

Units: N/A

Valid Values: Default


7.3.4.3 Motion Controller Properties

The CSF properties associated with the CV Motion Controllers will be identified and documented during

implementation. They will include the following:

Default and named position properties for each stage.

Any properties required to configure the motion controller for normal operation: units, range,

limits, etc.

7.3.5 Calibration Sequencer

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

perform calibrations. Calibrations are performed when the top-level CV controller receives a CSF

configuration containing both the atst.tcs.wccs.cv.mode attribute set to “calibrate” and the

atst.tcs.wccs.cv.calibrate attribute indicating the particular calibration to be performed. The CV

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 may submit various commands through CSF

configurations to the MC and the CC to cause them to achieve a desired state at any point in the

procedure. The Calibration Sequencer also uses the Image Pass Box described earlier to receive dark and

gain corrected images for any processing required by a particular calibration.

The Calibration Sequencer must also support the specialized TCS applications for night time pointing

map calibrations and daytime coordinate system initialization. However, the WCCS and all its subsystems

will be in idle mode for these applications. In order to send configurations for these two applications

directly to the Calibration Sequencer, the following rule is observed: when the incoming configuration

contains the atst.tcs.wccs.cv.mode attribute set to “idle” and the atst.tcs.wccs.cv.calibrate attribute set to

either “nightTime” or “limbFinding”, the CV Controller will send the configuration directly to the

Calibration Sequencer for processing.

The Calibration Sequencer will be implemented using an extension of the CSF Java

ScriptInterpretingController which will automatically download Python scripts from the script database to

sequence the calibrations.

7.3.5.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.

CV CDD


Name Type Comment

atst.tcs.wccs.cv

.calibrate String The name of the particular calibration task to be

accomplished

atst.tcs.wccs.cv.calibCtrl

.mode String The current WFC mode

.scriptName String The name of the script to be downloaded from the script

database

.scriptId String The id of the script to be downloaded from the script

database

.refPsfId String The ID of the reference image to download from the

Bulk Data Store

.centroidNumImages Int The number of CV images to accumulate when

computing the centroid.

.numImages Int The number of CV images to accumulate when

computing dark and gain calibration images

.focusNumSteps Int The maximum number of steps to be used in the focus

calibration

.focusStepSize Float The size of the focus change used in the focus calibration

.logEvents Boolean Used to indicate whether the .centroid and .limbPosn

events are to be logged

.saveDark Boolean Triggers saving the new dark as the default dark.

.saveGain Boolean Triggers saving the new gain as the default gain.

7.3.5.1.1 .calibrate

Data Type: String

Units: N/A

Valid Values: dark | gain | boresight | focus | manual | nightTime | limbFinding

Default Value: None

The .calibrate attribute is used to indicate the particular type of calibration is to be performed. The value

of the attribute may also be used to load the default script to be run for the specified calibration task if the

.scriptName and .scriptVersion attributes are not specified.

7.3.5.1.2 .mode

Data Type: String

Units: N/A

CV CDD


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

| limbTracking

Default Value: None

The .mode attribute represents the current operational mode of the WCCS and is used to control the

behavior of the CV.

7.3.5.1.3 .scriptName

Data Type: String

Units: N/A

Valid Values:

Default Value: None

The .scriptName attribute contains the name of the Python script to be downloaded from the script

database and run to execute the desired calibration procedure. A combination of the script category (the

controller name), script name and script ID form a primary key that is used to identify and download the

script from the script database for execution.

7.3.5.1.4 .scriptVersion

Data Type: String

Units: N/A

Valid Values:

Default Value: None

The .scriptVersion attribute contains the unique ID of the Python script to be downloaded from the script

database and run to execute the desired calibration procedure. A combination of the script category (the

controller name), script name and script ID form a primary key that is used to identify and download the

script from the script database for execution.

7.3.5.1.5 .refPsfId

Data Type: String

Units: N/A

Valid Values: seeLimit | diffLimit | seeLimit | pinhole | invPinhole | pinhole

Default Value: None

The .refPsfId attribute contains the ID of the reference PSF to be downloaded from the Bulk Data Store

for use in the centroid calculations performed by the calibration scripts.

7.3.5.1.6 .centroidNumImages

Data Type: Integer

CV CDD


Units: N/A

Valid Values: 1-1000

Default Value: 1

The .centroidNumImages attribute specifies the number of raw images to be accumulated when

computing the centroid.

7.3.5.1.7 .numImages

Data Type: Integer

Units: N/A

Valid Values: 1-1000

Default Value: 100

The .numImages attribute specifies the number of raw images to be accumulated when computing dark

or gain calibration images.

7.3.5.1.8 .focusNumSteps

Data Type: Integer

Units: N/A

Valid Values: 1-10

Default Value: 5

The .focusNumSteps attribute specifies the maximum number of steps to be taken in the automated focus

calibration algorithm.

7.3.5.1.9 .focusStepSize

Data Type: Float

Units: mm

Valid Values: TBD

Default Value: TBD

The .focusStepSize attribute specifies the size in mm of an adjustment step in focus (z) to be used in the

automated focus calibration algorithm.

7.3.5.1.10 .saveDark

Data Type: Boolean

Units: N/A


CV CDD



The .saveDark attribute triggers the Calibration Sequencer to save the newest captured dark image as the

default dark image. The default dark image will be used for dark corrections.

7.3.5.1.11 .saveGain

Data Type: Boolean

Units: N/A



The .saveGain attribute triggers the Calibration Sequencer to save the newest captured gain image as the

default gain image. The default gain image will be used for gain corrections.

7.3.5.1.12 .logEvents

Data Type: Boolean

Units: N/A



The .logEvents attribute is used to indicate whether the atst.tcs.wccs.cv.centroid and

atst.tcs.wccs.cv.limbPosn are to be logged. CSF does not provide automatic logging of events, so the

logging is accomplished by the Calibration Sequencer by using the CSF Archive Service to record the

attributes posted to an event. The archive service is called immediately after the posting of an event.

7.3.5.2 Properties

All of the attributes used in the public interface for the Calibration Sequencer will be backed by properties

in the property database. In addition there are many other properties that are not public that are used by

the system. All of the properties will be documented as part of the final user documentation for the

system.

7.3.6 Events Published by the CV and its components

7.3.6.1 CV Controller Events

The top-level CV controller will publish the following general status event.

Name Rate Comment

atst.tcs.wccs.cv

.cStatus 1 Hz A general CV status event

CV CDD


7.3.6.1.1 .cStatus

This event reports the general status of the Context Viewer. The attributes are listed in the table below.

Attribute Name Type Units Range Comment

cMode String N/A

off | idle | calibrate |

diffractionLimited |

seeingLimitedOnDisk |

seeingLimitedCoronal |

limbTracking

The current mode of the CV

Status String N/A The CV camera status

Inpos Boolean N/A True | False The CV in-position status

framerate Int Hz 1-17 The camera frame rate

expTime Int µsec 2 – 106 The camera exposure time

avgCounts Float DN The average count value

darkCorrect Boolean N/A True | False Whether dark correction is enabled or

not

gainCorrect Boolean N/A True | False Whether gain correction is enabled or

not

saveData Boolean N/A True | False Whether data is being saved to the

BDT or not

publishData Boolean N/A True | False Whether data is being published to

the BDT or not

configSetup String N/A Day | Night What basic configuration the system

is using, day or night

7.3.6.2 Camera Controller Events

The following events and data are sent from the CV CC.

Name Rate( Hz) Comment

atst.tcs.wccs.cv.cc

.cStatus 1.0 The general status of the CV camara in a single status event

7.3.6.2.1 .cStatus


cMode String N/A






CV CDD


limbTracking

Status String N/A The camera status

Inpos Boolean N/A True | False The camera in-position status

framerate Int Hz 1-17 The camera frame rate

expTime Int µsec 2 – 106 The camera exposure time

currentTemperature Float ºC The internal camera temperature

avgCounts Float DN The average count value

darkCorrect Boolean N/A True | False Whether dark correction is enabled

or not

gainCorrect Boolean N/A True | False Whether gain correction is enabled

or not

saveData Boolean N/A True | False Whether data is being saved to the

BDT or not

publishData Boolean N/A True | False Whether data is being published to

the BDT or not

configSetup String N/A Day | Night What basic configuration the

system is using, day or night

7.3.6.3 Mechanism Controller Events

The following events and data are sent from the CV MC.

Name Rate( Hz) Comment

atst.tcs.wccs.cv.mc

.cStatus 1.0 The general status of the CV mechanisms in a single status

event

7.3.6.3.1 .cStatus


cMode String N/A





limbTracking


inpos Boolean N/A True | False The camera in-position status

fov Int arcsec 30 | 60 The current field of view

objLens30Pos Float[] mm TBD The absolute position of the 30

arcsec objective lens in X, Z

CV CDD


objLens60Pos Float[] mm TBD The absolute position of the 60

arcsec objective lens in X, Z

plateScale Float arcsec/pixel The current CV plate scale

7.3.6.4 CV Calibration Sequencer Events

The Calibration Sequencer will publish the following events.

Name Rate Comment

atst.tcs.wccs.cv

.centroid On request The centroid position of the spot off of the boresight

.limbPosn On request The orthogonal distance to the limb from the boresight

7.3.6.4.1 atst.tcs.wccs.cv.centroid


centroid Real[2] Arc-sec N/A A 2-element vector containing the results of

a centroid computation

wci:timestamp String The timestamp for the wciWatch data

wci:tcsDmdPos Real[3] The current TCS demand position

wci:coudeDmdAngle Real Degrees The current coudé demand angle

wci:tcsInPosition Boolean The TCS in position status

wci:tcsCurPos Real[3] The TCS current position

wci:coudeCurAngle Real Degrees The coudé current position

wci:offsets Real[3] Arc-sec The current TCS offsets

This event reports the centroid position of a single spot in the CV image in arc-seconds off the telescope

boresight in x and y in the WFC coordinate system. It also includes a success Boolean and an

errorMessage string, which is only set if success is false. This event may be used to support both

boresight calibration and night time pointing. The current TCS position information from the CSF utility

WciWatch is appended to the centroid data for use in any required coordinate transformations. These

attributes are defined in TN-0088, Base Software for Control Systems.

7.3.6.4.2 atst.tcs.wccs.cv.limbPosn


limbPos Real[2] Arc-sec N/A A 2-element vector containing the results of

a limb finding computation

success Boolean Indicates if the limb finding calculation was

successful or not

CV CDD


errorMessage String An error message with details on any failure

wci:timestamp String The timestamp of the wciWatch data

wci:tcsDmdPos Real[3] The current TCS demand position

wci:coudeDmdAngle Real Degrees The current coudé demand angle

wci:tcsInPosition Boolean The TCS in position status

wci:tcsCurPos Real[3] The TCS current position

wci:coudeCurAngle Real Degrees The coudé current position

wci:offsets Real[3] Arc-sec The current TCS offsets

This event reports the orthogonal distance from the boresight to the limb in arc-sec in the WFC coordinate

system. This event is only used to support the daytime initialization of the telescope coordinate system. It

also includes a success Boolean and an errorMessage string, which is only set if success is false. The

current TCS position information from the CSF utility WciWatch is appended to the centroid data for use

in any required coordinate transformations. These attributes are defined in TN-0088, Base Software for

Control Systems.

7.3.7 Events subscribed to by the CV and its components

The CV does not subscribe to any events outside of its own sub-system. The MC will subscribe to its own

motion controllers’ status events.

7.3.8 Headers

The CV is not required to respond to any header requests.

7.3.9 Interlocks

The CV does not respond to any Global Interlock System interlock events. The main WCCS controller

will respond to GIS interlock events, if required, and direct the WCSS subsystems to respond as needed.

7.3.10 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

CV CDD


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

These debug messages are intended for diagnostic and engineering.

Logging of events is accomplished by using the CSF archive service and a .logEvents attribute to turn

logging on and off, as described earlier.

7.3.11 Health and Alarms

7.3.11.1 Health

CV components will set their health according to the guidelines outlined in SPEC-0022. Health is only

reported when a component’s health status changes state. If a component is operating normally, its health

is GOOD. All CV components will set their health to GOOD upon startup and initialization. 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.

7.3.11.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 CV, resulting in the following table of failures and

CV alarm responses. Note: the responses of the motion controllers are the default behavior of the

MotionController class and are not programmed or configured directly by the CV.

Failure Alarm Response

A motion control device

fails

An incorrectly placed optic in the CV

may cause the CV image data to be

bad. The motion controller raises an

alarm.

The CV Camera Controller

is unable to control the

camera

The CV camera may be operating at

incorrect settings, possibly leading to

bad CV image data. The CV Camera

Controller raises an alarm.

The CV Camera Controller

is unable to acquire image

data from the camera

Proper functioning of the CV image

data stream is required. The CV

Camera Controller raises an alarm.

A call to a CSF service by

a CV component fails

If the service is critical to the proper

functioning of the CV and to the

viability of the CV image data, the

component in question will raise an

alarm.

A component detects an If the resource failure can result in

CV CDD


internal SW resource

problem

bad CV image data being produced,

the component will raise an alarm.

7.3.12 GUI Screens

The CV will provide an Engineering GUI screen with multiple tabs to provide the following basic

functionality:

The current state and status of the CV

A summary of the positions of the motorized devices

A reduced size version of the current CV image

Setting any CV parameter

Moving any CV motorized device

Updating the default or named position of any CV device

Sequencing the CV through any internal calibrations

Startup/shutdown of the CV

A minimal control and status screen for the OCS Operator’s AO GUI tab

In addition, the CV will provide a separate display with a full size rendering of the current CV image

along with target and AO lock point location information.

We have mocked up some concept screens, shown in the figures below. Initial screens will be developed

based on these mock-ups during implementation and their design will be iterated and updated during lab

integration and testing. All Engineering GUI screens will be implemented using the JES tools that are part

of the CSF.

The high-resolution CV image and status display will be implemented using technologies other than JES

to provide advanced graphics capabilities such as interactive zoom, pan and contrast enhancement that are

not easily implemented in JES (Qt or PyQt are possibilities).

CV CDD


Figure 33: Screen 1 of 2 of CV Engineering GUI mock-up.

CV CDD


Figure 34: Screen 2 of 2 of CV Engineering GUI mock-up.

CV CDD


Figure 35: A mockup of the full-size CV Display.

CV CDD


7.3.12.1 Full-Size CV Display

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

x 2160 pixels. Although 4k displays are currently available, we plan to postpone the purchase of a display

for as long as possible to allow the technology to mature and the prices to drop. Currently 32” 4k

monitors are available for under $1000. We are working with the DKIST Operations Group to specify the

appropriate size monitor to be hung on a wall in the Operations Room. A mockup of the CV display using

the 4k format is shown above in Figure 35. The 2048 x 2048 image display is centered in the left 2160 x

2160 pixel portion of the screen. The remaining space on the right is used for basic CV status

information: the current time stamp, the current field of view and plate scale, and the current lock point

position as an offset from the boresight in arc-seconds in the WFC coordinate system. The boresight of

the telescope is the center of the image display. The lock point location is shown by a dashed blue reticle

(both the HOWFS and LOWFS lock points can be shown).

7.3.13 Use Case Details

In this section we present detailed discussions of the following uses cases: normal observing, dark

calibration, and boresight calibration. These use cases cover the important operational modes of the CV

and the typical interaction required between the CV controller, MC and motion controllers, and the

Camera Controller and camera. This section describes these interactions in detail. Note: the gain

calibration is nearly identical to the dark calibration and is not detailed here.

7.3.13.1 Normal Observing

The primary use of the CV is to display real-time image data during the diffractionLimited,

seeingLimitedOnDisk, seeingLimitedCoronal, and, possibly, limbTracking modes. We refer to this usage

as “normal observing”. We assume that the CV has been initialized and calibrated and that it is currently

in the idle mode. The sequence diagram shown below in Figure 36 illustrates in detail the interaction

between the CV controller, the MC and the motion controllers, and the CC and the camera during this

mode of operation. The following actions take place (the numbers in the list refer to the sequence

numbers in the diagram):

1. The WCCS sends a configuration to the CV containing the mode attribute set to one of the

normal observing modes mentioned above.

2. The CV now sends configurations simultaneously to the MC and the CC instructing them to

configure their devices according to the attributes contained in the configuration. For all intents

and purposes, these commands occur simultaneously, but this cannot be shown in the diagram.

Instead we show the command to the MC occurring first.

3. The CV commands the CC to configure the camera.

4. The CC sends a configuration command to the camera.

5. The MC sends a command to the objective lenses to move the 30” lens into the beam and the 60”

lens out of the beam (the MC does not send the command if the lenses are already in their proper

positions).

6. The objective lenses move into their requested positions (normally this would be illustrated using

one thread for each lens, but for brevity we show a single thread representing both devices).

7. The camera configures itself and begins streaming images. Note that we use the free-run

capability of the camera which does not require any software or hardware triggers.

8. The motion controllers for the lenses signal to the MC that they are done.

9. The MC signals to the CV that it is done.

10. The Camera signals the CC that it is done.

CV CDD


11. The CC signals to the CV that it is done. The entire CV subsystem is configured at this point.

Note that the publishing of image data to the BDT occurs automatically in the CC and is not

shown in the sequence diagram.

12. After some time the WCCS sends a configuration to the CV requesting it to store data to the

DHS.

13. The CV forwards the request to the CC.

14. The CC responds by changing the meta-data that is sent to the DHS to indicate that the image

data shall now be saved.

15. The CC responds to the CV that it is done.

16. After some time the WCCS sends a configuration to the CV requesting it to stop storing data to

the DHS.

17. The CV forwards the request to the CC.

18. The CC responds by changing the meta-data that is sent to the DHS to indicate that the image

data shall not be saved.

19. The CC responds to the CV that is done.

Figure 36: A sequence diagram illustrating CV normal observing operation..

7.3.13.2 Dark Calibration

The dark calibration is a typical calibration procedure for the CV. It requires that the beam be blocked at

the GOS, which must be initiated at the WCCS level. The remainder of the procedure can be sequenced

either from the WCCS or in the CV. The description below assumes the procedure is implemented within

the CV and that the beam is already blocked at the GOS. The following actions take place (refer to Figure

37):

CV CDD


1. The WCCS sends a configuration to the CV containing the mode attribute set to “calibrate” and

the calibrate attribute set to “dark”.

2. The CV controller forwards the configuration to the Calibration Sequencer for processing.

3. The Calibration Sequencer forwards the appropriate camera settings to the Camera Controller and

commands it to configure the camera.

4. The Camera Controller sends the commands to the camera.

5. The camera configures itself.

6. The camera signals the CC that it is done.

7. The CC signals the Calibration Sequencer that it is done.

8. The calibration sequencer begins the image summing loop by requesting an image from the

Correction Thread (this is actually a blocking read to the pass box mentioned earlier).

9. The camera performs an exposure. Note: the camera free-runs, so this step occurs asynchronously

with respect to the other steps in the loop.

10. The camera notifies the Correction Thread that an image is ready.

11. The Correction Thread applies the dark and gain corrections.

12. The Correction Thread notifies the Calibration Sequencer that the requested image is ready (this

is actually a return from the blocking read on the pass box).

13. The new image is added to the running sum. Steps 9-13 are repeated for the requested number of

frames.

14. The Calibration Sequencer computes an average from the sum.

15. The Calibration Sequencer validates the average dark frame to make sure it is OK.

16. The Calibration Sequencer saves the dark frame to the Calibration Store.

17. The Calibration Sequencer signals the CV that it is done.

CV CDD


Figure 37: A sequence diagram illustrating the CV dark calibration.

7.3.13.3 Boresight Calibration

This procedure is used to align the boresight of the telescope. It must be sequenced from the WCCS

because it uses data from both the CV and the HOAO in the computations. A point source is required at

the GOS as well. The description below assumes the GOS pinhole is already in position. The WCCS

sends a configuration to the CV containing the mode attribute set to “calibrate” and the calibrate attribute

set to “boresight”. As part of the procedure, the WCCS requests a centroid measurement from the CV. At

the CV level, the following actions take place (refer to Figure 38):

1. The WCCS sends a configuration to the CV containing the mode attribute set to “calibrate” and

the calibrate attribute set to “boresight”.

2. The CV controller forwards the configuration to the Calibration Sequencer for processing.

3. The Calibration Sequencer sends a configuration to the MC to move the objective lenses to select

the desired field of view.

4. The Calibration Sequencer sends a configuration to the Camera Controller to configure the

camera.

5. The Camera Controller sends the configuration parameters to the camera.

6. The MC sends a command to the objective lenses to move to the appropriate positions for the

desired FOV (the MC does not send the command if the lenses are already in their proper

positions).

CV CDD


7. The camera configures itself.

8. The objective lenses move to the proper positions. Note: this is shown in the sequence diagram

using a single thread for brevity.

9. The objective lens controllers respond to the MC that they are in position (done).

10. The in position message for the lenses is passed up to the Calibration Sequencer.

11. The camera signals the Camera Controller that it is finished configuring itself.

12. The Camera Controller signals the Calibration Sequencer that it is done.

13. The calibration sequencer begins the image summing loop by requesting an image from the

Correction Thread (this is actually a blocking read to the pass box mentioned earlier).

14. The camera performs an exposure. Note: the camera free-runs, so this step occurs asynchronously

with respect to the other steps in the loop.

15. The camera notifies the Correction Thread that an image is ready.

16. The Correction Thread applies the dark and gain corrections.

17. The Correction Thread notifies the Calibration Sequencer that the requested image is ready (this

is actually a return from the blocking read on the pass box).

18. The new image is added to the running sum. Steps 13-18 are repeated for the requested number of

frames.

19. The Calibration Sequencer computes an average from the sum.

20. The Calibration Sequencer computes the centroid of the image.

21. The Calibration Sequencer publishes the centroid results in a CSF event.

22. The Calibration Sequencer signals the CV that it is done.

If multiple centroid calculations are required, the process is repeated by the WCCS without the

preliminary configuration of the camera and lenses (steps 3-12).

CV CDD


Figure 38: A sequence diagram illustrating the CV portion of the boresight calibration.

7.4 HARDWARE REQUIREMENTS

The CV control software will all run on a single multi-core CPU. One or two cores may be dedicated to

the camera control, dark and gain corrections, and image publication to the BDT, as needed. The

remaining CSF controllers are not a significant load for the CPU. The motion controllers are all deployed

in a separate CPU dedicated to control of all the AO system motion control devices. All the CSF

controllers are Java-based and are deployed in a single Java CSF Container on the CPU. A deployment

diagram for the CV high level software is shown below in Figure 39.

CV CDD


Figure 39: Deployment diagram for the HOAO high-level software.

Wavefront Correction Context Viewer Critical Design Definition · The requirements in this document...

Documents

Transcript of Wavefront Correction Context Viewer Critical Design Definition · The requirements in this document...