New AO Arbitrator (UAO)

In the following paragraphs we describe the architecture and capabilities of the new AO arbitrator developed for the UAO project.

The AO Arbitrator is the process which provides a standard interface to the AO subsystem. AO Arbitrator clients are:
  • the AOS, which delivers commands from the TCS.
  • the FLAOGUI, which allows an operator to control AO operation interactively, supporting the so called "intervention mode"

The AO Arbitrator provides a command interface based on ICE which is defined in file aoArb.ice.

Note: An explicit design goal of the UAO project was to keep AOS unaltered without modifying command sequences (except for the cnage of communication protocol). For this reason the use of new advanced features, such as the intervention mode, is demanded to a specific FLAOGUI.

Finite State Machine

The AO Arbitrator implements a Finite State Machine controlling the sequence of commands. The FSM is implemented using SMC (the State machine compiler) which provides tools to define the FMC and and produce the associate diagram which is of great help in understanding the internal logic of the Arbitrator. The current state diagram of the AO Arbitrator is attached below.

The FSM supports both modes (Automatic and Intervention). The main sequence of operations is as follows:

  1. Status is Ready, command from AOS: PresetAO (AOS waits for PresetOK)
    1. Automatic mode: the PresetAO is executed and the status become PresetOK
    2. Intervention mode: the PresetAO is executed, the status becomes PresetCheck
      • The FSM waits for an aknowledgement from FLAOGUI
      • The operator presses "Done", the status becomes PresetOK (AOS is notified)
  2. Status is PresetOK. Command from AOS: AcquireRefAO (AOS waits for ReadyForStartAO)
    1. Automatic Mode: a full AcquireRefAO sequence is performed, the status becomes ReadyForStartAO.
    2. Intervention Mode: The status becomes ManualAcquire
      • The operator may use FLAOGUI to send any command: CenterStar, CenterPupils, CheckFlux
      • When the operator presses CloseLoop the AO loop is closed and the status becomes: InternalLoopClosed
  3. Status is InternalLoopClosed.
    1. Automatic Mode: AOS keeps waiting for ReadyForStartAO
    2. Intervention mode:
      • The operator may use FLAOGUI to send any command: OptimizeGain, ApplyOpticalGain
      • When the operator presses "Done" the status becomes ReadyForStartAO and AOS is notified.
  4. Status is ReadyForStartAO, command from AOS: StartAO
    1. Automatic mode: the status becomes LoopClosed. AOS may issue any command: CorrectModes, OffsetXY, OffsetZ
    2. Intervention mode:the operator may use FLAOGUI to send any command: AdjustGain, OptimizeGain

Standard Mode

In standard (automatic) mode the AO Arbitrator (new UAO version) will operate exactly as the previous AO Arbitrator in reply to commands issued by the AOS. In order to allow expert users to have finer control of the single steps of the AO operations an "intervention mode" has been implemented.

Intervention Mode

The intervention mode allows an expert user to control various steps of the AO operation so that a failure in some substep can be solved without the need to recover the entire operation from the beginning. When in intervention mode the operator can modify the sequence of substeps which implement two of the main commands issued by AOS. User intervention is usually managed by means of a dedicated GUI (FLAOGUI). The commands which are affected are:

  • PresetAO is executed as in automatic mode, but the execution is blocked just before returning an "OK" to AOS. Here the user can either send the "OK" so that AOS can issue the following command (AcquireRefAO) or can send "Cancel", which will return an error to AOS, so that the AO start sequence is interrupted.

  • AcquireRefAO. After a successful PresetAO, AOS will follow with an AcquireRefAO command. In Intervention mode this command will will simply be blocked while the user is enabled to issue a number of sub commands, possibly repeating them as needed until the status of the AO subsystem is suitable to proceed. The set of subcommands are divided into two groups: the first group of commands is issued before the closing of the AO loop (see status ManualAcquire in FSM diagram), the second one is issued after the loop has been closed (see status InternalLoopClosed in FSM).

    When the user is satisfied he/she will send an "OK" to AOS so that it will issue the final StartAO command. The latter command will have no physical effect, in that the AO subsystem is already in loop closed status, it will simply set the corresponding status in the FSM.

  • LoopClosed. In standard mode a "Skip frame" event will cause the AO subsystem to open the adaptive loop and go back to Ready status (i.e.: seeing limited operation). In Intervention mode, the same "Skip frame" will set the AO subsystem in LoopFault status, i.e.: waiting for user intervention. If the cause of "Skip frame" is temporary (e.g.: a passing by cloud) the user can send a ReCloseLoop command to force the AO subsystem to close the AO loop again. If the cause is persistent, of course, the user will instead send a "Cancel" command.

Failing Actuators

A relevant new feature of the FLAO Supervisor is the capability to manage failing actuators without stopping the current operation (both in seeing limited and in adaptive modes). This capability is allowed due two new mechanisms implemented in the Adaptive Secondary firmware and in the Supervisor Software.

  • Firmware mechanism: the legacy (pre UAO) version of AdSec firmware could detect and notify a failure in a single actuator. The notification would cause the Supervisor Software to drive the mirror to a safe status immediately, thus interrupting any operation on going. After that the AO operation could be resumed only after shutting doen the AO subsystem, adding the failed actuator to a "failed actuator list" and restarting everything from the very beginning.
    The UAO version of firmware still notifies failing actuators to the AO Supervisor and, moreover, can drive the mirror to safe status autonomously (i.e.: without the intervention of the Supervisor software), but this only happens when four contiguous actuators fail. In this way the failure of one actuator or a few sparse actuators would not cause the interruption of current activity.

  • Supervisor mechanism: while the Supervisor has not the task of setting the mirror to safe status on failing actuators any longer, it must be notified of failed actuator so that they are removed from internal computations so that funny position or current values related to that actuator are no used. This is performed on-the fly, without affecting operations. Moreover the Supervisor will notify the operator of failed actuators, allowing him to "temporarily remove" them (i.e.: acknowledging the failure). The implementation of this mechanism has two effects which must be known:
    1. If more than one actuator fail at the same time, they are notifyed/removed one at a time.
    2. The removal of failed actuators is temporary; i.e.: it will be cleared at the next mirror set up. Actuators can be removed permanently only by updating the "failed actuators" list as before.

FLAOGUI

The FLAOGUI has been developed to allow an experienced used to have a finer interaction with the FLAO subsystem. From the FLAOGUI the user may request to set the intervention mode which allows to optionally execute or repeat single substeps of the command sequence.

When the Auto mode is selected the system operates automatically as before the intervention mode feature were added to the system and the FLAOGUI has very limited capabilities.

When in Intervention mode the FLAOGUI mus be open to allow the correct operastion of the FLAO subsystem. With reference to the description of Intervention mode operations above, at each step of the command sequence issued by AOS, the user must use buttons to request FLAO to perform the single substeps. Available commands at each steps are clearly indicated by the corresponding button becoming green; an indicator close to each button shows the current status of the corresponding substep: yellow for substep in execution, green for substep terminated correctly or red for substep terminated with error.

The FLAOGUI shows also when a mirror actuator fails and allows to mark it as "removed".

Topic revision: r5 - 19 May 2016, LucaFini
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback