Software Progress Report - October 2009

The activity related to AdOpt Software was almost completely devoted to the test of the entire system by using the final version of the AO Software.

AdOpt software

The activity in this area was mainly related with fixing bugs discovered during the tests.

The following areas were involved:

  • Common software and libraries
    • The offload modes data computation was implemented in FastDiagnostic. Data validity test were also performed.

  • AdSec software
    • Bug fixes

  • WFS software
    • The support for the PresetAO and AcquireRef commands was considerably enhanced.

  • AO Arbitrator
    • Small modifications to the FSM of the AO Arbitrator were suggested by results of tests

AOS

  • A few commands were revised. The PresetAO and ModifyAO were splitted in two versions in order to better support both the IIF and the AOSGUI.
  • The logging of run-time info was toroughly revised and improved
  • Some enhancements to the AOSGUI
  • The AOS code was revised to comply with the definition of the lbto namespace in the entire TCS.

Miscellaneous

  • Log file analyze utilities enhanced.

Software tests

The testing of the entire software system was the central activity of the month.

AO Arbitrator test

The capability of the AO Arbitrator to coordinate operations of the WFS and the AdSec were tested.

The following operations were tested, against the real hardware, by means of the releted GUI.

  • Power on Adsec: Adsec is powered on and initialized with default flat shape
  • Power on WFS: WFS is powered on and initialized with default IRTC setup.
  • Power off Adsec: Adsec mirror is put in "rest" position and safely powered off.
  • Power off WFS: WFS is powered off.
  • Set ENGINEERING mode: AOArbitrator is driven to service state "ENGINEERING"
  • Set READY mode: AOArbitrator is driven to service state "READY"
  • Set STANDALONE mode: AOArbitrator is driven to service state "STANDALONE"

The test was successfully completed.

The other AO Arbitrator operations were tested by issuing commands from the AOS (see below).

TCS simulation setup

We set up a workstation running TCS in order to be able to simulate the working system. We successfully compiled and run the TCS subsystems involved in the tests, namely:

  • AOS and AOSGUI (of course)
  • OSS & OSSGUI
  • PCS and PCSGUI
  • PSF
  • IIF and IIFGUI

We also installed irs/irc to be able to simulate the operations of a telescope instrument.

Interfacing tests. 1 - Commands

The communication of commands and data between the TCS/AOS and the AO Supervisor have been toroughly tested by simulating AO related commands both issued from the AOSGUI and from a test client program.

This particular test exercises the chain of commands and data exchanges between the TCS and the AO Supervisor, excluding the IIF. The result of commands was evaluated by inspecting log files. In this phase the AO hardware is not involved.

All the commands were tested and a few cycles of the bug fixing process were performed.

The test was successfully completed.

Interfacing tests. 2- Offload modes

A simulated environment was set up to test the offload modes mechanism. This involved a test program on the AO Supervisor side which is able to send offload commands to the AOS.

The result of such commands was verified by inspecting the log files (both at the AO Supervisor and at the TCS side). The tests involved the following TCS subsystems: AOS, PSF, OSS.

The test was successfully completed.

Full system tests

Full system tests were performed by using the irc to send instrument commands to the TCS through the instrument interface ( IIF).

We first performed a few cycles of simulated tests (i.e.: tests without the AO hardware) to verify the correctness of commands and data exchanged.

Then we tested some of the commands in a real environment checking the results on the real hardware.

The following commands were successfully tested:

  • Start observation: AOArbitrator is driven to service state "OBSERVATION" and SeeingLmtd state.
  • Terminate observation: AOArbitrator is driven to service state "READY".
  • PresetFlatAO: Adsec selects the specified flat shape or, if no particular shape is specified, selects the default flat shape. AOArbitrator is driven to SeeingLmtd state.
  • PresetAO: Reference star information is used to do a preliminary selection of AO parameters (reference star is loaded with irc SetReference command) AO parameters are shown in the AOS GUI. WFS is prepared for source acquisition. AOArbitrator is driven to ReadyToAcquire state.

    Note: the coordinate conversion command, provided by PCS, did not provide correct position (in the focal plane reference) because we must properly emulate telescope pointing. This will require some fiddling with the TCS setup. The test is partially successful, anyway, because when sending correct focal planes coordinates from the AOSGUI, those are transmitted to the AO Arbitrator as expected.
The above tests were successfully completed

What remains to be tested

In the next few weeks we plan to use 4-5 days of Solar Tower time to complete the testing of the AOS commands, namely:

  • AcquireRefAO: WFS acquires the reference star using the acquisiton camera AO parameters are refined using the measured magnitude and seeing. AOSGUI shows the new AO parameters. Adsec is prepared for AO loop. AO Arbitrator in RefAcquired state.
  • CheckRefAO: WFS checks reference star position in the technical camera and offsets are computed. Offsets are shown in the AOS GUI. AO Arbitrator remains in ReadyToAcquire state.
  • ModifyAO: AO parameters modified as specified in the command parameters. WFS and Adsec are re-initialized as needed. AOS GUI shows the new AO parameters. AO Arbitrator is driven to RefAcquired state.
  • StartAO: AO loop is closed. AO Arbitrator is driven to LoopClosed state
  • PauseAO: AO loop is paused. AO Arbitrator in LoopPaused state
  • ResumeAO: Light levels are checked in the WFS camera. AO loop is resumed. AO Arbitrator is driven to LoopClosed state
  • StopAO: AO loop is opened. AO Arbitrator is driven to SeeingLmtd state.
  • OffsetXY: WFS applies XY offset. If in closed loop, PSF on technical camera and/or IRTC shows the same displacement. AO Arbitrator remains in current state (SeeingLmtd , LoopClosed or LoopSuspended).
  • OffsetZ: WFS applies Z offset. If in closed loop, PSF on technical camera and/or IRTC shows the same displacement. AO Arbitrator remains in current state (SeeingLmtd , LoopClosed or LoopSuspended).

It must be noted that the complexity of above test is very variable. AcquireRef, CheckRefAO and ModifyAO, are the most complex (in that they involve sequences of operations on the AO hardware) but have many steps in common, and have been already individually tested in the AO standalone tests.

OffsetXY and OffsetZ are of medium complexity (the number of AO harware operations involved is small). The other commands are trivial.

  • Offload modes: Simulated offset is applied to the AdSec and the resulting offload commands generated by FastDiagnostics are sent to the OSS. The correctness of correction is verified by the optical image.

Network setup tests

We tested the configuration of a Cisco Ethernet switch (which is going to be integrated into the AdSec rack in substitution of the current D-Link model).

The interoperability with the D-Link switch currently operating in the solar tower lab was successfully verified.

Acknowledgements

We thank all the members of the software group in Tucson which provided crucial support in setting up the TCS in Arcetri.
Topic revision: r2 - 05 Nov 2009, 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