ICD 1.1/4.4
Telescope Mount Assembly to Telescope Control System
Bret Goodrich, Alexei Ippa, Paul Jeffers
March 10, 2015
Version: I
Issued By: Software Group
Date:
Approved By: ___P. Jeffers_______________Lead Engineer (1.1) _17 Mar 2015_
___B. Goodrich_____________Lead Engineer (4.4) _17 Mar 2015_
___S. Craig________________ Systems Engineer _20 Mar 2015_
Telescope Mount Assembly to Telescope Control System
ICD 1.1/4.4 Rev I Page 2 of 33
Revision Control
1. Revision Version Draft 1
Date: 26thJanuary 2005
Revised by: Chris Mayer
Reason for / items changed: Original version.
2. Revision Version Draft2
Date: 8thFebruary 2005
Revised By: Chris Mayer
Reason for / items changed: Switch to new template and update in light of meetings at OSL
between 2-4 February 2005
3. Revision Version A
Date: 24 March 2006
Revised by: Bret Goodrich
Reason for / items changed: Changed to interface to TMA, removed device, removed
followecs mode, numerous design updates. Initial formal release.
4. Revision Version A1
Date: 28 March 2006
Revised by: Chris Mayer
Reason for / items changed: Merged back changes from Version 3.0 which were lost when
revision B was released. Update health event to match common services.
5. Revision Version A2
Date: 03 April 2006
Revised by: Bret Goodrich
Reason for / items changed: Fixed types and units for choice and Boolean attributes. Changed
versioning to the approved numbering scheme.
6. Revision Version A3
Date: 09 May 2006
Revised by: Chris Mayer
Reason for / items changed: Minor typos and name of health event set to __health as per
Panguitch release.
7. Revision Version A4
Date: 12 September 2006
Revised by: Bret Goodrich
Reason for / items changed: Formatting and renumbering revisions.
8. Revision Version A5
Date: 29 September 2006
Revised by: Chris Mayer
Reason for / items changed: Added top level m1cover attribute
9. Revision Version B
Date: 30 October 2006
Telescope Mount Assembly to Telescope Control System
ICD 1.1/4.4 Rev I Page 3 of 33
Revised by: Chris Mayer
Reason for / items changed: Added top level m1cover attribute. Reviewed at CDR.
10. Revision Version B1
Date: 21 June 2007
Revised by: Mark Warner
Reason for / items changed: Removed references to Nasmyth and Gregorian rotators; cleaned
up various errors and mistakes; changed certain specs (e.g., az rotation ranges), etc.
11. Revision Version C
Date: 29September 2008
Revised by: Bret Goodrich
Reason for / items changed: Rewrite for the SDR. Added more intro on CS, added more sensor
information, and more control loop configuration.
12. Revision Version C1
Date: 20 April 2009
Revised by: Bret Goodrich
Reason for / items changed: Updated from comment from SDR Reviewers.
13. Revision Version D
Date: 22 January 2010
Revised by: Bret Goodrich/Paul Jeffers
Reason for/items changed: added zenith flag, corrected properties.
14. Revision Version D1
Date: 21 July 2010
Revised by: Bret Goodrich, Alastair Borrowman
Reason for/items changed: reworked input modes, added explanatory information.
15. Revision Version E
Date: 25 August 2010
Revised by: Bret Goodrich, Alastair Borrowman, Chris Mayer
Reason for/items changed: removed MCS interlock event and topple bracket, changed demand
and current positions to go from -90 to +310 degrees, modified trajectory to polynomial
coefficients, changed namedpos limitpos[n] names, enforced camelCase, added isIndexed and
indexing event information, added cMode state, removed TCS from changing technical states,
added namedPos to the top-level controller.
16. Revision Version F
Date: 16 May 2011
Revised by: Bret Goodrich
Reason for/items changed: Changed status events to cStatus and cMode. Added track IDs.
Removed bearings.
17. Revision Version G
Date: 13 February 2013
Revised by: Bret Goodrich
Reason for/items changed: . Changed status events to cStatus and cMode. Added track IDs.
Removed bearings. Added wind deflection compensation. Removed ‘reset’ named position.
Telescope Mount Assembly to Telescope Control System
ICD 1.1/4.4 Rev I Page 4 of 33
18. Revision Version G1
Date: 15 May 2013
Revised by: Bret Goodrich
Reason for/items changed: Changed trajectory coefficients and timestamp from float to double.
19. Revision Version G2
Date: 11 March 2014
Revised by: Bret Goodrich
Reason for/items changed: New coude range of -90 to 450 degrees.
20. Revision Version H
Date: April 2014
Revised by: Bret Goodrich
Reason for/items changed: Updates per CR-0481. Changed trajectory coefficients and timestamp
data type to double. Changed the coude range to -90:+450. Changed the naming convention of the
various service positions. Added position tolerance average and max values. Added current
position error average and max status. Added max acceleration. Added hand-held device status.
21. Revision Version I
Date: 10 March 2015
Revised by: Alexei Ippa, Bret Goodrich
Reason for/items changed: Corrected the stow and service values to the factory default
positions.Updates per CR-0593.
Telescope Mount Assembly to Telescope Control System
ICD 1.1/4.4 Rev I Page 5 of 33
1. Description
This document specifies the interface between the Telescope Mount Assembly (TMA) and the Telescope
Control System (TCS). Within the DKIST Work Breakdown, these systems are defined as elements 1.1
and 4.4, respectively. All interface functionality is provided in the TMA by the Mount Control System
(MCS), element 1.1.8 in the Work Breakdown, hence this document defines the interface between the
MCS and the TCS.
Since there are no mechanical or optical connections between these two systems, this document contains
only the electronic and software interfaces. The interface defined in this document is inclusive of all
operations performed between the two systems. No commands, events, or other functional operations may
be performed that are not defined herein or are not a part of the engineering user interface for this system.
The software interface between the MCS and TCS is split into three parts: attributes sent from the TCS to
the MCS, events generated by the TCS of interest to the MCS, and events generated by the MCS of
interest to the TCS. The description of attributes, events, and the underlying DKIST Common Services
Framework is found in the software documentation. The specifications for the Common Services
Framework are found in the DKIST Common Services Framework Reference Manual (SPEC-0022).
Since all attributes that appear in this document can be sent from the Observatory Control System (OCS),
this document also constitutes part of the OCS to TCS interface (ICD 4.2/4.4).
Telescope Mount Assembly to Telescope Control System
ICD 1.1/4.4 Rev I Page 6 of 33
2. Included Documents and Drawings
[1] SPEC-0022-1, Common Services Framework Users’ Guide.
[2] SPEC-0063, Interconnects & Services Specification, Section 2.1.4.
[3] ICD-4.2/4.4, Observatory Control System to Telescope Control System.
Telescope Mount Assembly to Telescope Control System
ICD 1.1/4.4 Rev I Page 7 of 33
3. Physical System Interfaces
3.1. Mechanical Interface
N/A
3.2. Optical Interface
N/A
3.3. Electronic Interface
All software communications described in this document between the TMA and the TCS shall take place
over the DKIST control network. This control network is implemented as a Gigabit Ethernet as defined
by IEEE-802.3z-1998. The interface is found in SPEC-0063, Interconnects& Services Specifications,
Section 2.1.4.
3.4. Mass/Balance
N/A
3.5. Thermal Interface
N/A
Telescope Mount Assembly to Telescope Control System
ICD 1.1/4.4 Rev I Page 8 of 33
4. Software/Control Function Interface
The software interface between the MCS and the TCS provides a control mechanism for the TCS to
operate the telescope mount as part of the overall telescope operations. It also provides a status and event
mechanism for telescope mount information to be broadcast to interested systems (TCS, users, loggers,
etc.).
4.1. Overview of MCS Functionality
The TMA is the mechanical structure of the telescope that supports the major optical elements along with
the associated electronics and software for positioning the mount azimuth and altitude axes and the coudé
rotator azimuth axis. The TMA includes the Mount Control System (MCS), which is the software system
responsible for operating the servo control systems for the axes of rotation. The MCS is responsible for
the operation of the TMA and its subsystems, including: the mount drive systems of the mount azimuth,
mount altitude, and coudé azimuth axes, and the M1 mirror cover. It also monitors the ancillary
equipment of the TMA: the locking pins, and interlocks.
The MCS shall perform the following actions under commands from the TCS:
Initialize all servo electronics, sensing hardware, and other electronics;
Shut down all of the above equipment;
Control the configuration and motion of the three rotational axes;
Move to specified topocentric positions;
Follow a stream of position demands;
Open and close the mirror cover;
Enable the camera signals to the enclosure aperture plate;
Record the metrology from the TMA sensors;
Prevent the TMA from performing invalid or incorrect configurations; and
Provide up-to-date status information on all TMA equipment.
The TCS is one of the four principal software systems for the DKIST and is responsible for maintaining
telescope positioning and configuration. It calculates and provides accurate pointing and tracking
information and configures the appropriate thermal and wavefront correction states. The TCS also directly
controls all telescope software subsystems, including the Mount Control System (MCS), M1 Mirror
Control System (M1CS), Top End Optical Assembly Control System (TEOACS), Feed Optics Control
System (FOCS), Acquisition Control System (ACS), Wavefront Correction Control System (WCCS),
Polarization Analysis and Calibration Control System (PACCS), and Enclosure Control System (ECS).
The TCS is itself controlled by the Observatory Control System (OCS) under the guidance of the
telescope operator, resident astronomer, or authorized engineer.
The interface between the MCS and TCS is implemented on top of the DKIST software control
framework, known as the DKIST Common Services Framework (CSF). This framework provides three
important foundations for defining the application interface. First, the framework provides a set of
communications methodologies. Applications can communicate via one of two methods; synchronous
peer-to-peer or asynchronous publish-subscribe. In the first method, a system can send a command to
another system and wait for a response. In the second, a system can unilaterally broadcast information to
any other systems subscribed to that informational channel. Both of these communications methods are
more fully described in the DKIST Common Services Framework Users’ Manual (SPEC-0022-1).
Telescope Mount Assembly to Telescope Control System
ICD 1.1/4.4 Rev I Page 9 of 33
Second, the Common Services Framework provides a specified way to control the activities of systems.
The DKIST uses a command-action-response control mechanism that allows hierarchically superior
systems (such as the TCS) to issue commands to lower-level systems (such as the MCS), and monitor the
progress and results of that command. The control mechanism allows multiple commands to execute
simultaneously and thus multiple actions to run simultaneously. The control mechanism also defines the
allowable commands that can be executed. DKIST provides a narrow interface between systems,
meaning the defined commands are few and are based upon starting and stopping actions.
Third, the Common Services Framework provides a set of services that can be used by systems to perform
common activities. These services include a connection service to manage connections between systems
components, an event service to implement publish-subscribe activities, a logging and archive service,
and a property service for persistent storage information. Several other minor services also exist. DKIST
control systems are expected to use the provided services rather than implement their own.
4.2. Interface Naming
The TCS is registered in the DKIST connection service under the name atst.tcs. As a TCS subsystem, the
MCS top-level controller is registered with the name atst.tcs.mcs. MCS controllers under the top-level
controller are given similar hierarchical names, such as atst.tcs.mcs.az for the mount azimuth controller.
The designated names of MCS controllers given in this ICD are based purely on a logical function, and
may not represent the physical architecture of the MCS design. For instance, the MCS might use a single
hardware component to perform all operations on the mount azimuth (e.g., rotate the mount azimuth, read
the temperature sensors, interlock the locking pins), and this component may have a corresponding
software controller in the final design. It is the responsibility of the MCS software to map the logical
name from the interface to the physical controller in the design.
The MCS is comprised of a top-level device, responsible for all global operations and the logical
subsystem devices. Each device is given a name in the hierarchy of the MCS; these names may or may
not correspond directly to a process or entity in the MCS software.
atst.tcs.mcs # top-level MCS controller
atst.tcs.mcs.az # mount azimuth controller
atst.tcs.mcs.alt # mount altitude controller
atst.tcs.mcs.coude # coudé rotator controller
atst.tcs.mcs.cover # M1 mirror cover
atst.tcs.mcs.aux # camera power controller
Commands from the TCS (or MCS engineering user interface) should be directed to the MCS device
(atst.tcs.mcs) during normal science and engineering operations. Command to the MCS subsystem
controllers should be sent only during maintenance operations and only from the MCS engineering user
interface.
4.3. Context Diagram
The context diagram for the MCS is shown in Figure 1. The interface between the MCS and the TCS is
defined in this document. Another interface is between the MCS and the DKIST Common Services
Framework databases and is used to exchange persistent state information, events, log messages, and
header data. This interface is defined by the DKIST Common Services Framework programmatic
interface in SPEC-0022-1.
Telescope Mount Assembly to Telescope Control System
ICD 1.1/4.4 Rev I Page 10 of 33
4.3.1. Engineering User Interface
The MCS engineering user interface is another interface to the MCS. The engineering user interface shall
use the same interface as the TCS, although it may include additional configurations or components not
specified in this document. Documentation of these enhancements is part of the MCS design
documentation set and is not provided in this document.
4.3.2. Lifecycle Commands
The mount control system is implemented by using the component model of the DKIST Common
Services Framework. The CSF imposes a number of lifecycle states on the MCS components that are
used to implement the startup and shutdown procedures. This is described in details in SPEC-0022-1.
4.3.3. MCS Modes
The three MCS drive systems are always in one of three operating modes: off, active, or tracking. When it
is in the off mode, a drive system cannot move; its brakes are set, its motors are de-energized. When it is
in the active mode, a drive system has a running servo control loop with the brakes released; it may be
holding position or moving to a commanded position. In the tracking mode, a drive system continuously
repositions the hardware by following a stream of external position, velocity, and acceleration demands.
The three drive systems generally act in coordination, having the same mode. However, if the engineering
operation of the MCS requires it, the drive systems may be configured to behave differently.
Figure 1. Mount Control System context diagram
Telescope Mount Assembly to Telescope Control System
ICD 1.1/4.4 Rev I Page 11 of 33
4.4. MCS Named Positions
The MCS drive systems have several fixed positions that are given specific names. The location of these
fixed positions may be changed through the DKIST Property service by editing the value for each drive
system. The named positions are used with the active value of the mode attribute for the top-level
controller and each drive system controller. The named position is given in the .namedPos attribute.
The stow named position defines the location that the drive system shall use to stow the TMA before
ceasing operations for the day. These positions may be changed for each axis by modifying the value of
the .namedPos:stow attribute for each drive system controller (.az.namedPos:stow, .alt.namedPos:stow,
and .coude.namedPos:stow).
The serviceN named position defines one of n possible service positions for a controller, where n is the
number referring to the service position to move to. These positions may be changed for each axis
through the DKIST Property service by editing the value for each drive
system(.az.namedPos:serviceN,.alt.namedPos:serviceN, and .coude.namedPos:serviceN).
The following mount altitude service positions shall be defined:
service1—OSS vertical position locking pin; and
service2—OSS horizontal position locking pin.
There are four possible limit switch named positions for the TMA axes:
lolo— electronic lower end-of-travel limit switch;
lo — software lower limit switch;
hi — software upper limit switch; and
hihi — electronic upper end-of-travel limit switch.
Moving to a limit switch named position requires the MCS to travel until the requested limit switch is
triggered. Moving to the electronic end-of-travel limits requires the authorized engineer to switch to the
engineering mode.
The index named position defines the position of the next positive absolute index mark. Requesting
movement to this position will force an axis to search for the next valid index mark and subsequently
reset its known position.
Figure 2. State transitions in the MCS.
Off Active
active
off
Tracking
shutdownstartup
activetracking
off
tracking
Telescope Mount Assembly to Telescope Control System
ICD 1.1/4.4 Rev I Page 12 of 33
The named position here will force the axis to stop according to the normal stop ramp. Because of action
queuing {namedPos=here} will take effect only when the prior configuration has returned. If the
configuration is still running, the user must abort or cancel the action to force a stop.
The named position getlost will cause transition into the engineering mode (also called the rate mode
since this is an operation mode without the position control loop).
4.5. MCS TCS Attributes
This section describes those attributes that the TCS will send to the top level MCS controller. The
attributes are summarized in the table below and then described in more detail in the following sections.
As mentioned in 4.2 during normal science and engineering operations all configurations shall be sent
only to the top-level MCS controller, atst.tcs.mcs. It is the responsibility of this controller to validate the
configuration, separate the individual configurations that go to its subsystems, and queue the
configuration for execution. Any configurations that address low-level systems should be sent to the top-
level controller for verification and routing on to the appropriate controller (except for maintenance
operations). Conformance to this convention allows changes in the underlying MCS software design
without affecting the external interface.
Configurations sent to the MCS controller may be rejected for a variety of reasons, as defined in Section
4.13 of this document.
Configurations sent to the MCS controller while the controller has received an interlock event (through
the atst.gis event) will be accepted by the controller but the subsequent action will be aborted if the
configuration tries to run during the active interlock.
Name Type Units Range Comment
atst.tcs.mcs
.mode string Choice off |
active|tracking
Mount mode of operation
.trackId string ID unique Current track ID from TCS
.namedPos string Choice see below Named demand position
.interlock:event string Name atst.gis.interlock Name of interlock event
.interlock:attributes string[] Name tmaInterlock Attributes in event to watch
4.5.1. .mode
The mount azimuth, mount altitude, and coudé rotator are controlled by sending a demanded mode of
operation. If any attributes used in the mode are invalid, the configuration shall be rejected by the MCS.
The available modes and their descriptions are as follows:
off—The mount azimuth, mount altitude, and coudé rotator drive systems shall set the brakes,
power off the drive motors, and perform any other actions necessary to be considered parked.
This mode is executed automatically upon receiving a startup command from the TCS.
active—The mount azimuth, mount altitude, and coudé rotator drive systems shall power on the
drive motors, release the brakes, and perform any other actions necessary to be under active servo
loop control and holding in position. The drive systems may perform commanded moves while in
Telescope Mount Assembly to Telescope Control System
ICD 1.1/4.4 Rev I Page 13 of 33
this mode with input through the .pos, .jogVel, .oPos, and .namedPos attributes. A change in
mode from tracking to active shall stop any ongoing tracking activity and cause the MCS to hold
position using the last demanded tracking position sent prior to the mode change.
tracking—The mount azimuth, mount altitude, and coudé rotator drive systems shall begin
tracking an external stream of position, velocity, and acceleration demands from the TCS. The
input stream is found in the event atst.tcs.mcsTrajectory. A change in mode from active to
tracking shall stop any ongoing move activity.
If the submitted configuration does not contain .mode the MCS shall use the actual mode value.
When in the active mode, a number of movement activities may be commanded by the TCS. For instance,
the TMA may be stowed with the two configurations: {mode=active; alt.namedPos=stow; az.namedPos=stow; coude.namedPos=stow}
// move altitude, azimuth, and coudé to their stow positions
{mode=off}
// turn off the drives
Another configuration would have the same effect: {mode=active; namedPos=stow}
// move altitude, azimuth, and coudé to their stow positions
{mode=off}
// turn off the drives
Other movement operations include move, index, offset, and jog, and are performed, respectively: {mode=active; coude.pos=270}
// move coudé to 270 degrees
{mode=active; alt.namedPos=index}
// index altitude axis
{mode=active, az.oPos=100}
// offset azimuth 100 degrees
{mode=active; alt.jogVel=0.01}
// jog altitude .01 deg/sec
4.5.2. .trackId
The .trackId attribute is used to signal a discontinuity in the TCS trajectory stream used to position the
telescope mount and shall always be passed to the MCS when tracking is demanded. A discontinuity will
occur when the TCS tracking target is changed, or an offset is applied, etc. The track ID is also sent to the
MCS from the TCS in the trajectory event. When both track ID submitted in configuration to MCS and
track ID published in trajectory event match, and TMA position is within specified tolerances, the MCS
can report (via event) that it is in position. See TCS Software Design Description (SPEC-0021) for full
details on when track ID is changed and how it is to be used.
4.5.3. .namedPos
The .namedPos attribute changes the position of all TMA mechanisms. It may be one of index, here,
getlost, stow, serviceN, lolo ,lo ,hi, or hihi (see Section 4.4 for a description of all defined named
positions). This attribute is used in the active mode to move to a new fixed position or perform some
special activities.
Telescope Mount Assembly to Telescope Control System
ICD 1.1/4.4 Rev I Page 14 of 33
4.5.4. .interlock:event, .interlock:attributes
These attributes name the DKIST event channel and fields in the event to monitor for TMA interlocks.
The values should always be set to atst.gis.interlock and .tmaInterlock, respectively, and loaded at
startup through the Property service. When the value of .tmaInterlock is true the MCS shall perform its
required interlock behavior. When the value of .tmaInterlock changes to false the MCS shall cease
performing its interlock behavior and resume processing input commands.
The interlock behavior is a standard function of CSF controllers. The TCS will not modify these
attributes.
4.6. Mount Azimuth Attributes
This section describes those attributes that the TCS will send to the top-level controller that involve the
mount azimuth controller (atst.tcs.mcs.az). This controller operates the mount azimuth drive systems and
associated mechanisms.
The attributes that can be set on this controller are given below. Changes to the allowable ranges are made
by accessing the associated attribute metadata through the ?range field.
Name Type Units Range Comment
atst.tcs.mcs.az
.mode string choice see below Mode of drive system
.trackId string ID unique Current track ID from TCS
.pos float degs -90 to 310 deg Demand position
.oPos float degs ?range Demand offset
.namedPos string choice see below Named demand position
.namedPos:stow float degs 90 deg *) Stow position
.namedPos:service1 float degs 0 deg *) Service position 1
.namedPos:lolo,
.namedPos:lo,
.namedPos:hi,
.namedPos:hihi
float degs ?range Limit positions
.jogVel float degs/s ?range Demand jog velocity
.posTolAv float degs ?range Position tolerance for the average
position error
.posTolMax float degs ?range Position tolerance for the maximum
position error
.velTol float degs/s ?range Velocity tolerance
.interlock:event string name atst.gis.interlock Name of interlock event
.interlock:attribute string[] name tmaInterlock,
tmaInterlock:az
Attribute in event to watch
.maxRate float deg/s 2 deg/s Maximum cruising rate
.maxAccel float deg/s2 0.5 deg/s
2 Maximum acceleration
.hsDataArchived boolean on|off Enable/disable storing the High Speed
Data in the Archive for this controller
.windCompensation
boolean on|off Demand for wind deflection
compensation
.wcParamValues float[] TBD Array of parameters for wind
compensation (values)
Telescope Mount Assembly to Telescope Control System
ICD 1.1/4.4 Rev I Page 15 of 33
.wcIntTime float TBD Low-path filter integration time for the
FBC
*) final values will be defined during SAT
4.6.1. .mode
This attribute takes the same values as that of the top level MCS controller. In general, the mode is passed
to the controller from the top level controller, although for engineering purposes the MCS engineering
user interface can operate the controller independently from the state of the other controllers by issuing
the mode at this level.
4.6.2. .trackId
When the TCS is controlling the TMA using the MCS the .trackId shall be passed to the controller from
the top level MCS controller when it is received from the TCS. However, for engineering purposes the
MCS engineering user interface can operate the controller independently from the state of the other
controllers and will generate a .trackId for its use.
4.6.3. .pos
This attribute is the demand mount azimuth position in degrees. This attribute is used in the active mode
to move to a new fixed position. Azimuth demand positions are given for the entire range of travel. An
azimuth demand position of -60 degrees is different from a demand position of +300 degrees, even
though the telescope is pointing at the same place. In the former case, the TMA azimuth will travel
toward its lower limit to reach the position, while in the latter it will travel toward its upper limit.
4.6.4. .oPos
This attribute is the demand mount azimuth offset in degrees. This attribute is used in the active mode to
offset to a new fixed position.
4.6.5. .namedPos
This attribute is the demand mount azimuth as a named position (see Section 4.4 for a description of all
defined named positions). This attribute is used in the active mode to move to a new fixed position.
4.6.6. .namedPos:stow
This is the stow position to which the mount azimuth will move when sent to the stow named position.
4.6.7. .namedPos:service1
Value for the service named position to which the mount azimuth may move when sent to the service1
named position.
4.6.8. .namedPos:lolo, .namedPos:lo, .namedPos:hi, .namedPos:hihi
Values for the limit positions the mount azimuth may move to.
Telescope Mount Assembly to Telescope Control System
ICD 1.1/4.4 Rev I Page 16 of 33
4.6.9. .jogVel
This attribute is the demand azimuth rate in degrees per second. This attribute is used in the active mode
to move at a fixed rate.
4.6.10. .posTolMax, .posTolAv.velTol
These are the position and velocity tolerances used as the “in position” criteria for the mount azimuth.
The position tolerance is used for tracking and positioning and the velocity tolerance is used during
moving at a fixed rate (jogging). When the mount azimuth is located within the position tolerance and
moving at a rate within the velocity tolerance, the corresponding .inPosition attribute shall have a true
value, otherwise it shall have a false value.
4.6.11. .interlock:event, .interlock:attributes
These attributes name the DKIST event channel and fields in the event to monitor for the mount azimuth
interlocks. The values should always be set to atst.gis.interlock and [.tmaInterlock, .tmaInterlock:az],
respectively, and loaded at startup through the Property service. When the value of at least one of the
attributes istrue the mount azimuth controller shall perform its required interlock behavior.
4.6.12. .maxRate
This attribute is the maximum cruising rate during positioning (offsetting). This value is also valid during
a transition phase of tracking and jogging.
4.6.13. .maxAccel
This attribute is the maximum acceleration which is used to generate a slewing trajectory..
4.6.14. .hsDataArchived
Setting this attribute to true/false will enable/disable writing the High Speed Data into the CSF archive.
4.6.15. .windCompensation
This attribute switches the wind deflection compensation on or off.
4.6.16. .wcParamValues
This attribute is the vector of coefficients for the flexible body compensation (FBC) of wind-induced
deflections.
4.6.17. .wcIntTime
This attribute is the low-path filter integration time for the FBC.
4.7. Mount Altitude Attributes
This section describes those attributes that the TCS will send to the top-level controller that involve the
mount altitude controller (atst.tcs.mcs.alt). This controller operates the mount altitude drive systems and
associated mechanisms.
Telescope Mount Assembly to Telescope Control System
ICD 1.1/4.4 Rev I Page 17 of 33
The attributes that can be set on this controller are given below. Changes to the allowable ranges are made
by accessing the associated attribute metadata through the ?range field.
Name Type Units Range Comment
atst.tcs.mcs.alt
.mode string choice see below Mode of drive system
.trackId string ID unique Current track ID
.pos float degs 7 to 104 deg Demand position
.oPos float deg ?range Demand offset
.namedPos string choice see below Named demand position
.namedPos:stow float degs 90 deg Stow position
.namedPos:service1,
.namedPos:service2
float degs 103.5 deg
14.04 deg
Service positions
.namedPos:lolo,
.namedPos:lo,
.namedPos:hi,
.namedPos:hihi
float degs ?range Limit positions
.jogVel float degs/s ?range Demand jog velocity
.posTolAv float degs ?range Position tolerance for the average
position error
.posTolMax float degs ?range Position tolerance for the maximum
position error
.velTol float degs/s ?range Velocity tolerance
.interlock:event string name atst.gis.interlock Name of interlock event
.interlock:attribute string[] name tmaInterlock,
tmaInterlock:alt
Attribute in event to watch
.windCompensation
boolean on|off Demand for wind deflection
compensation
.maxRate float deg/s 2 deg/s Maximum cruising rate
.maxAccel float deg/s2 0.5 deg/s
2 Maximum acceleration
.hsDataArchived boolean on|off Enable/disable storing the High Speed
Data in the Archive for this controller
.wcParamValues float[] TBD Array of parameters for wind
compensation (values)
.wcIntTime float TBD Low-path filter integration time for the
FBC
4.7.1. .mode
This attribute takes the same values as that of the top level MCS controller. In general, the mode is passed
to the controller from the top level controller, although for engineering purposes the MCS user interface
can operate the controller independently from the state of the other controllers by issuing the mode at this
level.
4.7.2. .trackId
When the TCS is controlling the TMA using the MCS the .trackId shall be passed to the controller from
the top level MCS controller when it is received from the TCS. However, for engineering purposes the
Telescope Mount Assembly to Telescope Control System
ICD 1.1/4.4 Rev I Page 18 of 33
MCS engineering user interface can operate the controller independently from the state of the other
controllers and will generate a .trackId for its use.
4.7.3. .pos
This attribute is the demand mount altitude position in degrees. This attribute is used in the active mode to
move to a new fixed position.
4.7.4. .oPos
This attribute is the demand mount azimuth offset in degrees. This attribute is used in the active mode to
offset to a new fixed position.
4.7.5. .namedPos
This attribute is the demand mount altitude as a named position (see Section 4.7 for a description of all
defined named positions). This attribute is used in the active mode to move to a new fixed position.
4.7.6. .namedPos:stow
This is the stow position to which the mount altitude will move when sent to the stow named position.
4.7.7. .namedPos:serviceN
This is one of y of service positions to which the mount altitude may move when sent to the serviceN
named position.
4.7.8. .namedPos:lolo, .namedPos:lo, .namedPos:hi, .namedPos:hihi
These attributes are the values for the limit positions the mount altitude may move to.
4.7.9. .jogVel
This attribute is the demand altitude rate in degrees per second. This attribute is used in the active mode to
move at a fixed rate.
4.7.10. .posTolMax, .posTolAv .velTol
These are the position and velocity tolerances used as the “in position” criteria for the mount altitude. The
position tolerance is used for tracking and positioning and the velocity tolerance is used during moving at
a fixed rate (jogging). When the mount altitude is located within the position tolerance and moving at a
rate within the velocity tolerance, the corresponding .inPosition attribute shall have a true value,
otherwise it shall have a false value.
4.7.11. .interlock:event, .interlock:attributes
These attributes name the DKIST event channel and fields in the event to monitor for the mount altitude
interlocks. The values should always be set to atst.gis.interlock and [.tmaInterlock.tmaInterlock:alt],
respectively, and loaded at startup through the Property service. When the value of at least one of the
attributes is true the mount altitude controller shall perform its required interlock behavior.
Telescope Mount Assembly to Telescope Control System
ICD 1.1/4.4 Rev I Page 19 of 33
4.7.12. .windCompensation
This attribute switches the wind deflection compensation on or off.
4.7.13. .maxRate
This attribute is the maximum cruising rate during positioning (offsetting). This value is also valid during
a transition phase of tracking and jogging.
4.7.14. .maxAccel
This attribute is the maximum acceleration which is used to generate a slewing trajectory.
4.7.15. .hsDataArchived
Setting this attribute to true/false will enable/disable writing the High Speed Data into the CSF archive.
4.7.16. .wcParamValues
This attribute is the vector of coefficients for the flexible body compensation (FBC) of wind-induced
deflections.
4.7.17. .wcIntTime
This attribute is the low-path filter integration time for the FBC.
4.8. Coudé Azimuth Attributes
This section describes those attributes that the TCS will send to the top-level controller that involve the
coudé azimuth controller (atst.tcs.mcs.coude). This controller operates the coudé azimuth drive systems
and associated mechanisms.
The attributes that can be set on this controller are given below. Changes to the allowable ranges are made
by accessing the associated attribute metadata through the ?range field.
Name Type Units Range Comment
atst.tcs.mcs.coude
.mode string choice see below Mode of drive system
.trackId string ID unique Current track ID
.pos float degs -90 to 450 deg Demand position
.oPos float degs ?range Demand offset
.namedPos string choice see below Named demand position
.namedPos:stow float degs 0 deg Stow position
.namedPos:service1 float degs 0 deg Service position
.namedPos:lolo,
.namedPos:lo,
.namedPos:hi,
.namedPos:hihi
float degs ?range Limit positions
.jogVel float degs/s ?range Demand jog velocity
Telescope Mount Assembly to Telescope Control System
ICD 1.1/4.4 Rev I Page 20 of 33
.posTolAv float degs ?range Position tolerance for the average
position error
.posTolMax float degs ?range Position tolerance for the maximum
position error
.velTol float degs/s ?range Velocity tolerance
.interlock:event string name atst.gis.interlock Name of interlock event
.interlock:attribute string[] name tmaInterlock,
tmaInterlock:coude
Attribute in event to watch
.maxRate float deg/s 6 deg/s Maximum cruising rate
.maxAccel float deg/s2 0.5 deg/s
2 Maximum acceleration
.hsDataArchived boolean on|off Enable/disable storing the High
Speed Data in the Archive for this
controller
4.8.1. .mode
This attribute takes the same values as that of the top level MCS controller. In general, the mode is passed
to the coudé azimuth controller from the top level controller; although for engineering purposes the MCS
user interface can operate the controller independently from the state of the other controllers by issuing
the mode at this level.
4.8.2. .trackId
When the TCS is controlling the TMA using the MCS the .trackId shall be passed to the controller from
the top level MCS controller when it is received from the TCS. However, for engineering purposes the
MCS engineering user interface can operate the controller independently from the state of the other
controllers and will generate a .trackId for its use.
4.8.3. .pos
This attribute is the demand coudé azimuth position in degrees. This attribute is used in the active mode
to move to a new fixed position. Coudé azimuth demand positions are given for the entire range of travel.
A coudé azimuth demand position of -60 degrees is different from a demand position of +300 degrees. In
the former case, the coudé azimuth will travel toward its lower limit to reach the position, while in the
latter it will travel toward its upper limit.
4.8.4. .oPos
This attribute is the demand mount azimuth offset in degrees. This attribute is used in the active mode to
offset to a new fixed position.
4.8.5. .namedPos
This attribute is the demand coudé azimuth as a named position (see Section 4.4 for a description of all
defined named positions). This attribute is used in the active mode to move to a new fixed position.
Telescope Mount Assembly to Telescope Control System
ICD 1.1/4.4 Rev I Page 21 of 33
4.8.6. .namedPos:stow
This is the stow position to which the coudé azimuth will move when sent to the stow named position.
4.8.7. .namedPos:service1
These are the service position to which the coudé azimuth may move when sent to the service1 named
position.
4.8.8. namedPos:lolo, .namedPos:lo, .namedPos:hi, .namedPos:hihi
These attributes are the values for the limit positions the coudé may move to.
4.8.9. .jogVel
This attribute is the demand azimuth rate in degrees per second. This attribute is used in the active mode
to move at a fixed rate.
4.8.10. .posTolMax, .posTolAv, .velTol
These are the position and velocity tolerances used as the “in position” criteria for the coudé azimuth. The
position tolerance is used for tracking and positioning and the velocity tolerance is used during moving at
a fixed rate (jogging). When the coudé azimuth is located within the position tolerance and moving at a
rate within the velocity tolerance, the corresponding .inPosition attribute shall have a true value,
otherwise it shall have a false value.
4.8.11. .interlock:event, .interlock:attributes
These attributes name the DKIST event channel and fields in the event to monitor for the mount azimuth
interlocks. The values should always be set to atst.gis.interlock and .tmaInterlock:coude, respectively,
and loaded at startup through the property service. When the value of .tmaInterlock:coude is true the
mount azimuth controller shall perform its required interlock behavior.
4.8.12. .maxRate
This attribute is the maximum cruising rate during positioning (offsetting). This value is also valid during
a transition phase of tracking and jogging.
4.8.13. .maxAccel
This attribute is the maximum acceleration which is used to generate a slewing trajectory.
4.8.14. .hsDataArchived
Setting this attribute to true/false will enable/disable writing the High Speed Data into the CSF archive.
4.9. M1 Mirror Cover Attributes
This section describes those attributes that the TCS will send to the top-level controller that involve the
M1 mirror controller (atst.tcs.mcs.cover). This controller operates the M1 mirror cover mechanisms.
Telescope Mount Assembly to Telescope Control System
ICD 1.1/4.4 Rev I Page 22 of 33
The attributes that can be set on this controller are given below. Changes to the allowable ranges are made
by accessing the associated attribute metadata through the ?range field.
Name Type Units Range Comment
atst.tcs.mcs.cover
.pos string choice open | close Demand position
.interlock:event string name atst.gis.interlock Name of interlock event
.interlock:attribute string[3] name tmaInterlock,
tmaInterlock:az,
tmaInterlock:alt
Attribute in event to watch
4.9.1. .pos
During normal operation, the M1 mirror cover is commanded to either open or close. This attribute will
be rejected if there is an interlock active as the M1 mirror cover is one of the systems that protect the
DKIST from unintended illumination. Interlock will cause the cover to close automatically.
4.9.2. .interlock:event, .interlock:attributes
These attributes name the DKIST event channel and fields in the event to monitor for the M1 cover
interlock. The values should always be set to atst.gis.interlock and [.tmaInterlock, .tmaInterlock:az,
.tmaInterlock:alt] respectively, and loaded at startup through the property service.
4.10. Ancillary Device Attributes
This section describes those attributes that the TCS will send to the top-level controller that involve the
ancillary controller (atst.tcs.mcs.aux). This controller operates the various MCS ancillary mechanisms.
The attributes that can be set on this controller are given below. Changes to the allowable ranges are made
by accessing the associated attribute metadata through the ?range field.
Name Type Units Range Comment
atst.tcs.mcs.aux
.camera bool on | off Camera power state
4.10.1. .camera
This attribute specifies the power demand to the MCS camera tracking system, either off or on. When the
camera is on, it is used to align the enclosure aperture with the TMA and M1 aperture.
The camera system is not a part of the Telescope Mount Assembly. However, the MCS shall be
responsible for providing the control and status abilities for this system.
4.11. Events Generated By the MCS
The following events are generated by the MCS, usually within the controller specified in the name. The
TCS, the MCS engineering GUI, the DKIST archiver, or any other system that is interested in the
information may subscribe to these events. These event names, attributes, ranges, or units may not be
modified by the MCS without the approval of the TCS, and vice versa. Uses by systems other than the
TCS shall not be controlled by this interface control document.
Telescope Mount Assembly to Telescope Control System
ICD 1.1/4.4 Rev I Page 23 of 33
Name Rate Comment
atst.tcs.mcs.cStatus 1 Hz current TMA status
atst.tcs.mcs.cPos 10 Hz current TMA motion status
atst.tcs.mcs.az.cStatus 1 Hz azimuth status
atst.tcs.mcs.alt.cStatus 1 Hz altitude status
atst.tcs.mcs.coude.cStatus 1 Hz coudé rotator status
atst.tcs.mcs.cover.cStatus 1 Hz cover status
atst.tcs.mcs.aux.cStatus 1 Hz auxiliary components status
4.11.1. atst.tcs.mcs.cStatus
This event reports the current status of the MCS controller. 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
.cMode string choice current TMA mode
.inPosition boolean true|false true if is within tolerances
.zenith boolean true|false true = is within 0.5 degrees of the zenith
The current mode (.cMode) will be one of the following: unknown, off, tracking, or active and is set based
on modes of sub-controllers according to the following rules:
- off if all sub-controllers are in state off
- active if at least one sub-controller is in mode active
- tracking if all sub-controllers are in mode tracking
- unknown in all other cases
The .inPosition attribute reports whether all MCS components are in the correct position and within
tolerances. In active mode it indicates the demand position and velocity are being met. In tracking mode it
indicates the incoming trajectory stream’s position and velocity demands are being met. If either position
or velocity exceeds the allowable tolerance, this attribute will change to false.
The .zenith attribute reports true when the TMA is pointing in the region of the zenith blind spot.
4.11.2. atst.tcs.mcs.cPos
This event contains the current position and velocity of the telescope mount assembly and coudé rotator.
It is generated at a rate of 10 Hz and includes all listed attributes. The following attributes are posted in
the event.
Name Type Units Comment
.cTrackId string ID current track ID from TCS
.az:cPos float degs azimuth current position
.az:cVel float degs/sec azimuth current velocity
.az:cPosErrorMax float degs azimuth peak position error
.az:cPosErrorAv float degs azimuth average position error
.alt:cPos float degs altitude current position
Telescope Mount Assembly to Telescope Control System
ICD 1.1/4.4 Rev I Page 24 of 33
.alt:cVel float degs/sec altitude current velocity
.alt:cPosErrorMax float degs altitude peak position error
.alt:cPosErrorAv float degs altitude average position error
.coude:cPos float degs coudé current position
.coude:cVel float degs/sec coudé current velocity
.coude:cPosErrorMax float degs coudé peak position error
.coude:cPosErrorAv float degs coude average position error
The TMA and coudé rotator positions are in degrees and the velocities in degrees per second. The
.cTrackId attribute specifies the current trajectory in use. The position errors are the difference between
the user demanded position (either in active or tracking mode) and the current position of the axis.
4.11.3. atst.tcs.mcs.az.cStatus
This event reports the current status of the TMA azimuth controller. The event is generated at a rate of 1
Hz and includes at least all listed attributes. The following attributes are posted in the event.
Name Type Units Comment
.cMode string choice current azimuth controller mode
.inPositionAv boolean true|false true = if .cPosErrorAv is below .posTolAv
.inPositionMax boolean true|false true = if .cPosErrorMax is below .posTolMax
.inPositionRate boolean true|false true = if .cVelError is below .velTol
.inPosition boolean true|false true = if both .inPositionMax and .inPositionAv
are true(for tracking and pointing), or true =
.inPositionRate if moving at constant rate
(jogging)
.cPos float degs current position of the absolute high-precision
encoder
.caPos float degs current position of the additional encoder
.cPosErrorAv float degs current error in position calculated as average of
all position errors for the last second
.cPosErrorMax float degs current error in position calculated as the
maximum of all position errors for the last
second
.cVelError float degs velocity error
.cVel float degs/sec averaged current velocity
.cTorque float[4] N m torque of individual motors
.isIndexed boolean true|false has been indexed
.indexing boolean true|false is currently indexing
.cLimit string choice current limit switch status: none, lo, lolo, hi, hihi
.cPower boolean[4] off|on status of power
.cBrake boolean[2] off|on status of brakes
.wrap:cPos float deg cable wrap current position
.wrap:cTorque float N m cable wrap current torque
.wrap:cPower boolean[2] true|false cable wrap current power enable
.wrap:cLimit string choice cable wrap current limit switch status: none, lo,
lolo, hi, hihi
.wrap:cMialLimit string choice cable wrap misalignment limit switch status:
none, lo, hi
Telescope Mount Assembly to Telescope Control System
ICD 1.1/4.4 Rev I Page 25 of 33
.cHsDataArchived boolean off|on status of archiving of the High Speed Data
.hhdActive boolean true|false true if the Hand Held Device is plugged in
The current .cMode attribute will be one of the following: unknown (in case if communication is broken),
off, tracking, or active. Interlock/error will cause off to be set as current mode. The .cMode attribute is set
based upon the hardware status; it may be different from the demanded .mode value.
Several .inPosition attributes report whether the azimuth is in the correct position and within tolerances.
In active mode it indicates the demand position and velocity are being met. In tracking mode it indicates
the incoming trajectory stream’s position being met. If either position or velocity exceeds the allowable
tolerance, this attribute will change to false. The used inPosition flags are: inPositionAv to indicate if the
average position error for the last second is below the specified .posTolAv, inPositionMax to indicate if
the maximum position error for the last second is below the specified .posTolMax, and .inPositionRate
to indicate if the actual velocity error is below the specified .velTol. The .inPosition attribute is used to
summarize all three in position flags: during tracking and pointing it is set to true if both inPositionMax
and inPositionAv are true; in case of jogging, .inPosition is equal to .inPositionRate
This event also gives performance information for the averaged rates (.cVel) and torques (.cTorque) of
the azimuth servo drives and the positions of the absolute high-precision encoder (.cPos) and the
additional rough encoder (.caPos). The positions are in degrees and the velocities in degrees per second;
both are instantaneous readings. The torque value is given in Newton-meters and is an average over the
past 1 second.
The .isIndexed and .indexing attributes show whether the azimuth controller has found an index position
and has currently valid position information or is in the midst of performing this activity.
The .cLimit attribute reports the current limit switches for the azimuth travel range. The limit choices are:
none, lolo, lo, hi, and hihi, corresponding respectively to no limit, the lower limit electronic switch, the
lower limit software switch, the upper limit software switch, and the upper limit electronic switch. Travel
in a negative direction will encounter first the lo software switch (a programmable position in the servo
controller) and then the lolo electronic switch (a fixed mechanical relay). Travel in the positive direction
will encounter the corresponding hi and hihi software and electronic switches.
The .cPower attribute reports the current power states of the azimuth servo drives, either on or off. The
.brake attribute gives the current brake positions of the azimuth servo drives, either on or off.
The .wrap:cPos, .wrap:cTorque, and .wrap:cPower attributes give performance information for the
positions, torques, and power state of the azimuth cable wrap. The position is the instantaneous reading in
degrees. The torque value is given in Newton-meters and is an average over the past 1 second.
The .wrap:cLimit attribute gives the current limit switch settings for the azimuth cable wrap. The limit
choices are: none, lolo, lo, hi, and hihi, corresponding respectively to no limit, the lower limit electronic
switch, the lower limit software switch, the upper limit software switch, and the upper limit electronic
switch. Travel in a negative direction will encounter first the lo software switch (a programmable position
in the servo controller) and then the lolo electronic switch (a fixed mechanical relay). Travel in the
positive direction will encounter the corresponding hi and hihi software and electronic switches.
The .wrap:cMialLimit attribute gives the current misalignment (synchronization) limit switch settings
for the azimuth cable wrap. The synchronization switches check are used to stop the azimuth and cable
wrap axes in case a misalignment between both occurs. It is to be noted, that the sync switches may be
activated before the software limits as they mechanically move together with the telescope axis. A
Telescope Mount Assembly to Telescope Control System
ICD 1.1/4.4 Rev I Page 26 of 33
misalignment in a negative direction will encounter the lo sync switch. Misalignment in the positive
direction will encounter the hi sync switch.
The .cHsDataArchived attribute reports whether the High Speed Data being archived.
The .hhdActive attribute is set to true if hardware is in the maintenance mode and is operated from the
Beckhoff Hand Held Device. All configurations sent to a corresponding sub-controller will be rejected by
the MCS in this mode.
4.11.4. atst.tcs.mcs.alt.cStatus
This event reports the current status of the TMA altitude controller. The event is generated at a rate of 1
Hz and includes at least all listed attributes. The following attributes are posted in the event.
Name Type Units Comment
.cMode string choice current altitude controller mode
.inPositionAv boolean true|false true = if .cPosErrorAv is below .posTolAv
.inPositionMax boolean true|false true = if .cPosErrorMax is below .posTolMax
.inPositionRate boolean true|false true = if .cVelError is below .velTol
.inPosition boolean true|false true = if both .inPositionMax and .inPositionAv
are true(for tracking and pointing), or true =
.inPositionRate if moving at constant rate
(jogging)
.cPos float degs current position of the absolute high-precision
encoder
.caPos float degs current position of the additional encoder
.cPosErrorAv float degs current error in position calculated as average of
all position errors for the last second
.cPosErrorMax float degs current error in position calculated as the
maximum of all position errors for the last
second
cVelError float degs velocity error
.cVel float degs/sec current velocity
.cTorque float[2] N m individual torque
.isIndexed boolean true|false has been indexed
.indexing boolean true|false is currently indexing
.cLimit string choice current limit switch status: none, lo, lolo, hi,
hihi
.cPower boolean[2] off|on status of power
.cBrake boolean[2] off|on status of brakes
.cPins string[2] choice status of the locking pins: unknown, in, out,
between , test
.cWindCompensation boolean on|off actual status of the wind compensation
.cHsDataArchived boolean off|on status of archiving of the High Speed Data
.hhdActive boolean true|false true if the Hand Held Device is plugged in
The current .cMode will be one of the following: unknown (in case if communication to the hardware is
broken), off, tracking, or active.
Telescope Mount Assembly to Telescope Control System
ICD 1.1/4.4 Rev I Page 27 of 33
Several .inPosition attributes report whether the azimuth is in the correct position and within tolerances.
In active mode it indicates the demand position and velocity are being met. In tracking mode it indicates
the incoming trajectory stream’s position being met. If either position or velocity exceeds the allowable
tolerance, this attribute will change to false. The used inPosition flags are: inPositionAv to indicate if the
average position error for the last second is below the specified .posTolAv, inPositionMax to indicate if
the maximum position error for the last second is below the specified .posTolMax, and .inPositionRate
to indicate if the actual velocity error is below the specified .velTol. The .inPosition attribute is used to
summarize all three in position flags: during tracking and pointing it is set to true if both inPositionMax
and inPositionAv are true; in case of jogging, .inPosition is equal to .inPositionRate.
This event also gives performance information for the averaged rates (.cVel) and torques (.cTorque) of
the altitude servo drives and the positions of the absolute high-precision encoder (.cPos) and the
additional rough encoder (.caPos). The positions are in degrees and the velocities in degrees per second;
both are instantaneous readings. The torque value is given in Newton-meters and is an average the past 1
second.
The .isIndexed and .indexing attributes show whether the altitude controller has found an index position
and has currently valid position information or is in the midst of performing this activity.
The attribute reports the current limit switches for the altitude travel range. The limit choices are: none,
lolo, lo, hi, and hihi, corresponding respectively to no limit, the lower limit electronic switch, the lower
limit software switch, the upper limit software switch, and the upper limit electronic switch. Travel in a
negative direction will encounter first the lo software switch (a programmable position in the servo
controller) and then the lolo electronic switch (a fixed mechanical relay). Travel in the positive direction
will encounter the corresponding hi and hihi software and electronic switches.
The .cPower attribute reports the current power states of the altitude servo drives, either on or off. The
brake attribute gives the current brake positions of the altitude servo drives, either on or off.
The .cPins attribute gives the current state of the two locking pins for the mount altitude. Each pin
position shall be reported as one of three possible positions: in, between, test or out. Any reported position
other than out (in the operation mode) or out/test (in the engineering mode) shall also cause the MCS to
cancel all ongoing actions and reject further configurations until the position is again reported as out (or
out/test in the engineering mode).
The .cWindCompensation attribute informs whether the FBC of wind-induced deflection is on or off.
The .cHsDataArchived attribute reports whether the High Speed Data being archived.
The hhdActive attribute is set to true if hardware is in the maintenance mode and is operated from the
Beckhoff Hand Held Device. All configurations sent to a corresponding sub-controller will be rejected by
the MCS in this mode.
4.11.5. atst.tcs.mcs.coude.cStatus
This event reports the current status of the TMA coudé rotator controller. The event is generated at a rate
of 1 Hz and includes at least all listed attributes. The following attributes are posted in the event.
Name Type Units Comment
.cMode string choice current coudé rotator controller mode
Telescope Mount Assembly to Telescope Control System
ICD 1.1/4.4 Rev I Page 28 of 33
.inPositionAv boolean true|false true = if .cPosErrorAv is below .posTolAv
.inPositionMax boolean true|false true = if .cPosErrorMax is below .posTolMax
.inPositionRate boolean true|false true = if .cVelError is below .velTol
.inPosition boolean true|false true = if both .inPositionMax and .inPositionAv
are true(for tracking and pointing), or true =
.inPositionRate if moving at constant rate
(jogging)
.cPos float degs current position of the absolute high-precision
encoder
.caPos float degs current position of the additional encoder
.cPosErrorAv float degs current error in position calculated as average of
all position errors for the last second
.cPosErrorMax float degs current error in position calculated as the
maximum of all position errors for the last
second
cVelError float degs velocity error
.cVel float degs/sec current velocity
.cTorque float[4] N m individual torque motor values
.isIndexed boolean true|false has been indexed
.indexing boolean true|false in currently indexing
.cLimit string choice Limit switch: none, lo, lolo, hi, hihi
.cPower boolean[4] off|on status of power
.cBrake boolean[2] off|on status of brakes
.wrap:cPos float deg cable wrap current position
.wrap:cTorque float[2] N m cable wrap current torque
.wrap:cPower boolean[2] true|false cable wrap current power enable
.wrap:cLimit string choice cable wrap limit switch
.wrap:cMialLimit string choice cable wrap misalignment limit switch: none, lo,
hi
.cHsDataArchived boolean true|false status of archiving of the High Speed Data
.hhdActive boolean true|false true if the Hand Held Device is plugged in
The current .cMode will be one of the following: unknown (in case if communication to the hardware is
broken), off, tracking, or active.
Several .inPosition attributes report whether the azimuth is in the correct position and within tolerances.
In active mode it indicates the demand position and velocity are being met. In tracking mode it indicates
the incoming trajectory stream’s position being met. If either position or velocity exceeds the allowable
tolerance, this attribute will change to false. The used inPosition flags are: inPositionAv to indicate if the
average position error for the last second is below the specified .posTolAv, inPositionMax to indicate if
the maximum position error for the last second is below the specified .posTolMax, and .inPositionRate
to indicate if the actual velocity error is below the specified .velTol. The .inPosition attribute is used to
summarize all three in position flags: during tracking and pointing it is set to true if both inPositionMax
and inPositionAv are true; in case of jogging,.inPosition is equal to .inPositionRate.
This event also gives performance information for the averaged rates (.cVel) and torques (.cTorque) of
the coudé servo drives and the positions of the absolute high-precision encoder (.cPos) and the additional
rough encoder (.caPos). The positions are in degrees and the velocities in degrees per second; both are
instantaneous readings. The torque value is given in Newton-meters and is an average over the past 1
second.
Telescope Mount Assembly to Telescope Control System
ICD 1.1/4.4 Rev I Page 29 of 33
The .isIndexed and .indexing attributes show whether the coudé rotator controller has found an index
position and has currently valid position information or is in the midst of performing this activity.
The .cLimit attribute reports the current limit switches for the coudé rotator travel range. The limit
choices are: none, lolo, lo, hi, and hihi, corresponding respectively to no limit, the lower limit electronic
switch, the lower limit software switch, the upper limit software switch, and the upper limit electronic
switch. Travel in a negative direction will encounter first the lo software switch (a programmable position
in the servo controller) and then the lolo electronic switch (a fixed mechanical relay). Travel in the
positive direction will encounter the corresponding hi and hihi software and electronic switches.
The .cPower attribute reports the current power states of the coudé rotator servo drives, either on or off.
The .cBrake attribute gives the current brake positions of the coudé rotator servo drives, either on or off.
The .wrap:cPos, .wrap:cTorque, and .wrap:cPower attributes give performance information for the
positions, torques, and power state of the coudé rotator cable wrap. The position is the instantaneous
reading in degrees. The torque value is given in Newton-meters and is an average over the past 1 second.
The .wrap:cLimit attribute gives the current limit switch settings for the coudé rotator cable wrap. The
limit choices are: none, lolo, lo, hi, and hihi, corresponding respectively to no limit, the lower limit
electronic switch, the lower limit software switch, the upper limit software switch, and the upper limit
electronic switch. Travel in a negative direction will encounter first the lo software switch (a
programmable position in the servo controller) and then the lolo electronic switch (a fixed mechanical
relay). Travel in the positive direction will encounter the corresponding hi and hihi software and
electronic switches.
The .wrap:cMialLimit attribute gives the current misalignment (synchronization) limit switch settings
for the coudé cable wrap. The synchronization switches check are used to stop the azimuth and cable
wrap axes in case a misalignment between both occurs. It is to be noted, that the sync switches may be
activated before the software limits as they mechanically move together with the telescope axis. A
misalignment in a negative direction will encounter the lo sync switch. Misalignment in the positive
direction will encounter the hi sync switch.
The .cHsDataArchived attribute reports whether the High Speed Data being archived.
The hhdActive attribute is set to true if hardware is in the maintenance mode and is operated from the
Beckhoff Hand Held Device. All configurations sent to a corresponding sub-controller will be rejected by
the MCS in this mode.
4.11.6. atst.tcs.mcs.cover.cStatus
Attributes: cPos(string), hhdActive(boolean)
Rate: 1 Hz
This event gives the current position, power state, and brake status of the M1 mirror cover. The position
choices are: open, closed, between, or unknown (in case if communication to the hardware is broken). The
position is determined from the state of the two limit switches at either end of travel. Both switches open
indicates the cover is in between the stops, while both closed is an unknown condition as well.
Telescope Mount Assembly to Telescope Control System
ICD 1.1/4.4 Rev I Page 30 of 33
4.11.7. atst.tcs.mcs.aux.cStatus
Attributes: cCamera(boolean)
Rate: 1 Hz
The event shows the change in status of the camera between off and on.
4.12. Events Subscribed to By the MCS
The events subscribed to by the MCS are summarized below. For full details of the event, reference
should be made to the appropriate system ICD.
Name Rate (Hz) Comment
atst.tcs.mcsTrajectory 20.0 Azimuth, altitude and coudé demands from the
TCS
atst.gis.interlock on change Global interlock condition
4.12.1. atst.tcs.mcsTrajectory
Attributes: trackId(string), tRef[3](double), azCoeff[3](double), altCoeff[3](double),
coudeCoeff[3](double)
Rate: 20 Hz
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 they will ignore them. 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 will provide a 2nd
order polynomial so n will equal 2 and the units will be such that the resultant
demand will be in degrees.
The trackId changes when the telescope moves to a new target position. The MCS 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](double) – the times (MJD TAI) at which the interpolating coefficients were evaluated,
Telescope Mount Assembly to Telescope Control System
ICD 1.1/4.4 Rev I Page 31 of 33
azCoeff[3](double)—the azimuth coefficients,
altCoeff[3](double)—the altitude coefficients,
coudeCoeff[3](double)—the coudé coefficients.
4.12.2. atst.gis.interlock
Attributes:
tmaInterlock(boolean) – interlock for the TMA
tmaInterlock:az(boolean) – interlock for azimuth
tmaInterlock:alt(boolean) – interlock for altitude
tmaInterlock:coude(boolean) – interlock for coudé
Rate: On change when false, 1 Hz when true
The GIS generates an interlock event that is subscribed to by several MCS controllers. When the
.tmaInterlock attribute in the event is true the MCS shall enter the defined interlock state. However, if
one of the attributes in the event is true only the corresponding axis-controller shall enter the defined
interlock state.
While at least one of the interlock attributes is true, the event will be posted at a rate of 1 Hz.
4.13. MCS Error Codes
Configurations submitted by the TCS to the MCS return an immediate result code indicating the
acceptance or rejection of the configuration. Accepted configurations begin executing the appropriate
actions, while reject configurations return an error code. The returned error code is a negative integer with
an associated defined meaning. The base set of error codes are found in the Controller class. The MCS
controllers may also extend the list of supported error codes. The following error codes are supported by
the CSF controllers.
Controller.OK—accepted: the action has been accepted.
Controller.BUSY—rejected: the controller is too busy.
Controller.BAD_PARAM—rejected: bad parameter found.
Controller.EXCEPTION—rejected: uncaught exception.
Controller.NOT_RUNNING—rejected: controller not started.
Controller.DUPLICATE—rejected: already in use.
Controller.NO_CONFIG—rejected: null configuration.
Controller.SIMULATED—rejected: simulation.
Telescope Mount Assembly to Telescope Control System
ICD 1.1/4.4 Rev I Page 32 of 33
Controller. REJECTED—rejected; before trying to run, rejected for other reason.
Controller.ERROR —while trying to run some other error occurred.
Controller.ABORTED–The action was aborted.
Controller.CANCELED—action was cancelled
Controller.INTERLOCKED—the action was interlocked.
Telescope Mount Assembly to Telescope Control System
ICD 1.1/4.4 Rev I Page 33 of 33
5. Safety Issues
Safety issues are the primary responsibility of the Global Interlock System (GIS) and the TMA’s Local
Interlock Controller (LIC).
However, the MCS shall assure that all normal operations are performed in a safe manner.
Top Related