Commissioning - Software Testing of Build 12 - 03-04 October 2008

Summary

Weather is bad. So we are running closed dome software tests on new TCS build 12

Nighttime Activities

Times in MST

TCS General Tests

Found an obscure bug where a freshly started reflective memory segment doesn't get populated until the subsystem does something. After Chris restarted the reflective memory on lbtmu01, Aaron's PSFGUI LEFT on lbtmu01 was full of zeroes, while the same GUI on lbtmu103 was correctly populated.

Preset Tests

~19:40 It takes 15-20 sec to log into lbtmu05 when it has zero load, Michele reports similar for lbtmu03.

~19:50 irc Authorize 'bentGregorianFront left' LUCIFER command took ~20 seconds to return, but did succeed.
Repeated same behavior at 20:03.

20:10 Michele restarts irs on lbtmu105, because it apparently wasn't running.

20:12 Pointto BS9107 failed
Oct 3 20:11:50 lbtmu105 LBT_IIF: [I] parkActiveProbe: no AGw unit selected or GCS is guiding and/or WFSing

20:18 Aaron starting oacserver, etc.

20:21 Pointto BS9107 failed
Oct 3 20:21:41 lbtmu105 LBT_IIF: [I] parkActiveProbe: no AGw unit selected or GCS is guiding and/or WFSing

20:24 selectAGW (on lbtmu107)

20:25 Pointto BS9107 succeeds

Guiding Tests

20:29 Pointto BS9107 gs=0 GUIDE correctly didn't find star on acquisition image

Looking at a dome flat, it looks like Torsten has the minimum counts value set to high, as it won't start guiding even though it is expecting 359 counts.
Oct  3 20:36:46 lbtmu107 LBT_left_GCS: found guide star in image at 229.999359,220.262711.
Oct  3 20:36:46 lbtmu107 LBT_left_GCS: couldn't adjust exposure time to 128000 ms as the guide interval (5000.000000) minus 400ms processing time is not long enough.
Oct  3 20:36:46 lbtmu107 LBT_left_GCS: trying to estimate counts for maximum exposure time 4600 ms at given guide rate.
Oct  3 20:36:46 lbtmu107 LBT_left_GCS: estimated counts would be 359.
Oct  3 20:36:46 lbtmu107 LBT_left_GCS: couldn't adjust exposure time to meet minimum counts requirement. star too dim or guide rate too high.
Oct  3 20:36:46 lbtmu107 LBT_left_GCS: maximum exposure time is 4600 at the given guide rate.
Oct  3 20:36:46 lbtmu107 LBT_left_GCS: GCSL:startGuiding execution time: 16094 ms at 1223091406998

GCS low water mark for GS counts was 1000. We've chsnged to to 100 to continue some fake guiding. 1000 is a good value, but being below 1000 should still allow you to continue to guide down to the star detection threshold.

20:46 Stop and restart GCS to get new parameters.

20:47 Now guiding on dome flat gradients (a useful test feature)

20:49 Start 3 GCSGUIs (Aaron, John, Michele)

21:06 Pointto ACTIVE

End guiding testing, on to PCS testing.

PCS Tests

21:10 Pointto TRACK

21:12 irc OffsetPointing 0. 0. 5. COORD_FOCAL_MM MOUNT true REL left
OffsetPointing: Error on the coordinates System. Possible values: RADEC_SKY, RADEK_FOCAL, ALTAZ, FOCAL_PIX
Since Jose doesn't know about Michele's new command yet.

Michele's test client seems to update PCS correctly, but only Michele's test client can adjust the pointing origin.

21:20 azhold, elhold - then send a new preset. The bad polys problem on the first slew seems to be fixed.

21:56 Aaron presets telescope to near zenith. HA=-00:10:00 DEC=+30

Starting with guide filter values at the traditional 0.2, a 10 arcsec correction seems to appear "almost" instantly as servo error.

22:21 Change guide filters to 0.02 and restart PCS

22:25 Aaron presets telescope to near zenith. HA=-00:10:00 DEC=+30

We can't see that the guide correction is being applied at all.

22:33 Change guide filters to 0.1 and restart PCS; We can't see that the guide correction is being applied at all.

22:38 Change guide filters to 0.18 and restart PCS; We can't see that the guide correction is being applied at all.

22:41 Change guide filters to 0.2 (original value) and restart PCS

We can't see 10 or 100 arcsec offset guiding corrections on the MCS display, even though we could see them an hour ago with the same filter gains. irc OffsetGuiding 0. 0. -10. RADEC_FOCAL left

22:50 Change guide filters to 1.0 and restart PCS.

22:58 Switch to being LBC, where guding corrections are showing up on MCS.

23:01 Back to being LUCIFER

23:06 pointto BS9107, abort, and resend Aaron's preset from PRESETGUI. Guiding corrections don't show up.

23:13 pointto BS9107 and allow it to slew there.

23:25 pointto BS9107 GUIDE, but it doesn't recognize the irc OffsetGuiding 0. 0. -10. RADEC_FOCAL left

23:32 pointto BS9107 TRACK, but it doesn't recognize the irc OffsetGuiding 0. 0. 100. RADEC_FOCAL left

Oct  3 23:36:42 lbtmu102 LBT_PCS: PCS:GUIDER:SetCentroid executed
Oct  3 23:36:42 lbtmu102 LBT_PCS: Centroid Xrad: 0.000000000000000 Yrad: 0.004848136811095 Xarcs: 0.000000000000000 Yarcs: 1000.000000000000114
Oct  3 23:36:42 lbtmu102 LBT_PCS: PCS:GUIDER:SetCentroid execution time: 36 ms at 1223102202541

23:42 Michele sends directly to PCS client, ApplyGuideCorrection. And that worked. So GCS should be able to guide if we ever see a star. A key fact in the confusion is that only LBC should be using setCentroid, while GCS is using the lower level command ApplyGuideCorrection. However, irs/IIF is apparently calling setCentroid in response to a OffsetGuiding command from any instrument. What we still don't understand is why it worked sometimes and not other times.

Oct 3 23:50:56 lbtmu102 LBT_PCS: ROT RPC Error: 000000E000 (and we see that rotator is slewing??????) We don't know what caused this.

00:53 Tested that presets in ACQUIRE mode work by sending irc commands manually. Dave doesn't yet have ACQUIRE as one of the allowed values in the LBTtools.IRTC.pointto command.

-- JohnHill - 04 Oct 2008
Topic revision: r2 - 04 Oct 2008, JohnHill
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