40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 125 of 341  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  11106   Fri Mar 6 00:59:13 2015 ranaSummaryIOOMC alignment not drifting; PSL beam is drifting

In the attached plot you can see that the MC REFL fluctuations started getting larger on Feb 24 just after midnight. Its been bad ever since. What happened that night or the afternoon of Feb 23?
The WFS DC spot positions were far off (~0.9), so I unlocked the IMC and aligned the spots on there using the nearby steering mirrors - lets see if this helps.

Also, these mounts should be improved. Steve, can you please prepare 5 mounts with the Thorlabs BA2 or BA3 base, the 3/4" diameter steel posts, and the Polanski steel mirror mounts? We should replace the mirror mounts for the 1" diameter mirrors during the daytime next week to reduce drift.

  11112   Fri Mar 6 19:54:15 2015 ranaSummaryIOOMC alignment not drifting; PSL beam is drifting

MC Refl alignment follow up: the alignment from last night seems still good today. We should keep an cool on the MC WFS DC spots and not let them get beyond 0.5.

  11147   Thu Mar 19 16:58:19 2015 SteveSummaryIOOMC alignment not drifting; PSL beam is drifting

Polaris mounts ordered.

Quote:

In the attached plot you can see that the MC REFL fluctuations started getting larger on Feb 24 just after midnight. Its been bad ever since. What happened that night or the afternoon of Feb 23?
The WFS DC spot positions were far off (~0.9), so I unlocked the IMC and aligned the spots on there using the nearby steering mirrors - lets see if this helps.

Also, these mounts should be improved. Steve, can you please prepare 5 mounts with the Thorlabs BA2 or BA3 base, the 3/4" diameter steel posts, and the Polanski steel mirror mounts? We should replace the mirror mounts for the 1" diameter mirrors during the daytime next week to reduce drift.

 

  11149   Fri Mar 20 10:51:09 2015 SteveSummaryIOOMC alignment not drifting; PSL beam is drifting

Are the two  visible small srews holding the adapter plate only?

If yes, it is the weakest point of the IOO path.

  9336   Mon Nov 4 12:59:43 2013 JenneUpdateIOOMC alignment not so good after PSL output shutter installed

Quote:

  The PSL shutter is reinstalled.

 I'm not sure if Steve bumped something, or if it was just a fluke, but the MC didn't come back very nicely after Steve finished re-installing the shutter.

Earlier today, after Steve locked the PMC, MC trans looked good for over an hour (according to the striptool plot on the wall).  Then, the MC was unlocked for about an hour, presumably while Steve was working, he had the light blocked.  When he finished, the MC transmission was around 5,000 while usually it is around 17,000.  The reflection was around 3.4, rather than a best of below 0.5 (unlocked refl is 4.5).

Using Rana's ezcaservo trick to get the suspensions back to where they were at last good lock usually works (I used to do it by hand though).  However, today, it only got the reflection down to about 2.0.  So, I did the rest of the alignment by hand. 

After I did this, the reflection is down to 0.48.  Engaging the WFS makes the MC much more noisy, so I have them disabled currently. 

I have measured the spots, and if I compare them to the measurements that (I think it was Manasa) took last week, they look pretty bad. 

I think that we need to swap out the 2nd zigzag mirror, and then do a careful MC realignment.  It's certainly not worth doing the work, and then re-doing it after we swap out the zigzag mirror.

MCspots_4Nov2013.png

  6426   Fri Mar 16 16:03:03 2012 kiwamuUpdateIOOMC alignment servo : put some offsets in the TRANS QPD signal

The MC alignment servo wasn't great in the last 1 hour or so as it kept disturbing the MC lock. It was found to be due to some offsets in the MC trans QPD signals.

I put some values to cancel the offsets and then the lock became stable.

This is a first aid. So we need to take a closer look at the QPD signals and also probably the spot position on the QPD.

 


The symptom was that every time the alignment servo was engaged, at the beginning the amount of the transmitted light went to 27000 counts, which is good.

However, then the amount of the transmitted light slowly decreased in a time scale of ~ 20 sec or so, ending up with destruction of the MC lock.

According to the time scale I suspected that the servos using the trans QPD signals were doing something bad because their control width had been designed to be slow and slower than the rest of the servo loops.

I switched off the servos, called C1:IOO-TRANS_PIT and C1:IOO-TRANS_YAW and found the MC stayed locked stably with 27000 counts of the transmitted light.

Leaving the trans QPD servos off, I zeroed the offsets and then switched them on. It worked.

 

The values below are the current offset that I put.

                C1:IOO-MC2_TRANS_PIT_OFFSET = -0.115203
                C1:IOO-MC2_TRANS_YAW_OFFSET = -0.0323576
 

  307   Sun Feb 10 21:43:16 2008 robConfigurationIOOMC alignment tweaked

I adjusted the alignment of the free hanging mode cleaner to best transmit the PSL beam.
  3174   Wed Jul 7 22:58:08 2010 nancyUpdateIOOMC alignment values.

Nancy and Koji:

This is what I and Koji measured after aligning the MC in the afternoon.

MC_Trans 4.595 (avg)

MC_Refl 0.203 (avg)

MC2_trans :

power = 1.34mW

13.5% width : x=6747.8 +- 20.7 um  , y = 6699.4+- 20.7 um

 

  3175   Wed Jul 7 23:11:08 2010 KojiUpdateIOOMC alignment values.

Hmm. I expect that you will put more details of the work tomorrow.
i.e. motivation, method, result (the previous entry is only this),
and some discussiona with how to do next.

Quote:

Nancy and Koji:

This is what I and Koji measured after aligning the MC in the afternoon.

MC_Trans 4.595 (avg)

MC_Refl 0.203 (avg)

MC2_trans :

power = 1.34mW

13.5% width : x=6747.8 +- 20.7 um  , y = 6699.4+- 20.7 um

 

 

  3183   Thu Jul 8 20:32:22 2010 nancyUpdateIOOMC alignment values.

I and Koji were trying to lock the mode cleaner for measuring the beam power at MC2 end. That is when we obtained the trans and refl values.

The beam characteristics at the MC2 were measured so that we could now use a dummy beam of similar power to test and characterize the QPD we are about to install at the MC2 end. This QPD wil provide two more signals in pitch and yaw, and hence complete 6 signals for 6 rotatioanl dof of the cavity. (4 are coming from WFS).

Once the QPD is characterised, it can be used to see the spot position at MC2. This is related to the mirror angles.

The width measurements were done using a beam scan. the beam scan was properly adjusted so that the maxima of the intensity of the sopt was at its center.

We also fitted gaussian curve to the beam profile, and it was a substantially good fit.

 

The whole idea is that I am trying  to look how the Wavefront sensors respond to the perturbations in the mirror angles. Once this is known, we should be able to control the mirror-movements.

the starting point would be to do just the DC measurements (which I did today). For proper analysis, AC measurements are obviously required.(will be done later).

The matrices so calculated can be inverted, and if found enough singular, the method can be used to control.

The first shot is to see teh dependency of teh error signals only on MC1 and MC3, and see if that is kind of enough to control these two mirrors.

If this works, the QPD signals could be used to control MC2 movements.

Quote:

Hmm. I expect that you will put more details of the work tomorrow.
i.e. motivation, method, result (the previous entry is only this),
and some discussiona with how to do next.

Quote:

Nancy and Koji:

This is what I and Koji measured after aligning the MC in the afternoon.

MC_Trans 4.595 (avg)

MC_Refl 0.203 (avg)

MC2_trans :

power = 1.34mW

13.5% width : x=6747.8 +- 20.7 um  , y = 6699.4+- 20.7 um

 

 

 

  4305   Wed Feb 16 01:03:59 2011 JenneUpdateIOOMC alignment work

So.... Kiwamu and I were concerned (still a little concerned) that ETMY is not damping as nicely as it should be.  (It's fine, but the UL rms is ~5, rather than ~1 or less. BURT restores by Kiwamu didn't change anything.) Anyhow, I was heading out to push the annoying ribbon cables more firmly into the satellite adapter board things that are tied to the racks in various places (The back of 1X5 for the corner optics and the end station racks for the ETMs).  The point was to push in the ETMY one, but while I was out in the lab and thinking about it, I also gave all of the corner connectors (MC1, MC2, MC3, ITMx, ITMY, BS, PRM, SRM) a firm push. 

Kiwamu noticed that when I did this, the Mode Cleaner alignment got a little bit worse, as if the connection to the satellite adapter boards hadn't been great, I pushed the connectors in and the connection got better, but we also got a bit of a DC offset in the MC alignment.  Anyhow, the MC_TRANS power went down by ~2, to about the place it had been before Kiwamu adjusted the position of the lens in between the zigzag mirrors.  (I don't know if Kiwamu elogged it earlier, but he scooted the lens a teensy bit closer in the optical path to the Mode Cleaner). 

To counteract this loss in MC transmitted power as a result of my connector actions, I went back to the PSL table and fiddled with the zigzag steering mirrors that steer the beam from the PSL table over to the mode cleaner.  I got it a little better, but it's still not perfect.

Kiwamu has noted that to improve the mode matching into the Mode Cleaner with the new PMC in place, we might have to move the lens which is currently between the zigzag steering mirrors, and put it after the second mirror (so in between the last steering mirror and the pickoff window that sends a piece of the beam over to PSL_POS and PSL_ANG).  This will make the waist between MC1 and MC3 tighter. 

Moral of the story:  To improve IMC mode matching we need to move the last lens closer in the optical path to the mode cleaner waist. Twiddle with zigzag steering mirrors to optimize.

  4316   Thu Feb 17 14:52:27 2011 JenneUpdateIOOMC alignment work

I worked a little bit more on optimizing the mode matching to the MC, but it's still not great.  I've only gotten a visibility of ~45%, but Koji said that it used to be ~87%.  So there is a long way to go.  Kiwamu said he can work with the lower-power configuration for a few days, and so my next step will be to measure the beam profile (stick a window in the path, and look at the refl from the window....that way we don't get thermal lensing from transmission through an optic), and redo the mode matching calculation, to figure out where the last lens should actually sit.

Quote:

So.... Kiwamu and I were concerned (still a little concerned) that ETMY is not damping as nicely as it should be.  (It's fine, but the UL rms is ~5, rather than ~1 or less. BURT restores by Kiwamu didn't change anything.) Anyhow, I was heading out to push the annoying ribbon cables more firmly into the satellite adapter board things that are tied to the racks in various places (The back of 1X5 for the corner optics and the end station racks for the ETMs).  The point was to push in the ETMY one, but while I was out in the lab and thinking about it, I also gave all of the corner connectors (MC1, MC2, MC3, ITMx, ITMY, BS, PRM, SRM) a firm push. 

Kiwamu noticed that when I did this, the Mode Cleaner alignment got a little bit worse, as if the connection to the satellite adapter boards hadn't been great, I pushed the connectors in and the connection got better, but we also got a bit of a DC offset in the MC alignment.  Anyhow, the MC_TRANS power went down by ~2, to about the place it had been before Kiwamu adjusted the position of the lens in between the zigzag mirrors.  (I don't know if Kiwamu elogged it earlier, but he scooted the lens a teensy bit closer in the optical path to the Mode Cleaner). 

To counteract this loss in MC transmitted power as a result of my connector actions, I went back to the PSL table and fiddled with the zigzag steering mirrors that steer the beam from the PSL table over to the mode cleaner.  I got it a little better, but it's still not perfect.

Kiwamu has noted that to improve the mode matching into the Mode Cleaner with the new PMC in place, we might have to move the lens which is currently between the zigzag steering mirrors, and put it after the second mirror (so in between the last steering mirror and the pickoff window that sends a piece of the beam over to PSL_POS and PSL_ANG).  This will make the waist between MC1 and MC3 tighter. 

Moral of the story:  To improve IMC mode matching we need to move the last lens closer in the optical path to the mode cleaner waist. Twiddle with zigzag steering mirrors to optimize.

 

  7557   Tue Oct 16 11:54:05 2012 JenneUpdateIOOMC alignment??

The MC won't survive the boosts right now.  Pizza meeting is in a minute, and I won't be back to the lab before ~3:30 because of the seminar / a meeting, so someone else is welcome to try to fix it. Otherwise I'll have a look later on.

I'm leaving the autolocker disabled, so that it won't try any funny business.  WFS are off, so that they don't need to be turned off by the down script.

  9898   Fri May 2 02:22:56 2014 rana, QUpdateIOOMC alignments

We were having unstable MC locking so we did some physical alignment touch up. Use MC suspension bias to have good MC alignment. Unlock MC and align DC beams to center on WFS. Re-lock and things are now stable.

Someone had been feeding bad info to Eric about MC alignments; we do not center the MC WFS beams with the MC locked.

However, in any case, today the MC2-TRANS servo was not being good so I turned it off. We need the real matrix measurement to bring it back.

  8281   Wed Mar 13 02:48:13 2013 JenneUpdateIOOMC all better

Koji reminded me (again....this is probably the  2nd or 3rd time I've "discovered" this, at least) that the script

..../scripts/MC/WFS/WFS_FilterBank_offsets

exists, and that we should use it sometimes.  See his elog 7452 for details. 

 

Notes about using this script:

* Only use it after MC has been very well aligned.  MC REFL DC should be less than 0.5 when the MC is locked (with the DC value ~4.5 with the MC unlocked, as usual).  This is hard to achieve, but important.  Also, check the MC spot centering.

* With the WFS servo off, but the MC locked and light on the WFS diodes, run the script. 

  6679   Thu May 24 19:39:18 2012 SureshUpdateIOOMC and WFS alignment adjusted

[Yuta, Suresh]

We found that the MC was not locking and that the alignment between PSL and MC was too poor to obtain a TEM00 mode in the MC.   To correct the situation we went through the following steps:

1) We burt restored the MC alignment slider values to their values at 3:07 AM of today

2) We turned off the MC-autolocker and the ASC signal to the coils.   Then aligned the PSL beam into the MC (with the MC servo loop off) to obtain the TEM00 mode.  We had to adjust the zig-zag at the PSL output by quite a bit to maximise MC transmission.

3) We then centered the spot on the MC2 face and centered the transmitted beam on the MC2_TRANS_QPD

4) Next, we centered the beams on the MC_WFS sensors.

5) Turning on the WFS loops after this showed that everything works fine and WFS loops do not accumulate large offsets.

 

 

  10317   Fri Aug 1 01:57:24 2014 KojiSummaryIOOMC auto locker

To make MC auto locker running correctly, mcdown and mcup were revised

I tried it by unlocking MC several times. It seems OK. Let's see how it works.


Nominal gains for locking (to be taken care by mcdown)

C1:IOO-MC_REFL_GAIN
was 16 and is 19 now.

C1:IOO-MC_VCO_GAIN
was 9 and is 9 now too.

C1:PSL-FSS_MGAIN
was missing and now +13

C1:PSL-FSS_FASTGAIN
was +23.5 and is now +20.0

Nominal gains for operation ( to be taken care by mcup.

C1:IOO-MC_REFL_GAIN
was 19 and is 19 now too.

C1:IOO-MC_VCO_GAIN
was 25 and now uses ezcastep (ezcastep C1:IOO-MC_VCO_GAIN=9 +1,16 -s 0.1)

C1:PSL-FSS_MGAIN
C1:PSL-FSS_FASTGAIN

ezcawrite C1:PSL-FSS_MGAIN `ezcaread -n C1:PSL-STAT_FSS_NOM_C_GAIN`
ezcawrite C1:PSL-FSS_FASTGAIN `ezcaread -n C1:PSL-STAT_FSS_NOM_F_GAIN`

 

C1:PSL-STAT_FSS_NOM_C_GAIN`  is +18
C1:PSL-STAT_FSS_NOM_F_GAIN`   is +20

  10319   Fri Aug 1 08:55:34 2014 KojiSummaryIOOMC auto locker

It seems that the MC auto locker and the FSSSlow PID servo survived a night.

PC Drive is still angry occasionally. We want to know what this is.

  36   Wed Oct 31 08:38:35 2007 ranaProblem FixedIOOMC autolocker
The MC was having some trouble staying locked yesterday. I tracked this down to some steps in the last
half of the mcup script; not sure exactly which ones.

It was doing something that made the FAST of the PSL go to a rail too fast for the SLOW to fix.
So, I broke the script in half so that the autolocker only runs the first part. We'll need to
fix this before any CM locking can occur.

We also need someone to take a look at the FSS Autolocker; its ill.
  7735   Tue Nov 20 20:37:51 2012 KojiUpdateIOOMC autolocker

Last night I found that the MC autolocker has not been updated since the chamber was closed.
i.e. The low power version had been used.

I logged into op340m and modified crontab via "crontab -e" so that the normal power version is spawned.

  10048   Tue Jun 17 12:04:40 2014 manasaUpdateComputer Scripts / ProgramsMC autolocker NOT running, FB needs some attention

MC autolocker and Ottavia

I assume that the MC was left with a fully functioning autolocker enabled and running on ottavia last night.

But as of this morning, the MC autolocker is NOT running alright. The MC was in an unlocked state and the autolocker has been doing nothing to the servo sliders.  I think this was the state of MC since last night as seen on the stripchart.

Since the autolocker has been left to run on ottavia, I tried to look at the cronlogs to see if it running the autolocker script at all. I looked at the list on ottavia and it has the MCautlocker on it cronjobs list and yet doing nothing.

Later, I did a softreboot on ottavia when I could not ssh into it from rossa or pianosa. ssh to ottavia now works just fine.

I am leaving Ottavia at this and returning to the more important job of fixing the MC. I locked the MC manually and am now working on the alignment.

 

Framebuilder

Also, the CDS FE status screen had red lights blinking as if it required an 'mxstream restart'. I did the same and it did not fix the problem. So I tried to restart fb using the usual 'telnet fb 8087'; but could not restart fb that way.

Attached: FE status screen

  10247   Mon Jul 21 13:58:33 2014 ericqUpdateIOOMC autolocker acting up

The autolocker claimed it was running and blinking, but not doing anything (i.e. lock bit was not updating and no switches or sliders being touched)

After stopping and starting it a number of times, it began working again, through no real changes of my own. I'm a little mystified as to what the problem was... keep an eye out.

  8627   Thu May 23 10:48:42 2013 ManasaUpdateIOOMC autolocker and MCWFS enabled

Some strong seismic noise (not related to any earthquakes - watchdogs are all green) had got the MC unlocked this morning.

I found the MC autolocker and MCWFS disabled. Enabling them locked the MC right away. I don't see any updates in the elog  as to why these were left disabled and hence have left them ON now.

  5689   Tue Oct 18 22:47:09 2011 SureshConfigurationIOOMC autolocker script edited to shutdown and restart WFS loops

Quote:

I found that the MC WFS had large offset control signals going to the MC SUS. Even though the input switch was off, the integrators were holding the offset.

I have disabled the ASCPIT outputs in the MC SUS. Suresh is going to fix the MC autolocker script to gracefully handle the OFF and ON and then test the script before resuming the WFS testing.

MCL data for OAF may be suspect from this morning.

 I have edited (uncommented existing commands)  the following scripts to enable WFS locking to come on when the MC is locked.

1) $scripts$/MC/autolockMCmain40m*

2) $scripts$/MC/mcup

3) $scripts$/MC/mcdown

4) $scripts$/MC/WFS/mcwfson

5) $scripts$/MC/WFS/mcwfsoff.

I have checked that the autolocker script switches off the mcwfs when mc loses lock and then switches it on after re-obtaining lock.

 

  16480   Tue Nov 23 18:02:05 2021 AnchalUpdateIMCMC autolocker shifted to python3 script running in docker

I finished copying over the current autolocker bash script functionality into a python script which runs using a simple configuration yaml file. To run this script, one needs to ssh into optimus and :

controls@optimus|~> cd /opt/rtcds/caltech/c1/Git/40m/scripts/MC
controls@optimus|MC> sudo docker-compose up -d
Creating mc_AL_MC_1 ... done

That's it. To check out running docker processes, one can:

controls@optimus|MC> sudo docker ps

And to shut down this particular script, in the same directory, one can

controls@optimus|MC> sudo docker-compose down
Removing mc_AL_MC_1 ... done

If the docker image requires to be rebuild in future, go to the directory where Dockerfile is present and run:

controls@optimus|MC> sudo docker build -t pyep .

I had to add PyYAML package in the pyepics docker image already present on docker hub, thanks to Andrew.

For now, I have disabled the MCautolocker service on Megatron. To start it back again, one would need to ssh into megatron and do following:

~> sudo systemctl enable MCautolocker
~> sudo systemctl start MCautolocker

Let's see for a day how this new script does. I've left PSL shutter open and autolocker engaged.

To do: Fix the C1:IFO-STATE epics channel definition so that it takes its bits from separate lock status channels instead of scripts writign the whole word arbitrarily.

  7121   Wed Aug 8 18:01:58 2012 JenneUpdateIOOMC autolocker threshold changed

Jan and Manasa are going to elog about their work later, but it involved putting a BS/window/some kind of pick off in front of the MC Trans QPD, so the total light on the MC Trans QPD is now ~16000 rather than ~26000 counts.  I changed the threshold in the MC autolocker to 5000, so now the MC Trans PD must see at least 5000 counts before the autolocker will engage the boosts, WFS, etc.  Actually, this threshold I believe should have been some several thousand value, but when I went in there, it was set to 500 counts, for low power MC mode during a vent.  It had never gotten put back after the vent to some higher, nominal value.

  3352   Tue Aug 3 03:15:06 2010 nancyUpdateIOOMC back to locked mode

I turned the WFS gain to 0.02 back, and the MC is locked, the data for the seismic motion might be meaningful nowforth.

  4660   Sun May 8 16:32:52 2011 valeraUpdateIOOMC beam spot centering

 Kiwamu told me that the CDS matrix notation has changed and the 40m front end code has changed since February. I changed the senseMCdecentering script to reflect that. The other problems were: the "-" sign in ezcastep on ubuntu is not recognized - I used the known workaround of using "+-" instead; the echo command in csh script on ubuntu does not make a new line - but the echo " " does. The script ran on ubuntu with one error message "FATAL: exception not rethrown" but it finished nevertheless. The data appeared ok.  On centos machine the script produced "Segmentation fault'. The matlab script sensemcass.m now calculates the position on the MC mirrors in mm. The attached table shows the MC spot positions in mm:

    feb 26 2011      may 08 2011
MC1 pit   1.6   1.9
MC2 pit   6.4   9.0
MC3 pit   1.4   2.0
MC1 yaw   -1.5   -1.7
MC2 yaw   1.0   0.2
MC3 yaw   -1.3   -1.9

I had to rephase the lockin digital phases by tens of degrees. I don't know why this should happen at ~10 Hz.

 

  4661   Sun May 8 17:29:01 2011 ranaUpdateIOOMC beam spot centering

It seems like the best option would be to make the MCASS just adjust the SUS biases and center the beams on the suspended optics. Is this not possible somehow?

  4659   Sat May 7 18:08:54 2011 valeraUpdateIOOMC beam spot centering script

I tried to run the scripts/senseMCdecentering to check the centering of the MC beam spots on the mirrors. The script (csh) produces a lot of error messages on the control room machines. They are machine dependent combination of "epicsThreadOnce0sd epicsMutexLock failed", "Segmentation fault", "FATAL: exception not rethrown". Most of ezcawrite commands fail but not all(?). After running the mcassUp script couple of times all the dither lines came on. The MCL responses to dither lines look qualitatively similar to what it was in February (plot attached). The overall MCL spectrum looks ~100 times lower, presumably due to the analog gain reallocation.

Before that I realigned the beam into the PMC, recentered the PSL QPDs, and the beam into the MC to bring the MC RFPD_DC from ~3 to ~1.5 VDC then tweaked MC2 to bring the MC RFPD_DC from ~1.5 to ~1 VDC.

The mcass dither lines are off now and the loops are disabled.

  6715   Wed May 30 15:51:22 2012 yutaUpdateIOOMC beam spot oscillation

[Koji, Suresh, Jenne, Yuta]

Background:
  We noticed that the beam spots on MC mirrors are oscillating in ~ 1 Hz yesterday. It means MC mirrors are actually oscillating. This was observable even if the WFS servo is off.

What we did:
  1. By measuring the spectra of OSEM sensor outputs, we found that MC3 is the one that is oscillating.

  2.  Oscillation at ~ 1 Hz only happened when the local damping using OSEMs are on (see Attachment 1; REF is when the damping is on).

  3.  We found that this oscillation came from insufficiency in phase margin in SUSPOS loop. So, we increased the gain, C1:SUS-MC3_SUSPOS_GAIN, from 95 to 200. It helped a little, but oscillation is still there.

  4.  We measured openloop transferfunctions of SUSPOS, SUSPIT, SUSYAW, SUSSIDE loop, and concluded that diagonalization some how went wrong. The amplitude of the oscillation (peak height in the OSEM spectra) changed by pushing the MC SUS connectors.

Plan:
  - Fix the connectors so that we don't have to push them any more.
  - Redo the diagonalization of the MC suspensions.

  6718   Wed May 30 19:27:38 2012 yutaUpdateIOOMC beam spot oscillation

[Koji, Yuta]

We found that C1:SUS-MC{1,2,3}_TO_COIL_3_4_GAIN was somehow changed to -1, and feedback signal for SIDE was fedback to LLCOIL, which is apparently not correct.
We checked the snapshots on May 25 and confirmed that it was used to be 0, so we fixed it.
We suspect that it happened during the beam spot measurement, because the measurement changes the TO_COIL matrix gains.

Now, we don't see any MC beam spot oscillation.

Quote:

[Koji, Suresh, Jenne, Yuta]

Background:
  We noticed that the beam spots on MC mirrors are oscillating in ~ 1 Hz yesterday. It means MC mirrors are actually oscillating. This was observable even if the WFS servo is off.

 

  6719   Wed May 30 20:12:15 2012 ranaUpdateIOOMC beam spot oscillation

This is a common occurrence when diagnostic scripts are written without the ability to handle exceptions (e.g. ctrl-c, terminal gets closed, etc.).

The first thing to do is make sure that the "new" script you are writing doesn't already exist (hint: look in the old scripts directory).

If you are writing a script that touches things in the interferometer, it must always return the settings to the initial state on abnormal termination:

http://linuxdevcenter.com/pub/a/linux/lpt/44_12.html

  6728   Thu May 31 10:31:19 2012 JamieUpdateIOOMC beam spot oscillation

Quote:

This is a common occurrence when diagnostic scripts are written without the ability to handle exceptions (e.g. ctrl-c, terminal gets closed, etc.).

The first thing to do is make sure that the "new" script you are writing doesn't already exist (hint: look in the old scripts directory).

If you are writing a script that touches things in the interferometer, it must always return the settings to the initial state on abnormal termination:

http://linuxdevcenter.com/pub/a/linux/lpt/44_12.html

This is very good advice.  However, "trap" is bash-specific.  tcsh has a different method that uses a function called "onint".  Here's a description of the difference.

A couple notes about bash traps:

  • You can give a name instead of a number for the signal.  So instead of trap 'do stuff' 1 you can say trap 'do stuff' SIGHUP
  • The easiest signal to use is EXIT, which covers all your bases (ie. anything that would cause the script to exit prematurely.
  • You can define a function that gets executed in the trap

So the easiest way to use it is something like the following:

#!/bin/bash   # define cleanup function  function cleanup {      # do cleanup stuff, like reset EPICS records to defaults      ....  }  # set the trap on EXIT  trap cleanup EXIT  # the rest of your script below here
...
  6868   Mon Jun 25 15:07:49 2012 yutaUpdateIOOMC beam spot trend

I adjusted MC WFS offsets using /opt/rtcds/caltech/c1/scripts/MC/WFS/WFS_FilterBank_offsets.
Beam spot positions on MC mirrors came back to where it was past few weeks. See the trend below. Trend sometimes shows huge jump, but it's just a bad measurement caused by unlock of MC during the measurement.

I ran /opt/rtcds/caltech/c1/scripts/ASS/MC/mcassMCdecenter to measure beam spot whenever I feel like it (see elog #6727).
Beam spot doesn't move so much (~0.2 mm in standard deviation), which means incident beam from PSL table is quite stable.


MCdecenter.png

  6164   Wed Jan 4 00:43:06 2012 kiwamuUpdateIOOMC became flaky

I don't know what exactly is going on, but MC became flaky and it's been frequently unlocked.

I have turned off the MC WFS servo to check if the WFSs are doing something bad. But it still tends to be unlocked without the WFS servo.

Right now it doesn't stay locked for more than 10 min.

  9892   Thu May 1 14:45:44 2014 JenneUpdateLSCMC board back in

Quote:

Quote:

To fix this, I am going to put a 6.8uF cap in series with R30 in the MC board, which is part of the crossbar switch where the IN1 and IN2 get summed.  This should AC-couple the output of the IN2 slider before the summing node.

 MC board is out, so don't be surprised that the MC isn't locking.

 MC board is back in place, MC is locked.

If I disable all of the AO path bits of the CM servo (disable switch, and also gain slider to -32dB), and then move the MC IN2 slider around, the MC does not get an offset anymore (as seen by reduced transmission and increased reflected power), so I think the DC coupling is working.  I do lose lock of the MC if the slider goes above ~22 dB in this situation, but I don't see any effect before then, whereas we were able to see a steady increase in the reflected power as we moved the slider around last night.  So, it seems like things are good with the DC coupling of the IN2 slider.

Here are some photos from before I modified the board (front, back, and zoom of the area I was working in):

IMG_1394.JPG

IMG_1395.JPG

IMG_1398.JPG

And here is my modification, putting the 6.8uF cap in series with (a new) 2k thin film resistor, in the spot for R30:

IMG_1402.JPG

The board is https://dcc.ligo.org/DocDB/0004/D040180/001/D040180-C.pdf

[Edit, 20140721: It looks like this is actually D040180 rev B, not rev C. —Evan]

  10017   Mon Jun 9 23:08:58 2014 JenneUpdateIOOMC board checkout

Rana mentioned this in his elog entry re: SLOW computer recovery, but I want to highlight it:

We cannot yet lock the mode cleaner.

It seems that we need to be aware of the sticky slider issue that we have seen for years (although don't deal with too often) that a burt restore will make it seem like an EPICS channel is at some value, but in fact it is at some other value.  For any sliders or buttons in question, change the value by some amount, and then change it back.  This forces things to refresh, and it'll then be at the value that is reported.

However, for the MC board, this seems to not be enough.  Changing the offset slider doesn't seem to actually change the offset value.  The fast output of the MC board is railed at 9.996 V.  So.  We need to check out the MC servo board and ensure that we are actually connected and talking to it through the c1iool0 (C1i-oh-oh-L-zero, to make the characters more clear) slow machine.

  9891   Thu May 1 13:03:34 2014 JenneUpdateLSCMC board pulled for AC coupling

Quote:

To fix this, I am going to put a 6.8uF cap in series with R30 in the MC board, which is part of the crossbar switch where the IN1 and IN2 get summed.  This should AC-couple the output of the IN2 slider before the summing node.

 MC board is out, so don't be surprised that the MC isn't locking.

  9695   Wed Mar 5 19:27:24 2014 manasaUpdateIOOMC calmed down

The IMC has not been behaving well since this morning and totally not happy when Q was finishing his measurements. The WFS servo had large offsets in pitch. Looking back at the trend and using ezcaservo to restore the suspensions did not help.

I realigned the IMC and brought TRANS SUM to ~18000 and MCREFL to < 0.5. The spot positions are not very good; nearly 2 mm off in pitch on MC1 and MC3. But after the alignment of MC, the WFS servo offsets were below +/-20.

The MC has been locked stably with WFS servo ON for the last few hours.

P.S. I did not touch the WFS pointing or reset the WFS offsets.

  9701   Thu Mar 6 19:17:05 2014 manasaUpdateIOOMC calmed down

Quote:

The IMC has not been behaving well since this morning and totally not happy when Q was finishing his measurements. The WFS servo had large offsets in pitch. Looking back at the trend and using ezcaservo to restore the suspensions did not help.

I realigned the IMC and brought TRANS SUM to ~18000 and MCREFL to < 0.5. The spot positions are not very good; nearly 2 mm off in pitch on MC1 and MC3. But after the alignment of MC, the WFS servo offsets were below +/-20.

The MC has been locked stably with WFS servo ON for the last few hours.

P.S. I did not touch the WFS pointing or reset the WFS offsets.

MC remained locked with WFS enabled all through last night and this morning. Koji dropped by and looked at the MC. The MC WFS servo, though stable, was at the edge of becoming unstable. This was because I did not touch the WFS pointing on the QPDs yesterday after realigning. So I recentered the WFS, reset the WFS filterbank offsets and reenabled the servo.

I measured the spot positions on MC mirrors for reference.

Spot positions in mm (MC1,2,3 pit MC1,2,3 yaw): [1.405767579680834, 0.79369009503571208, 1.3220430681427462, -1.2937873599406551, -1.1704264340968924, -1.2518046122798692]

  3373   Fri Aug 6 12:22:04 2010 JenneUpdateIOOMC data taking over the weekend

Nancy has the Mode Cleaner for her work for the night, and is going to leave the MC happy, locked, autolocker on, WFS enabled, the works, and write down in the elog the time that she's finished. After that, I'm taking MC/seismic data all weekend long.  During the weekend, if at all possible, please don't go into the IFO room, especially near the Mode Cleaner.  If you do need to go into the IFO room, please elog the time you went in, and the time you left so I can correlate it with my dataThis is actually important, so please stick a quick elog entry in if you even think about opening the doors to the IFO room. It is much appreciated. 

  3375   Fri Aug 6 12:44:29 2010 KojiUpdateIOOMC data taking over the weekend

Question:

Do you like to keep the WFS turned on?

This may change the transfer functions between the ground motion to the angle time by time,
and thus change the TF between the GND and the MCL.

Quote:

Nancy has the Mode Cleaner for her work for the night, and is going to leave the MC happy, locked, autolocker on, WFS enabled, the works, and write down in the elog the time that she's finished. After that, I'm taking MC/seismic data all weekend long.  During the weekend, if at all possible, please don't go into the IFO room, especially near the Mode Cleaner.  If you do need to go into the IFO room, please elog the time you went in, and the time you left so I can correlate it with my dataThis is actually important, so please stick a quick elog entry in if you even think about opening the doors to the IFO room. It is much appreciated. 

 

  10363   Mon Aug 11 21:03:48 2014 ericq, ranaSummaryIOOMC demod measurement

We measured the TF of the MC Demod board today.

We set the Marconi to +3dBm and drove the PD IN port of the demod board, starting at 29.5 MHz. Then we looked at the beat signal amplitude in the output of the demod board. So this is a transfer function but with mag only. Plots from Q below.

Rana took the demod board out and took pictures of it. Inside, the post mixer low pass is a SCLF-5 from mini-circuits. This has a lot of cutoff down low. Since the purpose of this filter is only to cutoff the 2f-1f and the 3f-2f products, we need to have a lot of attenuation at 29.5 MHz. One day, we may want to re-instate that notch for the (3*f1- f_MC) beat frequency, but for now we want stability.

So, I recommend that we (Steve) get 3 each of the SCLF-10 and SCLF-10.7 from Mini-Circuits Tuesday morning. Maybe we can put them into a spare board?

Also, we should probably remove the 140kHz:70kHz lead filter which is in the MC servo board. Its out of date. I think it would be fine for us to get a 7-15 kHz UGF for the CM servo and the MC can basically do that already. Mainly we want to fix the high frequency shape to get more stability.

After the measurements and photos, we had to reset the MCWFS offsets to get the WFS to not break the lock. Seems very sensitive to offsets. Hopefully Andres will give us a new Gouy phase telescope.

  10364   Mon Aug 11 22:07:31 2014 KojiSummaryIOOMC demod measurement

SCLF-5!? It's surprising as the cut off of the OLTF is just above 1Hz. cf this entry

This means that not the demod board but MC or FSS boards seem to have large attenuation above 1MHz.

In this situation, does SCLF-10/10.7 really help us?

  10365   Mon Aug 11 23:32:54 2014 ericqSummaryIOOMC demod measurement

Here's the magnitude plot of the board TF. As mentioned above, this was done with Marconi+Scope, so we were not able to get the phase of this transfer function. 

MCDemod.pdf

Oddly enough, the bump that I saw is not included in Minicircuit's data on the SCLF-5.

  10879   Thu Jan 8 19:02:42 2015 JaxSummaryElectronicsMC demod modifications

Here's a summary of the changes made to the D990511 serial 115 (formerly known as REFL 33), as well as a short procedure. It needed tuning to 29.5MHz and also had some other issues that we found along the way. 

So here's a picture of it as built:

The changes made are:

1. U11 and U12 changed from 5MHz LP to 10 MHz LP filters.

2. Resistors R8 and R9 moved from their PCB locations to between pins 1 (signal) and 3 (ground) of U11 and U12, respectively. These were put in the wrong place for proper termination so it made sense to shift them while I was already replacing the filters.

Also, please note- whoever labeled the voltages on this board needed an extra cup of coffee that day. There are two separate 15V power supplies, one converted from 24V, one directly supplied. The directly supplied one is labeled 15A. This does NOT mean 15 AMPS.

Transfer functions:

Equipment: 4395A, Signal generator (29.5 MHz), two splitters, one mixer

You can't take the TF from PD in to I/Q out directly. Since this is a demod board, there's a demodulating (downconverting) mixer in the I and Q PD in paths. Negligible signal will get through without some signal applied to the L input of the mixer. In theory, this signal could be at DC, but there are blocking capacitors in the LO in paths. Therefore, you have to upconvert the signal you're using to probe the board's behavior before it hits the board.  Using the 4395A as a network analyzer, split the RF out. RFout1 goes to input R, RFout2 goes to the IF port of the mixer. Split the signal generator (SG). SG1 goes to LO in, SG2 goes to the L port of the mixer. The RF port of the mixer (your upconverted RFout2) goes to PD in, and the I/Q out goes back to the A/B port of the 4395A - at the same frequency as the input, thanks to the board's internal downconversion. 

Phase measurement:

Equipment: Signal generator (29.5 MHz), signal generator (29.501 MHz), oscilloscope

Much simpler: 29.5 MHz to the LO input (0 dBm), 29.501 MHz to the PD input (0 dBm), compare the phases of the I/Q outputs on the oscilloscope. There are four variable capacitors in the circuit that are not on the DCC revision of the board - C28-31. On the LO path, C28 tunes the I phase, C30 tunes the Q phase. On the PD path, C29 and 31 appear to be purely decorative - both are in parallel with each other on the PD in Q path, I'm guessing C29 was supposed to be on the PD in I path. Fortunately, C28 and C30 had enough dynamic range to tune the I/Q phase difference to 90 degrees.

Before tuning:

After tuning:

 

  4143   Wed Jan 12 17:22:47 2011 SureshConfigurationLockingMC demod phase adjusted to minimise the I output

[Koji, Suresh]

We wanted to check and make sure that the relative phase of the two inputs ( local oscillator and photodiode signal ) to the demod board is such that the Q output is maximised.   We displayed the I and  Q signals on the oscilloscope in XYmode with I along the X direction.  If Q is maximised (and therefore I is minimised) the oscillocope trace would be perfectly vertical since all the signal would be in Q and none in I. Initially we noted that the trace was slightly rotated to the CCW of the vertical and that a short cable was present in the PD input line.  Removing this rotated the trace CW and made it pretty much vertical.  The screen shot of the oscilloscope is below.

.TEK00000.PNG

  9524   Tue Jan 7 10:44:13 2014 SteveUpdateIOOMC drift

Quote:

 The trend shows a big jolt to the MC1/3 pointing this morning at 8:30.

Was anyone working anywhere near there today? There is no elog.

If not, we will have to put a 'no janitor' sign on all of the 40m doors permanently to prevent mops misaligning our interferometer.

 I was taking pictures at the AP table at the morning and ETMX optical table after noon. There was no activity on the IOO chamber.

 Look at the last 2 hours of  Rana's trend plot. MC1 and MC2 sensor voltage started increasing.

I think it was a drift action.

  9525   Tue Jan 7 11:11:36 2014 ranaUpdateIOOMC drift

 

 NOT drift. The sudden steps are certainly the result of being kicked. The slow drift at the end of the day might be a slow strain relaxation.

It pays to be careful and not put too much weight or impulsive forces on the chambers or tables.

ELOG V3.1.3-