Software Operations Manual...Operations Manual Alan Greer & Chris Mayer Observatory Sciences Ltd November 30, 2016. TCS Software Operations Manual MAN-0013 Rev A Page ii Revision Summary:

Project Documentation Document MAN-0013

Revision A

Telescope Control System Software Operations Manual

Alan Greer & Chris Mayer Observatory Sciences Ltd

November 30, 2016

TCS Software Operations Manual

MAN-0013 Rev A Page ii

Revision Summary:

1. Date: 13th December 2010

Revision: Draft 1

Changes: Original Version

2. Date: 27th September 2011

Revision: Draft 2

Changes: Alpha Release Version

3. Date: 31st October 2011

Revision: Draft 3

Changes: TCS Simulator Release Version

4. Date: 31st May 2012

Revision: Draft 4

Changes: Beta Release Version

5. Date: 21st December 2012

Revision Draft 5

Changes: Final Release Version

6. Date: 28th February 2013

Revision: Draft 6

Changes: Updated following comments from FAT. Added startup of all simulators. PAC replaced by PA&C. Updated PA&C screenshot. Add more details on switching pointing models. Added definitions of TCS subsystem simulators and trajectory stream. Change references to simulators to be explicitly TCS subsystem simulators. Changed AO to aO where needed and updated screen shots. Added section on interlocks

7. Date: 15th October 2015

Revision: Draft 7

Changes: Updated for Canary 9 release. Updated screenshots of the Offsets screen and added a new screenshot and text section describing the rate motion offset capability of the TCS. Covered under requirement 4.4-0190, Rate Offsets. Updated units of helioprojective coordinates added new heliographic radial coordinate. Expanded descriptions of solar differential rotation. Updated to use pkgDevel. Updated screenshots and associated descriptions

8. Date: 21st October 2016

Revision: Draft 8

Changes: Updated for Canary 10 release. New screen shots and updated descriptions.

9. Date: 30th November 2016

Revision: A

Changes: Updated screenshots and text to describe the operation of aoMode. Added description of new AZ rotator frame. Initial formal release.


MAN-0013 Rev A Page iii


MAN-0013 Rev A Page iv

Table of Contents

1. Introduction ...................................................................................... 1

1.1 PURPOSE ............................................................................................................. 1 1.2 SCOPE .................................................................................................................. 1

1.3 DEFINITIONS, ACRONYMS AND ABBREVIATIONS .......................................... 1 1.3.1 ACRONYMS ............................................................................................................ 1 1.3.2 DEFINITIONS ........................................................................................................... 2

2. Quick Start Guide ............................................................................. 3

3. Installing the TCS ............................................................................. 5

3.1 PREREQUISITES ................................................................................................. 5 3.1.1 CSF INSTALLED ..................................................................................................... 5

3.1.2 NETWORK CONFIGURATION ..................................................................................... 5

3.1.3 WEATHER SERVER CONFIGURATION ........................................................................ 6 3.2 INSTALLATION FROM CVS ................................................................................ 6

4. Configuring the TCS ......................................................................... 6

4.1 PKGDEVEL ........................................................................................................... 6 4.2 APPLICATION CONFIGURATION ....................................................................... 7

4.3 SPECIFIC CONTROLLER CONFIGURATION ..................................................... 9 4.4 FACTORY DEFAULT RESET ............................................................................ 42

5. Running the TCS ............................................................................ 44

5.1 STARTUP SCRIPT ............................................................................................. 44

5.2 TCS MAIN CONTROLLERS ............................................................................... 44 5.2.1 ATST.TCS ............................................................................................................. 44

5.2.2 ATST.TCS.TPK ....................................................................................................... 44 5.2.3 ATST.TCS.TIME ...................................................................................................... 45 5.2.4 ATST.TCS.ENVIRONMENT ....................................................................................... 45

5.3 ACCEPTED ATTRIBUTES ................................................................................. 45 5.3.1 ATST.TCS ............................................................................................................. 45

5.3.2 CONFLICTING ATTRIBUTES .................................................................................... 48 5.4 EVENTS POSTED .............................................................................................. 50 5.4.1 ATST.TCS.CSTATUS............................................................................................... 50 5.4.2 ATST.TCS.CPOS .................................................................................................... 51 5.4.3 ATST.TCS.MCSTRAJECTORY .................................................................................. 53

5.4.4 ATST.TCS.ECSTRAJECTORY ................................................................................... 54 5.4.5 ATST.TCS.PK.AGVT.WCSCONTENT ......................................................................... 54

5.4.6 ATST.TCS.PAC.GOSTRAJECTORY ........................................................................... 55 5.4.7 ATST.TCS.TIMESTOLIMITS ...................................................................................... 55 5.5 EPHEMERIS SERVICE (ORACLE) .................................................................... 56

6. Using the TCS (Engineering Interface) ......................................... 58


MAN-0013 Rev A Page v

6.1 STARTING THE ENGINEERING INTERFACE .................................................. 58

6.2 INTERACTING WITH THE ENGINEERING INTERFACE .................................. 59 6.3 AVAILABLE ENGINEERING INTERFACE SCREENS ...................................... 59

6.3.1 TCS MAIN ENGINEERING....................................................................................... 59 6.3.2 MAIN ENGINEERING TABS AND ADDITIONAL SCREENS ............................................. 61 6.3.3 TCS CONTROL TAB .............................................................................................. 63 6.3.4 FORBIDDEN REGION .............................................................................................. 66 6.3.5 SOLAR DISK TAB .................................................................................................. 66

6.3.6 DATA TAB ............................................................................................................ 68 6.3.7 MODES TAB ......................................................................................................... 69 6.3.8 SCANNING TAB ..................................................................................................... 70 6.3.9 SUBSYSTEMS TABS ............................................................................................... 74 6.3.10 ENGINEERING TAB ................................................................................................ 76

6.3.11 LIFECYCLE CONTROL SCREEN ............................................................................... 78 6.3.12 HEALTH SCREEN .................................................................................................. 79

6.3.13 SOLAR DISK SCREEN ............................................................................................ 81

6.3.14 TARGET CONTROL SCREEN ................................................................................... 82 6.3.15 POINTING TESTS SCREEN ...................................................................................... 86 6.3.16 IERS UPDATE SCREEN ......................................................................................... 87

6.3.17 WEATHER SCREEN ............................................................................................... 88 6.3.18 OFFSETS SCREEN ................................................................................................. 89

6.4 INTERLOCKS ..................................................................................................... 93

7. Calibrating the TCS ........................................................................ 94

7.1 POINTING TEST ................................................................................................. 94

7.2 USING THE DKIST TPOINT CONTROLLER ..................................................... 96

7.3 DERIVING SESSION PARAMETERS ................................................................ 98 7.4 SWITCHING BETWEEN POINTING MODELS ................................................ 100

8. Planetary Ephemerides ................................................................ 101

8.1 CSPICE LIBRARY ............................................................................................ 101

9. TCS SubSystem Simulators ........................................................ 103

9.1 MCS SIMULATOR ............................................................................................ 103 9.2 ECS SIMULATOR ............................................................................................. 109 9.3 M1CS SIMULATOR .......................................................................................... 115 9.4 PA&C SIMULATOR .......................................................................................... 122

9.5 WCCS SIMULATOR ......................................................................................... 126 9.6 FOCS SIMULATOR .......................................................................................... 131

9.7 ACS SIMULATOR............................................................................................. 139 9.8 TEOA SIMULATOR .......................................................................................... 143

10. Unit Testing ................................................................................... 152

10.1 UNIT TEST ENGINEERING INTERFACE ........................................................ 152

11. References .................................................................................... 154


MAN-0013 Rev A Page vi


MAN-0013 Rev A Page 1 of 143

1. INTRODUCTION

1.1 PURPOSE The intention of this document is to describe the software that constitutes the DKIST Telescope Control

System, how to configure and start it, how to calibrate it and how to operate it from its engineering

screens.

The intended audiences of this document are:

- The users and operators of the TCS who are to run and control it

- The engineers who may need to diagnose and inspect the system when it is not operational

- The reviewers of the TCS

- The developers of the TCS sub-system work packages

- The developers of the OCS and instrument systems

The layout of this document is as follows:

Section 3 provides instructions on how to install the TCS. It describes the steps necessary to prepare the

CSF database tables with the required entries and describes the scripts that can be used to start the TCS as

a standalone application. Section 4 describes in detail each of the configuration parameters required by

the TCS. Section 5 shows how to run the TCS and provides details of all configurations accepted by the

controllers of the TCS. Also described are any attributes accepted from a “set” command and any

attributes returned from a “get”, as well as the corresponding expected behavior from the TCS when it

receives attributes from any of the methods mentioned above. Section 6 describes the user interface that

is provided as part of the TCS. The user interface allows complete control of the TCS by a human

operator. Section 7 describes in detail the methods used to calibrate the TCS, section 8 describes the

external C SPICE application used for planetary ephemerides, section 9 provides an overview of the TCS

simulation facilities and section 10 describes how to run the various tests available to confirm the TCS is

executing as expected. Finally, section 11 contains the references for this document.

1.2 SCOPE The software described by this design is the DKIST Telescope Control System. It is referred to

throughout this and other DKIST documentation as the Telescope Control System or more usually by its

acronym the TCS.

The purpose of the TCS is to provide a high quality stable image of a specified point on the solar disk or

corona to instruments at the Gregorian or Coudé focal planes. The TCS achieves this by coordinating and

controlling the activities of its subsystems under instruction from the Observatory Control System (OCS).

Note that as defined here the DKIST Telescope Control System does not include direct control of any

DKIST hardware. That job is the responsibility of the TCS subsystems which are outside the scope of this

document.

1.3 DEFINITIONS, ACRONYMS AND ABBREVIATIONS Specific definitions, acronyms and abbreviations used in this document are described below. For a more

general glossary and acronym list as used in DKIST see [1].

1.3.1 Acronyms

ACS - Acquisition Control System

aO - Active Optics



AO - Adaptive Optics

CSF - Common Services Framework

CSV - Comma Separated Value

ECS - Enclosure Control System

FOCS - Feed Optics Control System

GOS - Gregorian Optical Station

JES - Java Engineering Screens

M1CS - M1 Control System

OCS - Observatory Control System

PA&C - Polarimetry Analysis and Calibration

TCS - Telescope Control System

TEOA - Top End Optical Assembly

TMA - Telescope Mount Assembly

WCCS - Wavefront Correction Control System

1.3.2 Definitions

Telescope subsystems – the subsystems of the TCS are the Telescope Mount Assembly (TMA), the M1

Control System (M1CS), the Top End Optical Assembly (TEOACS) which consists of the M2 and heat

stop assemblies, the Feed Optics Control System (FOCS), the Acquisition Control System (ACS), the

Wavefront Correction Control System (WCCS), the Enclosure Control System (ECS) and the Polarimetry

Analysis and Calibration System (PA&C) containing the Gregorian Optical Station (GOS).

Virtual telescope – the astrometric building block used to construct the pointing kernel. The virtual

telescope is an ideal telescope that responds instantaneously to new demands. The demands can be in the

form of a changed sky target or image position. The virtual telescope can also predict target or image

coordinates knowing the mount encoder readings.

Slew – a discontinuous change in position or velocity demand from the TCS.

Track – a continuously changing position or velocity demand from the TCS.

Trajectory stream - the events posted at 20 Hz that contain the position demands to the tracking

mechanisms e.g. the altitude and azimuth axes

TCS subsystem simulator - an internal simulator provided by the TCS so that it can be run in a

meaningful way without requiring any of the real TCS subsystems.



2. QUICK START GUIDE The following set of instructions will guide you through installing, configuring and running the TCS

application in the fastest possible time. They then demonstrate how to run up the engineering interface

and issue a new target command. Execution of the target command requires either the TMA or ECS

subsystem simulators or the real subsystems to be available. In this example it is assumed the TCS

subsystem simulators are being used. A more thorough explanation of the steps taken can be found in

later sections of the manual.

Begin by ensuring the ATST path and bin directories are exported in a terminal.

export ATST=<path to atst installation>

export PATH=$PATH:$ATST/bin

Export the CVSROOT environment variable to the TCS repository.

export CVSROOT=:pserver:<user>@maunder.tuc.noao.edu:/home/atst/src/tcs

Login and checkout the TCS application.

cvs login

cvs checkout atst

If you have permission, export the CVSROOT environment variable to the OSL directory, login and

checkout. If you do not have permission then this step can be skipped but you must then configure the

property database to execute the “simple” rather than the “full” pointing kernel (see instructions below

concerning tcsSite.config and Section 3.2).

export CVSROOT=:pserver:<user>@maunder.tuc.noao.edu:/home/atst/src/osl

cvs login

cvs checkout atst

From the root atst directory make the Java and C++ classes.

cd $ATST

make classes

make gcc_all

Load the application data and properties.

cd $ATST/admin/tcs

cp tcsSite.config.template tcsSite.config

Edit the tcsSite.config file to specify the hosts on which the TCS and the Ephemeris service should run

and select which if any internal simulators should be used and where they should run. An example file is

shown below

# Template for the TCS site config file.

# Specify which host the TCS Java and CPP Containers should run on

# These should probably be the same

TCS_HOST=localhost



# Specify which host the TCS Ephemeris should run on

TCS_EPHEM_HOST=localhost

# Which pointing kernel you would like to use for the TCS. Options are

# 'full' or 'simple'. The 'simple' pointing kernel is sufficient for

# testing and development work. The 'full' pointing kernel must be used

# to control the telescope

TCS_PK_TYPE=full

# Specifies whether or not the TCS-provided simulator for sub-system

# xxx should be used value should be 'yes' or 'no'

TCS_USE_ACS_SIM=no

TCS_USE_ECS_SIM=yes

TCS_USE_FOCS_SIM=no

TCS_USE_M1CS_SIM=no

TCS_USE_MCS_SIM=yes

TCS_USE_PAC_SIM=no

TCS_USE_TEOACS_SIM=no

TCS_USE_WCCS_SIM=yes

# Which host the TCS-provided simulators should run on

# Only needed if at least one of the above TCS_USE_xxx_SIM options is

'yes'

TCS_SIM_HOST=localhost

Generate and load the application data base entries and the controller properties

cd $ATST/admin

./pkgDevel –make-all tcs

Load the configured internal simulators and the TCS

osl-simsUp

tcsUp

To run the engineering screens

osl-simsGui

tcsGui

ephemGui

To enter a target click on the “Target Control” button on the left hand side of the screen, enter a target

name, RA and Dec and click on the “Submit” button at the bottom of the target configuration widget.

The target is entered and the position demand stream calculation is updated accordingly.

The TCS and its simulators can be shut down as follows

osl-simsDown

tcsDown



3. INSTALLING THE TCS The following instructions describe the installation process for the TCS on a COTS PC such as might be

used to run the TCS for test purposes. The TCS uses pkgDevel for configuration and deployment. A full

description of pkgDevel can be found in [2]. These instructions only cover the installation of the TCS and

its associated configuration database CSV files and not the installation of the CSF itself, which is beyond

the scope of this document. The installation instructions for the CSF can also be found in [2].

3.1 PREREQUISITES The TCS application runs under the Linux OS within the CSF environment. It has been developed and is

currently supported on CentOS 7 and the CSF release known as Canary_10. Although earlier versions of

the TCS ran under CentOS 5 and 6 it is unlikely that the current release will do so. CentOS is a

community supported version built from Red Hat’s source distributions. (See www.centos.org).

3.1.1 CSF Installed

Before the TCS can be compiled there must be a full installation of the CSF present on the target system.

Details of the installation of the CSF can be found in [2]

3.1.2 Network Configuration

There is one configuration item of the TCS that requires the TCS to access the external network. The

configuration must contain the IERS update attribute and is used to update the IERS parameters for the

pointing kernel. This check can be set up to automatically execute as part of startup but can also be

requested at any time to ensure the latest data are available. The health is set to warning if it is not

executed for at least seven days and the health is set to bad if it is not executed for at least 28 days. These

timescales can be configured by setting the appropriate properties for the IERS controller (see section

4.3).

To retrieve the parameters the TCS must make a connection to the IERS ftp site maia.usno.navy.mil and

then download and parse a file. A problem can arise if the network is not available at the time the

command is issued. A call is made into the operating system to perform the DNS lookup and at this point

the OS has been observed to completely swap the application off the CPU. If the DNS lookup can’t

proceed due to the network being unavailable then the TCS can be denied the processor for about 30s

before the DNS lookup times out.

Although it is recommended to only execute the IERS update command when not actually observing

since it modifies the telescope pointing, the problem can be avoided by placing the IP address of the ftp

site in the /etc/hosts file. The current IP address is 198.116.61.22 . It should also be ensured that the

/etc/nsswitch.conf file has the “files” keyword before the “dns” keyword for the hosts entry i.e.

hosts: files dns

With this configuration the DNS lookup is not required and the command will time out if the network

can’t be reached. More importantly, because it has avoided the DNS lookup the TCS remains active and

responsive at all times.

One potential drawback with this scheme is if the site maia.usno.navy.mil is ever switched to another IP

address. Fortunately, it is possible to distinguish between the cases of no network and an invalid IP

address and so this is handled in the IERS controller.

http://www.centos.org/



3.1.3 Weather Server Configuration

At this time the interface to the weather and environmental monitor is TBD. It is expected however that

the weather station will provide an event atst.ws.environment that the TCS will subscribe to on startup. It

is not at this stage therefore envisioned that any special configuration will be needed to access the weather

server.

3.2 INSTALLATION FROM CVS

The exact process of installing the TCS from CVS will be developed during construction i.e. the exact

server, modules etc. to check out will be specified here. The outline process however will be as follows

1. Create an empty top level directory

2. Checkout the TCS and associated modules from CVS

cd $ATST

export CVSROOT=:pserver:[email protected]:/home/atst/src/cs

cvs login

cvs checkout atst

export CVSROOT=:pserver:[email protected]:/home/atst/src/base

cvs login

cvs checkout atst

export CVSROOT=:pserver:[email protected]:/home/atst/src/tcs

cvs login

cvs checkout atst

export CVSROOT=:pserver:[email protected]:/home/atst/src/osl

cvs login

cvs checkout atst

3. The final checkout will only be possible if you are within the DKIST network. This is due to the fact

that some of the code in the osl sub-directory links to proprietary software packages. It is a

requirement of the use of the ICE infrastructure that any code linked to it must be provided with a

GPL license if it is to be distributed. Since this is not possible with proprietary code the osl sub-

directory can’t be checked out externally. If the code cannot be checked out then replacement classes

can be loaded instead by suitably configuring the property database items config:type in the pk and

sollib controllers via the tcsSite.config file (see Section 4.3)

4. In the top level directory type make build_all

Configuring the TCS once it is checked out and built is described in the following section.

4. CONFIGURING THE TCS The standard way of configuring the TCS is by use of pkgDevel. This provides simple access to the major

configuration parameters of the system. Many other configuration parameters are accessible directly

through the property and application databases. In the next section we describe how pkgDevel is used and

then for completeness how more detailed configuration can be achieved

4.1 PKGDEVEL

Configuration via pkgDevel is achieved by specifying options in a tcsSite.config file. A template file can

be found in $ATST/admin/tcs. Copy tcsSite.config.template to tcsSite.config and then edit the file as

required. The parameters to specify are as follows:

TCS_HOST – this is the host machine on which to run the TCS



TCS_EPHEM_HOST – this is the host on which to run the Ephemeris service

TCS_PK_TYPE – options here are full or simple. Only set to simple if you do not have access to the

proprietary code in the DKIST repository

TCS_USE_XXX – these options specify which if any TCS supplied simulators should be included. The

TCS currently requires access to the MCS, ECS and WCCS in order to run. If none of the “real” versions

of these systems is available then at a minimum specify “yes” for each of them

An example configuration file is listed in Section 2

Once the configuration file has been saved the application and property databases can be populated and

scripts generated to start and stop the system. This is achieved by passing the –make-all option to

pkgDevel

cd $ATST/admin

./pkgDevel –make-all tcs

The auto generated scripts are installed in $ATST/bin. If this is in your path then the following commands

will start up the simulators that were configured in tcsSite.config, startup the TCS and then start the TCS

engineering screens

osl-simsUp

tcsUp

osl-simsGui

tcsGui

The applications can later be shut down by

osl-simsDown

tcsDown

The next section describes all the different configuration settings that affect the TCS. This configuration

information is maintained within the property database of the CSF. How that configuration information is

maintained is the choice of the operator of the TCS, but a standard set of factory defaults are provided in

CSV format. After processing by pkgDevel, these factory default values can be reloaded into the

database to restore the TCS application to the state it was delivered in. How to restore to factory defaults

is described in detail in sections 4.2 and 4.4.

4.2 APPLICATION CONFIGURATION

The TCS application consists of twelve CSF controllers. Seven of the controllers are management

controllers. The TCS application also consists of three containers, one for the Java controllers, one for the

C++ controllers and an extra C++ container for the TPOINT application controller (should it be required).

All of the application configuration information i.e. which controllers to load into which containers,

names and classes of controllers and containers must be configured before the application can be loaded.

The following two tables present the information required to configure the TCS application containers

and controllers.

Name Class Language Toolbox Loader Description

TCS1 atst.cs.ccm.container.Container java ice The TCS Java container.



TCS2 atst.cs.ccm.container.Container c++ ice The TCS C++ container.

TCS3 atst.cs.ccm.container.Container c++ ice The TCS TPOINT

container.

Figure 1. TCS container configuration table.

Name Class Container Description

atst.tcs atst.tcs.system.Tcs TCS1 The TCS main controller.

atst.tcs.tpk atst.tcs.tpk.AtstPk TCS1 The TCS pointing kernel

management controller.

atst.tcs.time atst.tcs.time.Time TCS1 The TCS time management

controller.

atst.tcs.time.iers atst.tcs.time.Iers TCS1 The TCS IERS interface controller.

atst.tcs.tpk.pk atst.tcs.tpk.Pk TCS2 The TCS pointing kernel controller.

atst.tcs.tpk.sollib atst.tcs.tpk.Sollib TCS2 The TCS solar pointing kernel

controller.

atst.tcs.seq atst.tcs.system.Seq TCS1 The TCS sequencing interface

controller.

atst.tcs.hserver atst.tcs.system.Handset TCS1 The TCS hand paddle interface

controller

atst.tcs.thermal atst.tcs.thermal.Ctrl TCS1 The TCS thermal interface

controller.

atst.tcs.environment atst.tcs.environment.Ems TCS1 The TCS environment interface

controller.

atst.tcs.guide atst.tcs.guide.Guide TCS1 The TCS guiding interface

controller.

atst.tcs.tpk.tpoint atst.tcs.tpk.TpointController TCS3 The TCS tpoint pointing test

controller.

Figure 2. TCS controller configuration table.

The information provided in the tables above is delivered with the TCS application in the form of a CSV

formatted file.

$ATST/admin/tcs/app/tcsApp.csv

This file can be considered the application configuration factory defaults used in section 4.4. However, it

is not necessary to run the TCS using the application configuration data provided here. The TCS

application can be distributed over several machines if desired as it makes full use of the CSF connection

and event services, as well as the other services. The only restriction is that all machines involved in the

execution of the TCS application must have an installation of the CSF present and all of the machines

must be using the same underlying middleware server.

Note that this file should not be directly loaded into the application database. This is because it contains

substitution tokens used by pkgDevel. If changes are made to it then pkgDevel should be re-run. The



substitutions will be made and a file tcs.app created in $ATST/admin/tcs. This tcs.app file can

be directly loaded into the application database as follows

AppReader < tcs.app

4.3 SPECIFIC CONTROLLER CONFIGURATION

Each controller present in the TCS application has a corresponding set of configuration data items

relevant to its operation. All of this configuration data must be present before the application can be

successfully started. This includes (but is not limited to) the management controller configuration

required by each of the seven management controllers, defining the child controller destinations and the

corresponding management requirements of the parent controller. Also present is pointing kernel specific

data required for both the pointing kernel itself and the ephemeris service that utilises the same pointing

kernel libraries to obtain the required ephemeris information.

The tables below contain a comprehensive description of each configuration data item required by each

controller present in the TCS, including the default values that are provided as part of the TCS. For some

items additional descriptions can be found following the table.

Controller atst.tcs:

Name Type rwx Limits Default Description

.csf:maxThreads string r-- 10 Maximum

number of

simultaneous

action threads

.csf:numThreads string rw- 10 Number of

simultaneous

actions.

.csf:threadModel string rw- growable How the thread

pool is managed.

.header:freq real rw- 1.0 Synchronous

header data

collection

frequency.

.header:periodic string rw- List of header

items to collect

periodically

.header:start string rw- List of header

items to collect

on start event

.header:stop string rw- List of header

items to collect

on stop event

.header:type string rw- op Type of headers

op or exp

.interlock:event string rw- atst.gis.interlock Interlock event



channel.

.interlock:attributes string rw- tcsInterlock Name of interlock

to listen for.

.interlock:override boolean rw- false Interlocks are

currently

overridden.

.manage:actions string rwx atst.tcs.time,

atst.tcs.seq,

atst.tcs.thermal,

atst.tcs.environment,

atst.tcs.guide,

atst.tcs.tpk,

atst.tcs.hserver,

atst.tcs.mcs,

atst.tcs.ecs

atst.tcs.wccs

atst.tcs.focs

atst.tcs.teoacs

atst.tcs.acs

atst.tcs.pac

atst.tcs.m1cs

Names of the

controllers that

this controller

submits

configurations

.manage:lifecycles string rwx atst.tcs.time,

atst.tcs.seq,

atst.tcs.thermal,

atst.tcs.environment,

atst.tcs.guide,

atst.tcs.tpk,

atst.tcs.hserver

Names of the

controllers whose

lifecycles are

managed by this

controller

.config:dataRate integer rwx 200 Delay time

(milliseconds)

between data

context posts.

.config:dataChannel string rwx atst.tcs.data Name of the

event channel to

post the data

context out to.

.config:dataItems string rwx environment:heartbeat, Data items to



thermal:heartbeat,

guide:heartbeat,

seq:heartbeat,

time:heartbeat,

iers:heartbeat,

tpk:heartbeat,

pk:heartbeat,

sollib:heartbeat,

slalib:heartbeat,

health:value,

health:reason,

mount:cover

enclosure:cover

subsys:mcs:mode,

subsys:mcs:connected,

subsys:mcs:inPosition,

subsys:mcs:status,

subsys:m1cs:mode,

subsys:m1cs:connected,

subsys:m1cs:inPosition,

subsys:m1cs:status,

subsys:acs:mode,

subsys:acs:connected,

subsys:acs:inPosition,

subsys:acs:status,

subsys:focs:mode,

subsys:focs:connected,

subsys:focs:inPosition,

subsys:focs:status,

subsys:pac:mode,

subsys:pac:connected,

subsys:pac:inPosition,

subsys:pac:status,

subsys:teoacs:mode,

post.



subsys:teoacs:connected,

subsys:teoacs:inPosition,

subsys:teoacs:status,

subsys:wccs:mode,

subsys:wccs:connected,

subsys:wccs:inPosition,

subsys:wccs:status,

subsys:ecs:inPosition,

subsys:ecs:mode,

subsys :ecs :connected,

subsys :ecs :status

.ctr:rate1 real rw- 1.0 Rate motion

offset, rate index

1 (arcsec /

second).


offset, rate index

2 (arcsec /

second).


offset, rate index

3 (arcsec /

second).

.ecsCoverEventTimeout real rw- 20000 Timeout (msecs)

for ecs cStatus

event

.mcsCoverEventTimeout real rw- 2000 Timeout (msecs)

for mcs cStatus

event

.mode string r-x off | active |

tracking

off Overall telescope

mode.

.thermalMode string r-x off |

precondition

| active

off Overall thermal

mode.

.obsMode string r-x acquire |

setup | polcal

| telcal |

wavecal |

gain | dark |

focus | align |

target |

observe |

acquire Standard

observing modes.



aoCalibrate

.aoMode string r-x off |

aoCalibrate |

idle |

limbTracking

| open |

closed

off Active optics

modes.

.namedPos string r-x stow | index Move the TCS

into a named

position state.

.frame string r-x HG | HC |

HP | HPR |

ICRS | FK5 |

FK4 | APPT |

GAPPT |

AZEL

Target coordinate

reference system.

.targetName string r-x A name for the

target.

.target string r-x Coordinates for

the target.

.equinox string r-x Epoch of mean

equator and

equinox.

.epoch real r-x The zero point for

proper motion

(year).

.properMotion string r-x Proper motion in

RA and Dec.

.parallax real r-x Parallax (arcsecs).

.rv real r-x Radial velocity

(km/s).

.wavelength integer r-x Effective

wavelength

(microns).

.targetOffset real r-x Target offset.

.targetOffsetType string r-x simple |

tplane | solar

Target offset

type.

.targetOffsetIndex integer r-x 0 – 1 Whether these are

user (0) or

handset (1)

offsets.

.absorbTargetOffsets integer r-x 0 – 1 Absorb the

current offsets



into the target.

.clearTargetOffsets integer r-x 0 – 2 Clear the

currently applied

offsets.

0 = user,

1 = handset,

2 =both

.trackRate string r-x Telescope

differential

tracking rate.

.trackRateT0 string r-x Reference epoch

for the differential

tracking rate.

.trackRateIndex integer r-x 1..3 Index of track

rate to select

.trackRateDirecton string r-x positive |

negative |

stop

Direction to apply

the constant track

rate

.trackRateAxis integer r-x 0..2 Axis to apply the

track rate

.solarDiffRotate string r-x none |

standard |

custom

none Solar rotation

model.

.solarDiffRotateParams real r-x 14.1844, -2.0,0.0 Custom rotation

model

parameters.

(deg/day)

.ecsTargetName string r-x sun |

mountbase

mountbase ECS target.

.ecsTarget real r-x -1350 –

+1350

ECS sun

helioprojective

target demands.

.instOrigin real r-x Instrument

position of target

(mm).

.instOriginOffsetIndex integer r-x 0 – 1 Index of

instrument origin

offset.

.instOriginOffset real r-x Instrument origin

offset (mm).

.absorbInstOrigin integer r-x 0 – 1 Absorb

instrument offsets



into base origin.

.clearInstOrigin integer r-x 0 – 1 Clear the

currently applied

instrument origin

offsets.

.ipa real r-x Instrument

position angle

(degrees).

.ipaFrame string r-x FK4 | FK5 |

ICRS | APPT

| GAPPT |

AZEL

Coordinate

system for

instrument

position angle.

.ipaEquinox string r-x Epoch of mean

equator and

equinox.

.iaa real r-x Instrument

alignment angle

(degrees).

.horizonChecking string r-x on | off Reject demands

below horizon?

.wrap integer r-x -1 – +1 Preferred wrap

for the mount.

.rotWrap integer r-x -1 – +1 Preferred wrap

for the rotator.

.planet string r-x mercury |

venus | mars |

jupiter |

saturn |

uranus |

neptune |

pluto | moon

Track a planet.

.elementsType string r-x JPL | MPC |

Internal

Type of elements.

.elementsForm string r-x Major

planets |

Minor

planets |

Comets

Form of elements.

.elementsEpoch real r-x 0.0 –

100000.0

Epoch of

elements (TT

MJD).

.elementsInclination real r-x -180.0 –

180.0

Orbital

inclination (degs).



.elementsANode real r-x 0.0 – 360.0 Longitude

ascending node

(degs).

.elementsPerihelion real r-x 0.0 – 360.0 Longitude

perihelion (degs).

.elementsAorQ real r-x 0.0 –

10000.0

Mean distance

(AU).

.elementsEccentricity real r-x 0.0 – 1.0 Eccentricity.

.elementsAorL real r-x 0.0 – 360.0 Mean longitude

(degs).

.elementsDailyMotion real r-x 0.0 – 10.0 Daily Motion

(degs/day).

.collOffset real r-x Collimation

offsets (arcsecs).

.clearCollOffset boolean r-x Clear collimation

offsets.

.pointNew string r-x Open a new

pointing data file.

.pointAdd boolean r-x Add a new data

point to the

pointing file.

.sessionFit string r-x Fit the session

data set.

.sessionMask integer r-x Mask for

removing data

items from fit.

.sessionUseIA boolean r-x Use IA in data fit.

.sessionAction string r-x use | revert Use the session

data or revert to

the original

model.

.guide boolean r-x Turn on or off

guiding.

.clearGuide boolean r-x Zero any guiding

corrections.

.guideGain real r-x Gain correction

applied to guide

signals.

.scanType string r-x none |

random |

spiral | grid |

Selected scan

type.



raster

.scanStartTime string r-x Start time for the

scan.

.scanParams string r-x Array of

parameters for the

defined scan.

.iersUpdate boolean --x Fetch IERS

parameters.

.wsMode string r-x manual |

automatic

How weather

station data is

accessed.

.wsTemperature real r-x Weather station

temperature

(degrees C).

.wsPressure real r-x Weather station

pressure (mbars).

.wsHumidity real r-x Weather station

humidity (%).

.inPosition boolean r-- false In position flag.

.cTarget:dmd:base:ra string r-- Current base

demand RA

(hours).

.cTarget:dmd:base:dec string r-- Current base

demand Dec

(degrees).

.cTarget:dmd:total:ra string r-- Current total

demand RA

(hours).

.cTarget:dmd:total:dec string r-- Current total

demand Dec

(degrees).

.cTarget:dmd:pa real r-- Demand position

angle (degrees).

.cTarget:dmd:iaa real r-- Demand

instrument

alignment angle

(rotator offset in

degrees).

.cTarget:dmd:rma real r-- Demand rotator

mechanical angle

(degrees).

.cTarget:dmd:hp:x real r-- Demand



helioprojective x

coordinate.

.cTarget:dmd:hp:y real r-- Demand

helioprojective y

coordinate.

.cTarget:dmd:hg:theta string r-- Demand

heliographic

latitude (degrees).

.cTarget:dmd:hg:phi string r-- Demand

heliographic

longitude

(degrees).

.cTarget:dmd:hc:x real r-- Demand

heliocentric x

coordinate (R0).

.cTarget:dmd:hc:y real r-- Demand

heliocentric y

coordinate (R0).

.cTarget:dmd:hc:z real r-- Demand

heliocentric z

coordinate (R0).

.cTarget:dmd:hpr:rho real r-- Demand

helioprojective

radial radius.

.cTarget:dmd:hpr:psi real r-- Demand

helioprojective

radial angle

(degrees).

.cOffsets:manual real r-- Current manually

applied offsets

(arcsec).

.cOffsets:handset real r-- Current

collimation

corrections from

software handset

(arcsec).

.cOffsets:total real r-- Current total

offsets applied to

target (arcsec).

.cCollimation:manual real r-- Current manually

applied

collimation

corrections

(arcsec).



.cCollimation:handset real r-- Current

collimation

corrections from

software handset

(arcsec).

.cCollimation:total real r-- Current total

collimation

corrections

applied to target

(arcsec).

.cPorigin:base real r-- Current base

pointing origin

(mm).

.cPorigin:manual real r-- Current manually

applied pointing

origin (mm).

.cTrackRate real r-- Current

differential track

rate applied to the

target (arcsec/s).

.cTarget:pos:ra string r-- Current mount

position

(calculated RA in

hours).

.cTarget:pos:dec string r-- Current mount

position

(calculated Dec in

degrees).

.cTarget:pos:rma string r-- Current rotator

mechanical angle

(degrees).

.post:cStatus:enabled boolean rw- true

.post:cStatus:eventName string rw- cStatus Name of status

event.

.post:cStatus:interval real rw- 1.0 How often (sec)

to post cStatus

event.

.post:cPos:enabled boolean rw- true

.post:cPos:eventName string rw- cPos Name of position

status event.

.post:cPos:interval real rw- 0.2 How often (sec)

to post cPos

event.



.post:timesToLimits

:enabled

boolean rw- true

.post:timesToLimits

:eventName

string rw- timesToLimits Name of times to

limits status

event.

.post:timesToLimits

:interval

real rw- 1.0 How often (sec)

to post times to

limits event.

Figure 3. Properties for the atst.tcs controller.

Controller atst.tcs.environment:


.csf:maxThreads string r-- 10 Maximum number of

simultaneous action

threads


simultaneous actions.

.csf:threadModel string rw- growable How the thread pool is

managed.

.header:freq real rw- 1.0 Synchronous header

data collection

frequency.

.header:periodic string rw- List of header items to

collect periodically

.header:start string rw- List of header items to

collect on start event

.header:stop string rw- List of header items to

collect on stop event

.header:type string rw- op Type of headers op or

exp


channel.

.interlock:attributes string rw- tcsInterlock Name of interlock to

listen for.


currently overridden.

.post:heartbeat:enabled boolean rw- true

.post:heartbeat:eventName string rw- heartbeat Name of heartbeat

event



.post:heartbeat:interval real rw- 1.0 Interval (sec) between

heartbeat events


.post:cStaus:eventName string rw- cStatus Name of cStatus

event.

.post:cStatus:interval real rw- 1.0 Interval (sec) between

cStatus events.

.wsEventChannel string rw- atst.ws.environment Event channel to listen

on for weather data.

.mode string r-x automatic

| manual

automatic Mode of controller.

.airtemp:value real r-x -20.0 –

50.0

0.0 Air temperature value

(deg C).

.airtemp:source string r-x default |

automatic

| manual

default Source of last air temp

value.

.pressure:value real r-x 500.0 –

1000.0

710.0 Pressure (mbar).

.pressure:source string r-x default |

automatic

| manual

default Source of last pressure

value.

.humidity:value real r-x 0.0 –

100.0

50.0 Humidity value (%).

.humidity:source string r-x default |

automatic

| manual

default Source of last

humidity value.

Figure 4. Properties for the atst.tcs.environment controller.

Controller atst.tcs.guide:



simultaneous action

threads




managed.

.header:async string rw- none List of asynchronous

header data items.

.header:sync string rw- none List of synchronous



header data items.


data collection

frequency.


channel.


listen for.



.guide string r-x off | on off Should the TCS

integrate the guide

signals.

.clearGuide boolean r-x Clear any guide

signals.

.guideGain real r-x 0.0 –

1.0

0.1 Gain factor for

incoming guide

corrections.

.guide:channel string r-- atst.wccs.tipTiltOffload Event channel name

for the incoming guide

signals.

.guide:tmatrix real rw- 1.0, 0.0, 0.0, 1.0 Transformation matrix

for the guide signals.

.guide:dx real r-- The last received raw

signal (dx).

.guide:dy real r-- The last received raw

signal (dy).

.guide:timestamp string r-- Timestamp of the last

received signal.

.guide:id string r-- ID of the last received

signal.

.guide:ga real r-- The integrated

correction (ga).

.guide:gb real r-- The integrated

correction (gb).



event

.post:heartbeat:interval real rw- 1.0 Interval (s) between

heartbeat events

Figure 5. Properties for the atst.tcs.guide controller.



Controller atst.tcs.seq:



simultaneous action

threads




managed.


header data items.

.header:sync string rw- None List of synchronous

header data items.


data collection

frequency.

.interlock:event string rw- atst.gis.interlock Interlock event channel.


listen for.

.interlock:override boolean rw- False Interlocks are currently

overridden.

.post:heartbeat:enabled boolean rw- True


event


heartbeat events

Figure 6. Properties for the atst.tcs.seq controller.

Controller atst.tcs.thermal:



simultaneous action

threads




managed.


header data items.




header data items.


data collection

frequency.



listen for.

.interlock:override boolean rw- false Interlocks are currently

overridden.



event


heartbeat events

Figure 7. Properties for the atst.tcs.thermal controller.

Controller atst.tcs.time:



simultaneous action

threads




managed.


header data items.


header data items.


data collection

frequency.



listen for.

.interlock:override boolean rw- false Interlocks are currently

overridden.

.manage:actions string rwx atst.tcs.time.iers Controllers to load



.manage:lifecycles string rwx atst.tcs.time.iers Controllers to manage



event


heartbeat events

Figure 8. Properties for the atst.tcs.time controller.

Controller atst.tcs.time.iers



number of

simultaneous

action threads


simultaneous

actions.


pool is managed.

.header:async string rw- none List of

asynchronous

header data items.

.header:sync string rw- none List of

synchronous

header data items.


header data

collection

frequency.


channel.

.interlock:attributes string rw- tcsInterlock Name of

interlock to listen

for.


currently

overridden.


.post:heartbeat:eventName string rw- heartbeat Name of

heartbeat event

.post:heartbeat:interval real rw- 1.0 Interval (s)



between heartbeat

events


.post:cStatus:eventName string rw- cStatus Name of cStatus

event

.post:cStatus:interval real rw- 1.0 Interval (s)

between cStatus

events

.mjdnls real rw- 99999.9 MJD of next leap

second

.delut real rw- 99999.9 UT1 – UTC (s)

.delat real rw- 36.0 Current number

of leap seconds

.xpm real rw- 0.0 X component of

polar motion (“)

.ypm real rw- 0.0 Y component of

polar motion (“)

.updated real rw- 0.0 Date (MJD) of

most up to date

IERS data

.updated_ST string rw- 1900-01-01 Date of most up

to date IERS data

.warningTime integer rw- 2 Warning issued if

not updated for

warningTime

days

.errorTime integer rw- 7 Error issued if not

updated for

errorTime days

.fileName string rw- http://maia.usno.navy.mil/

ser7/finals.daily

Name of file

containing IERS

data

Figure 9. Properties for the atst.tcs.time.iers controller.

Controller atst.tcs.tpk:



simultaneous action

threads

.csf:numThreads string rw- 10 Number of simultaneous

actions.




managed.

.header:async string rw- None List of asynchronous

header data items.


header data items.

.header:freq real rw- 1.0 Synchronous header data

collection frequency.



listen for.

.interlock:override boolean rw- False Interlocks are currently

overridden.

.manage:actions string rwx atst.tcs.tpk.sollib,

atst.tcs.tpk.pk

Names of controllers this

controller controls

.manage:lifecycles string rwx atst.tcs.tpk.sollib,

atst.tcs.tpk.pk

Names of controllers this

controller manages

.post:data:enabled boolean rw- true

.post:data:eventName string rw- data Name of data event

.post:data:interval real rw- 0.2 Interval (s) between data

events

.azimuth real r-- -90.0,

310.0

0.0 Azimuth axis soft limits.

.altitude real r-- 7.0,

104.04

0.0 Altitude axis soft limits.

.coude real r-- -270.0,

270.0

0.0 Coude axis soft limits.

.carousel real r-- -265.0,

265.0

0.0 Carousel axis soft limits.

.shutter real r-- 7.0,

90.0

0.0 Shutter axis soft limits.

Figure 10. Properties for the atst.tcs.tpk controller.

Controller atst.tcs.tpk.sollib:





simultaneous action

threads




managed.

.header:async string rw- None List of asynchronous

header data items.


header data items.


data collection

frequency.


channel.


listen for.



.offsetIndex integer r-x 0 – 1 Index of offset (0 =

manual, 1 = handset)

.offsetDx real r-x -3600.0 –

3600.0

Offset in HP x

(arcsec).

.offsetDy real r-x -3600.0 –

3600.0

Offset in HP y

(arcsec).

.frame string r-x HG | HC |

HP | HPR

Frame of target

coordinates.

.theta1 real r-x First coordinate.

.theta2 real r-x Second coordinate.

.theta3 real r-x Third coordinate.

.trackId string r-x New track ID of TCS

demand event.

.mode string r-x active |

inactive

Mode of sollib

operation.

.fl real rwx 52330.0 Telescope focal length

(mm).

.xpm real rwx 0.0 Polar-motion x angle

(arcseconds).

.ypm real rwx 0.0 Polar-motion y angle

(arcseconds).



.delut real rwx 0.0 Current UT1-UTC.(s)

.delat real rwx 36.0 Current TAI-UTC.(s)

.ttmtai real rwx 0.0003725 Current TT-TAI (days)

.config:mode string rwx operational

| test

operational The kernel mode.

.config:type string rwx full |

simple

full The kernel type to load

.config:mediumRate integer rwx 250 Time delay between

each medium loop

update (ms).

.config:medoimLoops integer 1 Number of medium

loops to run between

each slow loop

.config:dataRate integer rwx 4 Number of loop

iterations between data

context posts.

.config:pkName string rwx atst.tcs.tpk.pk Name of pointing

kernel controller.

.diffrot:mode string r-- none |

standard |

custom

standard Solar differential

rotation mode.

.diffrot:coeffs string r-- 0.0, 0.0,0.0 Solar differential

rotation coefficients.

.config:dataChannel string rwx atst.tcs.tpk.sollib.data Name of the event

channel to post the

data context out to.

.config:fitsChannel string rwx atst.tcs.tpk.sollib.

solarFits

Name of the event

channel to post FITS

data.

.config:wcsChannel string rwx atst.tcs.pk.agvt.

WcsContext

Name of the event

channel to receive

WCS data.

.config:dataItems string rwx mode, tai,

target:frame, target:hp,

target:hpr,

target:hpr_ST,

target:hg, target:hc,

target:hct,

target:hg_ST,

target|:J2000,

target:gap, target:ap,

target:ap_ST,

target:dt,

Data items to post.



ephem:semid,

ephem:semid_AS,

ephem:pdate,

ephem:pdate_DEG,

ephem:hpsp,

ephem:hgl0,

ephem:hgb0,

ephem:hgl0_ST,

ephem:hgb0_ST,

enc:mode,

enclosure:ap_ST,

enclosure:hp,

current:hp,

current:hpr,

current:hpr_ST,

current:hc, current:hg,

current:hg_ST,

offsets:manual,

offsets:handset,

offsets:total,

diffrot:mode,

diffrot:coeffs,

diffrot:values

.numthreads integer rwx 5 Number of threads in

pool.

Figure 11. Properties for the atst.tcs.tpk.sollib controller.

The sollib controller also uses the following variables from the constants service

Name Value Description

height 3055.0 Site elevation above sea-level (m)

latitude 20.7070833 Site mean geodetic latitude (degrees)

longitude -156.2576111 Site mean east longitude (degrees)

Table 1 Items accessed from the constants service

Controller atst.tcs.tpk.pk:



number of

simultaneous

actions.


simultaneous

actions.




pool is

managed.

.header:async string rw- None List of

asynchronous

header data

items.

.header:sync string rw- None List of

synchronous

header data

items.


header data

collection

frequency.


channel.

.interlock:attributes string rw- tcsInterlock Name of

interlock to

listen for.

.interlock:override boolean rw- False Interlocks are

currently

overridden.

.tarTheta1 string r-x Target position

RA (or Az).

.tarTheta2 string r-x Target position

Dec (or El).

.tarUpdateTheta1 string r-x Target update

RA (or Az).

Used by sollib

.tarUpdateTheta2 string r-x Target update

Dec (or El).

Used by sollib

.tarName string r-x Target name.

.tarCosys string r-x AZEL |

GAPPT |

APPT | FK4

| FK5 | ICRS

Mount frame.

.tarEqx string r-x Target

equinox.

.tarParallax real r-x Target parallax

(arcsecs).

.tarPmRa string r-x Target proper



motion RA.

.tarPmDec string r-x Target proper

motion Dec.

.tarPmEpoch real r-x Target proper

motion epoch

(year).

.tarRv real r-x Target radial

velocity

(km/s).

.tarWavelength real r-x Target

effective

wavelength

(microns).

.encCosys string r-x Enclosure

frame.

.encMode string r-x slaved |

unslaved

Enclosure

slaving mode.

.encTheta1 string r-x Enclosure

target position

(HPX).

.encTheta2 string r-x Enclosure

target position

(HPY).

.encUpdateTheta1 string r-x Enclosure

target update.

Used by sollib

.encUpdateTheta2 string r-x Enclosure

target update.

Used by sollib

.rotPa real r-x Rotator

position angle

(degrees).

.rotCosys string r-x AZEL |

GAPPT |

APPT | FK4

| FK5 | ICRS

Rotator frame.

.rotEqx string r-x Rotator

equinox.

.tarOffSetIndex integer r-x 0 – 1 Index of offset

(0=manual,

1=handset).

.tarOffSetTheta1 real r-x Offset in RA



(arcsec).

.tarOffSetTheta2 real r-x Offset in Dec

(arcsec).

.tarOffSetType string r-x simple |

tplane

Offset type

(simple or

tplane).

.tarOffClrIndex integer r-x 0 – 2 Index of offset

to clear

(0=manual,

1=handset,

2=both).

.tarOffAbsIndex integer r-x 0 – 1 Index of offset

to absorb

(0=manual,

1=handset).

.rotOffset real r-x Rotator offset

(degrees).

.rotOffClr boolean r-x Rotator offset

clear.

.tarDiffRa real r-x Differential

track rate in

RA. (s/s)

.tarDiffDec real r-x Differential

track rate in

Dec. (arcsec/s)

.tarDiffT0 real r-x Reference

epoch for

differential

track rate.

.encDiffRa real r-x Enclosure

differential

track rate in

RA.(s/s)

.encDiffDec real r-x Enclosure

differential

track rate in

Dec. (arcsec/s)

.encDiffT0 real r-x Enclosure

reference

epoch for

differential

track rate.

.guideIndex string r-x handset | Collimation



manual index of offset

.guideGa real r-x Offset in

azimuth

(arcsec).

.guideGb real r-x Offset in

altitude

(arcsec).

.guideClrIndex string r-x handset |

manual

Collimation

index of offset

to clear

.poOrigin real r-x Pointing origin

array [x, y]

(mm).

.poOffsetIndex string r-x handset |

manual

Pointing origin

index of offset

(0=manual,

1=handset).

.poOffset real r-x Pointing origin

offset array [x,

y] (mm).

.poOffsetClrIndex string r-x handset |

manual

Pointing origin

index of offset

to clear

(0=manual,

1=handset).

.poOffsetAbsIndex integer r-x handset |

manual

Pointing origin

index of offset

to absorb to

base

(0=manual,

1=handset).

.metTemperature real r-x Temperature

(degrees C).

.metPressure real r-x Pressure (hPa).

.metHumidity real r-x Humidity.

.pointNew string r-x Location of

pointing test

file (or blank

for auto-

generated

name).

.pointAdd boolean r-x Add a new

point to the

current



pointing test.

.sessionFit string --x Fit the session

data set.

.trackId string r-x New track ID

of TCS

demand event.

.fastLog bool r-x false Log fast loop

data to fast.log

.mcsCoverEventTimeout integer rw- 2000 Timeout (ms)

for receipt of

mcs cover

cStatus event

.ecsCoverEventTimeout integer rw- 2000 Timeout (ms)

for receipt of

ecs cover

cStatus event

.zenithBlindSpot real r-x 89.5 Altitude of

zenith blind

spot (degrees)

.limits:message string r-- Message

describing

limits

.limits:status string r-- Limits status

message

.limits:times integer r-- Array of limit

times (mins)

for minEnter,

minExit,

maxEnter,

maxExit

.limits:inZenith boolean r-- True if within

zenith blind

spot

.limits:altitudeClipped boolean r-- True if target

below altitude

lower limit

.limits:innerRadius real rw- 1.5 Inner radius of

forbidden zone

(R solar)

.limits:outerRadius real rw- 25.0 Outer radius of

forbidden zone

(deg)

.horizonChecking string r-x on | off on Whether to



reject demands

below horizon

.rotl integer rwx 4 Rotator

location.

.fl real rwx 52330.0 Telescope focal

length at GOS

(mm).

.gim1z real rwx 0.0 Euler angle wrt

terrestrial

[Az,El] for

generalized

gimbal case.

1st rotation,

about z-axis.

.gim2y real rwx 0.0 Euler angle wrt

terrestrial

[Az,El] for

generalized

gimbal case.

2nd

rotation,

about y-axis.

.gim3x real rwx 0.0 Euler angle wrt

terrestrial

[Az,El] for

generalized

gimbal case.

3rd

rotation,

about x-axis.

.rnogo real rwx 0.25 Radius of

zenith

avoidance

region used in

PK calculations

(degrees).

.model integer rwx Term numbers

for the current

model (0 is the

end).

.xpm real rwx 0.0 Polar-motion x

angle (arcsecs).

.ypm real rwx 0.0 Polar-motion y

angle (arcsecs).

.mount integer rwx 2 Mount type.

.delut real rwx 0.0 Current UT1-

UTC. (s)



.delat real rwx 36.0 Current TAI-

UTC (secs)

.ttmtai real rwx 0.0003725 Current TT-

TAI (days)

.temp real rwx 276.0 Ambient

temperature

(degrees K).

.press real rwx 700.0 Pressure (hPa).

.humid real rwx 0.1 Relative

humidity.

.wavelr real rwx 0.5 Reference

wavelength

(microns).

.mCosys integer rwx 4 Mount frame

type.

.mEqx real rwx 2000.0 Mount frame

equinox (years)

.mWavel real rwx 1.0 Mount frame

wavelength.

.rCosys integer rwx 4 Rotator

orientation

frame type.

.rEqx real rwx 2000.0 Rotator

orientation

frame equinox.

.rWavel real rwx 1.0 Rotator

orientation

frame

wavelength

(microns)

.roll real rwx 0.0 Demand mount

roll (radians,

righthanded).

.pitch real rwx 1.0 Demand mount

pitch (radians).

.jbp integer rwx 0 TRUE (1) =

below the pole.

.last real r-- LAST (rads)

.pt:file string rwx No file Current

pointing test

file name.



.pt:qty integer rwx 0 Current

pointing test

star qty.

.point:session real r-- 0.0, 0.0, 0.0, 0.0, 0.0, 0.0 Current session

values (IA,

Sigma IA, CA,

Sigma CA, IE,

Sigma IE).

.point:session:stardata string r-- Current session

star data.

.point:standard:terms real r-- Current values

for IA, IE and

CA in

arcseconds.

.config:mode string rwx operational,

test, ephem

operational The pointing

kernel mode

(operational,

test, ephem).

.config:type string rwx full | simple full The kernel type

.config:slowRate integer rwx 1000 Time delay

between each

medium loop

update (ms).

.config:fastRate integer rwx 50 Time delay

between each

fast loop

update (ms).

.config:dataRate integer rwx 4 Number of fast

loop iterations

between data

context posts.

.config:eventChannel string rwx atst.tcs.tpk.demands Name of the

event channel

to post the raw

data out to.

.config:pacEventChannel string rwx atst.tcs.pacTrajectory Name of the

event channel

to post the

PA&C data out

to.

.config:dataChannel string rwx atst.tcs.tpk.pk.data Name of the

event channel

to post the data

context out to.



.config:fitsChannel string rwx atst.tcs.tpk.pk.celestialFITS Name of the

event channel

to post FITS

data.

.config:wcsChannel string rwx atst.tcs.pk.agvt.WcsContext Name of the

event channel

to post WCS

data.

.config:dataItems string rwx horizonChecking, mTarT0,

last, last_ST, time:utc_ST,

mEqx, mTarName,

mTarP0, mTarP0_ST,

mTarOp0, mTarOp0_ST,

mTarP, mTarP_ST,

mTarAzEl_ST, tai, roll,

pitch, rota,mCosys_ST,

mTarDt_AS, mTarOb_AS,

mTarUnits, guide:manual,

guide:handset,

guide:guider, guide:total,

offsets:manual,

offsets:handset,

offsets:wccs, offsets:total,

pOrigin:base,

pOrigin:handset,

pOrigin:manual,

pOrigin:total,

target:tai_MJD,

target:azimuth_DEG,

target:elevation_DEG,

demands:rotator,

demands:rotator_ST,

enc:target:dmdAzEl_ST,

enc:mode,

current:azimuth_DEG,

current:elevation_DEG,

current:azimuth_ST,

current:elevation_ST,

current:ra_ST,

current:dec_ST,

current:ra_DEG,

current:dec_DEG,

current:rotator_DEG,

current:rotator_ST,

enc:target:dmdRaDec_ST,

enc:current:azimuth_ST,

enc:current:elevation_ST,

enc:current:ra_ST,

enc:current:dec_ST,

demands:azimuth_ST,

Status items to

post out.



demands:carousel_ST,

demands:rotator:pa_DEG,

demands:rotator:iaa_DEG,

pt:file, pt:qty,

point:session,

point:session:stardata,

point:standard:terms,

limits:message,

limits:status, limits:times,

limits:inZenith,

limits:altitudeClipped,

sun:aboveHorizon,

sun:azimuth_DEG,

sun:elevation_DEG,

sun:horizonLimit,

sun:angularSeparation,

sun:separationStatus,

sun:insideAnnulus,

sun:inAnnulus,

sun:outsideAnnulus,

sun:innerRadius_R,

sun:outerRadius,

sun:horizonStatus,

sun:horizonLimit,

sun:aboveLowerLimit,

sun:lowerLimitStatus

.model:raw:names string rwx IA, IE, TF, CA, NPAE,

AW, AN

Raw pointing

model term

names.

.model:raw:values real rwx 0.0, 0.0, 0.0, 0.0, 0.0, 0.0,

0.0

Raw pointing

model term

values

(arcsecs)

.model:std:names string rwx IA, IE, TF, CA, NPAE,

AW, AN

Standard

pointing model

term names.

.model:std:values real rwx 25.0, 15.0, 10.0, -110.0,

8.0, -5.0, -12.0

Standard

pointing model

term values

(arcsecs)

.model:prime:names string rwx IA, IE, TF, CA, NPAE,

AW, AN

Prime pointing

model term

names.

.model:prime:values real rwx 0.0, 0.0, 0.0, 0.0, 0.0, 0.0,

0.0

Prime pointing

model term

values

(arcsecs)



.model:selected string rwx std Selected

pointing model

terms.

.starCatalogue string rwx Name of star

catalogue file

to load.

.ephemFile string rwx resources/tcs/de421.bsp Location of

JPL ephemeris

kernel file for

planet target

positions.

Figure 12. Properties for the atst.tcs.tpk.pk controller.

The atst.tcs.tpk.pk controller also accesses the following variables from the constants service

Name Value Description

height 3055.0 Site elevation above sea-level (m)

latitude 20.7070833 Site mean geodetic latitude (degrees)

longitude -156.2576111 Site mean east longitude (degrees)

Table 2 Items accessed from constants service

Controller atst.tcs.tpk.tpoint:



number of

simultaneous

actions.


simultaneous

actions.


pool is managed.

.start string r-x Start the tpoint

fitting library.

.stop string r-x Stop the tpoint

fitting library.

.file string r-x Set the current

data file.

.command string r-x Issue a command

to tpoint.

Figure 13. Properties for the atst.tcs.tpk.tpoint controller



The information provided in the table above is also delivered with the TCS application in the form of a set

of CSV formatted files in $ATST/admin/tcs/prop. These files can be considered the controller

configuration factory defaults used in section 4.4. However, it is not necessary to run the TCS using the

controller configuration data provided here, and some properties are expected to be changed over time.

These properties serve as a starting point for the configuration of the TCS controllers.

As with the application configuration files, these CSV files should not be loaded directly into the property

database as they contain substitution symbols used by pkgDevel. As part of the command

pkgDevel –make-all tcs

a set of .prop files with substitutions made is created in $ATST/admin/tcs/prop.

4.4 FACTORY DEFAULT RESET

To perform a factory default reset of the TCS software the files discussed in sections 4.2 and 4.3 are

required.

$ATST/admin/tcs/app/tcsApp.csv

$ATST/admin/tcs/prop/atst_tcs.csv

$ATST/admin/tcs/prop/atst_tcs_environment.csv

$ATST/admin/tcs/prop/atst_tcs_guide.csv

$ATST/admin/tcs/prop/atst_tcs_seq.csv

$ATST/admin/tcs/prop/atst_tcs_thermal.csv

$ATST/admin/tcs/prop/atst_tcs_time.csv

$ATST/admin/tcs/prop/atst_tcs_time_iers.csv

$ATST/admin/tcs/prop/atst_tcs_tpk.csv

$ATST/admin/tcs/prop/atst_tcs_tpk_sollib.csv

$ATST/admin/tcs/prop/atst_tcs_tpk_pk.csv

$ATST/admin/tcs/prop/atst_tcs_tpk_tpoint.csv

The data contained in these files replaces any values present in the application table and property table of

the property database. The files can be reloaded with pkgDevel or individually with the AppReader and

PropertyReader applications which are provided as part of the CSF infrastructure. Note hat the

AppReader or PropertyReader applications can only be used if previously pkgDevel has been run with the

–make-all, -- load-prop or-- load-app options. If this is not done then substitution symbols may still be

present in the .csv files

To reload the factory defaults using pkgDevel

$(ATST)/admin/pkgDevel –load-app tcs

$(ATST)/admin/pkgDevel –load-prop tcs

With the caveats of the previous paragraph, to reload the application and property files using AppReader

and PropertyReader

cd $(ATST)/admin/tcs

$(ATST)/bin/AppReader < tcs.app

cd $(ATST)/admin/tcs/prop

$(ATST)/bin/PropertyReader < atst_tcs.prop

$(ATST)/bin/PropertyReader < atst_tcs_environment.prop

$(ATST)/bin/PropertyReader < atst_tcs_guide.prop

$(ATST)/bin/PropertyReader < atst_tcs_seq.prop



$(ATST)/bin/PropertyReader < atst_tcs_thermal.prop

$(ATST)/bin/PropertyReader < atst_tcs_time.prop

$(ATST)/bin/PropertyReader < atst_tcs_time_iers.prop

$(ATST)/bin/PropertyReader < atst_tcs_tpk.prop

$(ATST)/bin/PropertyReader < atst_tcs_tpk_sollib.prop

$(ATST)/bin/PropertyReader < atst_tcs_tpk_pk.prop

$(ATST)/bin/PropertyReader < atst_tcs_tpk_tpoint.prop

This will reset the TCS application to its original state. It is important that the CSV files should never be

altered as they will always provide a way of returning the TCS application to a known working state. If

new files are desired then copies of the originals should be made before making alterations.

The factory default reset CSV files for the TCS supplied simulators can be found in

$ATST/admin/tcs/sim/app and $ATST/admin/tcs/sim/prop. The same caveats apply to these files as to

those for the TCS: the files should not be loaded directly until processed by pkgDevel as they may

contain substitution symbols. Once pkgDevel has been run then a file sim.app is placed in

$ATST/admin/tcs and .prop files are placed in $ATST/admin/tcs/sim/prop. Note that these files only

contain the properties for the simulators that have been configured in the tcsSite.config file



5. RUNNING THE TCS

5.1 STARTUP SCRIPT

Part of the pkgDevel process is to produce startup and shutdown scripts that are installed in $ATST/bin.

To start the TCS

cd $ATST/bin

./tcsUp

If any internal simulators have been configured then start these by

./osl-simsUp

The simulators can be started either before or after the TCS.

The engineering screens are started by

./tcsGui

./osl-simsGui

The TCS and its simulators are shutdown as follows

./tcsDown

./osl-simsDown

5.2 TCS MAIN CONTROLLERS

The TCS application consists of seven controllers grouped into four sets with each group managed by a

management controller. Each group is responsible for one area of the TCS, and the management

controllers are listed in the sections below along with a brief description of the responsibilities of that

group.

5.2.1 atst.tcs

This provides the main external interface to the TCS application. All configurations submitted to the TCS

application are submitted to the “atst.tcs” management controller. All configurations destined for the

subsystems of the TCS are submitted to the same “atst.tcs” controller. Its main task is to filter all

attributes; forward any destined for subsystems to the corresponding controllers, and create any new

configurations required for the internal controllers of the TCS application as a result of the received

configurations.

5.2.2 atst.tcs.tpk

The pointing kernel lies at the heart of the TCS application. The pointing kernel consists of three

controllers, one for the solar pointing calculations, one for the pointing kernel main calculations and data

context, and finally the management controller “atst.tcs.tpk” in charge of distributing the relevant

configurations to the pointing kernel controllers. Any solar target configurations are routed to the solar

pointing controller. Normal target, offset, wavelength, differential track rate and pointing origin

configurations are directed to the pointing kernel controller, as are any pointing model related

configurations.



5.2.3 atst.tcs.time

The two time controllers are not required to interface to the time card present on the TCS machine as the

CSF will provide the interface as a service. Therefore the only task required from the time controllers is

to query the current IERS data when requested to do so and to supply this information to the pointing

kernel. The OCS will request this automatically as part of startup but the query can be requested at any

time by submitting the relevant attribute to the “atst.tcs.time” controller.

5.2.4 atst.tcs.environment

The main responsibility of the environment group of controllers is to interact with the weather server to

obtain the latest meteorological data. The data is sent automatically when available but this group also

provides the option of an operator manually overriding this data and setting parameters by submitting

configurations to the “atst.tcs.environment”.

5.3 ACCEPTED ATTRIBUTES

This section details all of the attributes that the TCS application accepts. While attributes can be grouped

together and submitted in a single configuration, there are specific groups of attributes that cannot be sent

together as they would conflict with each other. These conflicting attributes are listed in section 5.3.2.

There is only one controller that attributes should be submitted to, as all other controllers receive their

configurations from other TCS controllers.

The main TCS application controller is the “atst.tcs” controller. All configurations destined for the main

TCS application should be submitted to this controller. It is a management controller and thus can re-

route attributes that are destined for other controllers.

5.3.1 atst.tcs

In the tables below the attributes have been grouped to make them easier to locate. For full descriptions

of each attribute see the OCS to TCS ICD [3].

MODES AND STATES

Name Type Units Range Comment

atst.tcs.

.mode string choice off | active |

tracking

Overall telescope mode

.thermalMode string choice off |

precondition |

active

Overall thermal mode

.obsMode string choice acquire |

setup | polcal

| telcal |

wavecal |

gain | dark |

focus | align |

target |

observe |

aoCalibrate

Observational mode



.aoMode string choice off |

aoCalibrate |

idle |

limbTracking

|open | closed

.namedPos string choice stow | index Figure 14. Mode and state attributes.

TARGET ATTRIBUTES The following attributes control relate to the target that the TCS should track


atst.tcs.

.frame string choice HG | HC |

HP | HPR |

ICRS |

FK5 | FK4

|APPT |

GAPPT |

AZEL

Target coordinate reference system

.targetname string A name for the target. This is just a label,

the TCS does not cache targets.

.target array varies Coordinates for target

.equinox string Epoch of mean equator and equinox

.epoch float year The zero point for proper motion

.properMotion string[2] Proper motion in RA and dec.

.parallax float arcsecs Parallax

.rv float km/s Radial velocity

.wavelength integer microns Effective wavelength

.targetOffset array varies Target offset

.targetOffsetIndex int none 0 | 1 Whether these are user or handset offsets

.absorbTargetOffsets int none 0 - 2

.clearTargetOffsets int none 0 - 2

.trackRate array varies Telescope tracking rate

.trackRatet0 string choice 0 | MJD |

UTC

Reference epoch for tracking

.trackRateIndex int 1 - 3 Defines which rate property to use for

motion rate offset actions. There are three

properties available, and each can be

configured using a set call on the atst.tcs

controller.

.trackRateDirection string positive |

negative |

stop

Positive increases the current target by the

rate selected above. Negative decreases the

current target by the rate selected above.

Stop stops the current target where it is, and

does not reset it.

.trackRateAxis int 0 - 2 The selected axis to apply motion rate

offsets to. The axis is dependent on the

current frame (for example if in HP then

axis 0 is HP x, 1 is HP y and 2 is Coudé).



Figure 15. Target attributes.

POINTING ATTRIBUTES The following attributes control the pointing of the telescope:

Axis 2 is always the Coudé axis.

.solarDiffRotate string choice None |

Standard|

Custom

Solar differential rotation model

.solarDiffRotParams float[3] Deg/day Custom rotation model parameters

.ecsTargetName string choice Sun |

Mountbase

.ecsTarget float[2] -2.0 .. 2.0

.instOrigin array mm Instrument position of target

.instOriginOffsetIndex int none 0 | 1 Index of instrument origin offset

.instOriginOffset array varies Instrument origin offset

.absorbInstOrigin int 0 - 2 Absorb offsets into base

.clearInstOrigin int 0 - 2 Clear offsets from base

.ipa float degrees Instrument position angle

.ipaframe string choice Coordinate system for ipa

.iaa float degrees Instrument alignment angle

.horizonChecking string choice On | Off Reject demands below horizon

.wrap integer choice -1 | 0 | 1 Preferred wrap for the mount

.rotWrap integer choice -1 | 0 | 1 Preferred wrap for the rotator

.planet string choice mercury |

venus |

mars |

jupiter |

saturn |

uranus |

neptune |

pluto |

moon

Track the named "planet"

.elementsType string choice JPL | MPC

| Internal

Type of elements to follow

.elementsForm string choice Major

planets |

Minor

planets |

Comets

Form of elements

.elementsEpoch float MJD Epoch on the TT timescale

.elementsInclination float degrees Orbital inclination

.elementsANode float degrees Longitude of ascending node

.elementsPerihelion float degrees Longitude of perihelion

.elementsAorQ float AU Mean distance

.elementsEccentricity float Orbital eccentricity

.elementsAorL float degrees Mean longitude

.elementsDailyMotion float deg/day Daily motion




Figure 16. Pointing attributes.

SCANS The TCS implements a number of predefined target scan patterns controlled by the following attributes:

Figure 17. Scan attributes.

Scan patterns are centered on the current target position.

MISCELLANEOUS The attributes described here are those that don’t fall into any particular category.

Figure 18. Miscellaneous attributes.

5.3.2 Conflicting Attributes

The following tables layout combinations of attributes that are rejected if submitted in the same

configuration or if not all present within a configuration, with an explanation of why they are rejected.

atst.tcs.

.colloffset float[] arcsecs Collimation offsets

.clearcolloffset Clear collimation offsets

.pointNew string Open a new pointing data file

.pointAdd Add a new data point to the pointing file

.sessionFit string Start a new session fit using a data set

.sessionMask integer[] Mask out any unwanted data items

.sessionUseIA boolean Fit the session data including the IA term

.sessionAction string choice use | revert Either use the session data in the current

pointing or revert to the original pointing

model

.guide string choice on | off

.clearGuide boolean Zero any guiding corrections

.guideGain float None Gain correction applied to guide signals

.offset string choice on | off

.clearOffset boolean Zero any offset corrections

.offsetGain float None Gain correction applied to offset signals


atst.tcs

.scanType string choice none | random

| raster | spiral

.scanParms array varies


atst.tcs

.iersUpdate Fetch IERS parameters

.wsMode string choice Manual |

Automatic

How weather station data is accessed

.wsTemperature float deg C Weather station temperature

.wsPressure float mbars Weather station pressure

.wsHumidity float % Weather station humidity



Attributes Conflict

.mode If the mode is set to “tracking” or “off” then a named position cannot be

submitted with the mode attribute. .namedPos

Attributes Conflict

.frame If the frame attribute is present then the target attribute must also be

present and vice versa. If any of the equinox, epoch, properMotion,

parallax or rv attributes are present then the target (and hence the frame)

attribute must also be present.

.target

.equinox

.epoch

.properMotion

.parallax

.rv

Attributes Conflict

.targetOffset The three attributes targetOffset, targetOffsetIndex and targetOffsetType

must always all be present in a configuration that contains any one of

them. Only one of targetOffset, absorbTargetOffsets and

clearTargetOffsets should be present in any one configuration.

.targetOffsetIndex

.targetOffsetType

.absorbTargetOffsets

.clearTargetOffsets

Attributes Conflict

.instOriginOffset The two attributes instOriginOffset and instOriginOffsetIndex must

always both be present in a configuration that contains any one of them.

Only one of instOriginOffset, absorbInstOrigin and clearInstOrigin

should be present in any one configuration.

.instOriginOffsetIndex

.absorbInstOrigin

.clearInstOrigin

Attributes Conflict

.ecsTarget If the target name is set to “mountbase” then a target attribute cannot be

present in the same configuration. .ecsTargetName

Attributes Conflict

.scanType If scanType is present in a configuration then the only other allowed

attribute is scanParams. Any other attributes present will result in

rejection. .scanParams

Attributes Conflict

.sessionFit If sessionFit is present in a configuration then the only other allowed



5.4 EVENTS POSTED

The TCS publishes the following events of interest to the OCS:

Figure 19. Event channels.

5.4.1 atst.tcs.cStatus This event notifies the OCS of any change in the status of the TCS or any of its subsystems. The event is

generated at a rate of 1 Hz and includes all listed attributes. The following attributes are posted in the

event.

Name Type Units Comment

.mode string Current mode of the TCS.

.inPosition boolean In position flag. Figure 20. cStatus attributes.

.sessionUseIA attributes are sessionUseIA and sessionMask. Any other attributes

present will result in rejection. .sessionMask

Attributes Conflict

.planet If planet is present then target parameters or orbital element parameters

must not be present

Attributes Conflict

.elementsType If any of the element attributes are present then they must all be present.

Configurations that do not contain them all will be rejected.

Configurations containing elements plus target or planet attributes will be

rejected.

.elementsForm

.elementsEpoch

.elementsInclination

.elementsANode

.elementsPerihelion

.elementsAorQ

.elementsEccentricity

.elementsAorL

.elementsDailyMotion

Name Rate Comment

atst.tcs.cStatus 1 Hz TCS mechanisms are in the correct position

atst.tcs.cPos 5 Hz Position status from the TCS.

atst.tcs.mcsTrajectory 20 Hz Azimuth, altitude and Coude demands

atst.tcs.ecsTrajectory 20 Hz Azimuth and altitude demands

atst.tcs.pk.agvt.WcsContent 20 Hz World coordinate system parameter array

atst.tcs.pacTrajectory 20 Hz Occulter radius and angle demands

atst.tcs.timesToLimits 1 Hz Times to limits



The current mode (.mode) is one of the following: off, tracking, or active as last set by the atst.tcs.mode

attribute.

The inPosition attribute reports whether all TCS subsystems are in the correct position and within

tolerances. The TCS is in position only if all its subsystems are in position.

5.4.2 atst.tcs.cPos This event provides the position status of the TCS (demand and current). It includes the additional

parameters that can affect the target position. The event is generated at a rate of 5 Hz and includes all

listed attributes. The following attributes are posted in the event.


.cCollimation:handset float[2] arcsec Current collimation corrections from

software handset.

.cCollimation:manual float[2] arcsec Current manually applied collimation

corrections.

.cCollimation:total float[2] arcsec Current total collimation corrections

applied to target.

.cOffsets:handset float[2] arcsec Current offsets from software handset.

.cOffsets:manual float[2] arcsec Current manually applied offsets.

.cOffsets:total float[2] arcsec Current total offsets applied to target.

.cPorigin:base float[2] mm Current base pointing origin.

.cPorigin:manual float[2] mm Current manually applied pointing origin.

.cPorigin:handset float[2] mm Current pointing origin from software

handset.

.cPorigin:total float[2] mm Current total pointing origin applied to

target.

.cTarget:dmd:base:ra string hours Current base demand RA.

.cTarget:dmd:base:dec string degrees Current base demand Dec.

.cTarget:dmd:hc:x float R○ Demand heliocentric x coordinate.

.cTarget:dmd:hc:y float R○ Demand heliocentric y coordinate.

.cTarget:dmd:hc:z float R○ Demand heliocentric z coordinate.

.cTarget:dmd:hct:x float R○ Demand Thompson heliocentric x

coordinate.

.cTarget:dmd:hct:y float R○ Demand Thompson heliocentric y

coordinate.

.cTarget:dmd:hct:z float R○ Demand Thompson heliocentric z

coordinate.

.cTarget:dmd:hg:theta string degrees Demand heliographic latitude.

.cTarget:dmd:hg:phi string degrees Demand heliographic longitude.

.cTarget:dmd:hg:r string R○ Demand heliographic radius

.cTarget:dmd:hp:x float arcsecs Demand helioprojective x

.cTarget:dmd:hp:y float arcsecs Demand helioprojective y

.cTarget:dmd:hpr:psi string degrees Demand helioprojective radial angle.

.cTarget:dmd:hpr:rho float Demand helioprojective radial radius.

.cTarget:dmd:iaa float degrees Demand instrument alignment angle

(rotator offset).

.cTarget:dmd:ipaFrame string Frame of the coude rotator

.cTarget:dmd:pa float degrees Demand position angle.



.cTarget:dmd:rma string degrees Demand rotator mechanical angle.

.cTarget:dmd:total:ra string hours Current total demand RA.

.cTarget:dmd:total:dec string degrees Current total demand Dec.

.cTarget:pos:ra string hours Current mount position (calculated RA).

.cTarget:pos:dec string degrees Current mount position (calculated Dec).

.cTarget:pos:apptPA float degrees Position angle in topocentric apparent

cords.

.cTarget:pos:rma string degrees Current rotator mechanical angle.

.cTarget:pos:hc:x float R○ Current Heliocentric X

.cTarget:pos:hc:y float R○ Current Heliocentric Y

.cTarget:pos:hc:z float R○ Current Heliocentric Z

.cTarget:pos:hct:x float R○ Current Thompson Heliocentric X

.cTarget:pos:hct:y float R○ Current Thompson Heliocentric Y

.cTarget:pos:hct:z float R○ Current Thompson Heliocentric Z

.cTarget:pos:hg:phi string degrees Current Carrington Heliographic longitude

.cTarget:pos:hg:r float R○ Current Heliographic radius

.cTarget:pos:hg:theta string degrees Current Carrington Heliographic latitude

.cTarget:pos:hgs:phi string degrees Current Stonyhurst Heliographic longitude

.cTarget:pos:hgs:theta string degrees Current Stonyhurst Heliographic latitude

.cTarget:pos:hp:x float arcsecs Current Helioprojective X

.cTarget:pos:hp:y float arcsecs Current Helioprojective Y

.cTarget:pos:hpr:psi string degrees Current Helioprojective radial angle

.cTarget:pos:hpr:rho float R○ Current Helioprojective radial radius

.cTarget:pos:paCurrent float degrees Current position angle

.cTarget:pos:paDemand float degrees Demand position angle

.cTarget:pos:paFrame string Frame of position angle

.cTargt:pos:visible boolean True if target is visible i.e. not occulted

.cTrackRate float[2] arcsec/s Current differential track rate applied to the

target.

.ephem:B0 float degrees Latitude of solar center

.ephem:L0 float degrees Longitude of solar center

.ephem:P float degrees Position angle of SNP

.ephem:diameter float arcmin Angular diameter of sun

.ephem:distance float AU Distance to target

.inPosition bool True if in position Figure 21. cPos attributes.

The .cTarget:dmd attributes are the current demand positions generated by the TCS and posted out as

trajectory streams for the TMA and ECS. The demand positions are provided in FK5, HP, HG, HPR.

HCT and HC frames.

The .cTarget:pos attributes are the upstream calculations of the current positions as provided by the

TMA. The current positions are provided in FK5, HP, HC, HCT, HPR and HG frames.

The .cOffsets attributes reflect any offsets that have been applied to the base position. They are provided

in units of arcseconds.

The .cCollimation attributes reflect any collimation corrections that have been made to the telescope.

They are provided in units of arcseconds.



The .cPorigin attributes reflect any pointing origin corrections that have been made to the target image on

the detector. They are provided in units of mm.

5.4.3 atst.tcs.mcsTrajectory This event provides the stream of demands required for driving the mount to the target position. The

event is generated at a rate of 20 Hz and includes all listed attributes. The following attributes are posted

in the event.


.trackId float Generated ID for current demand stream.

.tRef float[3] TAI Reference time for demand stream.

.azCoeff float[3] Azimuth coefficients for demand stream.

.altCoeff float[3] Altitude coefficients for demand stream.

.coudeCoeff float[3] Coude coefficients for demand stream. Figure 22. mcsTrajectory attributes.

The TCS generates a continuous stream of azimuth, altitude and coudé demands for the TMA. The mount

azimuth, mount altitude, and coudé azimuth controllers shall track these demands when the mode attribute

is set to tracking, otherwise the demands are ignored. The TCS encodes these demands in the form of an

interpolating polynomial.

𝑝𝑛(𝑡) = ∑ 𝑎𝑘

𝑛

𝑖=0

∏(𝑡 − 𝑡𝑗)

𝑖−1

𝑗=0

To efficiently evaluate the position demand at any time t, the following steps are performed

Set bk = ak

For i = k-1,…0, do:

Set bi = ai + (t – ti+1)/bi+1

p(t) = b0

The TCS provides a 2nd

order polynomial so n equals 2 and the units are such that the resultant demand is

in degrees.

The trackId changes when the telescope moves to a new target position. The TMA shall interpret a

change in track ID as an offset request and move efficiently to the new track as specified by the

coefficients.

The event contains the following attributes:

trackId(string)—the identifier of the track that the TMA is to follow,

tRef[3](float) – the times (TAI) at which the interpolating coefficients were evaluated,

azCoeff[3](float)—the azimuth coefficients,

altCoeff[3](float)—the altitude coefficients,

coudeCoeff[3](float)—the coudé coefficients.



5.4.4 atst.tcs.ecsTrajectory This event provides the stream of demands required for driving the enclosure to the target position. The

event is generated at a rate of 20 Hz and includes all listed attributes. The following attributes are posted

in the event.




.azCoeff float[3] Azimuth coefficients for demand stream.

.altCoeff float[3] Altitude coefficients for demand stream. Figure 23. ecsTrajectory attributes.

The TCS generates a continuous stream of azimuth and altitude demands for the enclosure. The enclosure

azimuth and altitude controllers shall track these demands when the mode attribute is set to tracking,

otherwise the demands are ignored. The TCS encodes these demands in the form of an interpolating

polynomial in the same way as it does for the mount

The trackId changes when the telescope moves to a new target position. The ECS shall interpret a change

in track ID as an offset request and move efficiently to the new track as specified by the coefficients.

The event contains the following attributes:

trackId(string)—the identifier of the track that the enclosure is to follow,


azCoeff[3](float)—the azimuth coefficients,

altCoeff[3](float)—the altitude coefficients

5.4.5 atst.tcs.pk.agvt.WcsContent This event provides the conversion factors for focal plane x, y into topocentric apparent and FK5 RA and

Declination. The event is generated at a rate of 20 Hz and includes all listed attributes. The following

attributes are posted in the event.


.tai float TAI MJD timestamp for data.

.hpxy float[2] arcsecs Helioprojective x, y of reference position

.theta float[2] radians Reference position of (0, 0).

.thetaFK5 float[2] radians FK5 reference position of (0, 0).

.wcsArray float[6] Linear transform coefficients.

.wcsArrayFK5 float[6] Linear transform coefficients. Figure 24. wcsContent attributes.

This event provides the data for a subscriber to convert focal plane x, y into topocentric apparent RA and

Declination. The data provided is as follows

tai – a TAI expressed as a Modified Julian Date. This is the instant for which the WCS information was

computed

hpxy[2] – the helioprojective x, y of the point corresponding to x = 0, y = 0



theta[2] – the topocentric apparent reference position (rads) of the point corresponding to x = 0, y = 0.

thetaFK5[2] – the FK5 reference position (rads) of the point corresponding to x = 0, y = 0.

wcsArray[6] – the array of linear transformation coefficients that convert from TCS x, y to RA and

Declination standard coordinates ξ, η.

wcsArrayFK5[6] – the array of linear transformation coefficients that convert from TCS x, y to FK5 RA

and Declination standard coordinates ξ, η.

5.4.6 atst.tcs.pac.gosTrajectory

N.B. The name of this event is specified in the TCS/PA&C ICD but does not follow the correct naming

convention. It should be atst.tcs.gosTrajectory.

This event provides the PA&C with required data for its occulter. The event is generated at a rate of 20

Hz and includes all listed attributes. The following attributes are posted in the event.



.timestamp AtstDate TAI Atst date string

.hprRadius float Helioprojective radial radius.

.hprAngle float degrees Helioprojective radial angle + 90 degrees.


.occulterCoeff float[3] HP angle coefficients for demand stream. Figure 25. pacTrajectory attributes.

The TCS is responsible for publishing an event that provides the information the PA&C needs to support

continuous rotation of the occulter that follows the angular trajectory of the solar image.

The trackId changes when the telescope moves to a new target position. The PA&C shall interpret a

change in track ID as an offset request and move efficiently to the new track as specified by the

coefficients.

The timestamp is a DKIST date string for the TAI time that the position is valid.

hprRadius – the helioprojective radial distance

hprAngle – the helioprojective angle. This value is the same as occulterCoeff[2]. It is retained for

compatibility with an earlier version of the interface.


occulterCoeff[3](float)—the occulter angular coefficients,

5.4.7 atst.tcs.timesToLimits This event contains the time to limit data generated by the TCS. The event is generated at a rate of 1 Hz

and includes all listed attributes. The following attributes are posted in the event.




.azimuth float minutes Time to azimuth limit.

.rotator float minutes Time to rotator limit.

.elevation float minutes Time to elevation limit.

.enterZenith float minutes Time until zenith limit entered.

.exitZenith float minutes Time until zenith limit exited.

.inZenith boolean Currently in zenith limit.

.altitudeClipped boolean Altitude clipping is taking place. Figure 26. timesToLimits attributes.

The attributes here are the times to reach the specified limits in minutes. These times are rounded to the

nearest minute. The values are negative if the limit is not relevant for the current target. For the azimuth

limit the time given is the earliest of the enclosure and mount azimuth limits.

The “inZenith” flag is set to true whenever the mount is within the zenith blind spot and is false

otherwise.

The “altitudeClipped” flag is true if horizonChecking has been turned off and the resultant demands to the

mount altitude axis are being clipped at the lower altitude limit.

5.5 EPHEMERIS SERVICE (ORACLE)

The ephemeris service is provided as part of the proprietary TCS application. It consists of a single

container, a single controller and an associated JES screen to provide interaction. The ephemeris service

has its own user manual and complete instructions on how to install, run and interact with the service can

be found in the manual (see [14]).

Figure 27 Ephemeris service engineering interface





6. USING THE TCS (ENGINEERING INTERFACE)

6.1 STARTING THE ENGINEERING INTERFACE

The simplest way to start the TCS engineering screens is with the command tcsGui. This will start the

JES application with the appropriate TCS top-level screen. Alternatively the screens can be started

manually as described below.

All engineering screens provided as part of the TCS control system have been designed using the Java

Engineering Screens (JES) application. To start the JES application (which is provided as standard with

the CSF development tree) change directory to the bin directory and execute the script called JES.

cd $(ATST)/bin

./JES

Alternatively the bin directory can be appended to the PATH environment variable and then the JES

application can be executed by simply typing “JES” from any location. When the JES application first

starts the operator is presented with the JES Manager window.

Figure 28. JES Manager Window.

To open a new engineering screen simply click on the “File” menu and select “Open”. A file selector

window opens with the default path set to “$(ATST)/resources/screens”. At this location is a folder

called “tcs”. Open the tcs folder and inside is a file called “TCS_Main.xml”. Double click on this file to

open the main engineering interface for the TCS.



Figure 29. Open file selection window.

Once the main engineering interface screen has been opened all remaining screens can be accessed from

this directly and no further interaction with the JES Manager is required.

6.2 INTERACTING WITH THE ENGINEERING INTERFACE

For full instructions on how to use the JES application for engineering screens see [13].

6.3 AVAILABLE ENGINEERING INTERFACE SCREENS

6.3.1 TCS Main Engineering

The TCS main engineering screen provides the ability to submit all attributes available in the TCS to OCS

ICD from a convenient set of JES widget classes. It also displays the current status of the TCS

application. The screen is shown below.



Figure 30. TCS Main Engineering Screen.

The screen is split into two sections:

1) Across the top is some general information relating to the current state of the TCS. The current

target name is presented at the very top. Below this the current target demands are displayed in

the relevant coordinate system (in the case above, helioprojective) along with the current mount

positions in the same coordinate system. The mount and enclosure individual azimuth and

altitude positions are then displayed along with the Coudé demand. The background of these

positions is green in the figure above showing that the axes are both tracking the target demands

and also are in position. If the axes are tracking a demand stream but are not in position then the

boxes have a yellow background, and if the axes are off then the boxes have a red background.

The top right hand side of the screen presents some general information, including the current

mode of the TCS, the solar semi-diameter (in arc-seconds), the UTC time of the system, the

current wavelength in microns and the current frame of the mount.

2) Below the status area is a set of tabs that provide the means to submit configurations to the TCS

and some additional detailed status items. There are also buttons present that when clicked open

additional control and status screens. The tabs and additional screens are explained in detail

below.



6.3.2 Main Engineering Tabs and Additional Screens

All tabs and additional screens available from the main engineering screen are now presented along with a

description of the attributes that can be submitted from them. A JES widget has been designed to allow

specific attributes to be submitted through an easy to use interface. The widget can be completely

customized for each instance. As well as providing a customized interface the widget provides a

consistent set of actions that are always available, as well as the current state of the most recently

submitted configuration and access to a complete history of all configurations submitted by the widget.

The widget can be considered a general configuration submit widget and the diagram below shows the

widget without any customization.

Figure 31. General configuration submit widget.

The “Submit” button may or may not be present depending on if it is necessary; some instances have

buttons that automatically submit the configuration when clicked. Similarly the “Pause” and “Cancel”

buttons may not be present if they are not supported by the underlying code. The “Cancel”, “Abort” and

“History” buttons are always present. When a new configuration is submitted the ID of the configuration

is displayed in the “Config:” text box. As reports of the configuration’s progress are posted by the CSF

these reports are displayed in the “Report:” text box. The currently executing configuration can be

paused by clicking on the “Pause” button (if pause functionality is supported for the specific

configuration) and resumed by clicking on the “Resume” button. The configuration can be cancelled by

clicking on the “Cancel” button and aborted by clicking on the “Abort” button. Clicking on the history

button opens the history window for that specific configuration widget.



Figure 32. JES configuration history window.

The history window contains a table of all configurations submitted along with a timestamp of when the

configuration was submitted, the current state of the configuration and any corresponding reason

messages (reason for the current state). Right clicking on one of the entries opens a menu that can be

used to pause, resume, cancel or abort the configuration. It can also clear the entry from the history or

open a new window with a full set of details for the configuration. This set of full details contains every

event that was posted for the configuration, including timestamps, states and messages.

Figure 33. JES configuration details window.

When describing the individual widgets in the following sections the information above is assumed to

have been read, it will not be described for each instance of the widget.



6.3.3 TCS Control Tab

Figure 34. TCS control tab.

The TCS control tab provides access to the main attributes of the TCS application in a single location, as

well as the ability to start and stop the application. In the top left corner of the tab there are three lifecycle

widgets, one for each of the main TCS containers (TCS1 is the Java container and TCS2 is the C++

container) and one for the main TCS controller (atst.tcs controller). These widgets display the current

lifecycle state of the containers and controller. Any of the lifecycle states can be changed by right

clicking on the lifecycle widget and selecting the new state. Certain state transitions are forbidden and

will not result in the container/controller changing state. If the state of the main TCS controller is

changed then the state of all TCS controllers will also be changed to match. Using these three widgets the

TCS application can be deployed, initialized, started, shut down, uninitialized and unloaded. During

normal operations the LED indicators on these widgets should be green. Just below the lifecycle widgets

is a “Lifecycle” button. Clicking on this button opens the full lifecycle screen with a widget for every

controller present in the TCS application. This is described in section 6.3.11.

Underneath the “Lifecycle” button is a health indicator for the atst.tcs controller. The health of the atst.tcs

controller does not depend on the health of the TCS sub-controllers, only on them being present within

the system and sending a regular heartbeat message to the atst.tcs controller. Clicking on the health

indicator opens the detailed health screen (see section 6.3.12) which displays the health of all sub-

controllers and the status of their heartbeats.

The bottom left of the tab contains several buttons, each of which opens a screen with control and status

widgets. The buttons are “Solar Disk”, “Target Control”, “Pointing Tests”, “IERS”, “Weather” and

“Offsets”. Each screen is described in the corresponding section 6.3.13, 6.3.14, 6.3.15, 6.3.16, 6.3.17 and

6.3.18.

The rest of the tab is populated with six configuration widgets:



The “Solar Target” widget provides the mechanism for entering a solar target. Four types of solar

coordinates are supported, polar heliographic, Cartesian heliocentric, Cartesian helioprojective and radial

helioprojective.

Heliographic coordinates HG (Θ, Φ, R) are based on the solar equator, with a prime meridian that rotates

relative to the Earth and stars. In a solid body this meridian would be defined by surface features, but in

the case of the Sun it is provided by a conventional ephemeris. The heliographic longitude and latitude of

a sunspot is approximately constant, though its position on the Sun’s disk changes from day to day.

The solar north pole is fixed at α2000 = 286.1300°, δ2000 = +63.8700°

The rotation angle W = 84.10° + 14.1844000° + (days since J2000 TDB)

The radius of the photosphere is 696000000 meters

HG coordinates will likely be the primary method for specifying the solar surface feature that is to be

observed. Conversely, when the position of an object is to be recorded, HG coordinates will be the usual

choice.

If HG coordinates are selected then the panel also allows switching between different models for the

differential solar rotation. The options are “standard”, “none” or “custom”. For further details see Section

6.3.5.

Heliocentric coordinates (HC) are Sun-centered. The orientation of heliocentric coordinates used here are

as defined by Thompson [17]. They could be used when specifying a target in the corona. Values are in

units of a solar radius

Cartesian Helioprojective coordinates (HP) lie in a plane normal to a line from the observer to the center

of the sun. For a given target, the helioprojective coordinates are where the line of sight intersects this

plane. The origin of the system is the center of the sun, the solar North Pole is on the y-axis and the edge

of the photosphere is a circle of radius equal to the solar radius centered on the origin.

Radial Helioprojective coordinates (HPR) are a variation on the Cartesian Helioprojective frame. The

units are ρ and ψ where ρ is the radial distance from the solar center in units of the solar radius i.e. ρ = 1

defines the solar limb. Ψ is the position angle in degrees measured counter clockwise from the projection

of the Solar north pole. The relationship between Cartesian and radial coordinates is

𝜌 = √𝑥2 + 𝑦2

𝜓 = tan−1(−𝑥/𝑦)

To specify a target, select the required frame, enter the target values into the controls and click on the

‘Submit’ button to submit the configuration.

If entering longitude and latitude you can either express the numbers as a sexagesimal number or as a

number of degrees with a fractional part e.g. the longitudes 84 30 20.2 and 84.5056111 would be

equivalent.

Solar targets entered through this panel are by default handled differently from targets entered through the

target command (see section 6.3.14) with regard to azimuth and elevation limits. Normally if a target is

specified that is unobservable then the command will be rejected. For solar targets these limit checks can

be turned off. The command will be accepted even if the sun is not currently visible. The reason for this is

that it is then possible to slew to the sun before it rises above the lower elevation limit of the telescope.



The TCS will clamp the output demands to the drives at the lower elevation limit but track the axes in

azimuth then, as soon as the solar target rises, it will track in elevation as well. The advantage of this is

that the solar target can then be acquired at the earliest moment. This different behavior for solar targets

can be disabled if desired.

Note that entering a target either through this command or the target or planet commands is an instruction

to the TCS to change the constantly updating stream of demands in azimuth, elevation and rotation that

will accurately track the target. Whether the main axes respond to these demands will depend on (a)

whether the axes are powered and datumed and (b) whether the system has been instructed to track that

target. The mode widget described below allows an operator to place the subsystems into tracking mode.

Next to the solar target panel is the enclosure mode configuration panel. The TCS application can track a

separate target for the enclosure if required and this configuration panel provides this capability. If

normal operations are required then select the “Mountbase” option from the drop down menu and click on

submit. This will force the enclosure to follow the same demand stream as the mount. If the “Sun”

option is selected then HP coordinates can be entered for the enclosure and it will track this position

irrespective of where the mount is asked to track.

The Wavelength command panel sets the effective wavelength for the observation, which is then used by

the pointing code to compute the refraction corrections. The effective wavelength should be based on the

spectral distribution of the target together with pass bands of any filters being used.

Below the solar target panel is the horizon checking configuration panel. This panel is used to turn on

and off horizon checking for targets. If horizon checking is on and a target configuration is submitted that

is below the altitude limit of the telescope mount then the configuration is rejected. If, however, horizon

checking is turned off then any target configuration is accepted irrespective of its altitude demand. This

allows a target currently below the altitude limit to be setup and the telescope can track it ready for when

it rises above the altitude limit.

Below the horizon checking panel is the mode selection configuration panel. Clicking one of the buttons

“OFF”, “ACTIVE” or “TRACKING” submits a configuration to the TCS with the mode attribute set to

the corresponding value. The TCS attempts to submit the same mode attribute to the TMA and ECS

subsystems. The modes are:

OFF – Motors are powered off and brakes are engaged.

ACTIVE – Motors are powered on, brakes are released and devices are servoing to their current positions.

TRACKING – The TMA and ECS are sent into tracking mode. In this mode the axes follow the

calculated trajectory demands from the TCS.

Next to the mode panel is the named position configuration panel. The TCS subsystems can be

simultaneously requested to perform the requested named position move by clicking on the buttons.

When clicked the TCS attempts to submit the same namedPos attribute to the TMA and ECS subsystems.

The named positions are:

Index – Motors perform a search routine to find the index switch and reset their encoders to a known

position reference.

Stow – Motors are moved to a predefined position (defined through properties) ready for power off.

The normal operational startup procedure may involve clicking on the “ACTIVE” button, followed by the

“Index” button, and then the “TRACKING” button. Shutting down may involve clicking on the “Stow”

button, followed by the “OFF” button. Both of these procedures can be carried out from this single TCS

tab.



6.3.4 Forbidden region

In order to prevent the telescope structure being illuminated, the TCS imposes a “forbidden” region that it

will not slew to nor slew across. This forbidden region is an annulus centered on the sun with an inner

radius of 1.5 R0 and an outer radius of 25 degrees. This restriction is only imposed if both the mirror and

enclosure covers are open and the sun is above the horizon. Note the horizon referred to here is the true

horizon not the 7o lower elevation limit of the TMA.

Also, if the telescope is currently pointed in this forbidden region and the mirror and enclosure covers are

closed. It will reject any attempts to open both at the same time.

6.3.5 Solar Disk Tab

Figure 35. Solar disk tab.

The solar disk tab displays information calculated from the solar library controller. Displayed at the top

left are the current longitude and latitude of the mid-point of the solar disk L0 and B0 along with the

position angle P between the geocentric North Pole and the solar rotational North Pole.

The sun does not rotate as a solid body and so the TCS supports a latitude dependent rotation of the form

𝑟𝑜𝑡 = 𝑤0 + 𝑤1 ∗ 𝑠𝑖𝑛2(𝑏) + 𝑤2 ∗ 𝑠𝑖𝑛4(𝑏)

The standard model built in to the TCS has w0 = 14.1844, w1 = -2.0 and w2 = 0.0 deg/day. The zeroth

order term is the rotation defining the fundamental physical ephemeris. In the screen shot the standard

model is being used and the values of the three terms are displayed along with the cumulative

contributions currently being added to base target longitude. As the standard model is being used there is

no additional contribution from the w0 term but a -0.012437 degree shift in longitude relative to the



equatorial rotation from the latitude terms w1 and w2.. Note that solar differential rotation is only applied if

the target coordinates are Heliographic.

The reference epoch from which the solar differential rotation is calculated is the time at which the

heliographic target is set. This epoch is reset each time the target is issued. This has a number of

consequences:

1. If you want to clear the accumulated differential rotation then re-issue the target heliographic

coordinates rather than setting the mode to “none”

2. Setting the mode to “none” will stop applying the current differential rotation model but retain the

current cumulative correction. The telescope will therefore keep tracking the current feature

without suddenly “jumping” to a new position. Over time the target will drift off and then if the

model (either standard or custom) is re-selected the telescope will catch up.

3. You can switch between the standard and custom models to check which model is the better

representation of the rotation at the solar latitude you are observing.

The possible models for the solar differential rotation are “standard”, “none” and “custom”. If “custom” is

selected you can then specify the individual parameter values. The panel in the lower left corner provides

the means to set the model and the parameters. Although it is not very obvious in the screen shot, the text

entry boxes for the parameters are disabled as the selected mode is “standard”. The boxes only become

enabled if the mode is “custom”.

The tab also provides a visual representation of the solar disk with heliographic longitude and latitude

lines overlaid to demonstrate the current position angle and give an indication of the coordinates of a

particular area on the disk. This schematic displays the required target position and the current mount

position along with the orientation of the rotator. The black circle (hidden by the red circle in the figure

above) with intersecting lines shows the current target demand position. There are four standard lines of

intersection plus one additional line that rotates to show the current rotator demand (relative to straight up

in the schematic). The red circle that currently overlaps the target circle is the current mount position. It

has only a single line of intersection that shows the current rotator position (relative to straight up in the

schematic). If the rotator is tracking and there is no rotator position angle or instrument alignment angle

applied then the red line will point straight up.

A new solar target can be selected from the schematic by right clicking on the desired point and selecting

“Move to here (helioprojective)”. This action issues a target command in helioprojective Cartesian

coordinates to the TCS.

Displayed in the lower right corner of the panel are the x and y helioprojective coordinates of the cursor.

These update as the cursor is moved over the image.



6.3.6 Data Tab

Figure 36. Data tab.

The data tab is split into two sections, the left hand side contains data relating to the solar coordinates and

some limit information, and the right hand side contains mount and enclosure data (valid for solar and

non-solar targets). The current solar target demands are presented in the five solar frames along with the

corresponding apparent coordinates for both the mount and enclosure. Note that the enclosure demands

might differ from the mount if a separate target has been selected for the enclosure to track. The currently

selected solar frame is displayed along with the frame of the coude and the times to sunrise and sunset.

The time to next sunrise is currently showing as 0 as the sun had already risen when the screen shot was

captured. The current solar library mode is also shown. If the mode is “active” then the mount is tracking

the solar target defined here. If the mode is “inactive” then the mount is tracking a non-solar target. Note

that the solar coordinate demands are still updated even if the library is in the “inactive” mode.

Below the solar target data is a table displaying the current solar differential rotation model coefficients

that are in use and below this a table of helioprojective offsets that are currently applied to the solar target.

Next to the solar differential rotation information are a set of status items relating to the position of the

sun in relationship to various limits. To avoid illuminating the telescope structure the telescope is not

allowed to point within an annulus centered on the sun’s position. The inner edge of this annulus has a

radius of 1.5 R0 and outer edge is at 25 degrees. These limits are displayed along with the current

target/sun separation. In the screen shot this separation is 0.000 deg as the current target happens to be the

sun center which is within the inner allowed zone.

The current horizon is shown as -2.59 degrees (due to a combination of refraction and the height of the

observatory above sea-level). The status shows the sun’s upper limb is above this limit and the current



target is observable i.e. is above the lower elevation limit of 7 degrees which is the lowest elevation to

which the mount can be pointed.

At the bottom left of the tab a table of limit information displays the current state of each of the three axes

along with any future limit predictions. The limit predictions will either state the number of minutes until

a limit is encountered, the fact that no limit will ever be encountered (for the current target) or the fact

that the axis is already outside a limit.

The right hand side of the tab shows the current mount and enclosure demands and encoder read-back

positions. Below these two tables is a table of RA, Dec offsets applied to the mount, any collimation

corrections currently applied and any pointing origin offsets currently applied. The collimation

corrections include any guide offsets and the LED provides an indication of whether the TCS is currently

accepting guide corrections or not. If the LED is green then guide corrections are currently integrated and

if the LED is red then guide corrections are not currently integrated.

6.3.7 Modes Tab

Figure 37. Modes tab.

This tab contains two configuration widgets designed to set the mode of the WCCS and the overall

thermal mode. Setting the mode of the WCCS will cause commands to be sent to the M1CS, TEOACS

and FOCS so that their modes are compatible with that of the WCCS. The mapping of the different modes

is shown in the table below

WCCS mode AO modes M2 FTT mode / input source

off passive off / teoa

idle passive off / teoa



calibrate active on / wfc

diffraction limited active off / teoa

seeing limited on-disk active off / teoa

seeing limited coronal active off / teoa

limb tracking passive on / wfc

Table 3 Mapping of WCCS modes to M1CS, FOCS and TEOACS modes

Note that setting the WCCS mode to off will only set the M1CS, FOCS and TEOACS to passive if they

are currently active or passive. If they are actually off then they are left off.

It may happen that the displayed demand mode may not match the current mode. This will occur on TCS

startup when the demand mode will be displayed as a question mark as it has never been set and alos if

the TCS has been bypassed and the mode of an individual subsystem has been set directly. If the pattern

of subsystem modes does not match that required in Table 3 then the current mode will be “undefined”.

N.B. At this point the tying of WFC modes to thermal modes is under discussion as well as what should be

done to set the overall thermal mode of the system. The operation of these widgets may change once those

discussions are finalized.

The thermal mode configuration is used to set the “thermalMode” attribute. To select the thermal mode

simply click on one of the buttons:

OFF – Shutdown the thermal control systems.

PRECON – Precondition the mirrors in preparation for sunrise. Normally this does not need to be issued

explicitly.

ACTIVE – This causes the thermal control systems to actively track the ambient temperature. Normally

this does not need to be issued explicitly.

6.3.8 Scanning Tab

The scanning tab provides a configuration widget to start, stop and setup parameters for scans, and a

graphical display to show the current demand trajectory and the mount position history for the scan. A

scan should only be started when tracking in a helioprojective frame. First choose a target and slew to

this target position, then start the scan which will center the scan on the current helioprojective target.



Figure 38. Random scan using scanning tab.

The figure above shows a random scan executing on the TCS application with the TCS subsystem

simulators running to provide positional feedback. The scan command widget can be set to either

“None”, “Random” ,“Spiral” or "Raster". If a random scan is required then select “Random” from the

drop down box and enter a size for the constraining box and a velocity in the corresponding text fields.

Click on submit to start the scan. If the two text fields are left blank then the scan defaults to sensible

values (box size 150 arcseconds, velocity 30 arcseconds/second). The configuration will complete

quickly, it is not held busy as the scan could potentially continue for a long time.

In the graphical display the red line shows the demand positions (only for a short time period). This red

line is updated every time a new batch of positions is calculated by the TCS. The green line shows the

mount position since the scan was started. The center of the graphical display represents the scan starting

point which is not necessarily helioprojective (0, 0).

To stop the scan select the scan type “None” and click on the “Submit” button.



Figure 39. Spiral scan using scanning tab.

The figure above shows an example of a spiral scan executing on the TCS application with the TCS

subsystem simulators running to provide positional feedback. To start a spiral scan select “Spiral” from

the drop down menu, set the radius of the spiral (arcseconds), the velocity (arcseconds/second), starting

radius (arcsecs) and spiral index and click on “Submit”. If no values are supplied for the radius and

velocity then default values are used. The configuration will complete quickly, it is not held busy as the

scan could potentially continue for a long time. The spiral is traced with a constant velocity so it does not

have a constant period.

The scan is defined by the equation

𝑟(𝜃) = 𝑎 + 𝑏 𝜃1/𝑐

Where a is the “start radius”, b is the “increment per turn” and c is the index. An Archimedean spiral has

c = 1. A circle would be defined by b = 0, a = radius




point which is not necessarily helioprojective (0, 0).

To stop the scan select the scan type “None” and click on the “Submit” button.



Figure 40. Raster scan using scanning tab.

The figure above shows an example of a raster scan executing on the TCS application with the TCS

subsystem simulators running to provide positional feedback. To start a raster scan select “Raster” from

the drop down menu, and set the parameters for the type of scan required. There are several parameters

used to configure the scan and these are explained below:

X offset: Arcsecond offset (in HP x) from the mount current position to

the center of the scan.

Y offset: Arcsecond offset (in HP y) from the mount current position to

the center of the scan.

Dy: Distance in arcseconds between each row of the scan.

Ny: Number of rows in the scan.

Specification: This is a menu option that lets the operator decide how to

perform each scan row. The options are:

VT – Velocity and time specified.

VX – Velocity and length specified.

XT – Length and time specified.

The next set of fields available for entry depend on the

selected specification.

(VT) Velocity: The velocity of the mount (arcseconds/second) while scanning

along each row.

(VT) Scan Time: The time taken (seconds) to scan each row.

(VX) Velocity: The velocity of the mount (arcseconds/second) while scanning

along each row.

(VX) Scan Length: The length of each row (arcseconds) of the scan.

(XT) Scan Length: The time taken (seconds) to scan each row.



(XT) Scan Time: The time taken (seconds) to scan each row.

Orientation: Orientation of the scan (in degrees).

Row reversal: If true then the mount moves in opposite directions for each

row (as shown in the diagram above). If this is false then the

mount moves back after each row and starts each row from the

same side.

Starting position: This is a menu that allows the starting corner to be specified.

Options are top-left, top-right, bottom-left, bottom-right or

nearest corner.

Once the parameters are setup as required, click on “Submit” to start the scan. The configuration will

complete quickly, it is not held busy as the scan could potentially continue for a long time.




point (point where the mount is located when the scan is started) which is not necessarily helioprojective

(0, 0).

A raster scan will stop automatically when it has completed its last row and the telescope will resume

tracking its previous position. The scan can be stopped early by selecting the scan type “None” and

clicking on the “Submit” button. There may be a brief delay before the telescope reverts to tracking the

previous target position until the scan processing empties its demand position queue.

6.3.9 Subsystems tabs

This MCS & ECS and M1CS & TEOACS tabs provide control of some key TCS subsystem functions.



Figure 41 MCS & ECS control tab

The top two widgets control the M1 mirror cover and the enclosure aperture cover. Both of these must be

open to get light onto the primary mirror. The TCS will prevent both of these opening if the telescope is

currently pointed into the forbidden zone (see Section 6.3.4) and the sun is above the physical horizon

defined by the “Horizon” value on the data tab.

Lastly there is an alignment camera on the mount. This has a simple on/off control



Figure 42 M1CS & TEOACS control tab

The M1 mirror control system can be in one of 3 modes: off, passive or active. This is the overall mode of

the mirror. Normally the M1CS will be in passive mode as it is not possible to turn off the lateral

controller unless the mirror is horizontal. This corresponds to a mount altitude of 104.028 degrees.

Switching of the M1CS between passive and active will normally happen automatically based on the

WCCS mode.

The Lyot stop control is straightforward clicking the appropriate button will either insert or remove the

stop from the beam.

6.3.10 Engineering tab

The engineering tabs provide easy access to the main events that the TCS posts. The contents of the tab

are shown below. Each button opens another screen that displays the attributes of the events from that

controller.



Figure 43 TCS engineering tab

For test purposes it is sometimes convenient to set the time that the TCS uses to a time offset from the

current time. For example an observing program may be being checked before sunrise or after sunset that

requires the telescope to be tracking the sun. If the current time were used then the commands in the

observing program to slew or offset would either be rejected (if horizon checking had been activated) or

would not complete and instead wait for the sun to rise. The time offset widget allows an offset time to

be set either by specifying the current required time or by specifying an offset directly. The offset can be

positive or negative. To switch the TCS back to the current time and set the offset to zero click the reset

button.



6.3.11 Lifecycle Control Screen

Figure 44. TCS lifecycle control screen.

The lifecycle control screen provides the current lifecycle state of each controller present in the TCS

application. At the top of the screen the lifecycle states of the two controllers are displayed. Any of the

lifecycle states can be changed by right clicking on the lifecycle widget and selecting the new state.



Certain state transitions are forbidden and will not result in the container/controller changing state. If the

state of any management controller is changed then the state of its children will also be changed. Thus

changing the state of the top-level atst.tcs controller will change the state of all of the controllers present

in the TCS application. The hierarchy of controllers is presented by indenting child controllers in the tree

layout.

6.3.12 Health Screen

Figure 45. Health screen.

The health screen provides an overview of the health of each sub-controller present in the TCS

application. A heartbeat event is also posted by each of these and the top level TCS controller monitors

these heartbeat events. If the heartbeat event is not received then the indicator will turn yellow and then

red and corresponding health messages will be displayed. Under normal operation the screen should look

as it does in the figure above, all LEDs displayed as green and all health status items displayed as “good”.

The screenshot below shows an example where various controllers are reporting a problem. The

atst.tcs.iers controller is reporting its health as ill. In this case the reason is that the IERS parameters have

not been updated for at least 7 days. This is reported as "ill" as the TCS is still fully operational but the

pointing accuracy is slightly degraded.

The atst.tcs.environment controller's health is bad as it has no connection to the event stream from the

Facility Control System that contains the temperature, pressure and humidity information needed by the

TCS to correct for refraction. In this situation the pointing may be seriously degraded as refraction can be

many arcminutes at lower altitudes.

Note that the above two health states do not propagate up into the top level TCS health. This is in line

with the DKIST policy that management controllers do NOT reflect their sub controller's health. In the

operational system this hierarchy will be displayed by the health system tool and so is not necessary to

duplicate that in individual engineering screens.



Figure 46 Health screen showing problems at different levels

The overall health of the TCS is bad in the screen shot above and this is because the TCS has lost the

heart beat from its atst.tcs.seq sub-controller. Note that the sub-controller health itself is good, it is the

connection to it from the top level TCS that is bad. If the TCS loses the heartbeat from any of its sub-

controllers then this is serious problem as the TCS is then non-operational . In practice this is only likely

to happen if a sub-controller crashed. The screen shot above was artificially generated by deliberately

shutting down the atst.tcs.seq controller.



6.3.13 Solar Disk Screen

Figure 47. Solar disk screen.

The solar disk screen is a larger copy of the solar disk tab (section 6.3.5). The solar disk screen provides

a visual representation of the solar disk with heliographic longitude and latitude lines overlaid to

demonstrate the current position angle and give an indication of the coordinates of a particular area on the

disk. This schematic displays the required target position and the current mount position along with the

orientation of the rotator. The black circle (hidden by the red circle in the figure above) with intersecting

lines shows the current target demand position. There are four standard lines of intersection plus one

additional line that rotates to show the current rotator demand (relative to straight up in the schematic).

The red circle that currently overlaps the target circle is the current mount position. It has only a single



line of intersection that shows the current rotator position (relative to straight up in the schematic). If the

rotator is tracking and there is no rotator position angle or instrument alignment angle applied then the red

line will point straight up.

A new solar target can be selected from the schematic by right clicking on the desired point and selecting

“Move to here (helioprojective)”. This issues a target command in helioprojective cartesian coordinates

to the TCS.

6.3.14 Target Control Screen

Figure 48. Target Control Screen.

The target control screen provides nine configuration widgets to interact with the TCS application and set

non-solar targets and associated rotator positions, wraps and differential track rates. Each configuration

widget is described in detail below.

The “Set Up Target” widget allows a user to enter a target position along with the ancillary data necessary

to fully specify an astronomical target.

For the target parameters command not all of the information is required. The only required information

is the frame, right ascension and declination, all other fields are optional and defaults will be provided.

The defaulting rules are described below. To enter a new target simply fill in the required information

and click on the “Submit” button. The range of input frames available is

FK4 – commonly equinox B1950

FK5 – commonly equinox J2000

ICRS – this is currently just a synonym for FK5 J2000. The differences are at most about 26 mas

APPT – topocentric apparent

GAPPT – geocentric apparent



AZEL – topocentric azimuth and elevation

The currently selected frame can have an impact on the target command panel as it automatically updates

to remove options that are not relevant to particular frames. This can be seen in the figure below, where

the selected frame is AZEL.

Figure 49. Target control screen AZEL frame.

Below is a table of the parameters of the target command.

Parameter Description

Name A name that can be used to identify the target object e.g. 3C273. The name

can include spaces and need not be surrounded by quotes. If no name is

specified then the string “undefined” will be provided.

Frame The reference frame in which the coordinates of the target are specified. The

default if none is specified is FK5 unless it can be deduced from the equinox

(see below).

Ra/Az The parameter names ra and az are used as synonyms i.e. either can be used to

specify the target position. Whether the following data is treated as an RA or

an Azimuth is actually determined by the frame. The format of the position

can be either sexagesimal separated by spaces or as hours or degrees with a

fractional part. If sexagesimal, it is not necessary to surround the position in

quotes. All the following are valid for example

ra = 3 4 5.6

ra = 3.5

az = 231 40 21.6

Dec/El Again the parameter names dec and el are synonyms and it is the frame



Parameter Description

parameter that determines how the following data is interpreted.

Equinox The epoch of the mean equator and equinox. The defaults depend on the

frame specified.

FK5 or ICRS – J2000.0

FK4 – B1950.0

GAPPT/APPT/AZEL – ignored

If no letter (B or J) precedes the number then pre 1984.0 is assumed to be B

whilst post 1984.0 is assumed to be J.

Parallax Stellar parallax in arcsecs it defaults to 0.0.

Radial Velocity Radial velocity (km/s). It defaults to 0.0.

Proper Motions

Ra

Proper motion in RA (s/yr) it defaults to 0.0. Note the input units. Many

catalogues give the Ra proper motion in arcsecs multiplied by cos(Dec).

Proper Motions

Dec

Proper motion in Dec. (arcsec/yr). It defaults to 0.0.

Epoch The zero point for the proper motion expressed as a year. If none is specified

it will default to the epoch of the equinox.

Note that entering a target may not immediately cause the telescope to start slewing to the demand

position. What the target command does is cause the pointing kernel to update the stream of position

demands for the tracking mechanisms i.e. the rotator and mount axes and the enclosure axes. Whether

those mechanisms act on this stream of demands is determined by whether they have been placed into

tracking mode.

When the target command is issued the default behavior of the TCS is to send demands that minimize the

movement of the azimuth axis. Due to the overlap of the azimuth position range this could result in a

negative or positive encoder demand for the same target. The default behavior will always attempt to

move the azimuth by less than 180 degrees unless this lies outside the limits. However, it may be

desirable to force the azimuth to drive in the opposite direction (unwrap). The “Azimuth Wrap” widget

below the “Set Up Target” widget can be used to force an unwrap in either direction. It can be issued

before, during or after a target update, or while the azimuth is already tracking. In the latter case if an

unwrap is possible then the azimuth will drive a full 360 degrees back to where it was currently tracking

from.

The “Differential Track Rate” widget is displayed below the “Azimuth Wrap” widget. It is possible to

track non-sidereal targets by specifying differential track rates. The point at which the differential track

should start is specified by a reference epoch. If this time is left blank the differential tracking will start

from when the configuration is submitted. Although it is possible to track non-sidereal targets this way, it

will be necessary to update the track rates from time to time if observing over a long period.

Note that this command is not needed for tracking the sun. The solar frames take care of the sun’s non-

sidereal motion directly.

The coudé specific configuration widgets are displayed in the middle of the screen. The “Set Up Coude”

configuration widget allows the coudé orientation to be specified in a variety of reference frames. The

position angle in the selected frame can be given as well as an instrument specific alignment angle

(“Coude Offset”) that handles any fixed offset between the instrument’s principal direction and the coudé

rotator’s reference direction.



The AZ frame needs special mention as it is not a frame in the same sense as the others but rather a mode

that the rotator can be set to. In this frame the rotator is locked to the mount azimuth demand.

When the coudé command is issued the default behavior of the TCS is to minimize the movement of the

coudé axis. Due to the overlap of the coudé position this could result in a negative or positive encoder

demand for the same target. The default behavior will always attempt to move the coudé by less than 180

degrees unless this lies outside the limits. However, it may be desirable to force the coudé to drive in the

opposite direction (unwrap). The “Coude Wrap” widget below the “Set Up Coude” widget can be used to

force an unwrap in either direction. It can be issued before, during or after a target update, or while the

coudé is already tracking. In the latter case if an unwrap is possible then the coudé will drive a full 360

degrees back to where it was currently tracking from.

To set the coudé position angle and frame use the “Set Up Coude” configuration widget. To set a specific

instrument alignment angle use the “Coude Offset” configuration widget. In each case, click on the

“Submit” button to submit the configuration to the TCS.

At the bottom of the screen in the middle is the “Planet Target Select” widget. This provides a simple

interface for selecting either a planet or the moon as a target. Simply select the required body from the

drop down menu box and click on “Submit”. The planet target makes use of the C SPICE library [15]. A

description of the library can be found in section 8.1. The top right hand side of the screen contains the

orbital elements widget. The heliocentric orbital elements can be provided in a variety of formats e.g. as

supplied by JPL or the MPC. The elements are used to generate Topocentric Apparent RA and Dec which

are then updated with the correct differential track rates. The elements are described below:

elementType - Elements can be entered in the form returned by the Horizons service (JPL), the Minor

Planet Center (MPC) or Internal i.e. the form used internally by the code

elementForm - three forms of elements are acceptable "Major planets", "Minor planets" or "Comets"

For the three types of elements, the mappings of the attributes onto the parameters used by the JPL, MPC

and Internal types for the different forms is shown in the tables below

Attribute Major planet Minor planet Comet

elementsEpoch JDCT-2400000.5 JDCT-2400000.5 Tp -2400000.5

elementsInclination IN IN IN

elementsANode OM OM OM

elementsPerihelion W W W

elementsAorQ A A QR

elementsEccentricity EC EC EC

elementsAorL MA MA Not used

elementsDailyMotion N Not used Not used

Table 4 JPL Orbital Elements


elementsEpoch Epoch-2400000.5 Epoch-2400000.5 T -2400000.5

elementsInclination IN Incl Incl

elementsANode OM Node Node

elementsPerihelion W Perih Perih



elementsAorQ A a q

elementsEccentricity EC e e

elementsAorL MA M Not used


Table 5 MPC Orbital Elements

Note that the MPC does not specify a set of elements for the major planets so we default to using the JPL

set.


elementsEpoch JDCT-2400000.5 JDCT-2400000.5 Tp -2400000.5

elementsInclination IN IN IN

elementsANode OM OM OM

elementsPerihelion OM + W W W

elementsAorQ A A QR

elementsEccentricity EC EC EC

elementsAorL MA+OM+W MA Not used


Table 6 Internal Orbital Elements

Due to the large number of attributes needed to specify a target via elements, configurations are rejected

that do not contain all of them.

The final widget present on this screen is the “Guiding” widget. This provides buttons to turn on and off

integration of the guide signals within the TCS. The clear button will zero out any current guide signals

integrated into the TCS pointing. Simply click on the corresponding button to execute the action.

6.3.15 Pointing Tests Screen

The pointing tests screen is described in detail in section 7.



6.3.16 IERS Update Screen

Figure 50. IERS update screen.

The IERS properties can be updated from this screen. Click on the “UPDATE” button to submit the

configuration to the TCS. The TCS uses the location specified in the “Filename” text update box at the

bottom of the tab to download the latest set of data. This is the default location and it is not expected to

change. However, the facility is available to make the change if ever it became necessary to do so by

altering the property atst.tcs.time.iers.fileName. The most recently read set of IERS data is presented in

the table and this includes the date of the dataset and the current date. If the data is more than 7days old

then the health of the TCS is set to warning and if the data is more than 28 days old then the health of the

TCS is set to bad. Again, these two values (numbers of days) can be set from the properties

(atst.tcs.time.iers.warningTime and atst.tcs.time.iers.errorTime).

The MJD of the next leap second is shown as 99999.9. This is the default value to show that a new leap

second is yet to be announced. Once one has been announced then the MJD of that date will be entered in

the property atst.tcs.time.iers.mjdnls. If the TAI MJD is greater than this then the UTC derived from the

TAI will have an additional second subtracted until atst.tcs.time.iers.mjdnls is reset to the default.

This reset will occur automatically when the value of UT1 –UTC changes by more than 0.9s. This change

in the IERS values signals a leap second has been added. The TCS will simultaneously add an extra leap

second at this point and reset mjdnls to 99999.9. If the property database has been reloaded then the

initial value of UT1 –UTC will also show as 99999.9. This indicates that no current value of UT1 – UTC

is available and the check for a change of more than 0.9s is bypassed.

Note that these leap second adjustments are only done so that correct UTC times can be derived at all

times even through a leap second. The TCS operates internally on TAI which is unaffected by these

adjustments.



6.3.17 Weather Screen

The weather controller screen shown in the figure below provides widgets to set the weather controller

mode and to input manual values for the weather data should the weather server fail. There are two

modes of operation, automatic and manual. When placed in automatic mode the TCS expects to receive

regular events (from the event channel defined by property .wsEventChannel, section 4.3) which contain

the three items that the TCS is interested in, temperature, pressure and humidity. When placed into

manual mode the TCS will accept the weather parameters submitted as a configuration, with the initial

values equal to whatever the most recently set of received values were, or the property values if no events

were received. The screen displays the current mode of the weather controller, along with the currently

used values and their source (default, manual or automatic). To change the mode simply click on the

corresponding button at the top of the screen. Whilst in manual mode values can be entered by entering

the value into the text box and clicking on the submit button. Note manual values cannot be entered

whilst the weather controller is in automatic mode.

Figure 51. Weather controller screen.



6.3.18 Offsets Screen

The offsets screen contains three tabs, each containing configuration widgets that can be used to offset the

telescope. Each tab is described in detail below.

Figure 52. Target offsets tab.

Offsets can be entered as either solar, simple or tangent plane and are in the target’s coordinate frame. To

enter manual offsets select the required offset type from the menu button, enter the amount of each offset

in the manual text input boxes and then click on the button with the tick. Note that the units for the

offsets change depending on the offset type. Solar and tangent plane offsets are always in arcsecs whereas

for non AZEL frames the RA component of a simple offset is in seconds of time.

Offsets entered through this screen can be either absolute or incremental i.e. if you enter a manual offset

of x, y and click on the tick twice the total offset is still x, y not 2x, 2y, but if you use the handset then the

offsets are applied incrementally.



Refer to the “Offsets” data tables on the data tab (Section 6.3.6) to see the total size and make up of any

offsets that have been added.

Offsets can also be cleared or absorbed from this panel. Since the offsets are absolute, clearing the offsets

is equivalent to setting the offset to 0, 0. Absorbing offsets involves transferring the offsets to the target

coordinates and simultaneously clearing the offset. This might be needed if the initial target coordinates

were uncertain and offsets had been applied to acquire the target. To clear either the handset or manually

applied offsets click on the corresponding button with the cross icon, and to absorb the offsets click on the

button with the refresh icon.

Figure 53. Collimation corrections tab.

Collimation corrections can be applied by the same method as the offsets described above. There is a

handset for applying small incremental corrections, or custom corrections can be applied using the ca and

ce input controls and applying them by clicking on the button with the tick icon.



You can see the total increment you have applied with the absolute adjustments and the handset in the

data tab (Section 6.3.6) on the TCS main engineering screen. There is a data table called “Collimation”

with the individual values and the totals. In contrast to offsets, which affect the RA and Dec. of the

target, collimation corrections affect the TCS pointing but leave the target RA and Dec. fixed.

Figure 54. Pointing origin tab.

The pointing origin is the position in the rotator frame where it is required that the image of the target will

fall.

Three types of pointing origin command can be applied if necessary. The base position is an absolute

value which has been calibrated for an instrument and then left. Additional offsets can either be applied

through values specified in the “Manual Offsets” controls or by using the handset to make small

corrections to the pointing origin. Both types of offset can be cleared or absorbed into the current

pointing calculations and buttons are available on the panel to perform all of these commands. Buttons

with a tick icon submit the current values, buttons with a cross icon clear the current values and buttons

with a refresh icon absorb the current offsets to the base pointing origin.



You can see the total pointing origin you have applied with the absolute adjustments and the handset in

the data tab (Section 6.3.6) on the TCS main engineering screen. There is a data table called “Pointing

Origin” with the individual values and the totals.

Figure 55. Rate motion offset tab.

The rate motion offset tab provides the operator with the capability of driving the telescope around at a

constant rate relative to the fixed original target position in the target coordinate system. The rate can be



selected from one of three values defined for the atst.tcs controller. This screen displays the three

available rates as selectable buttons (only one can be selected at any one time). To drive the telescope in

one coordinate direction click and hold any of arrow buttons. Whilst the button is held down the

telescope will continue to drive in the chosen direction at the chosen rate. To stop the telescope, release

the button. The telescope will remain stationary relative to the current coordinate system; it will not

return to the original target position. The moves are additive so an operator can use this panel to drive

around looking for a target of interest. The curved arrows are for driving the Coudé either clockwise or

counter-clockwise.

Note that the three available rates depend upon the frame of the target. For most frames a rate in arcsecs/s

is most natural but this is not the case for say HG or HCT or for controlling the rotator. The different

default rates are shown at the bottom of the panel. New default values can be entered if the provided rates

are not what is needed. The rotator is controlled in degs/s and the buttons update with the current values

as soon as the cursor is placed over the curved arrow buttons.

Note the configurations that are submitted as part of this control are matched immediately by the TCS,

they are not held busy for the duration of the move.

6.4 INTERLOCKS

The TCS is required to respond to interlock demands from the Global Interlock System (GIS). The TCS

design assumes that the TCS subsystems receive their own interlock demands and that it therefore has no

role in passing such demands on to them ,

In response to an interlock demand, the TCS will disable all commands within the configuration handler,

abort any ongoing actions and attempt to place itself and its subsystems into a safe state. Once the

interlock is removed the TCS will immediately revert to accepting commands and configurations again.

No special action will be needed to make this happen other than the removal of the interlock.

The state the TCS will enter will be to set its mode to off and then it will send configurations to all its

subsystems with mode set to off. The only exception is the PA&C which does not have a "off" mode. It

is possible that one of more of the subsystems will reject these configurations if they have already

received their own interlocks but in this case they will already have entered their off state



7. CALIBRATING THE TCS

7.1 POINTING TEST

A pointing test can be performed using the point test tool built into the engineering interface. To launch

the tool, click on the “Pointing Tests” button on the TCS Control tab (Section 6.3.3). The figure below

shows the main panel.

Figure 56. Pointing test engineering display.

The main display area consists of a projection of the sky on to the tangent plane at the latitude and

longitude of the telescope. The zenith is thus at the center and the outer edge is the horizon (altitude = 0).

The azimuths of the cardinal points are drawn along with circles of constant elevation (at 30 and 60

degrees). In this projection lines of elevation become more compressed towards the edge of the plot. The

position of the moon is indicated by the solid green circle (NOTE – not present in this release), and the

telescope position is indicated by the open black circle. The bottom left hand side of the projection

displays the current mount azimuth and elevation positions, and the bottom right hand side of the

projection displays the current azimuth and elevation of the mouse pointer whilst it hovers over the

projection.

Stars are plotted on this map from the currently selected star catalogue. Currently only the default star

catalogues provided by TPOINT [12] are available for display. The operator’s own catalogue may be used

but this must conform to the format defined and used by TPOINT (see [12] for details). To select another

catalogue, click on the “catalogue” button. The new screen is shown below



Figure 57 Catalogue selection display

The current catalogue name is shown and on the right the list of stars and their positions. If the “Choose

catalogue” button is clicked a file chooser is launched that allows the selection of a different catalogue

To perform a pointing test, click on the “New” button. This will create a new pointing data file in the

pointing sub directory of the application’s data directory ($ATST/data/pointing). The file name is made

up from the current date and time as yyyy_mm_dd_hh_mm.dat where yyyy is the year, mm is the

month, dd is the day, hh is the hour and the final mm is the minute. The file name of the current pointing

test is displayed in the text update widget on the main display.

Now click on any of the plotted stars on the main display. The point will turn orange and the parameters

of the selected star will appear in the configuration box of at the top right hand side of the window. If the

star is suitable click ‘Submit’ and the target will be submitted to the TCS and if accepted will cause the

telescope to slew to the new target. A small circle plots the current telescope position. Once the circle

surrounds the selected star you should also see the target appear on the CCD. Click on the “Adjustments”

button to open the collimation offsets window.



Use the collimation offsets handset to center the target on the reference position on the CCD and once the

alignment is satisfactory click the “Log” button to log the data to the file.

The above procedure can now be repeated for as many other stars as required. All data will get logged to

the same pointing file until the “New” button is clicked. Successfully selected stars will turn red on the

display so it is easy to keep track of which stars have already been observed. The current number of

logged data points is displayed on the pointing test display.

7.2 USING THE DKIST TPOINT CONTROLLER

The TCS application is delivered with an additional C++ controller called atst.tcs.tpk.tpoint. This

controller loads and manages a modified library version of TPOINT developed specifically for DKIST.

The library version provides full access to TPOINT functionality in a distributed manner making use of

the CSF framework. To interact with the TPoint controller select the TPoint tab on the main screen and

start the container and controller.



Figure 58. Pointing test tpoint interaction tab.

To start TPOINT click on the “Start” button at the bottom of the screen. At this point you will see the

TPOINT output displayed in the text area (as shown in the figure above). The pointing data files drop

down box will also populate with any current data files created by running pointing tests. It is now

possible to interact with the TPOINT application by entering commands into the text entry box at the

bottom of the display and pressing return. A full list of commands can be found in the TPOINT manual

[12]. When entering certain commands it is important to remember that the JES screen is not necessarily

running on the same machine as the TPOINT application and data files (which are both present on the

TCS machine). Using the buttons on the right hand side of the screen will provide easy access to some of

the TPOINT standard functions.

To plot a graph of the data click on the “Plot” button. After a few seconds the plot screen will open.



Figure 59. Tpoint plot screen.

The plot can be updated at any time by clicking on the “Plot” button again. To save a copy of the plot (to

the machine running the JES instance) click on the “Save” button and enter a filename. The plot is saved

as a gif file.

There are buttons present for performing standard and custom fits, and an automatic fitting routine. Once

a fit is complete the resulting model can be save to file by entering a filename and clicking on the “Save”

button. Once again this model file is saved to the machine upon which the Tpoint controller is running,

and is saved in the applications data directory ($ATST/data/pointing/models).

For instructions on how to analyze the data produced by TPOINT using the standalone application refer to

the TPOINT manual [12].

7.3 DERIVING SESSION PARAMETERS

It is envisioned that full pointing tests will be performed relatively infrequently. However, it may be

necessary to perform a “mini” pointing test more frequently to check and update the collimation terms.

This may be needed before the beginning of each observing session. The derivation of the corrections to

the full pointing test parameters is referred to as deriving the “session” parameters. The initial part of

deriving session parameters is identical to that of a full pointing test. Use the pointing test tab to create a

pointing data file and log the data by moving to the target stars and applying collimation corrections. To

‘Fit’ corrections to CA and IE you can use just 1 star but in this case there is no fitting involved, the



procedure simply takes the collimation adjustments you have made to get the target on the reference

position and returns these as the session adjustments. If you include the IA term in the fit (see below) you

need a minimum of 2 stars but again this hardly constitutes a fit. Four or five stars should be the minimum

you use.

Figure 60. Pointing test session fit tab.

Select the TPoint tab and ensure the atst.tcs.tpk.tpoint controller is running. Click on the “Start” button to

start the TPOINT library. Select the “Session Fit” tab, select the file from the drop down list of files and

click on the “Session Fit” button. If you want to include fitting IA as well as the standard CA and IE then

first select the check box “Use IA in session fit”. In order to separate CA and IA you will need stars over

a good range of elevation. Once the fit is complete, the “Fitted data” table will get filled in with the

corrections that have been calculated and the “Session data” entries will show the residuals of the star

positions from the new best fit pointing model. The residuals are shown in both the horizontal (dS) and

vertical directions (dZ) as well as a total radial value. If any points show very large residuals they can be

eliminated from the fit by de-selecting the check box on the relevant data row and then fitting again. If too

many entries are masked out then some extra points should be logged and then the fit remade.

Once you are happy with the session parameters click the “Use” button. This will apply the corrections to

the pointing model. The latest set of derived values will always be available when the TCS is next started

and can be reused by clicking on the “Use” button again. The original pointing terms can be reinstated by

clicking on the “Revert” button.

A complete record of the fitting session is maintained in the pointing directory

($ATST/data/pointing/ctrl). TPOINT maintains log files of its own internal calculations as well as the

output that would have gone to the user had the analysis been run interactively. These can be found in the

files tptMsg.dat and tptRpt.dat respectively. Note that these files will be over written each time as session



fit is performed. The complete output including commands issued to TPOINT is displayed in the text box

in the “TPoint” tab. This text can be copied and pasted.

7.4 SWITCHING BETWEEN POINTING MODELS

The TCS provides a mechanism for maintaining multiple sets of pointing model attributes and switching

between them using properties. Note that a pointing model is only read by the TCS when it is started up

and cannot be changed whilst the TCS is in the “running” CSF state.

To create a new set of pointing model attributes two new properties must be created:

1) atst.tcs.tpk.pk.model:<name>:names

2) atst.tcs.tpk.pk.model:<name>:values

The first is an array of strings, which correspond to the names of the pointing model terms and the second

is an array of doubles which correspond to the values of those pointing model terms. A few examples are

provided in the factory default properties for the atst.tcs.tpk.pk controller.

To select a model for execution within the TCS another property is used,

1) atst.tcs.tpk.pk.model:selected

This property has a single string value, which is the name of the pointing model set to use. For example if

a new pointing model called “test_21_12_2012” was to be used then the following properties would be

required:

Property name Property Value

atst.tcs.tpk.pk.model:test_21_12_2012:names IA, IE, CA

atst.tcs.tpk.pk.model:test_21_12_2012:values 0.0, 0.0, 0.0

atst.tcs.tpk.pk.model:selected test_21_12_2012

The values of the first two properties are simply examples whereas the value of the third property is

important and must match the <name> of the first two properties.

The steps involved in creating and then selecting a new pointing model are:

1) Create the new entries in the atst.tcs.tpk.pk.prop file as detailed above

2) Change the "selected" property as detailed above

3) Load the property file with the PropertyReader application

4) If the TCS is running execute a shutdown followed by an uninit on atst.tcs

5) Now execute an init followed by a startup on atst.tcs



8. PLANETARY EPHEMERIDES

The TCS provides attributes for selecting targets either by name (for the planets and moon) or by setting

orbital elements (all bodies). This section describes the additional libraries compiled as part of the TCS

that allow this particular type of target selection.

8.1 CSPICE LIBRARY

SPICE is described as an ancillary information system that provides scientists and engineers the capability

to include space geometry and event data into mission design, science observation planning, and science

data analysis software. The principle components of the SPICE system are the SPICE toolkit software

(cspice for the TCS) and SPICE data files called “kernels” [15], [16]

The TCS application is provided with the cspice library files in source code format, and these files are

compiled as part of the TCS application itself. The files are included unmodified and a CSF makefile

(Makefile.gcc) has been created to generate the required library for use in the TCS application. The

toolkit can be downloaded from

http://naif.jpl.nasa.gov/naif/toolkit_C.html

For the TCS the kernel file used is “de421.bsp”. This kernel is described as “suitable for any purpose

limited by the integration time span of approximately 1900 – 2050”. The kernel file can be downloaded

from

http://naif.jpl.nasa.gov/pub/naif/generic_kernels/spk/planets/de421.bsp

but the file is included as part of the TCS application. A property exists (.ephemFile for the pk controller)

that points to the kernel file location and if necessary a new kernel file can easily be tested/used in place

of the current kernel file.

The following licensing and use information is taken from the NAIF website

Export

SPICE software has been designated "Technology and Software Publicly Available" (TSPA) for export

control purposes. As a result the export of SPICE software and related documentation is not restricted,

and is independent of and not limited by export agreements for specific flight projects.

However, anyone outside of the NAIF Group who produces a derived product incorporating SPICE

software must obtain her/his own export designation.

It is the finding of NASA's export control official that none of the SPICE system data, software, training

or consultation are used for or useful in the design, fabrication, or operations of spacecraft systems or

instruments, and thus publication or provision is not restricted under ITAR.

To the extent that any SPICE information would take the form of software source code or non public

technical data that is beyond the scope and nature of the scientific and performance information contained

in the SPICE description provided to NASA, ITAR restrictions could apply.

Publication or provision of project-specific SPICE data could be restricted under a flight project's own

programmatic rules unrelated to ITAR regulations.

http://naif.jpl.nasa.gov/naif/toolkit_C.html

http://naif.jpl.nasa.gov/pub/naif/generic_kernels/spk/planets/de421.bsp



Clearance for Distribution

JPL Document Review has issued Clearance CL#05-2438 for the distribution of SPICE products via the

NAIF server.

Obtaining the SPICE Toolkit

To meet NASA/JPL requirements and to better ensure getting the correct products, persons wishing a

copy of the SPICE Toolkit should obtain it from this web site or from an official NASA flight project

distribution. (Also see "Toolkit Redistribution" below.)

Toolkit Redistribution

Redistribution of the complete Toolkit is prohibited without prior clearance from NAIF. However,

including the appropriate SPICE library modules and relevant SPICE Toolkit programs and allied User

Guides as part of a package supporting a customer-built SPICE-based tool is not restricted.

Modifications to SPICE Code

To support code portability and to promote user understanding of the algorithms and models used within

SPICE, NAIF has chosen to provide customers with well documented source code. NAIF cannot preclude

you from modifying this code, but we strongly recommend against doing this. If you do modify any

SPICE code NAIF will be unable to provide any customer support. If you do modify SPICE code be sure

to clearly note this in the header so future users of the modified code will understand these circumstances.

Kernels Distribution

SPICE kernels placed on the NAIF server may be downloaded and used by anyone, consistent with the

other rules found on this web page.

Kernels Redistribution

Redistribution of SPICE kernels distributed by NAIF is permitted as long as they have not been modified.

If a kernel distributed by NAIF has been modified in any way, any embedded or otherwise allied

attribution of the kernel producer must be replaced with the name and institution of whomever has made

the last modification. Redistribution of kernels distributed by any other entity is subject to the rules on

and of that entity.

Creation of SPICE Kernels

All users of SPICE may carefully create SPICE kernels, using appropriate methods (see "Intro to Kernels"

in the SPICE tutorials collection). Such self-made kernels should be annotated with appropriate metadata

(see "comments" tutorial) and validated before being used by yourself or distributed to others.

Modifications to SPICE Kernels

All users of SPICE may "modify" kernels received from any source, although such modifications must be

limited to a few appropriate actions (see "Intro to Kernels" in the SPICE tutorial collection). Such self-

modified kernels should be annotated with appropriate metadata (see "comments" tutorial) and validated

before being used by yourself or distributed to others. The file name must also be changed to help avoid

confusion.

Commercial Use of SPICE

Use of SPICE components in commercial products is allowed, subject to the substantial restrictions on

user support noted under "Getting Help from NAIF" above. No fees or licensing are required.

Acknowledgement of the use of NASA's SPICE system is encouraged. Please contact the NAIF Manager

if you have questions.



9. TCS SUBSYSTEM SIMULATORS A set of simulators (one for each TCS subsystem) is provided. By running the subsystem simulators the

TCS can be executed completely independently of any hardware. Note that the simulators discussed are

internal to the TCS. Each “real” TCS subsystem can also be executed in a simulation mode but that is

outside the scope of this manual. Refer to the individual subsystem user manuals for details of how to

execute them in that mode.

Each subsystem simulator provides a complete copy of the interface to the real subsystem, but with most

of the underlying functionality of the subsystem removed. Some simple functionality may be present to

provide a realistic “appearance” of the subsystem to the TCS (for example, some configuration actions

will delay for several seconds before completing). These subsystem simulators are designed so that the

TCS does not know that they are not the real subsystems and therefore the TCS can be executed in a

simulation mode without the necessity to change any code or reconfigure the TCS application in any way.

Configuring which TCS simulators to use is managed by pkgDevel (see section 4.1) The configured

simulators are started with the command

osl-simsUp

A panel to launch the engineering screens for these simulators is started with the command osl-simsGui as

illustrated below. Clicking on the buttons will start the individual simulator engineering screens.

Figure 61 Simulator launch screen

A brief description of each subsystem simulator is presented in the following sections.

9.1 MCS SIMULATOR

The TMA is responsible for the main axes of rotation of the telescope i.e. the azimuth, altitude and coudé

rotator as well as the mirror cover and some auxiliary devices.



Figure 62. MCS simulator main display.

The MCS simulator provides a set of simulated controllers:

atst.tcs.mcs

atst.tcs.mcs.az

atst.tcs.mcs.el

atst.tcs.mcs.coude

atst.tcs.mcs.cover

atst.tcs.mcs.aux

The controllers are designed to match the ICD specification between the TMA and TCS [4]. There is

some basic functionality present in the simulated system, including three simulated servo devices that can

track the demand stream from the TCS and provide realistic feedback to the TCS for its upstream position

calculations. The main screen (shown above) contains two sets of tabs and some additional status. The

status items are displayed on the top right hand side of the screen.

Mode – The current overall mode of the MCS, one of off, active or tracking.

In Position – An indicator to show the overall in position status of the TMA. If the LED is green then all

mechanisms are in position and if the LED is red then at least one mechanism is not in position.

Zenith Blind Spot – An indicator to show if the TMA has entered the zenith blind spot. If the LED is

green then the TMA is not currently in the zenith blind spot. If the LED is red then the TMA is currently

in the zenith blind spot.

Limits Override – This is green if the limits are not over ridden and red if they are. Currently this flag is

hard coded to false in the simulator i.e. limits not over ridden



The button labelled MCS events opens a screen that displays the contents of the main MCS event streams

e.g. atst.tcs.mcs.cPos etc.

The set of tabs located at the top left hand side of the screen are for control of the MCS simulator. The

first tab is the lifecycle tab.

Figure 63. MCS lifecycle command tab.

The lifecycle command tab displays the current lifecycle state of each of the controllers. The lifecycle

state of the controllers can be changed by right clicking on the atst.tcs.mcs lifecycle widget and selecting

the new lifecycle state. The top level controller atst.tcs.mcs is a management controller and is configured

through the property service to manage the controllers beneath it so, initializing and starting this top level

controller will initialize and start all the controllers underneath.

The mode tab can be used to submit a new mode attribute to the atst.tcs.mcs controller. Click on the

required mode to submit the attribute. This mode attribute is normally expected to be sent from the TCS.



Figure 64. MCS mode command tab.

If “Off” is selected the azimuth, altitude and coudé drive systems set the brakes and power off the drive

motors. This is the default startup state of the simulator. In “Active” mode the drives systems are powered

on and the brakes are released. The servos are active and hold the axes at their current positions. Finally,

if “Tracking” is selected then the drive systems begin tracking the stream of position demands from the

TCS contained in the event atst.tcs.mcsTrajectory.

The move command tab allows specific position demands to be submitted to the MCS.



Figure 65. TMA move command tab.

To move the axes to a specific position enter the value in degrees into the corresponding entry box and

click on submit. It is not necessary to enter a value in every box, any that are left blank are simply

ignored and no attribute is submitted for that axis. Named positions can also be entered into the box if

required. For example to move the azimuth axis to its stow position enter “stow” into the azimuth box

and click on submit.

Current valid named positions are service1, stow, lolo, lo, hi and hihi.

The cover command tab is used to turn the power on or off to the cover and to open or close the cover.

Click on the corresponding button to submit the attribute to the atst.tcs.mcs controller.



Figure 66. MCS cover command tab.

The camera command tab is used to turn the TMA camera on or off. Click on the corresponding button to

submit the attribute to the atst.tcs.mcs controller.

Figure 67. MCS camera command tab.



As well as the command tabs there are status tabs present at the bottom of the screen. The axes overview

tab provides status for each individual axis. The mode, position, velocity, error and in position status are

displayed in the table. Currently (for this release) the error is not functional.

Figure 68. TMA axes overview status tab.

The cover and camera status tab displays the current position, power and brake status of the cover and the

current status of the camera. If the LED indicators are red then they indicate the off state and if they are

green they indicate the on state.

Figure 69. TMA cover and ancillary status tab.

9.2 ECS SIMULATOR

The ECS is responsible for the operation of the enclosure and its subsystems. This includes the carousel,

shutter and aperture entrance cover.



Figure 70. ECS simulator main display.

The ECS simulator provides the following set of simulated controllers:

atst.tcs.ecs

atst.tcs.ecs.az

atst.tcs.ecs.alt

atst.tcs.ecs.aux

atst.tcs.ecs.cover

atst.tcs.ecs.emcs

The controllers are designed to match the ICD specification between the ECS and TCS [5]. There is

some basic functionality present in the simulated system, including two simulated servo devices that can

track the demand stream from the TCS and provide realistic feedback to the TCS for its upstream position

calculations.

The main screen (shown above) contains two sets of tabs and some additional status. The status items are

displayed on the top right hand side of the screen.

Mode – The current overall mode of the ECS, one of off, active or tracking. This mode has identical

meanings to those of the TMA (see Section 9.1)

In Position – An indicator to show the overall in position status of the ECS. If the LED is green then all


Zenith Blind Spot – An indicator to show if the ECS has entered the zenith blind spot. If the LED is

green then the ECS is not currently in the zenith blind spot. If the LED is red then the ECS is currently in

the zenith blind spot.



Limits Override – This is lit green (= false or off) if the limits are not being over ridden and red

otherwise. Currently in the simulator this is hard coded to false.

The button labelled ECS events opens a screen that displays the contents of the main ECS event streams

The set of tabs located at the top left hand side of the screen are for control of the ECS simulator. The


Figure 71. ECS lifecycle command tab.


state of the controllers can be changed by right clicking on the atst.tcs.ecs lifecycle widget and selecting

the new lifecycle state.

The mode tab can be used to submit a new mode attribute to the atst.tcs.ecs controller. Click on the




Figure 72. ECS mode command tab.

The move command tab allows specific position demands to be submitted to the ECS.

Figure 73. ECS move command tab.

To move the axes to a specific position enter the value in degrees (or mm for plate) into the corresponding

entry box and click on submit. It is not necessary to enter a value in every box, any that are left blank are

simply ignored and no attribute is submitted for that axis. Named positions can also be entered into the



box if required. For example to stow the carousel axis enter “stow” into the carousel box and click on

submit.

The following named positions are supported for the carousel: stow, servicePos[1], servicePos[2],

limitLo, LimitLoLo, limitHi and limitHiHi.

For the shutter the supported named positions are stow, servicePos[1], servicePos[2], servicePos[3],

servicePos[4], servicePos[5], limitLoLo, limitLo, limitHiHi and limitHi.

Note that neither the carousel nor the shutter support an index position.

The auxiliary command tab provides buttons to interact with the various mechanism states within the

ECS. These buttons do not submit attributes within configurations but instead issue set commands with

the attribute inside an attribute table. There is a corresponding indicator for each mechanism to display

the current state. Setting these attributes allows the ECS to generate events with the correct values for

testing purposes. The following mechanism states can be set from this tab:

Crane bridge – Park or un-parked

Crane jib – Park or un-parked

Platform lift – Park or un-parked

Inner door – Open, close, half or manual

Outer door – Open, close, half or manual

Door railing – On or off

High bay lights – On or off

Low bay lights – On or off

Figure 74. ECS auxiliary command tab.

The debug command tab is currently not used.



The shutters command tab provides buttons to interact with the various latches and seals within the ECS.

These buttons do not submit attributes within configurations but instead issue set commands with the

attribute inside an attribute table. There is a corresponding indicator for each mechanism to display the

current state. In each case the mechanism can either be set to on or off.

Figure 75. ECS shutters command tab.

The cover and aperture command tabs are currently left with old style configuration widgets that can be

used to submit attributes to the controllers.

As well as the command tabs there are status tabs present at the bottom of the screen. The axes overview

tab provides status for each individual axis. The mode, position, velocity, error and in position status are

displayed in the table.

Figure 76. ECS axes overview status tab.

The cover and ancillary status tab displays the cover position, power and brake status and allows these

values to be changed using set buttons.



Figure 77. ECS cover and auxiliary status tab.

9.3 M1CS SIMULATOR

Figure 78. M1CS simulator main display.

The M1CS simulator provides a set of simulated controllers:

atst.tcs.m1cs

atst.tcs.m1cs.axial

atst.tcs.m1cs.lateral

atst.tcs.m1cs.thermal

atst.tcs.m1cs.shape

The controllers are designed to match the ICD specification between the M1CS and TCS [7]. There is

some basic functionality present in the simulated system, including the ability to move the M1 in the x, y,



z, tip, tilt and rotation frames and the ability to set modes throughout the system. The main screen

(shown above) contains two sets of tabs and some additional status. The status items are displayed on the

top right hand side of the screen.

Mode – The current overall mode of the M1CS, one of off, passive or active.

In Position – An indicator to show the overall in position status of the M1CS. If the LED is green then all


Static LUT – An indicator to show if the static force lookup table is in use.

Altitude LUT – An indicator to show if the altitude force lookup table is in use.

Azimuth LUT – An indicator to show if the azimuth force lookup table is in use.

Temperature LUT – An indicator to show if the temperature force lookup table is in use.

aO Mirror Modes – An indicator to show whether active optics mirror mode data are accepted from the

WCCS.

aO Force Modes – An indicator to show whether active optics force map data are accepted from the

WCCS.

The set of tabs located at the top left hand side of the screen are for control of the M1CS simulator. The


Figure 79. M1CS lifecycle command tab.




state of the controllers can be changed by right clicking on the atst.tcs.m1cs lifecycle widget and selecting


The mode tab can be used to submit a new mode attribute to the atst.tcs.m1cs controller. Click on the


Figure 80. M1CS mode command tab.

The M1 position tab can be used to send demand positions to the M1. Individual axes can be commanded

by simply leaving all of the other entries blank. Click on submit to send the positions to the M1CS.



Figure 81. M1CS M1 position command tab.

The aO mirror modes and aO force modes flags can be turned on or off from the aO flags command tab

by clicking on the corresponding button.

Figure 82. M1CS aO flags command tab.



The state of each lookup table can set from the lookup table command tab. Clicking on an “ON” button

on this tab results in the corresponding lookup table being used for the mirror shape. The simulator sets

the flag appropriately but no actual lookups are carried out for the mirror shape.

Figure 83. M1CS lookup tables command tab.

The thermal command tab provides low level access to and higher level mode control of the thermal

controller. Click on any of the mode buttons to set the mode of the controller by submitting a

configuration. The buttons and text entry boxes on the left of the tab will perform a lower level set on the

controller to update its cache of data items.



Figure 84. M1CS thermal control tab.

As well as the command tabs there are status tabs present at the bottom of the screen. The M1 position

status tab displays the current position of each axis of the M1 mirror (x, y, z, tip, tilt and rotation).

Figure 85. M1CS M1 position status tab.

The axial status tab displays the current mode, in position flag, force and associated errors for the first 5

elements of the axial controller’s status event (atst.tcs.m1cs.axial.cStatus).



Figure 86. M1CS axial status tab.

The lateral status tab displays the current mode, in position flag, force and associated errors for the first 5

elements of the lateral controller’s status event (atst.tcs.m1cs.lateral.cStatus).

Figure 87. M1CS lateral status tab.

The shape status tab displays the current mode of the shape controller along with all elements of the

currently applied lookup tables, the current integrated values incoming from the WCCS system and the

total of these two.

Figure 88. M1CS shape status tab.



The thermal status tab displays the current mode of the thermal controller. Below this the in position flag

is displayed along with the aperture and rear cooling flags. The current offset temperature, mirror

temperature, air temperature, temperature difference and raw temperatures are also displayed.

Figure 89. M1CS thermal status tab.

9.4 PA&C SIMULATOR

Figure 90. PA&C simulator main display.



The PA&C simulator provides a set of simulated controllers:

atst.tcs.pac

atst.tcs.pac.gos

atst.tcs.pac.gos.level3

atst.tcs.pac.gos.level3.slide

atst.tcs.pac.gos.level3.optic6












atst.tcs.pac.gos.box

atst.tcs.pac.gos.box.thermal

atst.tcs.pac.gos.box.power

The controllers are designed to match the ICD specification between the PA&C and TCS [8]. The

functionality provided includes the ability to set the mode, move the various slides to selected optics and

then orient the optics to demanded positions. The main screen (shown above) contains two main sets of

tabs and some additional status. The status items are displayed on the top right hand side of the screen.

The tabs labeled Level3, Level2, Box, Test Level 3 and Test Level 2 are just for debugging and can be

ignored.

Mode – The current overall mode of the PA&C, one of active or off. It is only possible to move the slides

and optics in active mode.

Current thermal mode – The state of thermal control, one of off, housekeeping, precondition, ondisk,

coronal or maintenance

Levels, optics and their state – for each level in the GOS the currently selected optic and its state is shown

The tab located at the top left hand side of the screen shows the lifecycle state of each controller



Figure 91. PA&C lifecycle command tab.


state of the controllers can be changed by right clicking on the atst.tcs.pac lifecycle widget and selecting

the new lifecycle state. Due to the large number of controllers only the GOS level and box controllers are

shown on the main tab. To access the lifecycle states of the sub controllers then click the buttons on the

right hand side. Clicking the button will launch another screen with the sub controllers displayed. The

level1 sub-controller screen is shown below



Figure 92. PA&C level 1 controller lifecycle display.

The main tabs for the control of the simulator are found at the bottom of the main screen. The control tab

permits the mode to be changed as well as selecting the optic for each level and then its state. The state

displayed for optics that can rotate is its orientation. For optics that don’t rotate the state is displayed as

fixed.

The thermal tab is shown below



Figure 93 PA&C Thermal control

The main control buttons are on the left hand side. When not observing the normal thermal mode of the

PA&C will be housekeeping. If automatic mode transitions are set then at a pre-determined time the

PA&C will automatically switch to precondition mode and later to ondisk or coronal. The transition times

can be set by the controls in the center of the screen. The end time refers to the time at which the

transition to ondisk or coronal will take place. Subtracting the duration from that end time gives the time

at which pre-conditioning will start.

9.5 WCCS SIMULATOR

Figure 94. ECS simulator main display.

The WCCS simulator provides a set of simulated controllers:

atst.tcs.wccs

atst.tcs.wccs.hoao

atst.tcs.wccs.lowfs

atst.tcs.wccs.ao

atst.tcs.wccs.cv



atst.tcs.wccs.lt

These controllers are designed to match the ICD specification between the WCCS and TCS [6]. There is

some basic functionality present in the simulated system, such as the ability to generate errors for the M2,

M3 and M6 monitoring applications. The main screen (shown above) contains two sets of tabs and some

additional status. The status items are displayed on the top right hand side of the screen.

Mode – The current overall mode of the WCCS, one of off, idle, calibrate, diffractionLimited,

seeingLimitedOnDisk, seeingLimitedCoronal or limbTracking.

In Position – An indicator to show the overall in position status of the WCCS. If the LED is green then

all mechanisms are in position and if the LED is red then at least one mechanism is not in position.

Mode Table – A table displaying the mode for each of the WCCS subsystems.

The set of tabs located at the top left hand side of the screen are for control of the WCCS simulator. The


Figure 95. WCCS lifecycle command tab.


state of the controllers can be changed by right clicking on the atst.tcs.wccs lifecycle widget and selecting




The mode tab can be used to submit a new mode attribute to the atst.tcs.wccs controller. Click on the


Figure 96. WCCS mode command tab.

If the mode is set to “closed” then the WCCS begins to update the tip/tilt errors for M2, M3 and M6 and

the position errors for M2. The tip/tilt errors follow sinusoidal variations over varying periods of time

and the position errors are randomly generated. If the mode is set to any value other than “closed” then

these values are all zeroed.

The figure tab provides control over the event that sends correction modes to the M1CS



Figure 97 Controls for sending mode corrections to the M1CS

The top two rows of the panel provide control over the event itself. The event can be disabled completely

or, if enabled, the interval between events can be set.

The type of data can also be set. The WCCS can send corrections as modes or it can generate the whole

force map itself and send an array of 118 forces. If modes are sent then there is a choice of natural or

Zernike modes.

If it is required to zero out all the accumulated corrections already sent to the M1CS then click the “Zero

offsets” button. The M1CS will still apply any open loop lookup table corrections but the accumulated

corrections it has already received from the WCCS will be set to zero.

For simulation purposes user specified corrections can be entered. Clicking the “Manually specify modes”

button starts the screen shown below



Figure 98 Screen to manually enter mode corrections

Two tables are provided. Values can be typed in for any of the individual Zernike of natural mode

coefficients. These values can then be submitted. The set that are sent will depend on the currently

selected modal basis. The submit is a one off operation. Once they have been sent with an event the next

and subsequent events are posted with all corrections set to zero. This means the M1CS can be put in

active mode and the effect of applying known correction modes monitored.

As well as the command tabs there are status tabs present at the bottom of the screen. The tip tilt offload

tab displays the contents of the tip tilt offload event for the TCS (atst.tcs.wccs.tipTiltOffload).

Figure 99. WCCS tip tilt offload status tab.

The tip tilt errors status tab displays the contents of the M2 fast tip tilt error event

(atst.tcs.wccs.m2TipTiltError), and the M3 and M6 tip tilt error events (atst.tcs.wccs.m3TipTiltError and

atst.tcs.wccs.m6TipTiltError). The M2 error event is posted at 20Hz and the M3 and M6 error events are

posted at 0.02Hz. Due to this last relatively slow rate it may be some time before you see these numbers

update.



Figure 100. WCCS tip tilt errors status tab.

The M2 position errors status tab displays the contents of the M2 hexapod position error event

(atst.tcs.wccs.m2PosError). This event is posted as 0.02Hz and contains the errors that should be applied

to the hexapod axes. Note again that the slow update rate can mean it is some time before you see the

numbers update.

Figure 101. WCCS M2 position errors status tab.

The M1 figure error status tab displays the contents of the mirror modes event

(atst.tcs.wccs.m1FigureError). The timestamp of the calculation is displayed along with the currently

active state (mm or force). The two corresponding arrays of values (mm and force) are also displayed.

Figure 102. WCCS M1 figure error status tab.

9.6 FOCS SIMULATOR

The Feed Optics Control System is responsible for positioning both axes of the M3 and M6 as well as the

thermal monitoring of all mirrors in the FOA.



Figure 103. FOA simulator main display.

The FOA simulator provides the following set of simulated controllers:

atst.tcs.focs

atst.tcs.focs.m3

atst.tcs.focs.m6

atst.tcs.focs.thermal

The controllers are designed to match the ICD specification between the FOA and TCS [10]. There is

some basic functionality present in the simulated system, including the ability move the tip/tilt systems

for M3 and M6 and turn on and off particular lookup tables. The main screen (shown above) contains

two sets of tabs and some additional status. The status items are displayed on the top right hand side of

the screen.

Mode – The current overall mode of the FOA, one of off, passive or active.

In Position – An indicator to show the overall in position status of the FOA. If the LED is green then all


Static LUT – An indicator to show if the static lookup table is currently in use. If the LED is green then

the lookup table corrections are being applied. If it is red then they are not.

Altitude LUT – An indicator to show if the altitude lookup table is currently in use. If the LED is green

then the lookup table corrections are being applied. If it is red then they are not.

Azimuth LUT – An indicator to show if the azimuth lookup table is currently in use. If the LED is green




Temperature LUT – An indicator to show if the temperature lookup table is currently in use. If the LED

is green then the lookup table corrections are being applied. If it is red then they are not.

Coupling M3/M6 – An indicator to show if M6 corrections are coupled to M3 corrections. If the LED is

green then the M6 corrections are currently ignored and M6 is being coupled to the M3 corrections (with

scaling). The current coupling simply rotates the M3 corrections by the current altitude angle. If the LED

is red then M6 is using its own corrections.

The set of tabs located at the top left hand side of the screen are for control of the FOA simulator. The


Figure 104. FOA lifecycle command tab.


state of the controllers can be changed by right clicking on the atst.tcs.focs lifecycle widget and selecting




Figure 105. FOA mode command tab.

The mode tab can be used to submit a new mode attribute to the atst.tcs.focs controller. Click on the


This command tab also provides the functionality to clear any currently applied corrections. Click on the

“Clear” button in the clear corrections widgets to submit the attribute. The coupling state of the M3 and

M6 can be controlled by clicking on the “On” or “Off” buttons in the M3/M6 coupling widget and the

ratio of corrections applied when the two systems are coupled can be set by entering the required value in

the text entry box and clicking on the submit button.



Figure 106. FOA M3 tip tilt command tab.

The M3 tip tilt command tab provides widgets to allow the indexing of the tip tilt device, clearing of the

current M3 corrections and text entry boxes to allow submitting of a specific tip tilt demand position. If a

text entry is left blank then no attribute is sent for that axis. As well as accepting specific positions,

named positions can also be sent. The named positions supported are stow, index, limitLoLo, limitLo,

limitHi and limitHiHi.

Note that when in passive mode the tip/tilt controller positions the tip/tilt axes based on lookup tables. It

is important therefore to disable the lookup tables when moving to a fixed or named position or otherwise

the next time the lookup table is invoked the axes will be driven back to their table positions.



Figure 107. FOA M6 tip tilt command tab.

The M6 tip tilt command tab provides widgets to allow the indexing of the tip tilt device, clearing of the

current M6 corrections and text entry boxes to allow submitting of a specific tip tilt demand position. The

layout of the tab is identical to the M3 tip tilt mentioned above. As with the M3 command tab, named

positions can be entered into the tip and tilt fields instead of specific positions. Again, if moves to

specific or named positions are being issued in passive mode it is important to disable the lookup tables or

else the next time they are invoked the mirror will be driven back to the default lookup table position.

The state of each lookup table can be set from the lookup table command tab. Clicking on an “ON”

button on this tab results in the corresponding lookup table being used for the M3 and M6 corrections.

Clicking on the “OFF” button turns off the corresponding lookup for the M3 and M6 corrections. Lookup

tables for the axes are implemented as follows

𝐴 ∗ cos(𝑎𝑧) + 𝐵 ∗ sin(𝑎𝑧)

𝐶 ∗ cos(𝑎𝑙𝑡) + 𝐷 ∗ sin(𝑎𝑙𝑡)

𝐸 ∗ (𝑇 − 𝑇0)

𝐹

For the azimuth, altitude, thermal and static lookup tables respectively. The coefficients can be changed

by editing the property database.



Figure 108. FOA lookup table command tab.

The temperature status data can be controlled directly from the engineering command tab. This level of

control is purely available to simulate what might happen within the real system. Values entered from

this tab are set in the controller, no attributes are submitted via configurations. The in position flag of the

thermal controller can be set using the “TRUE” and “FALSE” buttons. It is also possible to set the M3,

M4 and M6 temperature and corresponding error values by simply entering the value into the text box and

pressing the return key. As stated in the tab, it can take up to 50 seconds for these changes to show up in

the events posted from the FOA thermal controller.



Figure 109. FOA engineering command tab.

As well as the command tabs there are status tabs present at the bottom of the screen. The M3 tip tilt

device status tab displays the current state of the M3 tip tilt mechanism. The in position and power state

is displayed as LEDs (green is on and red is off). The table below shows the current position, error

(difference between the demand and current position), in position flag, indexed flag, is indexing flag and

current limit flag for each of the axes. If the axis is not at a predefined limit then the limit display will

show “none”.

Figure 110. FOA M3 tip tilt status tab.

The M6 tip tilt device status tab displays the current state of the M6 tip tilt mechanism. The in position

and power state is displayed as LEDs (green is on and red is off). The table below shows the current

position, error (difference between the demand and current position), in position flag, indexed flag, is

indexing flag and current limit flag for each of the axes. If the axis is not at a predefined limit then the

limit display will show “none”. The M6 status tab also has an LED to show if it is currently coupled to

M3 and an indicator to show the ratio between the corrections of the two mechanisms.



Figure 111. FOA M6 tip tilt status tab.

The errors status tab displays the currently applied corrections for each axis of each mechanism for each

of the four lookup tables, static, altitude, azimuth and temperature.

Figure 112. FOA errors status tab.

The thermal status tab displays the current mode of the thermal controller and the in position flag. For

each mechanism (M3, M4 and M6) the current temperature and temperature error is also displayed.

Figure 113. FOA thermal status tab.

9.7 ACS SIMULATOR

The ACS is the telescope system responsible for providing full disk solar images for target identification

and acquisition during operations.



Figure 114. ACS simulator main display.

The ACS simulator provides a set of simulated controllers:

atst.tcs.acs

atst.tcs.acs.camera

The controllers are designed to match the ICD specification between the ACS and TCS [9]. There is

some basic functionality present in the simulated system, including the ability to set the mode, the number

of frames to be saved and the interval between frames. The main screen (shown above) contains a single

set of tabs and some additional status. The status items are displayed on the top right hand side of the

screen.

Mode – The current overall mode of the ACS, one of off, passive or active.

DHS Saving Images – An indicator to show if images are currently being saved. If the LED is green then

images are being saved if the LED is red then they are not.

Frames to be saved – An indicator showing the number of frames that should be saved.

Frames interval – An indicator showing the interval (in seconds) between saved frames.

The set of tabs located at the top left hand side of the screen are for control of the ACS simulator. The




Figure 115. ACS lifecycle command tab.


state of the controllers can be changed by right clicking on the atst.tcs.acs lifecycle widget and selecting


The mode tab can be used to submit a new mode attribute to the atst.tcs.acs controller. Click on the


Figure 116. ACS mode command tab.

The save to DHS command tab is used to turn on or off the save to DHS attribute. Clicking on either of

the buttons submits the attribute to the ACS and the corresponding indicator will update appropriately.



Figure 117. ACS save to DHS command tab.

The save parameters command tab is used to set the number of frames to be saved and the interval

between frames (in seconds). Enter the required value for each in the text entry boxes and click on the

submit button to submit the attributes to the ACS. The corresponding status items will update to reflect

the values submitted.

Figure 118. ACS save parameters command tab.

The events tab simply displays the ACS cStatus event (atst.tcs.acs.cStatus) for debugging purposes.



Figure 119. ACS events tab.

9.8 TEOA SIMULATOR

The Top End Optical Assembly Control System is responsible for the secondary mirror positioning and

tip/tilt system as well as the thermal management systems of the M2 Mirror and heat stop.

Figure 120. TEOACS simulator main display.

The TEOACS simulator provides a set of simulated controllers:

atst.tcs.teoacs

atst.tcs.teoacs.m2pos



atst.tcs.teoacs.m2tt

atst.tcs.teoacs.lyot

atst.tcs.teoacs.thermal

These controllers are designed to match the ICD specification between the TEOACS and TCS [11].

There is some basic functionality present in the simulated system, including the ability to set the mode,

movement of the M2 hexapod and tip tilt mechanism and positions of the lyot and thermal controllers.

The main screen (shown above) contains two sets of tabs and some additional status. The status items are

displayed on the top right hand side of the screen.

Mode – The current overall mode of the TEOACS, one of off, passive or active. When off the M2

positioner and tip/tilt systems are de-energized. When passive, the drive systems servos are running and

holding the current position using the enabled lookup tables. Finally, when active the drive systems are

holding their current positions using both the enabled lookup tables and input from the WCCS

In Position – An indicator to show the overall in position status of the TEOACS. If the LED is green then

all mechanisms are in position and if the LED is red then at least one mechanism is not in position.

Static LUT – An indicator to show if the static lookup table is currently in use. If the LED is green then

the lookup table corrections are being applied. If it is red then they are not.

Altitude LUT – An indicator to show if the altitude lookup table is currently in use. If the LED is green


Azimuth LUT – An indicator to show if the azimuth lookup table is currently in use. If the LED is green


Temperature LUT – An indicator to show if the temperature lookup table is currently in use. If the LED

is green then the lookup table corrections are being applied. If it is red then they are not.

The set of tabs located at the top left hand side of the screen are for control of the TEOACS simulator.

The first tab is the lifecycle tab.



Figure 121. TEOACS lifecycle command tab.


state of the controllers can be changed by right clicking on the atst.tcs.teoacs lifecycle widget and

selecting the new lifecycle state. This controller manages all the underlying controllers so issuing say

“Initialize” will initialize the whole controller tree.

Once the controllers are started the mode tab can be used to submit a new mode attribute to the

atst.tcs.teoacs controller. Switching the mode to active or passive will power up the positioner and tip/tilt

controllers. This mode attribute is normally expected to be sent from the TCS. From the mode command

tab the currently applied corrections from the WCCS can be cleared by clicking on the “Clear” button.



Figure 122. TEOACS mode command tab.

The M2 position command tab provides widgets to allow the indexing of all axes of the M2 hexapod

device, clearing of the current M2 corrections from the WCCs and text entry boxes to allow submitting of

a specific x, y, z, tip, tilt or rotation demand position. When submitting a set of positions either absolute

values or named positions can be entered into the text boxes (or a combination of both). Any text boxes

that are left blank are not submitted to the TEOACS controller.



Figure 123. TEOACS M2 position command tab.

The allowed named positions with the move command are stow, index, limitLoLo, limitLo, limitHiHi and

limitHi. Note that use of the index named position allows indexing of individual axes rather than indexing

all axes through the index button.

Note that when using the move command either with specific positions or named positions you should

first disable the LUT tables. If this is not done the axes will be driven back to their computed LUT

positions next time the LUT tables are computed.



Figure 124. TEOACS M2 tip tilt command tab.

The M2 tip tilt command tab provides widgets to allow the indexing of the M2 tip tilt device, clearing of

the current M2 tip tilt corrections and text entry boxes to allow submitting of a specific tip or tilt demand

position. When submitting a set of positions either absolute values or named positions can be entered into

the text boxes (or a combination of both). Any text boxes that are left blank are not submitted to the

TEOACS controller.



Figure 125. TEOACS lookup table command tab.

The state of each lookup table can be set from the lookup table command tab. Clicking on an “ON”

button on this tab results in the corresponding lookup table being used for the M2 corrections. Clicking

on the “OFF” button turns off the corresponding lookup for the M2 corrections. The static lookup table

corrections can be set by entering values into the lookup table text entry boxes and clicking on the submit

button.

Lookup tables for the axes are implemented as follows

𝐴 ∗ cos(𝑎𝑧) + 𝐵 ∗ sin(𝑎𝑧)

𝐶 ∗ cos(𝑎𝑙𝑡) + 𝐷 ∗ sin(𝑎𝑙𝑡)

𝐸 ∗ (𝑇 − 𝑇0)

𝐹

For the azimuth, altitude, thermal and static lookup tables respectively. The coefficients can be changed

by editing the property database.



Figure 126. TEOACS engineering command tab.

The engineering command tab provides low level access to the lyot stop controller and the thermal

controller. The widgets on this tab do not submit any attributes to the controllers; instead they perform

sets to set the internal cached values. The lyot stop power can be turned on or off and its current position

can be set to one of in, out, unknown or between. The temperature in position flag can also be set and the

M2 and HS temperature values and errors can be set by entering the value into the text entry box and

pressing return.

Note that there is currently an issue with the JES text entry widgets that attempt to specify the set

temperatures that makes these widgets non-functional. This is a known issue with the JES.

As well as the command tabs there are status tabs present at the bottom of the screen as shown in the

following figures.



Figure 127. TEOACS M2 positions status tab.

The M2 positions status tab displays the current state of the M2 hexapod mechanism. The in position and

power state is displayed as LEDs (green is on and red is off). The table below shows the current position,

error (difference between the demand and current position), in position flag, indexed flag, is indexing flag

and current limit flag for each of the axes. If the axis is not at a predefined limit then the limit display

will show “none”. The positions will update automatically in passive mode if any of the lookup tables are

enabled. Similarly they will update in active mode if the WCCS is operating in closed mode. Note that

LUT corrections and WCCS events occur only at 0.02Hz so it can be a while before an update is seen.

The M2 tip tilt status tab displays the current state of the M2 tip tilt mechanism. The in position and

power state is displayed as LEDs (green is on and red is off). The table below shows the current position,

error (difference between the demand and current position), in position flag, indexed flag, is indexing flag

and current limit flag for each of the axes. If the axis is not at a predefined limit then the limit display

will show “none”.

Figure 128. TEOACS M2 tip tilt status tab.

The lyot stop and temperature status tab shows the current position and power state of the lyot stop. The

in position state of the thermal controller is represented by an LED and the M2 and HS current

temperature and temperature error values are displayed.

Figure 129. TEOACS lyot and temperature status tab.



10. UNIT TESTING

At FAT, the TCS was supplied with a set of testing scripts and an engineering screen that could be used to

execute those tests. Those tests have now been ported to the Test Automation Framework (TAF) and are

described in detail in [18]. This section describes that earlier testing environment and is currently retained

for historic reasons but may be removed in later revisions.

The tests are written in the python scripting language and utilize the scripting facilities provided as part of

the CSF infrastructure. The scripting provides access to all CSF services and can be used to interact with

CSF applications. A complete description of the CSF scripting facilities can be found in [2]. The test

scripts submit configurations to the TCS application and capture the results through the use of the CSF

connection and event services. The results of the test scripts are logged using the CSF logging service

and can be reviewed using standard CSF logging facilities. The scripts are all stored in the test

directory of the TCS application.

The pointing kernel controller can be started in test mode. Note that once started the pointing kernel

controller mode CANNOT be altered. This prevents accidentally changing the mode of the controller

whilst the TCS application is running with real hardware. Some of the test scripts require the pointing

kernel to be running in a particular mode, and these will state the mode required. A full description of

how to start the pointing kernel controller in the test mode can be found in section 4.

10.1 UNIT TEST ENGINEERING INTERFACE

The unit test engineering interface is a JES screen with some specialized widgets created for the purposes

of testing CSF applications. A screen shot of the testing interface is shown below.



Figure 130. TCS test utility JES widget.

To load a set of tests simply click on the “Add” button. A file selector opens and the test script can be

selected. Once loaded, the tests will appear in the “Test Library” list box. To execute a test simply select

the test using the “Test Library” list and click on the “Execute” button. As the tests are executed

messages are logged and the results of individual test steps are also logged. These log messages are

displayed in the results table at the bottom of the screen. Some tests require operator input and if this is

the case then a dialog box will automatically open requesting that the operator enter the necessary

information. The test will halt execution until the operator has entered the information requested and

clicked on “Continue”.

Knowledge of the python scripting language is required to be able to update the test scripts.



11. REFERENCES

[1] Systems Engineering Group, Glossary of Terms and Abbreviations, SPEC-0012, Rev. G

[2] Guzzo, S., Cummings, K., Hubbard, J., Wampler, S. and Goodrich, B., Common Services

Framework Reference Guide, SPEC-0022-02, Rev. K

[3] Mayer, C. & Wampler, S., Observatory Control System to Telescope Control System Interface.

ICD 4.2/4.4, Rev. B.

[4] Goodrich, B. & Jeffers, P., Telescope Mount Assembly to Telescope Control System Interface.

ICD 1.1/4.4, Rev. F.

[5] Goodrich, B., Borrowman, A. & Marshall, H., Telescope Control System to Enclosure Control

System Interface. ICD 4.4/5.6, Rev. F.

[6] Goodrich, B. & Richards, K., Wavefront Correction Control System to Telescope Control

System Interface. ICD 2.3/4.4, Rev. C.

[7] Goodrich, B. & Hubbard, J. & Gonzales, K., M1 Assembly to Telescope Control System

Interface. ICD 1.2/4.4, Rev. D.

[8] Goodrich, B. & Ferayorni, A., Polarimetry Analysis and Calibration to Telescope Control

System Interface. ICD 3.1.1/4.4, Rev. A.

[9] Goodrich, B. & Hansen, E., Acquisition Control System to Telescope Control System Interface.

ICD 1.8/4.4, Rev. A.

[10] Goodrich, B. & Hansen, E., Feed Optics Assembly to Telescope Control System Interface. ICD

1.5/4.4, Rev. B.

[11] Goodrich, B. & Liang, C., Top End Optical Assembly to Telescope Control System Interface.

ICD 1.3/4.4, Rev. D.

[12] Wallace, P.T, TPOINT – A Telescope Pointing Analysis System

[13] Greer, A., Hubbard, J. & Wampler, S., Java Engineering Screens User Manual, TN-0089, Rev

E-1.

[14] Greer, A & Mayer, C., Telescope Control System Oracle (Ephemeris Service) Manual, MAN-

0012, Rev. F.

[15] C SPICE Toolkit, Navigation and Ancillary Information Facility (NAIF),

naif.jpl.nasa.gov/naif/toolkit.html

[16] Acton, C.H.; "Ancillary Data Services of NASA's Navigation and Ancillary Information

Facility;" Planetary and Space Science, Vol. 44, No. 1, pp. 65-70, 1996.

[17] Thompson, W. T., (2005) Coordinate systems for solar image data, Astron. & Astrophys., 449,

791

[18] Greer, A. & Mayer, C., Telescope Control System Test Plan, PROC-0026, Rev. D.

Documents

Software Operations Manual...Operations Manual Alan Greer & Chris Mayer Observatory Sciences Ltd November 30, 2016. TCS Software Operations Manual MAN-0013 Rev A Page ii Revision Summary: