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.
TEST0: (Closed dome) Determine the update time from the ingest of a "move" to the modification of the polynomials on the mountain server
- 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
- 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
maxTipTilt = 0.0025
tipTiltUpdateTime = 10 s
- 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
- 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?
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
where an incorrect elevation value would be used to compute
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
. 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
and the PSFs
must be addressed. The tips/tilts are communicated to the
every 10 seconds. This required the PCS
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
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
- 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.
- 06 Mar 2011