40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 169 of 341  Not logged in ELOG logo
ID Date Author Type Categorydown Subject
  9527   Tue Jan 7 17:16:04 2014 manasaUpdateIOOMC aligned

Quote:

Edit, JCD:  What this really means is that our DC MC pointing is bad, and we need to move the MC suspensions to offload the WFS.  (All of the WFS output numbers for MC1 and 3 were around 100, which is pretty big for those numbers).  We should resurrect the WFS offloading scripts so that we can do this more regularly, and not have to do it by hand.

 Aligned MC to offload the WFS

1. Turned OFF the WFS feedback servo.

2. Aligned the MC suspensions by moving the pit and yaw sliders. MC trans sum brought from ~11000 counts to ~15000 counts. MC RFPD DCMON reads 0.45 counts.

3. Turned ON the WFS servo. The WFS output now reads in the order of 0 to +/-15.

4. Measured the MC spot positions. The spot positions look like they moved for the better compared to what they were yesterday.

 

Attachment 1: MCspots.png
MCspots.png
  9528   Tue Jan 7 20:57:41 2014 JenneUpdateIOOMC aligned

[Rana, Jenne]

We turned off the WFS servos, and looked at the MC REFL DC, and saw that it was still good, so we said that since the MC spots are pretty good, that we'll keep this alignment for now. 

Rana put the beam back on the center of the IOO QPDs on the PSL table.

We switched a steering mirror in the WFS path that was the wrong handed-ness to be the correct handed-ness, then put the beam on the centers of the WFS.  We turned on the WFS, and everything seems good.

While we were out on the table, we also changed the anodized aluminum dump for a razor dump, to catch the reflection from the 2inch lens that is the first thing the MC refl path sees out of vac.

There were no major drifts in the WFS error signals while we were gone for dinner, so the MC seems okay for now.

  9529   Tue Jan 7 21:00:02 2014 JenneUpdateIOOIP POS, IP ANG aligned

After locking the arms (after the MC alignment work), Manasa and I aligned IP POS, IP ANG, and both end transmission QPDs. 

We noticed that IP ANG is clipping in yaw as it comes onto the end table.  It looks to me like it's clipping on the edge of the plastic box's aperture, but I can't guarantee that it's not also clipping elsewhere. 

  9532   Tue Jan 7 23:09:10 2014 manasaUpdateIOOMC aligned

Quote:

[Rana, Jenne]

We turned off the WFS servos, and looked at the MC REFL DC, and saw that it was still good, so we said that since the MC spots are pretty good, that we'll keep this alignment for now. 

Rana put the beam back on the center of the IOO QPDs on the PSL table.

We switched a steering mirror in the WFS path that was the wrong handed-ness to be the correct handed-ness, then put the beam on the centers of the WFS.  We turned on the WFS, and everything seems good. 

There were no major drifts in the WFS error signals while we were gone for dinner, so the MC seems okay for now.

 The last 4 hour trend for WFS error signals show some amount of drift. We should still look at the long term trend to solve the issue.

Attachment 1: WFSdrift.png
WFSdrift.png
  9577   Mon Jan 27 12:26:00 2014 KojiUpdateIOOIOO Slow Actuator Servo threshold changed

In order to activate the slow actuator servo for the MC locking,
the threshold level for this servo (C1:PSL-FSS_LOCKEDLEVEL) was changed from 10000 to 700.

Now the servo started to move the PZT fast out to be controlled to 5V.

  9580   Tue Jan 28 09:51:47 2014 SteveUpdateIOOlow power pointing

 

PSL output is stable.

Attachment 1: IOO4dlowpr.png
IOO4dlowpr.png
  9632   Thu Feb 13 13:18:33 2014 manasaUpdateIOOMC needed some help

The MC has been funny since yesterday. I checked the suspensions INMON channels and they seemed ok. So I went ahead and tweaked the alignment with WFS disabled (yesterday). Although the WFS PDs were cenetered at this point, the WFS servo was throwing the MC in a not-so-happy state. We worked with the WFS servo OFF all of yesterday.

This morning,

* I fine tuned the MC alignment from yesterday (TRANS_SUM > 17800 counts)

* measured the spot positions

* recentered the spots on the WFS PDs (was already quite centered)

*reset the WFS filterbank offsets.

The MC has been locked happily since then with autolocker and WFS servo enabled.

  9645   Tue Feb 18 14:28:15 2014 JenneUpdateIOOMC unstable - centering spots helped

As we've been seeing a bit lately, the MC will be locked happily for several hours, but then it will start misbehaving. 

Today, I measured the spots on the MC mirrors, and found that the MC2 spot was quite far off in yaw (about -3.5 cm).  I recentered the MC2 spot, and then (with the MCWFS on), moved MC1 and 3 until their WFS outputs were close to zero (they had gone up to 100+).  In the ~15 minutes since doing that, the MC refl signal is not oscillating like it was, the transmission is up, and the MC has not unlocked. 

To reiterate, I did not touch any settings of anything, except the alignment of the MC mirrors to center the MC2 spot, and then offload the WFS.  Next time the MC starts acting up, we should measure the spots, and roughly center them, before messing with any other settings.  Note however, that this is a ~10 minute procedure (including the fact that one spot measurement takes a little less than 5 minutes).  This need not be a several hour endeavour. 

  9677   Wed Feb 26 02:20:35 2014 JenneUpdateIOOMC unhappy

I've asked Manasa and Q to have a look at the MC in the morning.  Rana and I have found it to be slightly uncooperative in relocking after a lockloss.

The concern is that we may be (by actuating on things during lock, or during a lockloss) ringing up some mode, maybe a violin mode in one of the suspensions, maybe a PZT mode of some sort.  If we are, and then we have to push with the PZT on the laser to lock things, that may be why the laser's PZT RMS (on the FSS screen) is so often above 1Vrms.  When we close the PSL shutter, the rms is low, like 0.6 or something, and it stays flat.  As we've all see many a' time, the red trace on the top projector plot is pretty erratic throughout the day when the MC is locked or trying to lock.

We have found that just letting the autolocker go doesn't seem to work very well, and sometimes the MC just doesn't want to re-lock.  Closing the PSL shutter or disabling the autolocker for a few minutes (5ish) doesn't do anything, but leaving it closed for a long time (30 ish minutes) helps a lot.  The MC  will relock immediately after a nice long break. 

 

  9678   Wed Feb 26 10:08:14 2014 SteveUpdateIOOIOO trend

 

 The MC is happy (but only for this tiny snapshot in time and most probably will go dysfunctional again as it has been for several months, as of this writing)

Attachment 1: IOOtrend3&24h.png
IOOtrend3&24h.png
  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.

  9697   Thu Mar 6 09:47:11 2014 SteveUpdateIOOMC trend of 20 days

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.

 

Attachment 1: IOO_20days.png
IOO_20days.png
  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]

Attachment 1: MC_spots_Mar6.png
MC_spots_Mar6.png
  9704   Fri Mar 7 16:56:17 2014 steveUpdateIOOIOO qpds centered

Quote:

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]

 

Attachment 1: IOOqpdCentered.png
IOOqpdCentered.png
  9705   Mon Mar 10 09:28:48 2014 steveUpdateIOOIOO pointing 2 days

 Morning seconds without adjustment.

 

Attachment 1: IOOpointing2d.png
IOOpointing2d.png
Attachment 2: morningseconds.png
morningseconds.png
  9707   Mon Mar 10 12:49:27 2014 JenneUpdateIOOPMC input pointing misaligned

I don't know why, but as you can see in Steve's plot from earlier this morning, the PMC transmission has been going down significantly all weekend.  The PMC refl camera was very bright.  I tweaked up the alignment (mostly pitch), and now we're back to normal. 

The IMC was having trouble staying locked all morning, and I'm hoping that this PMC adjustment will help - the MC already looks better, although it's only been a few minutes.

  9739   Tue Mar 18 21:19:22 2014 KojiSummaryIOOMC spot positions checked

MC spot sposition script was ran

/opt/rtcds/caltech/c1/scripts/ASS/MC/mcassMCdecenter

Found no notable beam position change before and after the earthquake

 

Attachment 1: MCASS.png
MCASS.png
  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.

  9794   Thu Apr 10 10:52:15 2014 manasaSummaryIOOMC2_TRANS path in WFS servo

Quote:

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.

[From yesterday]

The MC had not been stable lately with WFS drifting constantly. I checked the servo and found that the MC_TRANS path was still running. It turned out that the autolocker script enables the TRANS path in the locking process. I have turned the MC_TRANS path servo inputs OFF and now it is no more a part of the WFS servo.

P.S. Jenne fixed the PMC alignment mostly in pitch to bring it up to 0.81 from 0.77. But the temperature fluctuations have still not got us to the sweet spot for optimum PMC trans.

  9815   Tue Apr 15 16:21:18 2014 KojiUpdateIOOMC2 LSC offset was set to be -5000

Yesterday, MC2 alignment was slipping all day. Even when the WFS was off (i.e. there wa sno actuation), I had continual misalignment caused by MC2

I was afraid that the MC2 mirror is on a bistable position somehow. So I gave -5000 offset on the MC2 LSC. We'll see how it makes the MC happier.

  9833   Sun Apr 20 18:15:37 2014 ericqUpdateIOOCleaner Cleanup

Came in, and the PMC and MC needed aligning. 

PMC Trans .74->.83

I wasn't able to move the MC1&3 the right way in pitch without having a terrible MC2 position... using the move MC2 scripts to bring it back threw off the other spots.

  9856   Fri Apr 25 22:20:01 2014 ranaUpdateIOOcsh/tcsh hackery combatted

To make the mcwfson/off scripts work from rossa (and not just Jamie's pet machine) I swapped the sh-bang line at the top of the script to use 'env bash' instead of 'env csh' in the case of mcwfsoff and 'env tcsh' in the case of mcwfson.

The script was failing to work due to $OSTYPE being defined for pianosa csh/tcsh, but not on rossa.

During debugging I also bypassed the ezcawrapper for ezcaswitch so that now when ezcaswitch is called, it directly runs the binary and not the script which calls the binary with numerous retries. In the future, all new scripts will be rewritten to use cdsutils, but until then beware of ezcaswitch failures.

WFS scripts checked into the SVN.

This was all in an effort to get Koji to allow me to upgrade pianosa to ubuntu 12 so that I can have ipython notebook on there.

Objections to upgrading pianosa? (chiara and megatron are already running ubuntu 12)

  9857   Fri Apr 25 23:08:57 2014 ranaSummaryIOOMC2_TRANS QPD Servo re-re-engaged again

We turned on the MC2_TRANS paths for both PIT/YAW tonight.

I turned off the BLP200 and turned on the RLP7 (RLP always are better than BLP). G_PIT = -0.111, G_YAW = 0.111. On Monday, let's let Steve look at the trends and determine if this centering servo is bad or good.

  9858   Sat Apr 26 13:19:59 2014 ericqSummaryIOOMC2_TRANS QPD Servo re-re-engaged again

Quote:

We turned on the MC2_TRANS paths for both PIT/YAW tonight.

I should've included this in my Thursday night ELOG... That evening, I aligned the mode cleaner with reasonable MC1/3 spot positions, and the MC2 spots very close to centered, and recentered the WFS and MC2 Trans QPDs. The mode cleaner held up very well over the course of that evening, even when actuating CARM on MC2 with WFS engaged (which previously wasn't very stable when the WFS weren't well aligned).

  9869   Mon Apr 28 15:47:57 2014 manasaSummaryIOOMC2_TRANS QPD Servo trend

Quote:

We turned on the MC2_TRANS paths for both PIT/YAW tonight.

I turned off the BLP200 and turned on the RLP7 (RLP always are better than BLP). G_PIT = -0.111, G_YAW = 0.111. On Monday, let's let Steve look at the trends and determine if this centering servo is bad or good.

The MC was showing slow but periodic alignment drifts and eventually unlocked around noon. I looked up the alignment trend (Attach: 2 day trend)

MC_TRANS_PIT_ERR and MC_TRANS_Y_ERR show that the MC_TRANS servo slowly drifted the IMC alignment causing it to lose lock from time to time (mostly in yaw).

To confirm that the drift was NOT due to off-centering in the MC2_TRANS QPD, I turned off the WFS servo, moved MC2 to recenter the trans beam on the QPD, and re-enabled WFS servo.

MC_TRANS path in WFS is still left enabled.

Attachment 1: MC_TRANSservoApr28.png
MC_TRANSservoApr28.png
  9871   Mon Apr 28 20:31:38 2014 ranaSummaryIOOMC2_TRANS QPD Servo trend

This is a 4-day trend. I don't see any difference here which is significant. My guess is that the MC_TRANS servo gain is so low that its not really doing anything.

I'll turn it on periodically this week and then on Monday people can look at the trend again to see if they can identify when the servo is ON and when its OFF.

Attachment 1: Untitled.png
Untitled.png
  9878   Wed Apr 30 11:16:41 2014 SteveUpdateIOOthis typical morning

c1sus and c1iscey were reset. The PMC needed to be locked. MC locked instantly.

The FSS ion pump power supply was turned on.

 

 

 

 

Attachment 1: 40days.png
40days.png
  9885   Wed Apr 30 21:31:25 2014 ranaHowToIOOMystery Alignment again

Looks like there was some mysterious MC alignment shift around 5:30 PM today, but no elog.....?? Now things are drifting much more than this morning or yesterday. Who did what and why???

I think I'll blame Jamie since he just got back and did some computer fiber voodoo today.

http://www.lawsome.net/no-throwing-rotten-tomatoes-a-repealed-kentucky-law/

  9886   Wed Apr 30 21:57:07 2014 ranaSummaryIOOMC2_TRANS QPD Servo now on for real

dolphin.pngMC2_QPD_trend.png

During a lull in Koji vs. The Arm, I switched on the MC2_TRANSQPD feedback path to check out its UGF. In the past months, when its been on, it has had a gain of ~0.03 - 0.1.

Today, I found that with the gain turned up to 11, it has a ~1 minute step response time (as you see in the above Strip chart). So its had a UGF of ~2 hours or so during the times when we thought it might be doing bad or good or magic.

I leave it on now to see if it behaves well over the next days. Let's see if Steve thinks its good or not based on his trend monitoring.

** also touched up the PMC pointing (using the PMC REFL image / please never align the beam into the PMC without this camera image)

  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.

  9901   Fri May 2 08:38:07 2014 SteveUpdateIOOthis typical morning

 

 c1sus needed reset.

Attachment 1: 2dTrend.png
2dTrend.png
  9907   Sun May 4 14:20:04 2014 ericqUpdateIOOPMC relocked

The PMC has been unlocked for ~23 hours. FSS slow was at ~-1.5 V. I zeroed it, and relocked the PMC, transmission is ~0.81V. MC with WFS came back fine.

  9981   Wed May 21 11:11:01 2014 manasaUpdateIOOMC tuned

I found MC unlocked this morning. I looked at the 2 day trend of the MC suspensions and found MC2 suspensions have been misaligned.

I used Rana's ezcaservo trick to recover MC lock. This brought the MC_REFL down to 0.7 counts. I did the rest of the alignment by moving the MC2 suspension sliders only. MC_REFL is down to 0.45-0.5 counts and TRANS_SUM is at ~16300.

Also, I found the WFS servo was left turned OFF. I re-enabled them as well.

Attachment 1: MC_SUS2days.png
MC_SUS2days.png
  9999   Wed May 28 14:13:06 2014 manasaUpdateIOOMC relocked

Quote:

MC wouldn't relock, it looked misaligned in pitch and yaw on MC camera.

I've touched the alignment, and gotten the reflection below 0.5, but it unlocks periodically, spot positions aren't great, and turning on WFS throws it out of alignment. ughhhhh


The IMC has not been happy since the weekend and were left with WFS disabled because of the bad alignment state that the MC has been left at.

I realigned the MC mirrors and brought down MC_REFL to 0.42 and MC_TRANS_SUM came up to ~ 17400 counts.

I measured the spot positions after alignment. MC1 and MC3 are slightly off in pitch :

spot positions in mm (MC1,2,3 pit MC1,2,3 yaw):
[2.0535418031770249, 0.84870716159663184, 1.9759940800847962, -1.6706240175650202, 0.089441353070240759, -1.0339963871771678]

I reset the WFS filterbank offsets and engaged the MCWFS servo. Atleast now the MC is not being thrown out of lock with WFS enabled. I have NOT touched the alignment to the WFS PDs.

  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.

  10038   Fri Jun 13 19:09:44 2014 KojiUpdateIOOA blown fuse found on the euro card crate at 1X2 (IOO) rack.

[Rana Zach Koji]

We tracked down the MC locking issue to be associated with the power supply problem.
Replacing a fuse which had incomplete connection with the new one, the MC started locking.

We still have the MC autolocker not running correctly. This is solely a software problem.


We went down to the IOO electronics rack to investigate the electronics there. After spending
some time to poking around the test points of the MC servo board, we noticed that the -24V
power indicator on the MC demodulator module was not lit. In fact, Steve mentioned on Wednesday
that the -24V Sorensen supply had lower current than nominal. This actually was a good catch
but should have been written in the ELOG!!!

We traced the power supply wires for the crate and found one of the three -24V supply has no
voltage on it. Inspection of the corresponding fuse revealed that it had a peculiar failure mode.
The blown LED was not lit. The connection was not reliable and the -24V power supply was flickering.

We then replaced the fuse.This simply solved all of the issues on the MC servo board. The electronics
should be throughly inspected if it still has the nominal performance or not, as the boards were exposed
to the single supply more than a week. But we decided to try locking ability first of all.

Yes, we now can lock the MC as usual.

Now the newly revealed issue is MC autolocker. It was running on op340m but op340m does not want to run it now.
It should be closely investigated.

Also turning on WFS unlocks the MC. Currently the WFS outputs are turned off.
We need usual align MC / check spot position / adjust WFS QPD spots combo.

  10039   Sat Jun 14 18:43:15 2014 ranaUpdateIOOMC Autolocker upgrades

 Somehow the caget/caput commands are really slow. I'm not sure if this is new behavior or not, but after changing values, it takes ~1-2 seconds to move on to the next command.

On op340m, once I ran autolockMCmain40m in the foreground, I could see that there were a lot of error messages that weren't being caught in the log file. On Solaris, the TDS and EZCA binaries work well, but the caget/pu stuff is missing a lot of the new flags and the new CDSUTILS python scripts are not there. So I decided to stop running on there and move over to running the MC autolocker on megatron. I also changes the mcup and mcdown scripts to BASH from CSH. There are still some PERL commands in there from Rob/Matt/Sam, so I also added the proper commands so that the pick up the scripts/general/perlmodules/ directory.

Yes, yes, I know. You would all feel warm in your tummy if we did everything in python because its the best language ever, but how about we lock the interferometer first and then we can rewrite all the last decades worth of scripts?

Looked at the trend from the last time the MCWFS were one (2 weeks ago!) and aligned the MC suspension back to that point. After that the WFS come on fine and MC looks good. I fixed the nameserver/DNS/fstab stuff on megatron, asia, and belladonna.

I've left AutoLockMC.csh (too painful to convert to BASH) running on megatron via an open terminal on pianosa. If it looks OK for the weekend, Q should move the crontab line from op340m over to megatron and then update the Wiki appropriately.

CDSUTILS is also gone from the path on all the workstations, so we need Jamie to tell us by ELOG how to set it up, or else we have to use ezcaread / ezcawrite forever.

  10042   Mon Jun 16 12:58:50 2014 manasaSummaryIOORingdown recap

A recap of the ringdown measurements made at the 40m in mid 2012, the hardware that was installed for the same and results from the measurements.

IMC ringdown:

Hardware installed 
A trans PD was installed (elog 7122).
This PD does not exist in the trans path anymore.

Measurements
The polarity in the MC servo was flipped with the MC WFS disabled and the PD trans signal was used to look at the cavity ringdown. 
Ringdown time = 13 us
Cavity finesse from the measurement = 453 (inconsistent with actual finesse). 

Attachment: Ringdown measurement and fits

PMC ringdown:

Hardware installed
The AOM was installed before the PMC. The AOM was driven by the driver installed on the PSL table. (RF power ~1.5W @ 80MHz @1.0V modulation input). An RF switch was installed to control the AOM driver input. ZASWA-2-50DR+ was installed.
Note: The AOM was used by the ISS crew after this. So the RF switch has been removed and the AOM is no more a part of the ringdown setup.

Measurements
No measurements were made as we could not obtain relevant TTL signals to control the switch remotely.

Attachment 1: Ringdown_815.pdf
Ringdown_815.pdf
Attachment 2: MCringdown_cum.pdf
MCringdown_cum.pdf
Attachment 3: cum_plot.png
cum_plot.png
  10043   Mon Jun 16 15:32:12 2014 ranaSummaryIOORingdown recap

 

To do this better:

1) Just step the analog input to the AOM (i.e. no RF switch) and measure the PMC trans output with a fast DC coupled PD. IMC should be unlocked and disable during this part. We want the PMC ringdown to be faster than 1 us.

2) Re-install a fast PD in the MC trans path without disrupting the existing MC trans QPD setup.

3) Measure IMC ringdown and fit the data to find the cavity losses.

4) Think about how to use the Isogai, et. al (2013) technique to better measure the losses, taking into account the mirror transmissions.

  10064   Wed Jun 18 21:37:11 2014 KojiUpdateIOOMC REFL investigation

[Jenne Koji]

We decided to check the situation of the REFL MC beam path.

- No resolution of the weird MC REFL DC increase
- The reflection from the PD was adjusted to hit the beam dump
- The MC WFS paths were aligned again


Detail:

We found that the reflected beam from the PD was hitting the mount of the beam dump.
So the entire MC REFL path was steered down such that the last steering mirror does not neet to steer the beam.
When the alignment was adjusted so that the reflection from PD hit the beam dump, the beam spot on the small mirror right before the PD
got a bit marginal but it seemed still OK after some tweak.

Then we looked at the reflection value. It is still about 6.5. No change.

As we messed up the entire MC REFL path, we aligned the MC WFS paths again.
This was done with the unlocked MC REFL beam. Once the cavity was locked,
it turned out that it was enough for the WFS too keep the MC locked.

  10066   Wed Jun 18 22:34:44 2014 ericqUpdateIOOcaget frusrtation

Quote:

 Somehow the caget/caput commands are really slow. I'm not sure if this is new behavior or not, but after changing values, it takes ~1-2 seconds to move on to the next command.

This is still happening. Specifically: on all of the control room computers, calls to caget display the result immediately, but then hang for five seconds (consistently five). We had also seen a situation where calls hang indefinitely on ottavia/pianosa, but a reboot "fixes" this.

Some observations:

  • Front end machines and the FB have proper caget/caput response times.
  • Control room machines have some odd ping behavior when targeting frontends/FB; namely the ping times themselves are ok, but each ping line takes quite some time to show up, which made us think that there is odd network routing issue happening with some network switch. 
  • Front ends and FB get epics from /opt/rtapps, whereas control room machines get epics from /ligo/apps, which has different contents. (Is this for Gentoo vs. Ubuntu? I don't really get why this is the case...). This means different environment setting scripts to be called, so maybe the control room machines are misconfigured in some way for the new name server?

I poked around the network settings on all of these machines, but everything seemed reasonable. Nothing was changed. Rossa and Pianosa have their network settings done through some Ubuntu GUI, but I don't know where the settings are written. I had expected their settings to be in /etc/network/interfaces; maybe we should change this to be consistent with other machines, and easier to administrate via the terminal. 

Despite all this, ezcaread is fine.

  10078   Fri Jun 20 09:46:49 2014 manasaUpdateIOOMC WFS servo turned ON

The IMC stayed locked last night, but with  a high REFL ~3.0. I found the WFS servo OFF; so went ahead and enabled it. (Did somebody disable it for reasons not elog'd?)

MC returned to a happy state. But the WFS offsets are quite large. So I tweaked the alignment and got MC REFL down to ~0.45 and MC TRANS SUM to ~16500 counts. MC WFS offsets also dropped significantly after this without any need to touch the alignment to the WFS PDs.

  10225   Thu Jul 17 01:24:35 2014 ranaUpdateIOOMC / EOM Stability Mystery Solved!

MC loop is near unstable. Common gain reduced. Needs more loop tuning.

We've often seen that the MC gets into a state where it keeps losing lock and the EOM drive shows a large RMS. We've usually been looking at the noise spectrum to diagnose this.

Tonight we finally just measured the OLG. The attached plot shows the loop gain measured with the 4395 on the MC servo board

Although the phase margin is a healthy 45 degrees, its close to instability at 1 MHz. For this plot, I reduced the gain by 3 dB and now the margin is ~7 dB. So usually its pretty close to unstable and at least its always making a noise peak.

That whole TF above a few hundred kHz is weird. We should tune out whatever makes it so flat and also remove the resonance that makes the 1 MHz peak; maybe its from some post mixer low pass?

Anyone interested in helping in the investigation ought to measure the TF of the MC demod board, the MC servo board, and the FSS box.

Silver lining: if we fix this loop shape, we might be able to have a much more stable IMC and IFO.

Attachment 1: MC_OLG.pdf
MC_OLG.pdf
  10235   Fri Jul 18 14:59:07 2014 EvanUpdateIOOMC servo TFs

[Rana, Evan]

This morning we took several TFs of the MC servo board using the HP4395A.

The 4395 source was teed, with one output of the tee going to 4395 R and the other output going to the board's IN1. We then took TFs of (4395 A) / (4395 R), where 4395 A was one of the following four points on the servo board:

  • OUT2
  • A TEST1
  • B TEST1
  • SERVO

For each of these points, we took a TF at two gain settings: IN1 and VCO gains both at 0 dB, and then IN1 and VCO gains both at 20 dB.

Before doing these measurements, we calibrated out the cable delay. Additionally, SERVO was always loaded with 50 Ω—either from the 4395 or from a terminator.

The attached png shows the servo board settings when these TFs were taken with the 0 dB gain settings. The settings for the 20 dB measurements are identical, except for the higher IN1 and VCO gains.

Attachment 1: mcServoTFSettings.png
mcServoTFSettings.png
Attachment 2: MCtfs.pdf
MCtfs.pdf
  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.

  10251   Tue Jul 22 08:36:08 2014 EvanUpdateIOOMC servo TFs

Quote:

[Rana, Evan]

This morning we took several TFs of the MC servo board using the HP4395A.

The 4395 source was teed, with one output of the tee going to 4395 R and the other output going to the board's IN1. We then took TFs of (4395 A) / (4395 R), where 4395 A was one of the following four points on the servo board:

  • OUT2
  • A TEST1
  • B TEST1
  • SERVO

For each of these points, we took a TF at two gain settings: IN1 and VCO gains both at 0 dB, and then IN1 and VCO gains both at 20 dB.

Before doing these measurements, we calibrated out the cable delay. Additionally, SERVO was always loaded with 50 Ω—either from the 4395 or from a terminator.

The attached png shows the servo board settings when these TFs were taken with the 0 dB gain settings. The settings for the 20 dB measurements are identical, except for the higher IN1 and VCO gains.

Using the modified schematic (40m:10250), I've made a plot of the TFs I expect for GIN1 = GVCO = 0 dB, taking into account our 50 Ω loading of the board.

Evidently I'm somehow missing a factor of 2 in the gain of the overall TF, but the shapes of the expected vs. measured magnitudes agree quite well.

At 1 MHz, I expect we should have accumulated about 80 degrees of phase going through the servo board. In reality, we appear to have lost more like 105 degrees.

Attachment 1: MCtfExpectations.pdf
MCtfExpectations.pdf
  10303   Thu Jul 31 09:14:14 2014 ericqUpdateIOOMC stability

 Last night, I poked around to try and see if I could reproduce the sketchy MC behavior by exciting MC2 in a way that may be similar to what we do when using it as a CARM actuator. 

The short of it is that at frequencies under 1k, the MC lock didn't mind MC2 position excitations up to 8000 counts. However around 4-5k, a 1000 count excitation would induce a good deal of low frequency (2-5Hz) activity in the MC trans power, causing it to fluctuate by thousands of counts before unlocking. If I turned the excitation off before the unlock, it would eventually settle back down, but not immediately. 

I was able to reproduce this a handful of times before it decided to stop locking altogether, perhaps because of its random mood swings, or perhaps because this kind of disturbance is related to the mood swings...

  10310   Thu Jul 31 19:37:59 2014 KojiUpdateIOOSuccessful modification of the FSS

Quick note:

Migration of the 10Hz pole from the output stage of the FSS to the pomona box was successful.
This also allowed me to insert my offsetting/summing point circuit.

Trial 1:

- Remove C63 (1uF cap) of the FSS

- Short 500 Ohm in the pomona box

This removed 10Hz pole in FSS and 32 Hz zero in the pomona box.
In total we obtain the gain and range of 3.2 for the fast PZT path.

3x10^2 to 3x10^3 times more filtering of the HV amp noise between 10kHz and 100kHz.

The current maximum gains of the FSS is

Overall +19dB (prev. +13dB)
Fast     +30dB (prev +21.5dB)

Trial 2:

- Insert a summing amplifier between the FSS box and the HV amp.

- This amplifier attenuate the input by a factor of 2, and add 5V. i.e. +/-10V input => 0~10V output.

- This just worked fine.

Trial 3:

- Now the fast gain is nominally +30dB.

- In order to provide more room to play with the fast-PC cross over, I moved the pole freq from 2.9Hz to 9.9Hz
  This was done by replacing a 5kOhm in the pomona box by a 1.5kOhm.

Trial 4:

- I just noticed that the output impedance of the FSS (15.8kOhm) and the input impedance of the summing amp (10k Ohm)
  interfere and gives additional 1/2.58 attenuation in addition to the attenuation in the summing amplifier.
  This yields the output range of the HV amp between 45-105V, instead of 0-150V. This is not nice.

- The output impedance of the FSS box (R46 15.8kOhm) was replaced with 100Ohm.

- Now the PMC unlocks very frequently. This might have come from the PMC locking issue or too much gain of the IMC

Trial 5 (final):

- I suspected that the PMC unlock is caused by too much actuation at the high freq. So I decided to revert the  pomona box change

  10314   Thu Jul 31 23:43:00 2014 KojiUpdateIOOModulation frequency adjustment

The main IFO modulation frequency was adjusted to match with the FSR of the IMC.

The new frequency is 11.066128 MHz. This corresponds to the IMC round-trip length of 27.0910 m

This has been done by looking at the peak at 25.845MHz (5* fmod - 29.5MHz) in the MC REFL PD mon.

ELOG V3.1.3-