We went near the MC2 area and opened the lid to inspect the GigE and analog video monitors for MC2. Looked like whatever image is coming through the viewport is split into the GigE (for beam tracking) and the analog monitor. We hooked the monitor found on the floor nearby and tweaked the analog video camera around to get a feel for how the "ghost" image of the transmission moves around. It looks like in order to try and remove this "extra spots" we would need to tweak the beam tracking BS. We will consult the beam tracking authorities and return to this.
[Kruthi, Yehonathan, Gautam]
Today evening, Yehonathan and I aligned the MC2 cameras. As of now there are 2 GigEs in the MC2 enclosure. For the temporary GigE (which is the analog camera's place), we are using an ethernet cable connection from the Netgear switch in 1x6. The MC2 was misaligned and the autolocker wasn't able to lock the mode cleaner. So, Gautam disabled the autolocker and manually changed the settings; the autolocker was able to take over eventually.
Kiwamu, Koji, Valera
We centered the beam on MC2 in pitch by moving the MC1,2,3 in the following combination [-9,+3,-7]. This actuation vector mostly moves the spot on MC2 vertically. The attached plot shows the dither before and after the centering. We monitored the demodulated signals and saw the reduction of the MC2 pit response from -1.0 to -0.22 which corresponds to the beam spot position change from 9 to 2 mm. Thus all the spots on MC mirrors are within 2 mm of the center. We estimate based on the distance between the MC1-MC3 of 20 cm, the distance from the center between MC1 and MC3 to the end of the Faraday isolator of 80 cm, and the aperture of the FI of 12 mm, the maximum angle out of MC of 3/200 rad. Which implies the maximum differential spot motion of 3 mm not to be limited by the FI aperture.
Thinks to do before the NEXT realignment:
B, tie 4 ancher bolts on table legs to the floor
C, tie 4 dog clamps between table and chamber
D, check the locked position of the 4 x 4 positioning screws
E, check bellow protecting 4 tubes are not shorting
A, here is the concrete slab cut
It reminds me to check the IFO vacuum envelope dog clamps on the chambers to floor with torque wrench.
I locked the PMC and MC resonated in TM00 right on. Than I started checking anchoring screws with the torque wrench.
B, 3/8 foor bolts were tight, They were set to 50 ft/lbs
C, dog clamp bolts were tight at 80 ft/lbs
D, horizontal position locks were lose. They were locked by finger.
E, below covers were reset not to short
The MC is locking in TM01 mode now
we measured the RIN of the MC2 transmission using the PDA255 I had put on the MC2 trans table sometime ago for ringdowns. Attached are (i) spectra for the RIN, (ii) spectra for the classical rad. pressure noise assuming 500W circulating power and (iii) a tarball of data and code used to generate these plots.
We took a full span measurement (to make sure there aren't any funky high-freq features) and a measurement from DC-800 Hz (where we are looking for excess noise). The DC level of light on the photodiode was 2.76V (measured using o'scope)
I'll add this to the noise budget later. But the measured RIN seems consistent with a 2013 measurement at 100Hz (though the 2013 measurement is using DTT and so doesn't have high frequency information).
Following up from morning's work, I balanced the coils at DC as well. Attachment 1 is screenshot of striptool in which blue and red traces show ASCYAW and ASCPIT outputs when C1:SUS-MC2_LSC_OFFSET was switched by 500 counts. We see very slight disturbance but no real DC offset shown on PIT and YAW due to position step. This data was taken while nominal F2A filter calculated to balance coils at DC was uploaded
I have uploaded the filters on filter banks 7-10 where FM7 is the nominal filter with Q close to 1 and 8-10 are filters with Q 3, 7 and 10 respectively. The transfer function of these filters can be seen in Attachment 2. Note, that the high frequency gain drops a lot when higher Q filters are used.
These filters are designed such that the total DC gain after the application of coil outputs gains for high frequency balancing (as done in morning 16054) balances the coils at DC.
Since I had access to the complete output matrix that balances the coils to less than 1% cross coupling at high frequencies from 16009, I also did a quick test of DC coil balancing with this kind of high frequency balancing. In this case, I uploaded another set of filters which were made at Q close to 1 and gain such that effective DC gain matrix becomes what I got by balancing in the above case. This set of filter also worked as good as the above filters. This completes the proof that we can also use complete matrix for high frequency coil balancing which can be calculated by a script in 20min and works with DC coil balancing as well. In my opinion, this method is more clear and much faster than toggling values in coil output gains where we have only 4 values to optimize 6 cross-coupling parameters. But don't worry, I'm not wasting time on this and will abandon this effort for now, to be taken up in future.
Corrected the calculation of filters in case of Q different than . There was a bug in the code which I overlooked. I'll correct the filter bank modules tomorrow.
Edit Wed Apr 21 11:06:42 2021 :
I have uploaded the corrected foton filters. Please see attachment 3 for the transfer functions calculated by foton. They match the filters we intended to upload. Only after uploading and closing the foton filter, I realized that the X=7 filter plot (bottom left in attachment 3) does not have dB units on y-axis. It is plotted in linear y-scale (this plot in foton is for phase by default to I guess I forgot to change the scaling when repurposing it for my plot).
We did some quick DC balancing of the MC2 coil drivers to reduce the l2a coupling. We updated the gains in the C1:SUS-MC2_UL/UR/LR/LLCOIL to be 1, -0.99, 0.937,-0.933, respectively. The previous values were 1, -1, 1, -1.
The procedures are the following:
Drive UL+LR and change the gain of LR to zero pitch.
Drive UR+LL and change the gain of LL to zero pitch.
Lastly, drive all 4 coils and change UR & LR together to zero yaw.
We used C1:SUS-MC2_LOCKIN1_OSC to create the excitations at 33 Hz w/ 30,000 cts. The angular error signals were derived from IMC WFSs.
While this time we did things by hand, in the future it should be automated as the procedure is sufficiently straightforward.
My old scheme was flawed as I used pitch as the readback. The pitch signal could not distinguish the cross-coupling due to coil imbalance and that due to the natural suspension L2P. A new scheme based on yaw alone has been developed and will be integrated into ifo_test. For now we revert the C1:SUS-MC2_UL/UR/LR/LLCOIL gains back to 1, -1, 1, -1.
I was looking at some signals from last night, see Attachment #1.
Attachment #2 shows some ASC metrics. My conclusion here is that running the PRCL and MICH dither alignment servos (former demodulating REFLDC and latter demodulating ASDC to get an error signal) that running the dither alignment servo and hand tuning the arm ASC loop offsets improves the mode matching to the IFO, because:
The REFLDC behavior needs a bit more interpretation I think, because if the IFO is overcoupled (as I claim it is), then better alignment would at some point actually result in REFLDC increasing.
All the DC signals recorded by the fast system come from the backplane P2 connector of the PD interface boards. According to the schematic, these signals have a voltage gain of 2. The LSC photodiodes themselves have a nominal DC gain of 50 ohms. So, the conversion from power to digital counts is: 0.8 A/W * 50 V/A * 2 * 3276.8 cts/V * whtGain. Inverting, I get 3.8 uW/ct for a whitening gain of 1. This is power measured at the photodiode - optical losses upstream of the photodiode will have to be accounted for separately.
Assuming a modulation depth of 0.2, the 55 MHz sideband power should be ~20 mW. The Schnupp asymmetry is supposed to give us O(1) transmission of this field to the AS port. Then, the SRM will attenuate the field by a factor of 10, so we expect ~2 mW at the AS port. Let's assume 80 % throughput of this field to the AP table, and then there is a 50/50 beamsplitter dividing the light between the AS55 and AS110 photodiodes. So, we expect there to be ~700 uW of power in the TEM00 mode 55 MHz sideband field. This corresponds to 1600 cts according to the above calibration (the ASDC whitening gain is set to 18 dB). The fact that much smaller numbers were seen for ASDC indicates that (i) the schnupp asymmetry is not so perfectly tuned and the actual transmission of the sideband field to the dark port is smaller, or (ii) one or more optical splitting fractions assumed above is wrong. If the former is true, we can still probably infer the contrast defect if we can somehow get an accurate measurement of the sideband transmission to the dark port.
> Can't we offload this DC signal to the laser crystal temperature servo?
No. PSL already follows the MC length. So this offset is coming from the difference between the MC length and the CARM length.
What you can do is to offload the MC length to the CARM DC if this helps.
MC2 damping restored, MZ locked and the arms are flashing now.
I turned on some filters and gain in the SUS-MC2_MCL filter bank tonight so as suppress the seismic noise influence on MC_F. This may help the MC stay in lock in the daytime.
Koji updated the mcdown and mcup scripts to turn the MCL path on and off and to engage the Boost filters at the right time.
The attached PNG shows the MCL screen with the filters all ON. In this state the crossover frequency is ~45 Hz. MC_F at low frequencies is reduced by more than 10x.
I also think that this may help the X-Arm lock. The number of fringes per second should be 2-3x less.
Earthquake mag 4.0 at Lennox, Ca trips MC2 watchdogs http://quake.usgs.gov/recenteqs/Quakes/ci10411545.html
See 40m accelerometers as they see it.
The EQ did not change the input beam pointing. All back to normal, except MC2 wachdogs tripped again.
Round 3 for the day of MC2 watchdogs tripping.
The analog de-whitening filters for MC2 are different from those on the other optics (i.e. ITMs and ETMs). They have one complex pole pair @7Hz, Q~sqrt(2), one complex zero pair @50Hz, Q~sqrt(2), one real pole at 2.5kHz, and one real zero @250Hz (with a DC gain of 10dB).
I took the opportunity last night to measure all 4 de-whitening channel TFs. Measurements and overlaid LISO fits are seen in Attachment #1.
The motivation behind this investigation was that last week, I was unable to lock the IMC to one of the arms. In the past, this has been done simply by routing the control signal of the appropriate arm filter bank (e.g. C1:LSC-YARM_OUT) to MC2 instead of ETMY via the LSC output matrix (if the matrix element to ETMY is 1, the matrix element to MC2 is -1).
Looking at the coil output filter banks on the MC2 suspension MEDM screen (see Attachment #2), the positions of filters in the filter banks is different from that on the other optics. In general, the BIO outputs of the DAC are wired such that disengaging FM9 on the MEDM screen engages the analog de-whitening path. FM10 then has the inverse of the de-whitening filter, such that the overall TF from DAC to optic is unity. But on MC2, these filters occupy FM7 and FM8, and FM9 was originally a 28Hz Elliptic Low-pass filter.
So presumably, I was unable to lock the IMC to an arm because for either configuration of FM9 (ON or OFF), the signal to the optic was being aggressively low-passed. To test this hypothesis, I simply copied the 28Hz elliptic to FM6, put a gain of 1 on FM9, left it engaged (so that the analog path TF is just flat with gain x3), and tried locking the IMC to the arm again - I was successful. See Attachment #3 for comparison of the control signal spectra of the X-arm control signal, with the IMC locked to the Y-arm cavity.
In this test, I also confirmed that toggling FM9 in the coil output filter banks actually switches the analog path on the de-whitening boards.
Since I now have the measurements for individual channels, I am going to re-configure the filter arrangement on MC2 to mirror that on the other optics.
Unrelated to this work: the de-whitening boards used for MC1 and MC3 are D000316, as opposed to D000183 used for all other SOS optics. From the D000316 schematic, it looks like the signals from the AI board are routed to this board via the backplane. I will try squishing this backplane connector in the hope it helps with the glitching MC1 suspension.
GV Aug 13 11:45pm - I've made a DCC page for the MC2 dewhitening board. For now, it has the data from this measurement, but if/when we modify the filter shape, we can keep track of it on this page (for MC2 - for the other suspensions, there are other pages).
I briefly checked the MC2 analog dewhitening filters.
It turned out that the switching of the dewhitening filters from epics worked correctly except for the UR path.
I couldn't get a healthy transfer function for the UR path probably because the UR monitor at the front panel on either the AI filter or the dewhitening filter maybe broken.
Need a check again.
Tomorrow I'll take a look at the binary outputs and see why the analog filters aren't actually changing.
We need to re-look at this new MC autolocker stuff, and the new MCL filters.
MC2 is getting kicked up (sometimes the watchdog trips, sometimes it just comes close) pretty regularly. I'm not sure yet what is causing this, but we need to deal with it since it's pretty obnoxious.
Mirko and Den are measuring MC_F, which they will report about later, but I noticed that MC2 is totally crazy right now. It shouldn't matter that they are doing things (like unplugging the feedback to the PSL's PZT), because we actuate on the laser, not on the MC. I disabled the MC autolocker before they started working.
Anyhow, somehow MC2 got kicked up (whatever, that happens), but it won't re-damp. I think it's the WFS. The yaw output from the WFS is truely crazy.
I have disabled the WFS output / ASC input on the MC SUS screens, and MC2 was then able to damp. My disabling only the MC2 WFS input at first kicked up MC1 and 3, so I disabled all of the WFS stuff, and all 3 MC mirrors are again happy.
SURESH: FIX ME! (signed, The WFS)
Turning off the WFS servo loops usually should be done using the 'mcwfsoff' script. The script takes care of switching off the integrators and Clears the History.
'mcdown' and 'mcup' scripts run the 'mcwfsoff' and 'mcwfson' scripts so when the MC unlocks the WFS servos are shutdown and restarted properly. However if the MC autolocker script is suspended by pressing the Enable/Disable switch in the LOCKMC screen and then the MC unlocks, it results in the WFS servo integrators accumulating large values. If these values are passed through the ASC filter banks the optic will get a pretty huge kick.
I have added some indicators which will let us know if the WFS Servo Filter outputs are larger than +/-1000. When engaging the WFS loops the user has to take care to Clear History in the servo filter banks if these indicators are steadily Red. before engaging the WFS Servo loops ensure that the servo filter outputs are zeroes.
Koji and I discussed whether it would be useful to run the 'mcwfsoff' script when the Disable button is pressed in the autolocker. His recommendation is that we should keep the autolocker script simple and that user has to be cautious when switching on the WFS servos and when directing the ASC outputs to the suspensions.
MC2 is having a bad day, and I'm not yet sure why. It's to do with the damping though. When the damping is off, after a little while it will settle to ~30mV or so on the Watchdog screen. When I enable all of the outputs and then turn on the damping, the optic gets kicked up. It's like there's a minus sign error somewhere, maybe in a bad burtrestore? This has been going on since I did my morning bootfest.
It's started to sit down and play nicely now. Is someone doing magic remotely that is fixing things that I hadn't figured out yet?
The MCL path of MC2 was in a strange state as the filters were activated as if it is in lock even though we had no lock. So I manually ran "mcdown". This reset the filters of the MCL path.
I'm running the MC2 loss map scripts on pianosa now. The camera server is throwing an error and is not grabbing snapshots :(
Update: I finished taking the readings for MC2 loss map. I couldn't get the snapshots with the script, so I manually took some 4-5 pictures.
Can you please be more specific about what the error is? Is this the usual instability with the camera server code? Or was it something new?
The camera server is throwing an error and is not grabbing snapshots :(
The camera server keeps throwing the error: failed to grab frames. Milind suggested that it might a problem with the ethernet cable, so I even unplugged it and connected it again; it still had the same issue. One more thing I noticed was, it does take snapshots sometimes with the terminal command caput C1:CAM-ETMX_SNAP 1, but produces a segmentation fault when ezca.Ezca().write(C1:CAM-ETMX_SNAP, 1) ezca.Ezca().write(CAM-ETMX_SNAP, 1) is used via ipython. When the terminal command also fails to take snapshots, I noticed that the SNAP button on the GigE medm screen remains on and doesn't switch back to OFF like it is supposed to.
I think ezca.Ezca().write() takes the string "CAM-ETMX_SNAP" as an argument and not C1:CAM-ETMX_SNAP. See this, line 47. Are you sure this is not the problem?
The camera server keeps throwing the error: failed to grab frames. Milind suggested that it might a problem with the ethernet cable, so I even unplugged it and connected it again; it still had the same issue. One more thing I noticed was, it does take snapshots sometimes with the terminal command caput C1:CAM-ETMX_SNAP 1, but produces a segmentation fault when ezca.Ezca().write(C1:CAM-ETMX_SNAP, 1) is used via ipython. When the terminal command also fails to take snapshots, I noticed that the SNAP button on the GigE medm screen remains on and doesn't switch back to OFF like it is supposed to.
In my script I have used "CAM-ETMX_SNAP" only; while entering it in the elog I made a mistake, my bad!
I aligned MC2 suspension by 0.01 in pit and yaw to align the MC better to the PSL beam. Then I turned the WFS back on. The beams are not centered on the WFS heads.
Nic and Gabriele ought to send their SURF some example code (in April) for how to start redesigning the WFS telescopes so that we can order some optics in early June.
I've also turned on the MC2 TRANS path to gather some data over the weekend on how well or bad it works. Please turn it off on Monday.
MC2_TRANS path in WFS servo turned OFF.
Summary: I calibrated MC2 pitch and yaw offsets to spot position in mm. Here's what I did:
Results: In the pitch/yaw vs pitch_offset/yaw_offset graph attached,
Around 6PM on the 27th, I found that the C1:IOO-MC_RFPD_DCMON had risen to about 2.5V. I checked the trend of MC2 sensors and found that between 2PM and 6PM, MC2 had drifted in a strange way. And also that the alignment had grown worse over several days. I also noticed that the spot on the MC2F camera had shifted to the left.
I attempted to correct the alignment (decrease the C1:IOO-MC_RFPD_DCMON to ~0.5V ) by just moving the MC2 and succeeded!! So it is quite likely that most of the slow MC drift is arising due to MC2 table drift.
I decided to try and close the MC2_TRANS QPD to MC2 loops separately to see if MC alignment becomes stable But several screens needed to be fixed before we could try anything. So I fixed C1IOO_WFS_MASTER, C1IOO_WFS_INMATRIX and ...OUTMATRIX screens. Deleted the older ones to avoid confusion.
In this process I noticed that the directory of $screens$/c1mcs/master contains copies of older C1SUS_MC1 , 2. and 3 screens which look very similar to the new autogenerated screens. Some of the links in the WFS screens were pointing to the old screens. I have redirected the links and I will delete these in a couple of days, if no one objects.
Olympus SP570 UZ - without IR blocker, set up as Atm.3 Camera distance to MC face ~85 cm, IOO-MC_TRANS_SUM 16,300 counts, Lexan cover on not coated viewport.
Image mode: RAW + JPG, M-costum, manual focus, Lens: Olympus 4.6 - 92 mm, f2.8 - 4.5, Apeture: F2.8 - 8, Image pick up device: 1/2.33" CCD (primary color filter)
Atm.1, 212k.jpg of raw 15 MB, exp 0.025s, apeture 2.97, f 4.6, iso 64,
Atm.2, Copied through my Cannon S100 ( 3.3 MB.jpg of raw from UFraw photo shop )I will look up the original raw file for details.
I found the IMC was largely misaligned and was not locking. The WFS feedback signals were saturated and MC2 was still largely misaligned in yaw after resetting the saturation.
It seemed that the MC WFS started to put the large offset at 6:30AM~7:00AM (local).
MC2 was aligned and the lock was recovered then the MC WFS seems working for ~10min now.
This afternoon I felt like saying hello to the input mode cleaner. So I decided to center the spot on MC2.
MC has 6 alignment dofs. 4 of them are controlled by the WFSs. Remaining 2 appears at the spot position on MC2.
If the spot on the MC2 is fixed, the beam hits the same places of three mirrors. If the mirrors are completely fixed
in terms of the incident beam, I suppose the reflected beam is also fixed. This makes the WFS spots more stable.
Then I feel better.
Today's goal is to confirm the behaviour of MC such as dithering amplitude, response of the couplings to the alignment,
behavior of the WFS, and the transmitted power.
1) Turned off MC auto locker. Turned off MC WFS as the WFS servos disturbs my work.
2) Dithered MC2 in Pitch and Yaw using DTT. There looks elliptic filter (fc=28Hz) in the ASC path, I used 20Hz-ish excitations.
- C1:SUS-MC2_ASCPIT_EXC 100cnt_pk@19Hz
- C1:SUS-MC2_ASCYAW_EXC 100cnt_pk@22Hz
3) Looked at C1:SUS-MC2_MCL_OUT to find the peaks at 19Hz and 22Hz. These are caused by alignment-length coupling.
If they are minimized I assume the spot is somehow centered on MC2.
Note: This may not be the true center. The suspension response should be investigated. But this is a certain reporoducible spot position.
Note: I should use ezcademod in order to obtain the phase information of the dither result.
4) Move MC2 Pitch for certain amount (0.01cnt) by the alignment slider. Align MC1/MC3 to have max transmittion.
5) If the Pitch peak got lower, the direction of 4) was right. Go further.
5') If the Pitch peak got higher, the direction of 4) was wrong. Go the other direction.
6) Repeat 4)&5) for Yaw.
After the adjustment, the couplings got lower about 10 times. (Sorry! The explanation is not so scientific.)
Next time I (or someone) should make a script to do it and evaluate the coupling by the estimated distance of the spot from the center of the mirror (the center of the rotation).
I have not seen visible change in the spectrum of C1:SUS-MC2_MLC_OUT.
By the spot centering, I could expected to see some improvement of the transmittion. But in reality, there was no change.
In fact, the transmittion power was getting down for those weeks.
I checked WFS and MCT paths. Eventually I found that a couple of possible problems:
1) MCT Total output varies more than 10% depending on the spot position on MCT QPD.
2) Just before the QPD, there is a ND1 filter.
This may suggest that:
a) Four elemtns of the MCT QPD have different responses.
b) The ND filter is causing a fringe.
So far I aligned the ND filter to face the beam. The reflection from the filter was blocked at a farther place.
Still the output varies on the spot position. Probably I have to look at the QPD someday.
So far the spot on the QPD was defined so that I get the maximum output from the QPD. This is about 8.8.
As I touched the steering mirrors, the X and Y outputs of the QPD are no longer any reference.
For now, I closed the PSL table. The full IFO was aligned.
I made good on my threat from yesterday to convert the MC2 suspension controller to the library part. Whatever changes were in MC2 were thrown out, although they are archived in the SVN. Again, this kind of undocumented breaking is forbidden.
Change was committed to SVN, and c1mcs was recompiled/installed/restarted.
While Kevin is working on the MC2 electronics chain - we disconnected the output to the optic (DB15 connector on coil driver board). I decided to look at the 'free' freeswinging MC2 OSEM shadow sensor data. Attachment #1 suggests that the suspension eigenmodes are showing up in the shadow sensors, but the 0.8Hz peak seems rather small, especially compared to the result presented in this elog.
Maybe I'll kick all 3 MC optics tonight and let them ringdown overnight, may not be a bad idea to checkup on the health of the MC suspensions/satellite boxes... [MC suspensions were kicked @1207113574]. PSL shutter will remain closed overnight...
Why is MC2 LR so different from the others???
For whatever reason, the autolocker didn't turn the tickle off for several hours. Seems to work okay now. The linked plot suggests that the coil balancing on MC2 is pretty lousy.
While we were trying to relock the MC after Jenne put back the RF box, we found there was some mysterious motion in MC2. After spending time trying to figure out where this was coming from, the source was found to be at LOCKIN2 of MC2 suspension "The MC TICKLER" that was left enabled. This was turned OFF and MC locked just fine after that.
EDIT JCD: The Tickler should be disabled, if the autolocker is disabled.
Sounds like this was just incidental, since the MC locked fine also with the tickler enabled for weeks.
The tickle is disabled by the down script, but there's no way to correctly handle all possible button pushes. If you want to disable the autolocker for some reason you should run mcdown before trying to lock. This will set up things with the correct settings.
Isn't that backwards? Shouldn't the tickler be enabled by the down script, and disabled by the up script? Either way, the problem was that, after I acquired lock, the tickler was causing the transmitted power to fluctuate by ~20%, and often the MC would lose lock after a minute or so. Also, the WFS definitely couldn't be enabled by hand.
Anyhow, I'll try to keep in mind that this exists, so I'm not stymied by it again.
You're right - down turns it on. Still, the fact that the same tickle recently causes a problem and didn't make 20% power fluctuations until now tells me that its not that the tickle amplitude is too large. Whatever changed recently is the problem.
Last night while noise hunting, Rana found that the MC2 trans beam has been left for an unknown length of time just hitting the side of the black enclosure box. Today I put a brand-spankin'-new razor dump on the MC2 table, to dump the beam.
We noticed last week that the MC2 trans camera has pitch and yaw swapped; I rotated what I thought is the correct camera by 90 degrees clockwise (as viewed from above, like in the attachment), but I now have doubts. It's the camera on the right in the attachment.
The left one is analog and 90deg rotated.
See also: This issue tracker
Just felt a big "kerplunk" type ground-shaking, presumably from all the antics next door. MC2's watchdog tripped as a result. The watchdog has been reenabled.
People complained about the MC instability: If we aligned the MC, it locked nicely for a while.
Then suddenly you find that it got totally misaligned with the order of 0.2 with the alignment slider.
This misalignment usually happens for MC2, but it happend on MC3 once.
Surprisingly to me, this instability happened even without MCL and WFS, not only once but at least three times.
This suggests that the suspensions are the cause of the trouble.
I played with the MC2 suspension for a while in the afternoon. It seems that it has a hysteresis (or say, bistablity).
And the nominal alignment of MC2 seems close to the point where the transition happens. (Dunno why)
I further played with MC2 and found that a step of POS actuation by +/-10000 induces this transition go and back.
When the POS kick is in the negative direction (-10000), the MC2 seems to return to the preferrable
position. Therefore, I applied DC position force of -5000 to pull the mirror a bit from the nominal position.
I let the MC locked for ~4hours without MCL and WFS, it kept good alignment and the lock was stable
except for unlocks because of the activties by Den and Ayaka.
All of them has been done without previous monitor data as the tools were available.
The MC2 situation is not conclusive but we should check how we can prevent the bistable transition
by restricting MCL/WFS.