ICD 1.1/4.4 Telescope Mount Assembly to Telescope Control System · 2020-01-22 · Telescope Mount...

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_


ICD 1.1/4.4 Rev I 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


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.


Date: 03 April 2006


Reason for / items changed: Fixed types and units for choice and Boolean attributes. Changed

versioning to the approved numbering scheme.


Date: 09 May 2006


Reason for / items changed: Minor typos and name of health event set to __health as per

Panguitch release.


Date: 12 September 2006


Reason for / items changed: Formatting and renumbering revisions.


Date: 29 September 2006


Reason for / items changed: Added top level m1cover attribute

9. Revision Version B

Date: 30 October 2006


ICD 1.1/4.4 Rev I of 33


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


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


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


Reason for/items changed: Changed status events to cStatus and cMode. Added track IDs.

Removed bearings.

17. Revision Version G

Date: 13 February 2013


Reason for/items changed: . Changed status events to cStatus and cMode. Added track IDs.

Removed bearings. Added wind deflection compensation. Removed ‘reset’ named position.


ICD 1.1/4.4 Rev I of 33

18. Revision Version G1

Date: 15 May 2013


Reason for/items changed: Changed trajectory coefficients and timestamp from float to double.

19. Revision Version G2

Date: 11 March 2014


Reason for/items changed: New coude range of -90 to 450 degrees.

20. Revision Version H

Date: April 2014


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.


ICD 1.1/4.4 Rev I 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).


ICD 1.1/4.4 Rev I 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.


ICD 1.1/4.4 Rev I 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


ICD 1.1/4.4 Rev I 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).


ICD 1.1/4.4 Rev I 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.


ICD 1.1/4.4 Rev I 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


ICD 1.1/4.4 Rev I 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


ICD 1.1/4.4 Rev I 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


ICD 1.1/4.4 Rev I 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.


ICD 1.1/4.4 Rev I 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.


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)


ICD 1.1/4.4 Rev I 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.


ICD 1.1/4.4 Rev I 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.


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


mount altitude controller (atst.tcs.mcs.alt). This controller operates the mount altitude drive systems and

associated mechanisms.


ICD 1.1/4.4 Rev I of 33




atst.tcs.mcs.alt


.trackId string ID unique Current track ID

.pos float degs 7 to 104 deg Demand position

.oPos float deg ?range Demand offset


.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




position error


position error




tmaInterlock:alt


.windCompensation

boolean on|off Demand for wind deflection

compensation




.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


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




ICD 1.1/4.4 Rev I of 33



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



4.7.5. .namedPos

This attribute is the demand mount altitude as a named position (see Section 4.7 for a description of all



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.


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.


ICD 1.1/4.4 Rev I of 33

4.7.12. .windCompensation

This attribute switches the wind deflection compensation on or off.

4.7.13. .maxRate



4.7.14. .maxAccel

This attribute is the maximum acceleration which is used to generate a slewing trajectory.



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


coudé azimuth controller (atst.tcs.mcs.coude). This controller operates the coudé azimuth drive systems

and associated mechanisms.




atst.tcs.mcs.coude


.trackId string ID unique Current track ID

.pos float degs -90 to 450 deg Demand position

.oPos float degs ?range Demand offset


.namedPos:stow float degs 0 deg Stow position

.namedPos:service1 float degs 0 deg Service position

.namedPos:lolo,

.namedPos:lo,

.namedPos:hi,

.namedPos:hihi




ICD 1.1/4.4 Rev I of 33


position error


position error




tmaInterlock:coude





.hsDataArchived boolean on|off Enable/disable storing the High

Speed Data in the Archive for this

controller

4.8.1. .mode


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





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



4.8.5. .namedPos

This attribute is the demand coudé azimuth as a named position (see Section 4.4 for a description of all



ICD 1.1/4.4 Rev I of 33


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.


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



4.8.13. .maxAccel

This attribute is the maximum acceleration which is used to generate a slewing trajectory.



4.9. M1 Mirror Cover Attributes


M1 mirror controller (atst.tcs.mcs.cover). This controller operates the M1 mirror cover mechanisms.


ICD 1.1/4.4 Rev I of 33




atst.tcs.mcs.cover

.pos string choice open | close Demand position


.interlock:attribute string[3] name tmaInterlock,

tmaInterlock:az,

tmaInterlock:alt


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.


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


ancillary controller (atst.tcs.mcs.aux). This controller operates the various MCS ancillary mechanisms.




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.


ICD 1.1/4.4 Rev I 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.


.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


ICD 1.1/4.4 Rev I 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.


.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


ICD 1.1/4.4 Rev I 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


ICD 1.1/4.4 Rev I 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.


.cMode string choice current altitude controller mode







(jogging)


encoder






second

cVelError float degs velocity error

.cVel float degs/sec current velocity

.cTorque float[2] N m individual torque


.indexing boolean true|false is currently indexing

.cLimit string choice current limit switch status: none, lo, lolo, hi,

hihi



.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


The current .cMode will be one of the following: unknown (in case if communication to the hardware is

broken), off, tracking, or active.


ICD 1.1/4.4 Rev I of 33









and inPositionAv are true; in case of jogging, .inPosition is equal to .inPositionRate.


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 hhdActive attribute is set to true if hardware is in the maintenance mode and is operated from the



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.


.cMode string choice current coudé rotator controller mode


ICD 1.1/4.4 Rev I of 33







(jogging)


encoder






second

cVelError float degs velocity error

.cVel float degs/sec current velocity

.cTorque float[4] N m individual torque motor values


.indexing boolean true|false in currently indexing

.cLimit string choice Limit switch: none, lo, lolo, hi, hihi



.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


The current .cMode will be one of the following: unknown (in case if communication to the hardware is

broken), off, tracking, or active.









and inPositionAv are true; in case of jogging,.inPosition is equal to .inPositionRate.


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.


ICD 1.1/4.4 Rev I 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 hhdActive attribute is set to true if hardware is in the maintenance mode and is operated from the



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.


ICD 1.1/4.4 Rev I 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,


ICD 1.1/4.4 Rev I 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.


ICD 1.1/4.4 Rev I 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.


ICD 1.1/4.4 Rev I 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.

ICD 1.1/4.4 Telescope Mount Assembly to Telescope Control System · 2020-01-22 · Telescope Mount...

Documents

Transcript of ICD 1.1/4.4 Telescope Mount Assembly to Telescope Control System · 2020-01-22 · Telescope Mount...