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

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

3. 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

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

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

6. 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

7. 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

8. 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

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

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

11. State model

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

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

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

21. 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.

22. 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

23. Tracking Devices

24. Use case – Telescope startup

25. 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

26. 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

27. 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

28. 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.

29. 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

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

31. 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

32. 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

33. 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 (??)

34. 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

35. 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

36. 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

37. 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 ?

38. Outstanding TCS Issues
Status of GOS
Mount and Enclosure coordinated control