BP9 Test Report

The BP9 was not destented for operational service so the regression test was not executed.

Rather a series of specific binocular operations test cases for checking basic functionality were performed.

BP9 Tests

TEST0: (Closed dome) Determine the update time from the ingest of a "move" to the modification of the polynomials on the mountain server

Need:
  • Use PCSTimingTest version of the code.
  • Set up PCS for Binocular (use same PM on both sides).
    OK if Monocular.
  • Delete any old mountPolys.txt files.
  • Do a Track Preset, both sides.
  • Do an Offset in increments in 5", both sides (if BIN).
  • Repeat Step 3 a couple of times.
  • Stop PCS and grab poly file and SYSLOG.
  • Analyze polys with Matlab and determine delay.

Results of this test will influence the "NLoopWaits" value in lbt.conf. This variable is currently 15 (cycles).

TEST1: (Closed dome) Check the new TPK has fixed the "bad polys" problem on the mountain using the "Dice Five Offset" test script

Need:
  • Patched TPK and PCS BP9
  • Edit the lbt.conf for the GCS settings:
    • GCSL/R.noAGW true
    • GCSL/R.noAzCam true
    • GCSL/R.noTCS false
    • Restart GCSL/R
  • Delete any existing mountPolys.txt file.
  • Start PCS and run in MONOCULAR mode - LFBG.
  • Stop PCS and grab poly file.
  • Analyze polys with Matlab looking for glitches.

Run the "Dice Five Offset" test with KFPTicks=18 (default value). Looking to see if the collimation problem is triggered; This problem is also manifested as transient "bad polys" to the MCSPU. Michele needs to use Matlab to analyze the polynomials produced during the test to see if the patched kernel has addressed the "bad poly" issue.

TEST2: Test some BINOCULAR operations

The tips/tilts generated by the Demo and PCS now agree, in general, with respect to action taken for Presets and Offsets. Testing was done with a special version of PCS which communicates with the PSFs at 20Hz and no confirmation is needed. Locking/unlocking is important. Please note the real PCS only communicates with the PSFs every 10 seconds AND waits for confirmation. This means that if leaking is on, it will take approximately the following to equilibrate (in seconds):

[offsetSize / (2.0 * maxTipTilt)] * tipTiltUpdateTime

where maxTipTilt = 0.0025 tipTiltUpdateTime = 10 s

Need:
  • Start PCS and run in BINOCULAR mode.
  • Ensure using same pointing model on both sides.

FYI: Offset in Dec = tip, Offset in RA = tilt (PSF reference)

  • Evaluate leaking/non-leaking (pay attention to mount)
  • Is leaking necessary as it takes sooo long to equilibrate?
  • Change criteria for leaking?
  • Monitor the locking/unlocking of the telescope sides via the events.
    • Is a requested action applied to the proper side?
    • How good well are the actions performed?
    • Are the tips/tilts the right order of magnitude.
    • Do the tips/tilts change (increase) over time?
    • etc.

BP9 Test Results

Please know this is not an exhaustive list of the items which were identified for discussion/correction during observing. Rather this list only contains the more important issues.

Items that went well

1) Confirmed the Kernel Patch (TPK Version-1.8.2) fixes the random and occasional glitches in the trajectories. The problem was traced to uninitialized matrix variables in the kernel. The glitches could potentially cause problems for the mount in that too many incorrect polynomials in a row would cause the mount to revert to HOLD, and/or the PSFs where an incorrect elevation value would be used to compute the collimation.

This fix may also address the "nan" problem which is seen on occasion in the rotator polynomials.

2) Confirmed that once a request is communicated to the kernel by the PCS, the result of the request is manifested in the trajectories in at most two tick updates of the mount (2 x 50 ms).

3) Concluded the leaking portion of the binocular algorithm works as expected. The purpose of the leaking is to equalize the tips/tilts on the optics of the two sides of the telescope and transferring the excess to the mount. The transfer rate is limited by the optics hardware, and therefore, is too slow to be effective. However, it does no harm.

4) It is clear the binocular algorithm for locking is quite important for proper distribution of the "move" requests. For a telescope side to be locked means that effectively the optics on the locked side cannot be moved. The unlocking/locking decision process has been made more robust in that both telescope sides are always addressed for requests; this in conjunction with Item 2 above ensures the optics on the proper telescope side are available (unlocked) to accomplish the "move" request.

Items that need more work

- There were problems with late trajectories from the PCS being reported by the MCSPU. If the trajectories exceed a defined late threshold, the mount will go into HOLD mode. Late trajectories arose for at least two reasons with only one reason being pin-pointed, but it is not understood. The PCS communication with the GCS to command pause/resume guiding when tips/tilts were being requested of the PSFs seemed to cause an unreasonable delay in the transmission of polynomials to the MCSPU. This is odd as the two actions are happening in independent threads. However, the problem was repeatable and commenting out the GCS calls alleviated the problem.

The logs are being investigated in an attempt to determine other reasons for late polynomials.

- The signs of the tips/tilts were addressed for working with the front, bent Gregorian focal stations. However, some testing was done previously at Prime focus with the "opposite" signs and the guiding appeared to be working. The signs on the tips/tilts should still be considered an open issue.

- The tips/tilts are not always distributed between the optics on each side of the telescope and the mount in an expected way.

- The algorithm driving when tips/tilts should be communicated between the PCS and the PSFs must be addressed. The tips/tilts are communicated to the PSFs every 10 seconds. This required the PCS continue to update the kernel virtual telescopes with old tip/tilt demand values until confirmation could be received by the PSFs. BP9 was modified to continue to communicate with the PSFs at 10 second intervals, but the kernel was updated as if the demands were passed to the PSFs at 20 Hz. This seemed to work better in that the tips/tilts were reasonable. This issue is prime for discussion and investigation.

- Modifying and then resetting the pointing model to its default values did not removed imposed tips/tilts.

- Once the pointing correction (rectification of the predicted and measured location of the guide star in the focal plane) is requested, the GCS must wait for the optics to be in position. In the Monocular world, the mount would move for the pointing request, and the mount moves rather snappily. However, in the Binocular world, the optics are moving and some of the optics move slowly. This issue needs to be discussed by relevant parties.

- DETXY offsets in the binocular code do not work properly. DETXY offsets allow the observer to modify the location in focal plane of where the target light is imaged. Unexpected movement of the mount was observed followed by an immediate "correction" back to its original (apparently) location. This issue needs to be investigated.

-- NormCushing - 06 Mar 2011
Topic revision: r1 - 06 Mar 2011, NormCushing
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