Release Date: Mar 13, 2011
Generic Release Name: BP10
Public Release Name: "Binocular Observing" release 10
General Description: This is BP9 with bug and extensions to various TCS subsystems. It supports Telemetry version 13.
Telescope Operator Overview Information
GCSGUI now only shows the CCD temperature of guide and WFS camera in main window
GCSGUI will not show a centroid marker on subsequent full frame images during MODS acquisition sequence anymore. Only the first image will show a marker. This is correct and intended as no actions are taken on subsequent images anyway and they are only for visual verification of the process.
The PMCGUI ventilation form no longer shows the detailed temperature data. The data is available on the 'details' form.
The defaults for the PSF arbitrator have been changed per John Hill's email of 2/23/11.
Support Astronomer Overview Information
GCS will apply Z4-Z8 on the RFBG when the WFS RMS exceeds 1000nm for these coefficients as per its current configuration
Specific Tests that need to be performed with the Telescope
GCS configuration for all AGWs has been changed to have a guideCorrectionFactor of 0.8 which should dampen the problems described in IT #2853. A test should be run if this is indeed the case. Details would have to be set up by an astronomer familiar with the issues described in IT #2853.
as a reminder for the GCS developer: logs of the on-sky test night with BP10 should be analyzed to confirm that there are no temperature readout requests being sent to the guide camera during the acquisition sequence. If this can be confirmed IT #3205 can be closed. No special tests have to be run to generate the log entries. One successful preset should be enough to create the log data necessary.
Patches to the Release
Add the networkserver build name to the output of 'netconfig -v'.
added a new configuration value to lbt.conf: GCSL/R.maxFWHM which takes a maximum allowable FWHM in arcsecs for filtering Source Extractor results
added code to support filtering all Source Extractor results that exceed FWHM limit defined in lbt.conf
set lbt.conf GCSL/R.sextractorFlags to 16
fixed an annoying bug in MovieThread that caused resends of a full frame ROI command when using a full frame ROI different from the detector size
added new MODS Source Extractor configuration for left and right side to configuration
set lbt.conf GCSL/R.maxFWHM to 10.0
added all default Source Extractor convolution matrix files to the GCS configuration
added _xy_transpose related offAxis compensation from BP7 to current code
removed sextractor analysis of movement verification acquisition images when using MODS as the last one caused many acquisitions to fail because the star ended up in the darker area of the prism as well as close or a little beyond the edge. The images will still be visualized but they will not have a red centroid marker on them as sextractor is not evaluating them. These images are not used to get the star in the box and the sextractor result on them was not used to do anything but a sanity check if the signs for the telescope and guide probe movements were correct. This will finally fix the problems with IT #2893
corrected the WFSingThread::calculateRMS() function to use the defined _WFS_hex_z string to calculate the hex RMS value
found and fixed a problem with the range setting to catch the zero position error with MODS (IT #3011), fixed it so we can see if this problem occurs again.
made Sextractor class more robust by catching any kind of exceptions during basic centroid handling. There were a few core files on the mountain where GCS died due to strange exceptions during Sextractor functions and I want to avoid a crash while collecting debug informations when and what is going on.
added SysLog::log statement before calling Source Extractor program to document the full command line as there seems this seems to be where the previous core files came from
added log message in GuideThread::executeExternalCentroiding if a thread join failed (might be causing an exception in a timed out worker thread)
AGWCamera now logs the camera type it received an error during temperature readout from
cleaned up the Mutex handling in AzCam class and removed auto recovery from a deadlock as it made te problem worse and hard to detect
completed the list of conditions under which the temperatures of cameras should not be updated
extended the timeout for the guide loop to respond to a pause request to 4 seconds plus current exposure time as we had a timing issue as described in IT #2370
changed the guide loop camera temp updates to not occur more than once a minute as the temperature command on some AzCams can sometimes get really slow to respond (3 secs!)
updated the AIP_R.cfg & AIP_IRTC_R.cfg files to have WFS_redefine_hex_z set to 45678 which corrects Z4-Z8 when WFE RMS hex limit is exceeded
changed the WFS loop camera temp updates to not occur more than once a minute as the temperature command on some AzCams can sometimes get really slow to respond (3 secs!)
Make waiting for both synchronous Presets/Offsets standard behavior. It is no longer switchable on the GUI
Require two BinocularControl commands for each synchronous Preset and Offset, one for each side. This allows one side to be waiting for a synchronous Preset/Offset while the other side continues to issue asynchronous Presets/Offsets (requested by John Hill).
Add configurable (in lbt.conf) delays before starting/resuming guiding in Preset/Offset.
Move enabling PCS tip/tilt to as soon as the PCS is done processing position change so the optics will start moving earilier.
Rework Preset and Offset by getting the PCS tip/tilts with a new PCS client method, send them to the PSFs without collimating the mirrors, collimate the mirrors explicitly, and enable PCS tip/tilts when the collimations are done. This is to avoid collisions between the IIF collimation requests and the PCS tip/tilt requests, but insure the optics are in position before returning to the instrument.
The Offset command will now collimate the primary for the LBC, so an LBC StepFocus following a preset/offset is no longer necessary.
IIFGUI Version 3.7
Display the status color.
Modify the display for synchronous/asynchronous Presets and Offsets for the changed logic and flags related to the two required BinocularControl commands.
In the class which performs the communication of the tip/tilt values to the PSFs, release the trigger and allow the PCS to continue, regardless of whether the communication has been successful or not. This will ensure tip/tilt demands can continue to be processed, and the calling subsystem (e.g., GCS) can continue with guiding. As "fail" events are generated by the communication routine, each situation will need to be analyzed and understood for possible sequencing or timing issues.
Change leak to 0.0 for LBC. Documented in lbt.conf.m4. This variable will migrate to being instrument-specific in an upcoming build.
Remove obsolete PCS variables from lbt.conf and source code. Variables, pcDelay and guideDelay, have been replaced by the "trigger" algorithm. Variable "tipTiltUpdateTime" is obsolete due to an algorithm change which allows essentially continuous updates.
Implemented a new client method which allows access to the tip/tilt demands upon request. The values are returned as needed by the PSFs; the positive/negative sign has been set appropriately, and the Kernel_tip = PSF_tilt and Kernel_tilt = PSF_tip.
New method: getTipTilts(void) - Returns (in order and type double): psfTipSX, psfTiltSX, psfTipDX, psfTiltDX
Support started/complete/failed events implemented.
PCS_Version-6.13 - BINOCULAR
Changed the algorithm that issues tip/tilt demands to the PSF subsystems. The demand updates are no longer periodic, but they are continuous. This means demands are made to the PSFs, on a per side basis, but no further demands can be issued, until the PSF side has completed the previous update and has "rested" for 0.5 seconds.
The lbt.conf variable, tipTiltUpdateTime, has been rendered obsolete by this modification.
In conjunction with the tip/tilt algorithm change to continous updates, actions which require the optics to adjust to accommodate the change issue a "pulse" which acts as a token. This token is tracked as a mechanism to determine when the tip/tilt demands have been sent to the PSFs, and more importantly, when the PSFs determine the optics are in their new position. Only after the confirmation is received by the routine which requested the change initially (e.g., request to apply a guide update) will the PCS return to the invoking subsystem. The affected routines are:
The lbt.conf variables, pcDelay and guideDelay, have been rendered obsolete by this modification.
When switching from Binocular to Monocular mode, the PCS will set the tip and tilt demands for the PSFL and PSFR to zero.
Reinstated the synchronization for the pointing correction when the focal stations/instruments are appropriate. Also reinstated the locking/unlocking calls as they were formerly encapsulated by the Preset. These methods are: updateGuideOrigin and updateReferenceOrigin.
Made improvements to ensure the synchronized Presets and Offsets are handled properly in terms of when each generated Preset/Offset is actually processed by PCS. Ensured that only the first Preset of the synchronized pair is allowed to be promoted. Also, the first command must unlock a mutex before the second Preset/Offset can be processed. This eliminates TEL errors, and more importantly, sets the SX and DX targets correctly and only once.
Moved the responsibility of locking/unlocking telescope sides entirely into the PCS. Formerly, the IIF handled locking/unlocking when instruments Authorized and issued Presets and Offsets. The PCS handled all other instances of the locking/unlocking.
Originally modified lbt.conf.m4 in BP9 primarily by adding variables which could be used in testing of the binocular pointing algorithms: (enableLockAlgorithm, pcDelay, guideDelay, azNArc/elNArc). Modified "NLoopWaits = 3" and "[tip|tilt]Sign[SX|DX] = -1"; the latter accommodates the Front, bent, Gregorian focal stations.
PCS_Version-6.13 - MONOCULAR
Ensured in Monocular mode the rotator on the unauthorized (aka None) side does not send any polynomial values to the MCSPU. The MCSPU always checks the validity of any polynomials that it receives, even if the MCSPU has not been requested to use the polynomials. This change required an additional check on the return values for the rotator matrix provided to MCSPU to eliminate a potential and misleading message/event which could be generated IFF the rotator were in "state of READY and tracker status of HOLDING" versus "state of IDLE and tracking status of HOLDING". The message would be annoying, but it would not affect observing.
TPK - 1.8.2: This patch was in BP9 which never was used for science operations.
Patch TPK with three files: TcsLib.h, TcspkRefSys.h, and BaseVt.cpp. This addresses an initialization problem in the kernel which manifested itself as inconsistent tracking polynomials. There would be some number of azimuth and elevation polynomials (~5 - 40) whose values were discrepant from the overall trajectory.
First cut at calculating the actual applied tip/tilt in adjustPointing (called by the PCS). If the final mirror positions will be limited, the limited values are sent to the mirror(s) and the applied tip/tilt returned to the adjustPointing caller in the CommandReturn object.