40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 131 of 339 Not logged in
ID Date Author Type Category Subject
13066   Thu Jun 15 18:56:31 2017 jigyasaUpdateComputer Scripts / ProgramsMC2 Pitch-Yaw offset

A python script to randomly vary the MC2 pitch and yaw offset and correspondingly record the value of MC transmission has been started on Donatella in the control room and should run for a couple of hours overnight.

The script is named MC_TRANS_1.py and is located in my user directory at /users/jigyasa

Apologies for any inconvenience.
Data analysis will follow.

13073   Mon Jun 19 18:41:12 2017 jigyasaUpdateComputer Scripts / ProgramsMC2 Pitch-Yaw offset

The previous run of the script had produced some dubious results!

The script has been modified and now scans the transmission sum for a longer duration to provide a better estimate on the average transmission. The pitch and yaw offsets have been set to the values that were randomly generated in the previous run as this would enable comparison with the current data.

I am starting it on Donatella and it should run for a couple of hours.

Apologies for the inconvenience.

 Quote: A python script to randomly vary the MC2 pitch and yaw offset and correspondingly record the value of MC transmission has been started on Donatella in the control room and should run for a couple of hours overnight. The script is named MC_TRANS_1.py and is located in my user directory at /users/jigyasa
13076   Tue Jun 20 17:44:12 2017 jigyasaUpdateComputer Scripts / ProgramsMC2 Pitch-Yaw offset

The script didn't run properly last night, due to an oversight of variable names! It's been started again and has been running for half an hour now.

Quote:

I am starting it on Donatella and it should run for a couple of hours.

Apologies for the inconvenience.

 Quote: A python script to randomly vary the MC2 pitch and yaw offset and correspondingly record the value of MC transmission has been started on Donatella in the control room and should run for a couple of hours overnight. The script is named MC_TRANS_1.py and is located in my user directory at /users/jigyasa

13084   Tue Jun 27 18:47:49 2017 jigyasaUpdateComputer Scripts / ProgramsMC2 Pitch-Yaw offset

The values generated from the script were analyzed and a 3D scatter plot in addition to a 2D map were plotted.

Yesterday, Rana pointed me to another method of collecting and analyzing the data. So I worked on the code today and have left a script (MC2rerun.py) running on Ottavia which should run overnight.

 Quote: The script didn't run properly last night, due to an oversight of variable names! It's been started again and has been running for half an hour now.

13087   Thu Jun 29 10:04:18 2017 jigyasaUpdateComputer Scripts / ProgramsMC2 Pitch-Yaw offset

The script is being executed again, now.

 Quote: I worked on the code today and have left a script (MC2rerun.py) running on Ottavia which should run overnight.

5905   Wed Nov 16 09:21:56 2011 SureshUpdateIOOMC2 Shifted in Pitch, corrected by adjusting the pitch bias

[Steve, Suresh]

Steve went over to the MC2 walkway and stepped over the barrier to pick up some stuff there.  MC2 stack shifted and MC2 pitch as off.  MC unlocked and could not relock till the MC2 pitch bias was readjusted

Without the WFS the MC to PSL alignment is poor, but it is largely due to a shift in the MC and not a shift in the PSL beam.  We know this 'coz the shift in the DC spot positions on WFS (when the MC is unlocked) is not significant nor is the shift on the C1:IOO-QPD.  When WFS loops are engaged the MC optics are turned to optimise the PSL to MC alignment, but the shift is large at the moment.

(Sorry Mirko your measurement could not be completed.  The MC unlocked in the middle)

Please Note:  If you need to access the blocked off area near MC2 stack, do not step over the barrier.  The disturbance is too great and the MC2 stack will shift.  Instead please move the barrier aside and walk as gently as possible near it, taking care not to touch the MC2 Chamber.

5910   Wed Nov 16 10:53:35 2011 SureshUpdateIOOMC2 Shifted in Pitch, corrected by adjusting the pitch bias

 Quote: [Steve, Suresh]     Steve went over to the MC2 walkway and stepped over the barrier to pick up some stuff there.  MC2 stack shifted and MC2 pitch as off.  MC unlocked and could not relock till the MC2 pitch bias was readjusted previous MC2PIT reading: 3.6235           current MC2PIT reading:  3.9565 Without the WFS the MC to PSL alignment is poor, but it is largely due to a shift in the MC and not a shift in the PSL beam.  We know this 'coz the shift in the DC spot positions on WFS (when the MC is unlocked) is not significant nor is the shift on the C1:IOO-QPD.  When WFS loops are engaged the MC optics are turned to optimise the PSL to MC alignment, but the shift is large at the moment. (Sorry Mirko your measurement could not be completed.  The MC unlocked in the middle) Please Note:  If you need to access the blocked off area near MC2 stack, do not step over the barrier.  The disturbance is too great and the MC2 stack will shift.  Instead please move the barrier aside and walk as gently as possible near it, taking care not to touch the MC2 Chamber.

Apparently the MC2 stack had not finished shifting.   The MC unlocked while Steve was working on the PSL table installing the mirror for IOO_QPD and then it could not relock.  So I moved the MC2 once again in Pitch.  The current status of the sliders is here

Yesterday I fixed the yellow buttons on the MC_ALIGN and MCLOCK screens.  They use the new updatesnap script  .  Could we also add a couple of lines to this script so that eveytime we save a snap shot the various values are written(appended) to a text file?  That way we do not need to depend solely on the conlog, which is quite slow.

5913   Wed Nov 16 17:03:19 2011 KojiUpdateIOOMC2 Shifted in Pitch, corrected by adjusting the pitch bias

MC was not locked for more than 5 hours because of the misalignment.

Noticed that MC2 WFS feedback filters had big outputs (particularly in Pitch).
They were reset to zero.

MC2 was aligned and recovered the lock. Once the WFS is engaged, the transmission returned to the uisual value.

9884   Wed Apr 30 21:16:42 2014 ranaUpdateLSCMC2 Strad

I found the YARM LSC feedback going to MC2 and the MC2 violin mode (at 644.69 Hz) rung up. The existing notch was just a second order Twin-T style notch (so not a good idea) and also not turned on, since it was in the FM4 spot of LSC-MC2 and the vio triggers are ganged between all mirrors and don't touch FM4.

I copied the PRM vio bandstop into FM2 of this bank, deleted the old notch, and tuned the bandstop frequencies a little to get the violin peak into one of the zeros of the elliptic bandstop. Attached are the Y-arm / MCF spectrum with the mode rung up as well as the new filter's TF compared with the old notch.

P.S. I installed http://en.wikipedia.org/wiki/Midnight_Commander on pianosa.

Attachment 2: MC_Y_vio.pdf
Attachment 3: MC2_vio.pdf
16066   Wed Apr 21 15:50:01 2021 Anchal, PacoUpdateSUSMC2 Suspension Optimization summary
MC2 Coil Balancing DC and AC Gains
POS PIT YAW COIL_GAIN (AC balancing)

UL

1.038 1 1 1.05
UR 1.009 1 -1 -1.05
LL 0.913 -1 1 -1.030
LR 0.915 -1 -1 0.995

MC2 Diagonalized input matrix
UL UR LR LL SIDE
POS 0.2464 0.2591 0.2676 0.2548 -0.1312
PIT 1.7342 0.7594 -2.494 -1.5192 -0.0905
YAW 1.2672 -2.0309 -0.9625 2.3356 -0.2926
SIDE 0.1243 -0.1512 -0.1691 0.1064 0.9962

MC2 Suspension Gains
Old gain New Gain
SUSPOS 150 150
SUSPIT 10 30
SUSYAW 10 30

16067   Wed Apr 21 18:49:29 2021 ranaUpdateSUSMC2 Suspension Optimization summary

the POS column should be all 1 for the AC balancing. Where did those non-1 numbers come from?

16071   Thu Apr 22 08:50:21 2021 AnchalUpdateSUSMC2 Suspension Optimization summary

Yes, during the AC balancing, POS column was set to all 1. This table shows the final values after all the steps. The first 3 columns are DC balancing results when output matrix was changed. While the last column is for AC balancing. During AC balancing, the output matrix was kept to ideal position as you suggested.

 Quote: the POS column should be all 1 for the AC balancing. Where did those non-1 numbers come from?

5635   Fri Oct 7 22:48:26 2011 SureshUpdateIOOMC2 Trans QPD spot size and incident power decreased

After centering the spot on the MC2, I started to adjust the spot position on MC_TRANS_QPD to center the beam on it.  I noticed that the spot size was about 3 to 4mm dia. because the 200mm lens was too close to the QPD.  I moved it back and decreased the spot size to about 1mm and the sensitivity to spot position increased.  However, Koji noted that the QPD sectors were near saturation, so I put in a ND=0.3 filter to reduce the incident power on the QPD.

At optimal alignment the current QPD_SUM is around 25k to 26k counts (factor of 2 down). Eventually the gain of the QPD ckts have to be reduced to prevent saturation, for the moment this is temporary fix.

The MC_TRANS_SUM trigger for MC autolocker is working fine no further change was required.

13705   Mon Mar 26 21:25:55 2018 ranaSummaryIOOMC2 Trans table has issues

Gautam, Rana

While at the MC2 table, we noticed that it has some optical problems:

1. There is an ND filter mounted to the beam reducing lens. ND filters are illegal, Steve. It causes too much scattering noise. We should instead have a beamsplitter and a dump.
2. One of those bad U100-AC28 mounts is in use. This is one of those ones with plastic clips that Osamu liked, but the plastic gets in the way of the beam. Needs to be removed.
3. Reflections from the QPD and the PDA255 are not dumped. This causes noise. Bad.
4. The QPD transimpedance should be reduced so that it can handle more light. I don't know what it has now, but its probably 10-100 kOhm.

We estimated that the power in the IMC is (1 W)*Finesse/pi = 500 W. The MC2 Transmission spec is < 10 ppm, so the power on the table is probably ~5 mW. Since the PDA255 has a transimpedance of 10 kOhm and a max output power of 10V, it can handle up to ~1 mW. Probably we can get the QPD to handle 4 mW.

Gautam, Steve  3-27

We measured MC2 transmitted power right at the uncoated window ~2.5 mW  The beam was just a little bigger than the meter.

Attachment 1: 20180326_201929.jpg
674   Tue Jul 15 12:23:22 2008 JenneUpdateGeneralMC2 Watchdog tripped
Alberto, Jenne

Mode Cleaner was unlocked. We checked, and found that MC2's watchdog was tripped. It didn't look like anything bad was going on, so we turned the optic back on, and tried to relock the MC. It looks like the Mode Cleaner is now locked, but the lock bit on the LockMC screen is still red. I don't know what's up.
2208   Mon Nov 9 11:11:19 2009 AlbertoConfigurationLSCMC2 Watchdogs tripped

The MC2 watchdogs tripped. I just restored them.

I also had to relock the MZ and then the Mode Cleaner.

2123   Tue Oct 20 02:14:29 2009 robUpdateIOOMC2 alignment bias changed

the mode cleaner was having trouble locking in a 00 mode, needing several tries.  I changed the MC2 coil biases, and it seems better for now.

16163   Wed May 26 11:45:57 2021 Anchal, PacoConfigurationIMCMC2 analog camera

[Anchal, Paco]

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.

14774   Thu Jul 18 22:03:00 2019 KruthiUpdateCamerasMC2 and cameras

[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.

4674   Tue May 10 00:44:52 2011 valeraUpdateIOOMC2 centering

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.

Attachment 1: mc2centering.pdf
5782   Wed Nov 2 10:04:05 2011 steveUpdateSUSMC2 chamber anchoring tightened

 Quote: 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

13706   Mon Mar 26 21:40:26 2018 gautamSummaryIOOMC2 classical radiation pressure noise

[rana, gautam]

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).

Attachment 1: IMC_RIN.pdf
16055   Tue Apr 20 18:19:30 2021 AnchalUpdateSUSMC2 coil balanced at DC

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.

Next up:

• Tomorrow, we'll finish DC balancing for MC1 and MC3 with the method I practiced today. This should not take much time and should be completed before the meeting.
• I'll also, calculate and upload the F2A filters for MC1 and MC3.
• Next, we'll optimize gains in the suspension damping loops by doing step response test (with TRAMP = 0s). We'll look for decaying response (at MC_F, and WFS sensors) with a few oscillations for each step in POS, PIT, and YAW.

Edit Tue Apr 20 21:25:46 2021 :

Corrected the calculation of filters in case of Q different than $\large \sqrt{G_{DC}}$. 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).

Attachment 1: MC2_DC_Coil_Balanced_St.png
Attachment 2: IMC_F2A_Params_MC2.pdf
15224   Tue Feb 25 19:58:06 2020 HangUpdateIOOMC2 coil balancing

[Yehonathan, Hang]

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:

Lock IMC.

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.

15265   Wed Mar 11 16:46:25 2020 HangUpdateIOOMC2 coil balancing

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.

 Quote: [Yehonathan, Hang] 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: Lock IMC. 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.
15468   Fri Jul 10 15:26:28 2020 gautamUpdateLSCMC2 coils need DC balancing?

I was looking at some signals from last night, see Attachment #1.

• It looks like as the DC control signal to the MC2 suspension increases, the MC transmission decreases.
• I confirmed that the IMC REFL level doesn't correspondingly trend up, but didn't include it here for plot compactness, so I think the cavity length isn't being detuned.
• So the problem is suggestive of some L2A coupling, and the MC2 coil actuators need to be balanced better at DC?
• You can see from the IMC WFS control signals that the WFS servo is presumably trying to counteract this L2A action, but doesn't succeed, probably because the servo isn't tuned correctly.
• This is a problem that is distinct from the drifting TT alignment. So it complicates the alignment situation.
• Ideally, if the dither alignment servos could be made to work for the arm cavities when locked in the PRFPMI config, this wouldn't be so much of a problem, as the TTs would just adjust the beam pointing to match the cavity axes of the arms. But since I haven't managed to get that servo working yet...
• But why should MC2 need such a large DC control signal ever?
• In the PRFPMI lock, the CARM servo is supposed to match the laser frequency to the average length of the two arm cavities.
• The MC2 suspension is used as a frequency actuator in order to realize this matching.
• But, as you can see, the digital CARM control signal picks up a significant DC offset the deeper we go into the lock.
• Can't we offload this DC signal to the laser crystal temperature servo? Is there going to be some weird interaction with the existing slow loop? Or is the idea itself flawed?

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:

1. The arm transmission increases.
2. POPDC increases.
3. ASDC decreases.

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.

Attachment 1: MC2_balancing.png
Attachment 2: ASDC.png
15470   Sat Jul 11 18:24:30 2020 KojiUpdateLSCMC2 coils need DC balancing?

> 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.

15474   Mon Jul 13 11:36:08 2020 ranaUpdateLSCMC2 coils need DC balancing?
1. if IMC REFL is not increasing, I don't think its a mis-alignment. Usually, REFL is a more sensitive indicator of alignment than TRANS since its usually near zero. Maybe the MC2 TRANS PD is not centered or doesn't have enough lens action.
2. to reduce the DC load on MC2, you could have a slow releif drive the ETMs and DC and minimize LSC-MCL
996   Fri Sep 26 09:05:47 2008 steveUpdateSUSMC2 damping restored
The MC2 sus damping was restored.
1300   Fri Feb 13 08:38:03 2009 steveUpdateIOOMC2 damping restored
2207   Mon Nov 9 08:43:16 2009 steveUpdateSUSMC2 damping restored

MC2 damping restored,  MZ locked and the arms are flashing now.

7268   Fri Aug 24 09:21:45 2012 SteveUpdateIOOMC2 damping restored

 Quote: 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.

Attachment 1: 10hrsMC2.png
1607   Tue May 19 15:57:07 2009 steveUpdateIOOMC2 damping restored after EQ

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.

Attachment 1: acc.jpg
2033   Thu Oct 1 10:23:00 2009 steveUpdatePSLMC2 damping restored again

The EQ did not change the input beam pointing. All back to normal, except MC2 wachdogs tripped again.

Attachment 1: mc2again.jpg
2034   Thu Oct 1 11:39:47 2009 JenneUpdateSUSMC2 damping restored again

 Quote: 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.

13174   Wed Aug 9 11:33:49 2017 gautamUpdateElectronicsMC2 de-whitening

Summary:

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).

Details:

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).

Attachment 1: MC2deWhites.pdf
Attachment 2: MC2Coils.png
Attachment 3: MC2stab.pdf
4146   Wed Jan 12 22:33:24 2011 kiwamuUpdateCDSMC2 dewhitening are healthy except for UR

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.

 Quote:  #4144 Tomorrow I'll take a look at the binary outputs and see why the analog filters aren't actually changing.

7276   Sun Aug 26 11:53:09 2012 JenneUpdateIOOMC2 getting kicked up regularly

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.

5862   Thu Nov 10 12:28:31 2011 JenneUpdateSUSMC2 is being a little wild...WFS to blame

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)

5877   Fri Nov 11 21:09:30 2011 SureshUpdateSUSMC2 is being a little wild...WFS to blame

 Quote: 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)

The Problem

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.

The Solution

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.

1002   Fri Sep 26 19:18:39 2008 JenneUpdateIOOMC2 is having a bad day
As Steve mentioned earlier in today's elog, MC2 keeps ringing up for no clear reason. It is definitely only MC2 that is ringing up, since it's sensors will read several hundreds of counts, while all the other optics are at regular 2 counts and below on the Watchdog screen.

Preliminary investigation results: Around the time of these "kick up" events, the Ranger seismometer does not see any motion, nor does the set of accelerometers under the MC1 chamber. The set of accelerometers under the MC2 chamber do see activity that is at the same time as these events. These events are not caused just by someone walking around, since Rana went inside and clunked around near MC2 while I watched the sensor levels. MC2's watchdog did not trip.

For further investigation: Why is it that only the MC2 accelerometers are seeing the motion? Similarly, why is MC2 the only optic being kicked? Has anyone done anything lately to the MC2 stack?
2457   Mon Dec 28 12:35:57 2009 JenneUpdateSUSMC2 is having a bad day

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?

2458   Mon Dec 28 12:45:55 2009 KojiUpdateSUSMC2 is having a bad day

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.

 Quote: 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?

14788   Sun Jul 21 02:07:04 2019 KruthiUpdateLoss MeasurementMC2 loss map

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.

14789   Sun Jul 21 12:54:18 2019 gautamUpdateLoss MeasurementMC2 loss map

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?

 Quote: The camera server is throwing an error and is not grabbing snapshots :(
14791   Sun Jul 21 17:17:03 2019 KruthiUpdateLoss MeasurementMC2 loss map

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.

Quote:

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?

 Quote: The camera server is throwing an error and is not grabbing snapshots :(
14792   Sun Jul 21 19:27:25 2019 MilindUpdateLoss MeasurementMC2 loss map

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?

 Quote: 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.
14796   Mon Jul 22 12:57:35 2019 KruthiUpdateLoss MeasurementMC2 loss map

In my script I have used "CAM-ETMX_SNAP" only; while entering it in the elog I made a mistake, my bad!

Quote:

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?

 Quote: 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.
9759   Fri Mar 28 20:23:02 2014 ranaSummaryIOOMC2 moved

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.

9764   Mon Mar 31 11:34:00 2014 manasaSummaryIOOMC2 moved

 Quote: 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.

ELOG V3.1.3-