Telescope Control System Preliminary Design Review Chris Mayer, Dave Terrett & Pat Wallace

Overview Introduction (Bret) Overview of TCS Design (CJM) The Pointing Kernel (DLT) Subsystem Control (CJM/DLT) Outstanding Issues

TCS Overview Responsibilities of TCS To provide a high quality stable image of user specified points of the solar disk or corona to instruments at Gregorian, Nasmyth or Coude focal planes To coordinate and monitor the activities of the TCS subsystems To provide an easy to use engineering interface for use during commissioning and engineering To provide an interface compatible with the ATST common services for use by OCS and ICS

TCS Overview TCS does not control hardware directly Hardware control is responsibility of the TCS subsystems

TCS Context TCS Interfaces with DHS, OCS, ICS, Real Time database TCS subsystems AGS, MCS, M1CS, M2CS, FOCS, HSA, WCCS, ECS GIS Time system

DHS OCS ICS GIS Database Server TCS AGCS ECS WCCS MCS M1CS M2CS FOCS Configurations Configurations TCS Status TCS Status Defaults TCS Status GIS Database Server Interlocks TCS TCS State Configurations + TCS Status AGCS ECS Status WCCS MCS M1CS M2CS FOCS HSA

System Constraints TCS is an ATST principal system Other principal systems are OCS, ICS, DHS TCS will be written in C++ Will make extensive use of ATST common services Configurations Device model Services

Configurations All control of TCS is via configurations Configurations consist of a table of attribute value pairs Attributes are named hierarchically and the name identifies the device to which the attribute will be sent

Configurations (Cont) Configurations are sent with a preset command Configurations have a unique id Examples Atst.tcs.focus coude1 Atst.tcs.tracking On

Devices Devices are a sub class of component that implement a state machine A small set of commands drive the device between its states

State model

State commands Online devices start in the off state. Don’t respond to commands nor generate nor monitor events. Online command drives system to idle state where it can accept commands Online is propagated down the device tree TCS devices will be configurable to ignore online command

State commands (Cont.) Offline Offline takes device back to Off state. Offline is also propagated down the device tree TCS devices can’t ignore offline Devices will have to be taken offline individually working from the bottom up if only part of the system needs to be taken down

State commands (Cont.) Preset Issued with a configuration Device will verify the configuration – this will involve passing pieces of the configuration to the relevant sub-devices with a preset. Only devices that have attributes in the configuration are preset Device stays in idle state Configuration is now said to be queued if the configuration was checked and was valid

State commands (Cont.) Start Propagated from top level device to those sub-devices that had attributes in the preset. Start always succeeds Device will go to busy state on receipt of start and then to either idle or fault on completion of actions associated with the configuration While device is busy it cannot accept another configuration

State commands (Cont.) Stop Pause/Resume Forces state machine back to idle. It stops the action in the device but does not necessarily stop the movement of any underlying mechanism (although it can do) Pause/Resume Pause / resume an action associated with a configuration Will not be used by TCS

State commands (Cont.) Set / Get Different in that they don’t cause state transitions in the device Set can set attributes in the current configuration Get will retrieve attributes from the current configuration

Services Major Services Connection Event Log Health For locating TCS subsystems and sub-devices Event For dispatching information to subsystems and monitoring Log For general logging and debug Health

Services (Cont.) Minor Services Archive Property Used for recording engineering data Property Retrieve and store (?) metadata associated with TCS components

tcs thermal ems pk seq mcs m1cs ecs m2cs focs wccs hsa agcs

TCS Devices Top level Thermal EMS Component that receives all configurations Thermal Monitors thermal state of whole TCS. Raises warnings if there are problems EMS Environmental Monitoring System provides data to pk for refraction corrections etc.

TCS Devices Pk Seq The main pointing engine of the ATST Sequencer to handle “simple” sequencing of TCS subsystems Most TCS sub-systems come under this device for now

Tracking Devices

Use case – Telescope startup

Subsystem Interfaces Common features All are controlled by configurations All provide state via event service All configurations go to top level device but some may pass transparently to sub-devices Ability to mask health status Ability to mask “in position” status

TCS/MCS Interface MCS is responsible for positioning the TMA plus the rotators Main mechanisms to control Altitude axis Azimuth axis Coude rotator Nasmyth rotator Gregorian (??) M1 cover

TCS/MCS Interface (cont) Mechanisms to monitor The above plus thermal sensors Major attributes mode – this can be datum, park, halt, move or follow. The mode determines how the mechanisms will respond to other attributes Followecs – used for azimuth and elevation if mount is to follow the enclosure

TCS/MCS Interface (Cont) Tracking – follows the trajectory generated by the TCS pk device. Trajectory consists of time, track identifier, position and velocity. The time is the time at which the position and velocity demands need to be met.

TCS/M1CS Interface M1CS responsible for all aspects of control of the primary mirror Figure control Axial and Lateral support Thermal control Main mechanisms to control Axial supports Lateral supports Thermal system

TCS/M1CS Interface (Cont) Major attributes Thermal model – reactive or predictive Control mode – None, Active or Passive aO corrections – On or Off

TCS/M2CS Interface M2CS must position the secondary mirror in all 6 DOF plus control the fast tip/tilt system and thermal state Main mechanisms to control Hexapod Fast tip/tilt (used when observing at Nasmyth) Thermal

TCS/M2CS Interface (Cont) Major attributes Mode – move, halt, follow (datum ? Park?) Follow is main operational mode. M2 tracks a model generated by the WCCS Thermal Control On or Off Tip/tilt On or Off

TCS/ECS Interface ECS controls operation of the ATST enclosure and its subsystems Mechanisms to control Carousel (azimuth) Shutter (altitude) Entrance cover Vent gates Fans Thermal Weather stations (??)

TCS/ECS Interface (Cont) Mechanisms to monitor The above plus crane, doors, interlocks Major attributes Mode – datum , park, halt, move, follow, followmcs Entrance cover position– Open or Closed Vent pattern – Identifier for pattern Fan settings Cooling mode

TCS/HSA Interface HSA plays critical role by preventing unwanted heat and light from solar disk from reaching subsequent optics Major mechanisms Occulter Lyot stop Thermal

TCS/HSA Interface (Cont) Major attributes Occulter mode – datum, park, halt, move, follow Closed loop – true or false. If true occulter demands are corrected by occulter sensor Lyot stop – In or Out Cooling – On or Off

Outstanding TCS Issues Where should M2 open loop model reside ? Currently it is in WCCS Is the device model really appropriate for the TCS ? Perhaps the new controller class is the way to go Where is boundary of weather station responsibilities ?

Outstanding TCS Issues Status of GOS Mount and Enclosure coordinated control