9.1 External Software Interfaces

9.1.2 Keck II Active Control System (ACS)

SC communicates with the ACS through the ACS Gateway RPC Server, the standard interface by which any task requests information from and sends commands to the ACS. No special interface or provisions for AO are envisioned. Gateway services are described in detail in KSD 103,The ACS Gateway RPC Server; only those of specific interest to AO are reprised here. The KSD also provides specific information concerning programming details of the RPC (Remote Procedure Call) interface, as well as those of the keyword layer also available. Only functional capabilities will be called out in this section, rather than the particular RPCs or keywords through which the function is implemented.

The UI does not communicate directly with the ACS. All necessary setups, initializations, and commands are achieved through other tools, such as

• Facsum for a quick look at ACS health

• MAlign to analyze focus mode images

• ACS GUI to command global attitudes during testing and calibration

9.1.2.1 SC/ACS interface overview

The salient features of the ACS Gateway of interest to the SC are as follows:

• The ACS Gateway offers three basic types of interaction: action commands, state information, and event notification.

• Actions, typically moves, can be issued with a notification request in such a way that if the move command is accepted by the ACS, then the requester is guaranteed notification when the command completes. The SC will exploit this feature in order to prevent move-on-move requests. Move commands issued while another move is in progress, or those that would result in an actuator limit violation, will be rejected with an error return code.

• State information includes MOVE-IN-PROGRESS, ACS-UNSETTLED, and MODE. The SC will monitor these states to apprise itself of the overall health of the ACS so that it can take appropriate action on state changes. See reference below...

9.1.2.2 AO/ ACS interface block diagram

The ACS Gateway will support three protocols at its interface to the outside world: RPCs, ktl-keywords, and EPICS-style Portable Channel Access; the latter two being of particular interest to AO.

9.1.2.3 SC/ ACS interface component description

One move vector and three status keywords comprise the functional components pf the SC/ACS interface. The SC sends move commands and is aware when they complete; it also monitors the ACS's mode and unsettled conditions [??].

9.1.2.3.1 TIP-TILT-PISTON:

The ACS Gateway supports a 108-element move vector, that allows each segment to be moved in both tip-tilt and piston.

9.1.2.3.2 MODE:

For the ACS to be in RUN mode implies that the primary mirror's sensor-to-actuator control loop is closed. STANDBY mode is a condition indicating abnormal operation. IDLE indicates that the ACS is functioning normally, but the control loop is open.

9.1.2.3.3 MIRROR-MOVE-IN-PROGRESS:

The SC will register to receive notification of MIRROR-MOVE-IN-PROGRESS events. This is necessary in order to monitor moves that it requests, so that it can be advised when the move is complete. SC needs to know when the ACS move command is complete, because only then will it want to begin determining the next error correction vector.

9.1.2.3.4 ACS-UNSETTLED:

The SC will register to receive notification of ACS-UNSETTLED events. The ACS-UNSETTLED state indicates that some disturbance, not associated with a move command, is causing large actuator moves.

9.1.2.4 Unloading corrections to the ACS: a walk-through

TBD

9.1.2.1 - SC/ACS interface overview

9.1.2.2 - AO/ ACS interface block diagram

9.1.2.3 - SC/ ACS interface component description

9.1.2.3.1 - TIP-TILT-PISTON:

9.1.2.3.2 - MODE:

9.1.2.3.3 - MIRROR-MOVE-IN-PROGRESS:

9.1.2.3.4 - ACS-UNSETTLED:

9.1.2.4 - Unloading corrections to the ACS: a walk-through

Generated with Harlequin WebMaker