Changes between Version 67 and Version 68 of PublicPages/MayallZbandLegacy/NotesforObservers/Problems

Timestamp:

Jan 30, 2017 2:27:14 PM (7 years ago)

Author:

Benjamin Alan Weaver

Comment:

--

PublicPages/MayallZbandLegacy/NotesforObservers/Problems

@@ -146 +146 @@
 == 7. Focus drifting ==
 
-If you lose track of the focus and don’t know whether you are below or above the focus value, wait for the readout countdown to start 
-and then type CTRL-c  in the window executing the script. Wait for the readout to complete and the “DONE” to appear on the NMSL window.
-Then execute
-{{{
-        ditscmd nohs nohs_endobs
-}}}
-Then do a focus sequence. 
-- Once you have determined the best focus: 
-                - set the focus value in the MCCD window and hit “Apply”
-                - log the Truss temperature and focus values. 
-- Create a new observing script
-- Tell the OA that you have determined a new focus and changed the focus. 
-- Restart observing
+ Symptom:: If you lose track of the focus and don’t know whether you are below or above the focus value.
+ Frequency:: Unknown.
+ Fix::
+       - Wait for the readout countdown to start and then type CTRL-c  in the window executing the script. Wait for the readout to complete and the “DONE” to appear on the NMSL window.
+       - Then execute
+         {{{
+ditscmd nohs nohs_endobs
+         }}}
+         Then do a focus sequence. 
+       - Once you have determined the best focus: 
+         - set the focus value in the MCCD window and hit “Apply”
+         - log the Truss temperature and focus values. 
+       - Create a new observing script
+       - Tell the OA that you have determined a new focus and changed the focus. 
+       - Restart observing
 
 == 8. Images of stars on the guider are bouncing around ==
 
-'''Symptoms:''' Guider images are visibly bouncing around on the TV guider image, and the seeing is poor, with the image extension being 
-primarily in the EW (i.e., up-down) direction: 
-
-[[Image(windshake.tiff, 300px)]]
-
-'''Fix:''' If the wind is high, ask the OA to close the louvers that allow additional outside air to circulate into the dome.
-If observing near zenith, the lower part of the dome slit can also be closed.  That lower part of the slit only starts
-vignetting the telescope if observing to airmasses larger than 2.
-
-'''Fix 2:''' If accounting for the wind does not fix the problem, it may be related to an issue of telescope tracking, as was the case in February 8-9 2016.  You can try a test of moving to a different part of the sky and taking a 60-second exposure.  If the stars are round, but are elongated when you move back to the field, there may not be much you can do other than report the problem and continuing to observe.  The problem seen in February 8-9 2016 was traced to the RA axis encoder tape.  Shelby Gott cleaned the tape, which fixed the problem.
+ Symptom:: Guider images are visibly bouncing around on the TV guider image, and the seeing is poor, with the image extension being primarily in the EW (''i.e.'', up-down) direction:[[BR]]
+           [[Image(windshake.tiff, 300px)]]
+ Frequency:: Unknown
+ Fix:: If the wind is high, ask the OA to close the louvers that allow additional outside air to circulate into the dome. If observing near zenith, the lower part of the dome slit can also be closed.  That lower part of the slit only starts vignetting the telescope if observing to airmasses larger than 2.
+ Fix 2:: If accounting for the wind does not fix the problem, it may be related to an issue of telescope tracking, as was the case in February 8-9 2016.  You can try a test of moving to a different part of the sky and taking a 60-second exposure.  If the stars are round, but are elongated when you move back to the field, there may not be much you can do other than report the problem and continuing to observe.  The problem seen in February 8-9 2016 was traced to the RA axis encoder tape.  Shelby Gott cleaned the tape, which fixed the problem.
 
 == 9. Bad telescope pointing ==
 
-'''Symptoms:''' The reported telescope offsets from the python "obsbot" or the IDL "mosstat" show
-that the pointing has gone off by more than 20 arcsec.  The "mosstat" script will likely fail to match
-stars if this offset is larger than 20 arcsec.
-
-'''Frequency:''' This happened many times per night in 2015, but should happen only rarely now.
-
-'''Fix:'''
-The operator will need to recenter the telescope. One can do this by
-telling the OA to offset the telescope in the *OPPOSITE* direction of the computed mosstat positional offsets, i.e., if you see: 
-{{{
-   RA, Dec offsets: -15.230 14.756
-}}}
-ask the OA to offset the telescope +15" in RA (i.e., east) and -15" in DEC (i.e., south) and zero the coordinates there. Only 
-apply these offsets when the exposure is done (i.e., during readout) and when the telescope is not moving!
-
-One can also check the observing progress using the almanac command:
-{{{
-  IDL> almanac, 10001, /noprint
-}}}
-will print out a summary of all the frames from 10001 to the present in a nice tabular form (widen the window).  This is useful for checking how the seeing and sky brightness have varied since frame 10001, and whether  one should create and upload a new JSON observing script. The /noprint just prevents the decstat output for every frame; if you want to see that, then don't use the /noprint keyword. 
+ Symptom:: The reported telescope offsets from the python "obsbot" or the IDL "mosstat" show that the pointing has gone off by more than 20 arcsec.  The "mosstat" script will likely fail to match stars if this offset is larger than 20 arcsec.
+ Frequency:: This happened many times per night in 2015, but should happen only rarely now.
+ Fix:: The operator will need to recenter the telescope. One can do this by telling the OA to offset the telescope in the '''OPPOSITE''' direction of the computed mosstat positional offsets, ''i.e.'', if you see: 
+       {{{
+RA, Dec offsets: -15.230 14.756
+       }}}
+       ask the OA to offset the telescope +15" in RA (i.e., east) and -15" in DEC (i.e., south) and zero the coordinates there. Only apply these offsets when the exposure is done (''i.e.'', during readout) and when the telescope is not moving! One can also check the observing progress using the almanac command:
+       {{{
+IDL> almanac, 10001, /noprint
+       }}}
+       will print out a summary of all the frames from 10001 to the present in a nice tabular form (widen the window).  This is useful for checking how the seeing and sky brightness have varied since frame 10001, and whether  one should create and upload a new JSON observing script. The /noprint just prevents the decstat output for every frame; if you want to see that, then don't use the /noprint keyword. 
 
 == 10. tonight.sh script stops for no apparent reason ==
 
-'''Symptoms:''' Things go idle and quiet.  No exposures are being taken or read out, the telescope is not moving, and the software does not indicate any activity.  The shell window where you are running tonight.sh returns to a prompt, and has no error message of any kind.    
-
-'''Frequency:''' This happened > 5 times on the night of 06/07 March.  The tonight show just stopped after one exposure on multiple occasions.
-
-'''Fix:''' Re-run the mosbot -py command with the appropriate pass?.json files.  Check that the tonight.sh script has been rebuilt anew.  Start the new tonight.sh script.
+ Symptom:: Things go idle and quiet.  No exposures are being taken or read out, the telescope is not moving, and the software does not indicate any activity.  The shell window where you are running tonight.sh returns to a prompt, and has no error message of any kind.    
+ Frequency:: This happened > 5 times on the night of 06/07 March.  The tonight show just stopped after one exposure on multiple occasions.
+ Fix:: Re-run the mosbot -py command with the appropriate pass?.json files.  Check that the tonight.sh script has been rebuilt anew.  Start the new tonight.sh script.
 
 == 11. MOSSTAT or MUPTILES don't see data ==
 
-'''Symptoms:''' mosstat or muptiles can’t see the data as its being taken.
-
-'''Frequency:''' Rare.
-
-'''Fix:''' check the MOS3_DATA environment variable and change as necessary in ~/.bashrc file on mayall-idl. Then: 
-
- {{{export MOS3_DATA=/mosaic3/dataX/observer/DATE}}} 
-or 
- {{{source .bashrc}}}
-
-Note "dataX" is usually data2 or data3 and DATE is the UT Date of the morning on which we are observing.
+ Symptoms:: mosstat or muptiles can’t see the data as its being taken.
+ Frequency:: Rare.
+ Fix:: Check the MOS3_DATA environment variable and change as necessary in ~/.bashrc file on mayall-idl. Then: 
+       {{{
+export MOS3_DATA=/mosaic3/dataX/observer/DATE
+       }}} 
+       or 
+       {{{
+source .bashrc
+       }}}
+       Note "dataX" is usually data2 or data3 and DATE is the UT Date of the morning on which we are observing.
 
 == 12. Semaphore Failure ==
 
-'''Symptoms:''' 
-- The tonight.sh script ends without writing the last image. There is a message in the NOCS xterm that tonight was executed in that says "FAILURE" and refers to a semaphore failure. 
-- NMSL window shows countdown green 0.0
-
-'''Frequency:''' Rare. Several times in a three night run in March 2016.
-
-'''Fix:''' 
-- First kill mosbot with ctrl C in the mzls@mayall-idl xterm.
-- Try to read out the last image. 
-
- {{{ > ditscmd nohs nohs_endobs }}}
-
- This should work. The image may be ok, or it may show all 0's
-
-- Take a zero, and check with mscstat. Usually ok. (if not follow [0] above for full restart of Mosaic3. 
-- restart mosbot.
-- restart tonight.sh.
+ Symptoms::
+            - The tonight.sh script ends without writing the last image. There is a message in the NOCS xterm that tonight was executed in that says "FAILURE" and refers to a semaphore failure.
+            - NMSL window shows countdown green 0.0
+ Frequency:: Rare. Several times in a three night run in March 2016.
+ Fix::
+       - First kill mosbot with ctrl C in the mzls@mayall-idl xterm.
+       - Try to read out the last image. 
+         {{{
+> ditscmd nohs nohs_endobs
+         }}}
+         This should work. The image may be ok, or it may show all 0's
+       - Take a zero, and check with mscstat. Usually ok. (if not follow [0] above for full restart of Mosaic3. 
+       - restart mosbot.
+       - restart tonight.sh.
 
 == 13. Elongated images due to 4MAPS valve problems ==
 
-'''Symptoms:''' 
-- Images appear elongated. In April 2016 the PA was ~20 - 30 and possibly due to a valve issue in the 4MAPS system.
-- 4MAPS o10, o11 might show blue signifying a delta psi > 1 indicating an open valve. The valve stuck at blue (delta psi > 1) during an exposure usually, but not always, leads to elongated images since forces on the mirror may be bad.
-
-'''Frequency:''' Rare. Occurred on several nights in April, 2016.
-
-''' Fix '''
- You can tell if the valve is stuck open if the “light” on the 4MAPS display of the airbags turns blue (for, e.g., o11 or i11) for an extended period of time (more than 30 sec, say). Flickering between red/yellow/green does not count; However, if the valve is stuck open, the color on the light should go from green to yellow to red to blue. 
-
- Looking at the engineering GUI for 4MAPS will show the pressure reading dropping. If it is stuck on blue, then the fix Bob Marshall recommends is the following: 
- - manually command (using the 4MAPS gui) the pressure on the problematic airbag '''lower than the reading.''' This should try and force the exhaust valve to open. 
-
- - then set the pressure back '''up to the nominal reading'''; this should try and force the exhaust valve to close. 
-
- This can be done without moving the telescope, but you probably want to stop the mosbot script, since you don’t want the script to command the telescope to move while you are repressurizing the bag. 
-
- If this test does not work with the telescope in its current position, then the next step is to take the telescope to zenith and repeat the procedure.
+ Symptoms::
+            - Images appear elongated. In April 2016 the PA was ~20 - 30 and possibly due to a valve issue in the 4MAPS system.
+            - 4MAPS o10, o11 might show blue signifying a delta psi > 1 indicating an open valve. The valve stuck at blue (delta psi > 1) during an exposure usually, but not always, leads to elongated images since forces on the mirror may be bad.
+ Frequency:: Rare. Occurred on several nights in April, 2016.
+ Fix::
+       - You can tell if the valve is stuck open if the “light” on the 4MAPS display of the airbags turns blue (for, ''e.g.'', o11 or i11) for an extended period of time (more than 30 sec, say). Flickering between red/yellow/green does not count; However, if the valve is stuck open, the color on the light should go from green to yellow to red to blue. 
+       - Looking at the engineering GUI for 4MAPS will show the pressure reading dropping. If it is stuck on blue, then the fix Bob Marshall recommends is the following: 
+       - manually command (using the 4MAPS gui) the pressure on the problematic airbag '''lower than the reading.''' This should try and force the exhaust valve to open. 
+       - then set the pressure back '''up to the nominal reading'''; this should try and force the exhaust valve to close. 
+       - This can be done without moving the telescope, but you probably want to stop the mosbot script, since you don’t want the script to command the telescope to move while you are repressurizing the bag. 
+       - If this test does not work with the telescope in its current position, then the next step is to take the telescope to zenith and repeat the procedure.
 
 [[BackLinks]]