User Tools

Site Tools


chara:discussion_of_alignment_procedures

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
chara:discussion_of_alignment_procedures [2024/03/25 13:46]
gail_stargazer
chara:discussion_of_alignment_procedures [2024/04/23 08:20] (current)
denis [Current Alignment Sequence]
Line 28: Line 28:
   * When slewing to next star, send M7 to default position and repeat.   * When slewing to next star, send M7 to default position and repeat.
  
-==== New Alignment Sequence ====+==== Current Alignment Sequence ====
  
 Implemented January-July 2023 Implemented January-July 2023
Line 38: Line 38:
   * Align TelWFS boxes to center on the red beacon.   * Align TelWFS boxes to center on the red beacon.
   * Align blue beacon to labAO using dichroic.   * Align blue beacon to labAO using dichroic.
-      * <font inherit/inherit;;inherit;;transparent>I do not understand why M2 corner cube is not used here, with laser coming from lab as in original sequence? I think it is the only way to orient the dichroic.</font> +      * <font inherit/inherit;;#2980b9;;transparent>I do not understand why M2 corner cube is not used here, with laser coming from lab as in original sequence? I think it is the only way to orient the dichroic.</font> 
-      * <font inherit/inherit;;#cc0000;;inherit>The laser/cc is not used for the fine alignment for the same reason the acq camera is not used for aligning the red beacon to tel wfs. The ao system aligns to sub arcsec.</font> +      * <font inherit/inherit;;#cc0000;;inherit>The laser/cc is not used for the fine alignment for the same reason the acq camera is not used for aligning the red beacon to tel wfs. The ao system aligns to sub arcsec.</font><font inherit/inherit;;#8e44ad;;inherit>I do not believe the laser has ever been used to align during observing since the AO system has been installed. I have never used it or the corner cube. The cc is at times unreliable and can get lost or stuck. The laser spots can be seen without the corner cube if needed to realign the dichroic. What are we to see or align with the laser and corner cube that we don’t see without?</font>* Focus blue beacon on labAO and red becaon on TelWFS.
-      * <font inherit/inherit;;#8e44ad;;inherit>I do not believe the laser has ever been used to align during observing since the AO system has been installed. I have never used it or the corner cube. The cc is at times unreliable and can get lost or stuck. The laser spots can be seen without the corner cube if needed to realign the dichroic. What are we to see or align with the laser and corner cube that we don’t see without?</font> +
-  * Focus blue beacon on labAO and red becaon on TelWFS.+
   * If aberration terms are high, ZERO CENTROIDS to adjust relative positions of the boxes.   * If aberration terms are high, ZERO CENTROIDS to adjust relative positions of the boxes.
  
Line 56: Line 54:
   * If coma and astigmatism high, create sky flat on bright star - Turn off **[DM]**, **[SV FLT]**, **[FLATEN]**, then relock the **[DM]**.   * If coma and astigmatism high, create sky flat on bright star - Turn off **[DM]**, **[SV FLT]**, **[FLATEN]**, then relock the **[DM]**.
   * For IR combiners, move beacon flat to align star to STST.   * For IR combiners, move beacon flat to align star to STST.
-  * For SPICA, move beacon flat to align star on SPICA FTT. +  * For SPICA, move beacon flat to align star on SPICA FTT. <font inherit/inherit;;#16a085;;inherit>(denis: we validated the combined method BF+M7 on E1 on April 23 and it did excellent worj, permitting to use the Right/Left,Up/Down axes of the IPDET to put the star in the FTT boxes.)</font>* Star Acquired. 
-  * Star Acquired. +  * <font inherit/inherit;;#1abc9c;;inherit>(denis: when FTT is locked turn on the offload to keep the alignment during tracking =⇒ good for FTT and good for Alignment. This has been successfully implemented in April 2024)</font>* When slewing to the next star, DO NOT send M7 to default. If next star is bright, then align beacon flat to center star on STST/SPICA FTT. If star is faint, keep beacon flat fixed or align beacon flat to center red beacon in offset beacon boxes on TelWFS. 
-  * When slewing to the next star, DO NOT send M7 to default. If next star is bright, then align beacon flat to center star on STST/SPICA FTT. If star is faint, keep beacon flat fixed or align beacon flat to center red beacon in offset beacon boxes on TelWFS.+
  
 ==== Proposed Revisions to Current Alignment Sequence ==== ==== Proposed Revisions to Current Alignment Sequence ====
Line 64: Line 62:
 There is some controversy on whether moving the TelWFS boxes corrupts the reconstructor. During engineering time we should try keeping the boxes fixed at their reference positions when the last reconstructor was made using the CalSource. For these tests, do not move the boxes to center on the red beacon at stow, also do not use Zero Centroids to change the relative positions of the boxes. This might mean that beacon/star will be offset in the ACQ hole. <font 11pt/inherit;;inherit;;inherit>It might be better to use the boxes as the absolute reference rather than the Acq hole.</font> There is some controversy on whether moving the TelWFS boxes corrupts the reconstructor. During engineering time we should try keeping the boxes fixed at their reference positions when the last reconstructor was made using the CalSource. For these tests, do not move the boxes to center on the red beacon at stow, also do not use Zero Centroids to change the relative positions of the boxes. This might mean that beacon/star will be offset in the ACQ hole. <font 11pt/inherit;;inherit;;inherit>It might be better to use the boxes as the absolute reference rather than the Acq hole.</font>
  
-<font 11pt/inherit;;inherit;;inherit>In February, Norm found that some telescopes performed OK with not moving the boxes and other telescopes could not lock stars without adjusting the boxes. If the WFS boxes need to be moved, then it would be a good idea to create a new on-sky reconstructor and flat using a bright star.</font> The gain should be high enough to give good SNR (without saturating) on the TelWFS when recording on-sky reconstructors.+<font 11pt/inherit;;inherit;;inherit>In February, Norm found that some telescopes performed OK with not moving the boxes and other telescopes could not lock stars without adjusting the boxes. If the WFS boxes need to be moved, then it would be a good idea to create a new on-sky reconstructor and flat using a bright star.</font>The gain should be high enough to give good SNR (without saturating) on the TelWFS when recording on-sky reconstructors.
  
 **Action Item:**  Determine best gain settings for creating on sky reconstructors. Give guidance so operators can determine whether WFS counts are approaching saturation. **Action Item:**  Determine best gain settings for creating on sky reconstructors. Give guidance so operators can determine whether WFS counts are approaching saturation.
Line 70: Line 68:
 **<font 11pt/inherit;;inherit;;inherit>Action Item:</font>**<font 11pt/inherit;;inherit;;inherit>Figure out the best way to align star to the reference WFS boxes while simultaneously keeping the star centered in ACQ hole (see discussion/diagram at the end of this page).</font> **<font 11pt/inherit;;inherit;;inherit>Action Item:</font>**<font 11pt/inherit;;inherit;;inherit>Figure out the best way to align star to the reference WFS boxes while simultaneously keeping the star centered in ACQ hole (see discussion/diagram at the end of this page).</font>
  
-<font inherit/inherit;;inherit;;transparent>If this problem gets too big on some scopes, we could try to move the TWFS collimator in XY, while maintaining the star centered in Ref Boxes with Tel AO in closed loop (not tested yet). I know Theo have some concerns about risking a complete misalignment, but I hope someone could try when it is safe.</font>+<font inherit/inherit;;#2980b9;;transparent>If this problem gets too big on some scopes, we could try to move the TWFS collimator in XY, while maintaining the star centered in Ref Boxes with Tel AO in closed loop (not tested yet). I know Theo have some concerns about risking a complete misalignment, but I hope someone could try when it is safe.</font>
  
-<font inherit/inherit;;inherit;;transparent>Another way to deal with it is what operators usually do:</font>+<font inherit/inherit;;#2980b9;;transparent>Another way to deal with it is what operators usually do:</font>
  
-<font inherit/inherit;;inherit;;transparent>Moving the boxes allows to get the star back in the hole, but destroys the reconstructor (for a non well-understood reason, probably DM not being in pupil plane...). Maybe we could try moving the boxes and then do an on-sky reconstructor?</font>+<font inherit/inherit;;#2980b9;;transparent>Moving the boxes allows to get the star back in the hole, but destroys the reconstructor (for a non well-understood reason, probably DM not being in pupil plane). Maybe we could try moving the boxes and then do an on-sky reconstructor?</font> 
 + 
 +<font inherit/inherit;;#cc0000;;inherit>Moving the boxes does not always break the reconstructor. Sometimes it does help. It is very similar to moving the wfs. \\ 
 +Any optic moved behind the acq fold is just trying to compensate for something wrong before the fold which is not the best correction.</font>
  
 **Proposed Changes to the Alignment Sequence**  - rough ideas - comment in different color to provide feedback or propose different steps. **Proposed Changes to the Alignment Sequence**  - rough ideas - comment in different color to provide feedback or propose different steps.
Line 80: Line 81:
   * Send M7 to default.   * Send M7 to default.
   * Align red beacon to the reference TelWFS boxes (NOT the offset boxes) using beacon flat.   * Align red beacon to the reference TelWFS boxes (NOT the offset boxes) using beacon flat.
-  * Align blue beacon to lab WFS using DICHROIC. <font inherit/inherit;;inherit;;transparent>Julien would recommend M2 corner cube and laser from lab.</font>+  * Align blue beacon to lab WFS using DICHROIC. <font inherit/inherit;;#2980b9;;transparent>(Julien would recommend M2 corner cube and laser from lab.)</font>
   * Lock star on TT and TelAO DM.   * Lock star on TT and TelAO DM.
   * Move beacon flat to center star on STST or SPICA FTT.   * Move beacon flat to center star on STST or SPICA FTT.
Line 87: Line 88:
   * If the next star is too faint for STST [or close on sky?], then keep M7 fixed at current position and use current method of aligning blue beacon by moving M7 (instead of dichroic).   * If the next star is too faint for STST [or close on sky?], then keep M7 fixed at current position and use current method of aligning blue beacon by moving M7 (instead of dichroic).
  
-<font inherit/inherit;;inherit;;transparent>Remark: it is very difficult to evaluate AO performance without actually watching a “live” image (even if WFS give us the aberrations)</font>+<font inherit/inherit;;#2980b9;;transparent>Remark: it is very difficult to evaluate AO performance without actually watching a “live” image (even if WFS give us the aberrations)</font>
  
-<font inherit/inherit;;inherit;;transparent>Using Spica camera is better than STST because it has short exposures. Would it be possible to use Vis Dichro on IR programs? I know it reduces the flux sent to Tel WFS, but maybe some programs are on bright enough objects? IR flux is the same with VIS and IR dichro.</font>  \\  \\ <font inherit/inherit;;#cc0000;;inherit>Moving the boxes does not always break the reconstructor. Sometimes it does help. It is very similar to moving the wfs. \\ +<font inherit/inherit;;#2980b9;;transparent>Using Spica camera is better than STST because it has short exposures. Would it be possible to use Vis Dichro on IR programs? I know it reduces the flux sent to Tel WFS, but maybe some programs are on bright enough objects? IR flux is the same with VIS and IR dichro.</font> \\  \\ <font inherit/inherit;;#8e44ad;;inherit>Is the dichroic alignment coming back for each slew? It is not responsible for coude misalignments so we don’t do it now. What is the reason to bring it back?</font>
-Any optic moved behind the acq fold is just trying to compensate for something wrong before the fold which is not the best correction.</font> \\  \\ <font inherit/inherit;;#8e44ad;;inherit>Is the dichroic alignment coming back for each slew?  It is not responsible for coude misalignments so we don’t do it now. What is the reason to bring it back?</font>+
  
 The coordinated Beacon/M7 movements (using STST button on obsgtk) will speed up compensating for big shifts after sending M7 to default. The coordinated Beacon/M7 movements (using STST button on obsgtk) will speed up compensating for big shifts after sending M7 to default.
Line 123: Line 123:
  
 <font inherit/inherit;;#cc0000;;inherit>The lower image is on axis but the pupil is shifted. The beam coming in is on axis but the pupil is shifted.</font> <font inherit/inherit;;#cc0000;;inherit>The lower image is on axis but the pupil is shifted. The beam coming in is on axis but the pupil is shifted.</font>
 +
 +<font inherit/inherit;;#cc0000;;inherit>——-</font>
 +
 +<font inherit/inherit;;#cc0000;;inherit>I see your point that if acqhole and everything to the right is aligned then positioning the star in the center of the acqhole should give #3 or #1 in the diagram. but sometimes we get #2 still.</font>
 +
 +<font inherit/inherit;;#cc0000;;inherit>if thats the case, then should we not also see it with the beacon? we slew to the next star and align beacon to boxes. we should see the same error as we will see with the star?</font>
 +
 +<font inherit/inherit;;#cc0000;;inherit>many of these errors may cause a vignetting at the acq hole also.</font>
 +
 +<font inherit/inherit;;#2980b9;;inherit>Yes, if star shows #2 (at edge of boxes and hole), beacon should behave same way.</font>
 +
 +<font inherit/inherit;;#2980b9;;inherit>The purpose of my drawings was to decompose what can happen to the incoming beam (either star or beacon) in terms of pure shift (no angle) or pure tilt around the center of acq hole. Any real beam will have a combination of those two effects.</font>
 +
 +<font inherit/inherit;;#2980b9;;inherit>It shows that there is no way to explain a correct centering in boxes and not in acq hole by a problem with the incoming beam. In this case, Acq hole/Collimator/µL+Detector have moved one to another.</font>
 +
 +__**Engineering Update - UT 2024Apr03**__
 +
 +We experimented a bit with the AO alignment sequence. Specifically, on the slew to a new star:
 +
 +  * Send M7 to default.
 +  * Align the red beacon to telWFS using the beacon flat.
 +  * Align the blue beacon to labWFS using the dichroic.
 +  * Use STST button to center star on STST (coordinated beacon flat/M7 movements).
 +
 +The biggest issue (and the reason why we replaced the third step above with moving M7 instead) is that on large slews (> 90 deg), the blue beacon moves off labAO. To recover, we needed to turn on the laser and move the dichroic to center the laser in the ACQ hole. After the course adjustment, we could then see the blue beacon on labAO again. If we end up using this sequence on sky, perhaps we can calculate the expected motion of the dichroic and move it automatically during the slew. The main motivation for the change is that since the dichroic is causing the misalignment to the lab, it is probably the more correct optic to move vs. M7.
 +
 +We tested this with E1, and we were able to keep telAO locked without needing to move the WFS boxes (the star was maybe just slightly on the edge of the ACQ hole when locking the AO loops). DM current was ~ 0.8 A. However, E1 might be one of the scopes where the operators don't ordinarily have to move the WFS boxes much. We can try with additional scopes on future engineering nights and with more diagnostic tools to gauge AO performace (by eye, the star looked good on STST with a bright circular core).
  
  
chara/discussion_of_alignment_procedures.1711388810.txt.gz · Last modified: 2024/03/25 13:46 by gail_stargazer