40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 180 of 344  Not logged in ELOG logo
ID Date Author Type Categoryup Subject
  7202   Thu Aug 16 05:08:38 2012 YoichiUpdateIOOMC Servo Transfer Function Measurements

Quote:

 Also the MC board includes many generic filter stages to customize the frequency response. I will open the MC board box to examine what is actually implemented on the board. 

 I took out the MC board. Unfortunately, most of the components are surface mounted. So the values of the capacitors are not legible.

I will try my best to guess what is implemented on the board.

Attachment 1: MCBoard1.JPG
MCBoard1.JPG
Attachment 2: MCBoard2.JPG
MCBoard2.JPG
  7205   Thu Aug 16 16:44:55 2012 ManasaConfigurationIOOPD from AP table removed

Quote:

The PD (pda255) at the AP table, close to the MC refl , which Steve mentioned to be not in use, has been removed from the table for testing.

 The PD installed at MC trans to make ringdown measurements has been replaced with the above PDA255. 

  7206   Thu Aug 16 17:28:51 2012 ManasaConfigurationIOOMC trans optics configured

Quote:

Quote:

Quote:

Quote:

Quote:

  The PDA255 is a good ringdown detector - Steve can find one in the 40m if you ask him nicely.

 We found a PDA255 but it doesn't seem to work. I am not sure if that is one you are mentioning...but I'll ask Steve tomorrow!

 I double checked the PDA255 found at the 40m and it is broken/bad. Also there was no success hunting PDs at Bridge. So the MC trans is still in the same configuration. Nothing has changed. I'll try doing ringdown measurements with PDA400 today.

Can you explain more what "broken/bad" means?  Is there no signal?  Is it noisy?  Glitch?  etc.

 The PD saturates the oscilloscope just by switching on the power; with no real signal at all. But Steve helped locating a PD that is not being used at the AP table. So I will check it and replace the current one if it works!

Koji opened up the PD and found that the screw connecting the PD to the pole was doing an additional job as well; connecting the power cable to the PD output in the inside. The PD is now fixed! Yippie...we have two PDA255 s at 40m now!!

  7239   Tue Aug 21 00:35:25 2012 ranaSummaryIOOVisibilities and Chrome

MC and PMC vis:

MC REFL Unlocked    = 4.4

MC REFL Locked      = 0.67

 1 - Locked/Unlocked = 85%

 

PMC REFL Unlocked   = 0.270

PMC REFL Locked     = 0.013

 1 - Locked/Unlocked = 95%

I checked (by looking through recent trends) that the zero level is zero on both channels. I tried to do a proper mode scan, but we have lost the PSL fast channels during the upgrade sadly. Also, the DC signal for the PMC REFL needs some gain. Unlocked level should be more like 3-5 V.

Also used the instructions from this page to add Google's sources to rosalba's apt-get list and then installed Chrome.

Attachment 1: Untitled.pdf
Untitled.pdf
  7263   Thu Aug 23 22:21:13 2012 ranaConfigurationIOOMCL turned back on

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: mcl-screen.png
mcl-screen.png
Attachment 2: mcf-noise.pdf
mcf-noise.pdf
  7264   Thu Aug 23 22:41:04 2012 KojiUpdateIOOMC Autolocker update

[Koji Rana]

MC Autolocker was updated. (i.e. mcup and mcdown were updated)

mcup:

  • Turn on the MCL input and output switches
  • Change the MCL gain from 0 to -300 with nominal ramp time of 5sec
  • Turn on FM2, FM5, MF7 after a sleep of 5sec. Note: FM1 FM8 FM9 are always on.
  • Set the offset of 42 counts
  • Turn on the offset

# Turn on MCL servo loop
echo mcup: Turning on MCL servo loop...
date
ezcaswitch C1:SUS-MC2_MCL INPUT OUTPUT ON
ezcawrite C1:SUS-MC2_MCL_GAIN -300
sleep 5
ezcaswitch C1:SUS-MC2_MCL FM2 FM5 FM7 ON
# Offset to take off the ADC offset of MC_F
ezcawrite C1:SUS-MC2_MCL_OFFSET 42
ezcaswitch C1:SUS-MC2_MCL OFFSET ON


This offset of 42 count is applied in order to compensate the ADC offset of MC_F channel.
The MCL servo squishes the MC_F signal. i.e. The DC component of MC_F goes to zero.
However, if the ADC of MC_F has an offset, the actual analog MC_F signal, which is fed to FSS BOX,
still keep some offset. This analog offset causes deviation from the operating point of the FSS (i.e. 5V).

mcdown:

  • Basically the revese process of mcup.
  • This script keeps FM1 FM8 FM9 turned on.

# Turn off MCL servo loop
echo mcdown: Turning off MCL servo loop...
date
ezcawrite C1:SUS-MC2_MCL_GAIN 0
ezcaswitch C1:SUS-MC2_MCL INPUT OUTPUT OFFSET FMALL OFF FM1 FM8 FM9 ON
# Remove Offset to take off the ADC offset of MC_F
ezcawrite C1:SUS-MC2_MCL_OFFSET 0

  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
10hrsMC2.png
  7275   Fri Aug 24 22:01:15 2012 JenneUpdateIOOMC spot position - close

I am getting closer with the MC spot centering.  I had everything but MC1 really great, but then I tweaked MC1's pointing, and things all went to hell. 

I have to go home to let Butter out, but I'll be back tomorrow, and I'll try to get back to where I was in the 2nd to last measurement in the plot below.

I recenterd the WFS after moving the input beam, so that the beam was hitting the WFS at all.

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

  7277   Sun Aug 26 12:26:44 2012 JenneUpdateIOOMC spot position - not done yet

Quote:

I am getting closer with the MC spot centering.  I had everything but MC1 really great, but then I tweaked MC1's pointing, and things all went to hell. 

I have to go home to let Butter out, but I'll be back tomorrow, and I'll try to get back to where I was in the 2nd to last measurement in the plot below.

I recenterd the WFS after moving the input beam, so that the beam was hitting the WFS at all.

 We are being riddled with earthquakes.  Brawley, CA (~150 miles from here) has had 9 earthquakes in the last hour, and they're getting bigger (the last 4 have been 4-point-somethings).  I may try to come back later, but right now the MC won't stay locked for the ~5 minutes it takes to measure spot positions.  Koji and Jamie said they were coming in today, so they can call me if they want help.

  7280   Mon Aug 27 01:05:36 2012 JenneUpdateIOOMC spot position - callin' it quits
spot positions in mm (MC1,2,3 pit MC1,2,3 yaw):
[-0.98675603448324423, -0.94064212026141558, 2.6749179375892544, -0.65896393156684185, -0.4508281650731974, -0.55109088188064204]

MC3 pitch isn't what I'd like it to be, but MC1 and MC3 pitch aren't quite acting in relation to each other how I'd expect. Sometimes they move in common, sometimes differentially, which is confusing since I have only ever been touching (on the PSL table) the last steering mirror before the beam is launched into the vacuum.

The latest few measurements have all been with the WFS off, but reflection of ~0.48 . I haven't figured out why yet, but MC1 and MC3 yaw WFS outputs start to escalate shortly after the WFS becoming engaged, and they keep knocking the MC out of lock, so I'm leaving them off for now, to be investigated in the morning.
Attachment 1: MCdecenter_26Aug2012.png
MCdecenter_26Aug2012.png
  7284   Mon Aug 27 12:03:54 2012 KojiUpdateIOOMC spot position - callin' it quits

The MC REFL path was checked. ==> Some clippings were fixed. MC WFS is working now.

- MC was aligned manually

- The steering mirror for the WFS and camera was clipping the beam. => FIxed

- The WFS spots were realigned.

- There was small clipping on the MC REFL RFPD. ==> Fixed

  7288   Mon Aug 27 18:32:48 2012 JenneUpdateIOOMC spot position - Jenne is stupid

Quote:

The MC REFL path was checked. ==> Some clippings were fixed. MC WFS is working now.

- MC was aligned manually

- The steering mirror for the WFS and camera was clipping the beam. => FIxed

- The WFS spots were realigned.

- There was small clipping on the MC REFL RFPD. ==> Fixed

 We have figured out that some of these measurements, those with the WFS off, were also not allowing the dither lines through, so no dither, so no actual measurement.

Jamie is fixing up the model so we can force the WFS to stay off, but allow the dither lines to go through.  He'll elog things later.

  7289   Mon Aug 27 18:59:24 2012 jamieUpdateIOOMC ASC screen was confusing - Jenne is not stupid

Quote:

We have figured out that some of these measurements, those with the WFS off, were also not allowing the dither lines through, so no dither, so no actual measurement.

Jamie is fixing up the model so we can force the WFS to stay off, but allow the dither lines to go through.  He'll elog things later.

In the c1ioo model there were filter modules at the output of the WFS output matrix, right before going to the MC SUS ASCs but right after the dither line inputs, that were not exposed in the C1IOO_WFS_OVERVIEW screen (bad!).  I switched the order of these modules and the dither sums, so these output filters are now before the dither inputs.  This will allow us to turn off all the WFS feedback while still allowing the dither lines.

I updated the medm screens as well (see attached images).

Attachment 1: Screenshot-1.png
Screenshot-1.png
Attachment 2: Screenshot-2.png
Screenshot-2.png
  7290   Mon Aug 27 23:52:59 2012 JenneUpdateIOOMC Spots centered

Finally!

Jamie and I have the MC spots centered.  We did the normal move the input beam, realign jazz for a while, then when we got close, used the "move MC2 spot" scripts to get the MC2 spot back to ~center.

This was way easier when the measurements were real, and not just noise.  Funny that.

The dark blue spot is the farthest from 0 in pitch, and it is 1.04mm.  The cyan and yellow we've done a pretty good job of getting them equally far from zero.  Since we aren't translating the beam, we can't get better than the point at which the cyan and yellow curves cross.

Attachment 1: MCdecenter_26Aug2012.png
MCdecenter_26Aug2012.png
  7312   Wed Aug 29 20:43:23 2012 KojiUpdateIOOSetup for a cavity scan or the input mode cleaner

The technique is based on detection of the beating between the resonant carrier and a resonant higher order mode.
This means that the beat signal is cancelled out if the transmitted beam is integrated over the entire beam.
Thus, you may want to introduce intentional clipping (or cutting a half of the beam with a razor blade). 

Ref: LIGO DCC G080467: Precise Measurements on Longitudinal and Transverse Mode Spacings of an Optical Cavity using an Auxiliary Laser

I am quite curious on the measurement as I am going to do the same measurement for the aLIGO OMC.
I am interested in seeing the statistical evaluation on the precision of the measurement.

  7313   Wed Aug 29 21:02:45 2012 JenneUpdateIOOOptics between Faraday and PRM are centered, realigned

[Jenne, Suresh, with support from Jamie and Koji]

MC spots measured, MC1, MC3 no change.

No clipping going through Faraday.

Beam hitting to the right of center of PZT1.  It was translated sideways so we are now hitting it on the center.  Knobs adjusted so we hit center of MMT1.

Beam totally obscured by Faraday on the way to MMT2.  MMT2 moved north, so that we clear the Faraday by more than a beam diameter.  MMT1 knobs adjusted to hit center of MMT2.

MMT2 knobs adjusted to hit center of PZT2.

PZT2 didn't have enough range with knobs, so we loosened it, pointed then adjusted with knobs so we're hitting center of PRM. 

We need to check spot centering on PRM with camera tomorrow.

Suresh checked that we're not clipped by IP ANG/POS pickoff mirrors, but we haven't done any alignment of IP ANG/POS.

 

Tomorrow:  Open ITMX door.  Check with Watek that we're hitting center of PRM.  Then look to see if we're hitting center of PR2.  Then, continue through the chain of optics.

  7320   Thu Aug 30 18:01:05 2012 ElliUpdateIOOSetting up Input MC cavity scan measurement

Riju, Elli

Today tried to take our first cavity scan.  We unplugged the 55MHz sideband input from the RF combiner on the PSL table, and connected a network analyser instead.  Using the network analyzer we injected a 12dBm signal (swept from 32MHz to 45MHz) through the RF combiner into the EOM to create our swept sidebands.  We measured the  MC cavity response by looking at the signal comming out of the RF photodiode on the MC2 table.  I replaced the BNC cable connected to the RF PD with a longer BNC cable that could reach our network analyzer next to the PSL table.  Riju will post a diagram of our setup.

We didn't see the expected carrier resonances when we performed a cavity scan.  The light incident on the RF PD is around 0.7micro Watts and we are still thinking about whether this is strong enough to see our signal above the noise.  We also want to work out what the strength of our swept sidebands is.  We will attempt to do a 'real' cavity scan tomorrow.

 

  7323   Thu Aug 30 20:31:35 2012 JenneUpdateIOOPZT1 and PZT2 set to center of their ranges

[Koji, Jenne]

Jamie and Koji pointed out that we need to be doing the in-vac alignment with the PZTs at the center of their ranges.  Also, we confirmed that they were set to "closed loop off", so the strain gauges were not supplying any feedback.

PZT1 was set to 0 for both pitch and yaw, since it has a very limited range of motion right now, so 0 is close enough.

For PZT2, Koji and I moved the slider in pitch and yaw, and watched the LCD output monitor on the PZT driver at the bottom of 1Y3.  We saw the value on the LCD change between slider values +4 to -6 for PZT2 yaw, so it is set to -1 as the center.  We saw the value on the LCD change between slider values -4 to +5 for PZT2 pitch, so it is set to +0.5 as the center.   Beyond these slider values (the sliders all go -10 to +10), the LCD value didn't change, either at 0, or at the maximum. 

Since PZT1 doesn't really move, this shouldn't affect any of the alignment work that Suresh and I did last night, although we should quickly confirm tomorrow. On the agenda for tomorrow is adjusting PZT2 such that we hit the center of PR2 (and hopefully that will also put us through the center of the PRM target, if the alignment was done well enough last time), so it's okay that we have only now set it to the center of its range.

  7328   Fri Aug 31 13:22:29 2012 ElliUpdateIOOCorrecting improper termination of the 55MHz input to the EOM

Koji, Riju, Elli

This morning Koji discovered that the 55MHz input into the RF combiner that I disconnected yesterday wasn't terminated properly, so it was reflecting power back into the amplifier in the signal generation unit.    We turned off the signal generation unit and checked that the amplifier was still working properly- it was.  A 50 ohm terminator was attached to the end of the 55MHz cable so that it is now terminated properly.

When we tried to turn the signal generator box back on we discovered the switch is broken (the box will only stay on while you hold down the on switch) and will need to be replaced.  In order to create the 29.5MHz sidebands to lock the mode cleaner, we bypassed the signal generation unit which won't stay on (unplugging '29.5 MHZ out' cable from the frequency generation unit), and instead sent a 0.39V 29.5MHz signal from a function generatior into 'RF input' on the 'RF AM Stabiliser' board.

We also increased the power coming exiting the PSL table and going into the cavity from 11 microwatts to 20 microwatts by adjusting the polariser at the end of the table slightly.  The power has been set to 20 microwatts using the polariser a few days ago but had drifted down since then.

  7332   Fri Aug 31 18:32:47 2012 KojiUpdateIOOCorrecting improper termination of the 55MHz input to the EOM

 

The power switch of the frequency source was mechanically broken. I replace it with the spare in Kiwamu's treasure box.
I think this replaced new one also had the same problem before, we basically have to find an alternative switch.
The problem is too much friction between the metal housing and the plastic button. I have lubricated the button with
bicycle oil.

I have checked that the 55MHz output still have the output of 25dBm after a 5m BNC cable. (nominal: 27dBm)

I could not test it with the MC as the chambers have already been closed with the light doors.

  7349   Thu Sep 6 13:07:02 2012 JenneUpdateIOOIPANG no longer a reference :(

I was having trouble centering IPANG using the PZTs, and I suspected something funny was going on at the end.  I went down there, and the beam was focused right on the PD, and the spot was very very small.  I think this means that when I was trying to center the beam, I was falling into the gap between the pieces of the diode.  Also, as Koji pointed out to me the other day, if the PD is at the focal point of the beam, any parallel rays hitting the lens just before the PD will all go to the same place, no matter how the input beam has moved.  This means we're not getting as much info out as we'd like.

So.  I moved the lens a little bit farther from the PD such that we are just beyond the focal point of the beam.  The beam size is now ~1mm on the QPD.

This means, however, that I moved the beam on the QPD such that IPANG is no longer a reference of the input pointing. Ooops. I think this adjustment needed to be done though.  Right now, the PZTs are set to where we had them yesterday, when we moved them slightly to center the IPANG QPD, and I've recentered IPANG.

  7407   Wed Sep 19 09:24:01 2012 SteveOmnistructureIOOaccess connector at athmoshere

Quote:

Quote:

We really need something better to replace the access connector when we're at air.  This tin foil tunnel crap is dumb.  We can't do any locking in the evening after we've put on the light doors.  We need something that we can put in place of the access connector that allows us access to the OMC and IOO tables, while still allowing IMC locking, and can be left in place at night.

 It is in the shop. It will be ready for the next vent. Koji's dream comes through.

 24" diameter clear acetate access connector is in place. The 0.01" thick plastic is wrapped around twice to insure air and bug tight barrier for the MC to lock overnight. The acetate transmission for 1064 nm is 90 % This was measured at 150 mW   2.5 mm beam size.

 

Attachment 1: IMG_1641.JPG
IMG_1641.JPG
Attachment 2: IMG_1642.JPG
IMG_1642.JPG
Attachment 3: acetateAC.png
acetateAC.png
  7410   Wed Sep 19 13:12:48 2012 JenneUpdateIOOPower into vacuum increased to 75mW

The power buildup in the MC is ~400, so 100mW of incident power would give about 40W circulating in the mode cleaner.

Rana points out that the ATF had a 35W beam running around the table in air, with a much smaller spot size than our MC has, so 40W should be totally fine in terms of coating damage.

I have therefore increased the power into the vacuum envelope to ~75mW.  The MC REFL PD should be totally fine up to ~100mW, so 75mW is plenty low.  The MC transmission is now a little over 1000 counts.  I have changed the low power mcup script to not bring the VCO gain all the way up to 31dB anymore.  Now it seems happy with a VCO gain of 15dB (which is the same as normal power).

  7439   Tue Sep 25 22:40:55 2012 JenneUpdateIOOIPANG ND filter installed

[Jenne, Evan Hall]

Both IPPOS and IPANG beams are (after turning on the input and output PZTs) hitting their QPDs.  However IPANG was saturating.  We went down to take a look, and we had ~2.8mW incident on the QPD.  There was an ND filter sitting unmounted, next to the diode, and an empty fork directly in front of the diode.  Since IPPOS also has an ND filter in front, we stuck this ND filter back in.  Now we are no longer saturating.

We're not hitting (yet) the center of these 2 PDs, but we're at least hitting the diodes, so it shouldn't be too hard to steer the input PZTs.

Whomever took away this ND filter without elogging it was BAD!!!  (Jamie, when we first found IPANG coming out of the vacuum during this vent, we moved some of the mirrors on the out-of-vac table in the IPANG path.  Was the ND filter removed at that time?  Or has it been out for much longer, and we never noticed because IPANG wasn't coming nicely out of the vacuum / was clipping on the oplev lens?)

  7440   Wed Sep 26 01:10:34 2012 JenneUpdateIOOPZT2 not working?!?! MC back to normal

[Jenne, Evan, Den]

MC REFL beam is back on the PD, and the mode cleaner locks.  It looks like we're a little high on the MC Refl camera, but the MC spots were measured, and don't look like they changed from Friday (or maybe Monday?), the last time they were measured. We took this to be acceptable MC alignment, and did not touch the PSL table's pointing.

The laser power reduction optics were removed, and placed out of the way on the PSL table (where do they belong?).  PSL-POS and PSL-ANG aren't quite perfectly centered, but a beam dump had been in the way of that path, so I don't know if they drifted bad, or if it was a sudden thing.  The beam is still hitting the QPDs though.  After removing the beam power reducing optics, we recentered the MC REFL beam on the REFL PD, still not touching any PSL alignment.  MC mirrors were aligned (Den did this work while I showed Evan around, so I don't know by how much), and MC Trans was maximized (really MC Refl was minimized, making sure that the unlocked MC Refl was the usual 4.something units on the EPICS readback.

We turned on the PZT high voltage supplies for the output steering PZTs and for the input steering PZTs.  We left the OMC locking PZT supplies off, since we're still not using the OMC.  Sadly, the beam coming out of the AS port looks clipped somewhere.  [SELF: attach the videocapture shot when you get to work tomorrow] We tried moving PZT2's sliders, but nothing happened!!! I can move BS and the ITMs to get the beam mostly unclipped, but I really need to be able to move the PZTs, or at least one of them.  IPPOS and IPANG beams are hitting the QPDs (although they're not centered perfectly), so the PZTs came back mostly to the same positions, but not exactly.  Evan and I sat next to the input steering PZT controllers in 1Y3, and moved the sliders around.  For most of the range, nothing changes on the LCD screen for either PZT2 pitch or yaw.  Yaw can make 2 small steps near the far negative side of the slider, but nothing happens for most of the slider.  Pitch really doesn't do anything for any part of the slider.  We ensured that the LED labeled "CL ON" was not illuminated, next to the button labeled "closed loop", for all 4 controllers (PZT1 and 2, pitch and yaw).  Sad!!   I don't know if the LCD screen on the front panel of the PZT controllers is a readback of signal supplied to the PZTs, or of the strain gauges.  I really hope it's the controller that's not working, rather than the PZTs themselves.  The PZTs were fine before we vented, and Koji and I did our centering of the PZT range check during the vent, so they were fine then.  What happened???  All PZT high voltage supplies were off during the pump-down.  I turned them off yesterday, and Evan and I turned them back on tonight around 9:30pm or 10pm.  What else could make them bad?

Without being able to move PZT2, just using BS and / or ITMs, I was unable to completely make the beam look nice on the AS camera.  I came close, but it still seems a little bit funny, and I had to move the suspended optics quite a bit to find that place.  This is not good. 

  7442   Wed Sep 26 16:59:30 2012 jamieUpdateIOOIPANG ND filter installed

Quote:

[Whomever took away this ND filter without elogging it was BAD!!!  (Jamie, when we first found IPANG coming out of the vacuum during this vent, we moved some of the mirrors on the out-of-vac table in the IPANG path.  Was the ND filter removed at that time?  Or has it been out for much longer, and we never noticed because IPANG wasn't coming nicely out of the vacuum / was clipping on the oplev lens?)

I do not remember removing anything from that setup.  We just moved some mirrors and lenses around

  7444   Wed Sep 26 23:55:14 2012 JenneUpdateIOOWFS centered

Since the MC spots are good, I put the beam back on WFS 1 and WFS 2.

Also, I changed the indicators on the LockMC screen to reflect the change in elog 7289, where we added another on/off switch for the WFS so that the ASS could be on, but the WFS off.  For the last month, the WFS could be disabled, but the MC screen's indicators would suggest that we were pushing very significantly on all 3 MC mirrors.  Now the MC screen reflects reality a little better.

I also uncommented the WFS lines in the mcup script.  Den had commented them out, but didn't elog about it!  C'mon Den, please elog stuff!!!!  (He confessed out loud the other day, but it still wasn't in the elog).

I'm leaving the WFS loops disabled (even though the MC autolocker tries to turn them on, I have them manually disabled using the extra on/off switch) since they're unstable.  I'm in the process of figuring out what's wrong.  So far, the WFS improve the MC alignment for a minute or two, and then they totally misalign the MC.  This is a work in progress.

  7452   Fri Sep 28 21:17:41 2012 KojiUpdateIOOMC WFS adjustment

MC WFS was fixed. Now it is running constantly with the autolocker.

Found a bug in the IOO screen: All of the 6 WFS signal indicators is liked to the same info (C1:IOO-MC1_PIT_OUTPUT).
Fix this, Jenne! Baaaaagghhhhh! 


What I did:

1. C1:IOO-MC_RFPD_DCMON indicator was saturating. "HOPR" of this entry was  set to 5 by running the following command:

ezcawrite C1:IOO-MC_RFPD_DCMON.HOPR 5

2. Scan MC2 spot position by using /opt/rtcds/caltech/c1/scripts/MC/moveMC2 scripts.
or the adjustment, C1:SUS-MC2_ASCPIT_EXC and C1:SUS-MC2_ASCYAW_EXC were excited with 300cnt at 12Hz and 10Hz, respectively.
The corresponding peaks (i.e. ANgle to length coupling) in C1:IOO-MC_F were monitored on DTT and adjusted so that the peaks are approximately nulled.

3. moveMC2 scripts are not perect to keep the maximum of the transmission. So, the alignment was adjusted with MC1 and MC3.

4. Repeated 2 and 3 until the alignment converges.

5. Once I got satisfied with the MC2 spot position, I went to the MC2 table and aligned the steering mirror before the QPD.

6. As these actions above moves the REFL beam, I went to the MC REFL path and adjusted the MC REFL PD position and the MC WFS spot positions.

7. Checked if the alignment is still good. The MC REFL is 0.50~0.51. Pretty good.

8. Run /opt/rtcds/caltech/c1/scripts/MC/WFS/WFS_FilterBank_offsets to register the current WFS offset etc.

9. At this point, MC WFS started working fine. I also confirmed the autolocker worked with this setting.

--------

Checked how the things are going in the morning. There were several unlocks. But the autolocker and WFS kept the cavity lcoked again.
Very good.

Some power fluctuation of ~1% is observed in the MC trans. I checked the PMC trans and found it is also fluctuating by 1% in a coherent way.
So I judge the WFS itself is fine. (See attached)

 

 

Attachment 1: MC_WFS_12h.png
MC_WFS_12h.png
  7455   Mon Oct 1 11:08:25 2012 JenneUpdateIOOMC WFS adjustment

Quote:

Found a bug in the IOO screen: All of the 6 WFS signal indicators is liked to the same info (C1:IOO-MC1_PIT_OUTPUT).
Fix this, Jenne! Baaaaagghhhhh! 

 My bad.  As it turns out, you can't copy and paste between MEDM instances.  It is now fixed.

  7456   Mon Oct 1 13:11:43 2012 JenneUpdateIOOPZT inspection elogs

I'll come back to the PZTs later, but I want to write down all the elogs I have found so far that look relevant.

http://nodus.ligo.caltech.edu:8080/40m/699

http://nodus.ligo.caltech.edu:8080/40m/5368

nodus.ligo.caltech.edu:8080/40m/5431

  7462   Tue Oct 2 14:20:33 2012 ManasaConfigurationIOOPDA255 not working

The PDA255 that Koji repaired is still not alright. It seems to be saturating again. I've left it in the PD cabinet where it is marked 'PDA 255'. I've asked Steve to order a fast PD at 150MHz, PDA10A because we don't seem to have any at the 40m.

  7463   Tue Oct 2 15:14:54 2012 jenne, jamieUpdateIOOPZT diagnosis

pzt2 mod signals matched slider vals for both pitch and yaw

  pzt2 yaw mon output = 6
  pzt2 pitch mon output = 11.3

From the PZT connector-converter board we determined the following pin-outs:

  X=Yaw:  red=1, white=14, black=3 
  Y=Pitch:  red=2, white=15, black=16

We believe that red is signal, white/black/shield are all ground.  We also believe (although this is from the PMC PZT) that the expected capacitance of the PZTs should be in the 100's of nF range.

Here are the readings from the two PZT dsub connectors:

  pin 1:14   PZT1 = ".003" on 2uF scale
             PZT2 = ".184"
   
  pin 2:15   PZT1 = ".002" on 2uF scale
             PZT2 = ".202"

So we think this means (given this crappy capacitance meter) that PZT2 is showing roughly 200nF, which sounds ok, but that PZT1 is indeed bad.

So next we investigate the PZT2 driver.

 
  7465   Tue Oct 2 16:32:43 2012 JenneUpdateIOOPZT diagnosis

[Koji, Jenne]

Jamie and I pulled the whole PZT driver for both PZT1 and PZT2. 

Koji and I found that each HV power supply (the left-most module) has 2 fuses.  Both HV supplies (PZT1 and PZT2) have one blown fuse.  The "T2L250A" measures low resistance for both HV supplies, but the "T250mAL250V" measures Open for both HV supplies.

I have ordered 10 pieces of each kind of fuse, Next Day shipping, from DigiKey.

  7469   Wed Oct 3 15:58:57 2012 SteveConfigurationIOOSOS coil drivers moved

The SOS coil drivers (Atm2) were moved from 1X1 to 1Y2 location. Is this the best place to locate the  IOO Tip-Tilt steering that will replace the PJ-PZT ?

See 40m wiki T-T

Attachment 1: SOScoildriversTT.jpg
SOScoildriversTT.jpg
Attachment 2: IMG_1680.JPG
IMG_1680.JPG
  7472   Wed Oct 3 18:45:51 2012 jamieUpdateIOOwiki page for active IO tip-tilts

I made a wiki page for the active IO tip-tilts.  I should have made this a long time ago.

  7475   Thu Oct 4 01:06:52 2012 JenneUpdateIOOPZT diagnosis

[Koji, Jenne]

We naively hoped that just replacing the fuses would fix the problem with the PZT HV drivers.  Alas, this was not the case. 

All of our investigations (other than visual inspections) today have been of the PZT2 module.  We have not applied any electricity to any PZT1 components/modules today.

After blowing a few more fuses (not good, we know, but we really didn't know what was going on at the time and were convinced that our changes between fuse installations should prevent fuse-blowing, including removing all modules except the HV driver), we found that the YAW driver for both PZT1 and PZT2 has severe discoloration on the PCB, and several resistors and other solder joints are damaged near some high voltage regulators. Pitch on PZT1 looks a tiny bit discolored, but doesn't look totally cooked like the 2 YAW modules do.  So, at least PZT1's Yaw was cooked before we started replacing fuses, since we haven't plugged it in yet today.

We then began some more methodical checks:

We bypassed the fuses by applying 10 Vpp = ~7.2 Vrms to the input side of the big transformer on the PZT2 HV driver board.  (This usually sees the 120 Vrms from the wall AC, so we were looking at things with a factor ~16 attenuation from what they normally see.)  We then measured things on the other side of the transformer, and made sure that they made some sense (one path for 5V stuff, one path for 15V stuff, one path for 180V stuff).  One of the rectifying diode bridges (the one for HV) didn't seem to be working, and didn't seem to have all of its pins connected, as if perhaps one or more diodes inside was destroyed.

When I went home for dinner, Koji continued looking at the low voltage supply capability of the PZT2 driver.  He removed the diode bridge from the HV path, and also removed the FET that lives on the output side of the HV driver board.  He was then able to energize the HV driver and the non-burnt pitch module.  So the +\-5 V and +\-15 V paths have been confirmed okay for PZT2's driver stuff.

What I will do tomorrow (when there is someone here to rescue me if I crispy-fry myself) is solder a wire to the now open pin of the backplane connector on the HV driver board, so that we can supply an external 180V to the pitch / yaw modules (although, obviously we won't be using the burnt yaw modules as-is).  Tomorrow I'll start by applying a nice small voltage, check that things still look okay, no shorts, and then I'll slowly increase the voltage until I get to the nominal 180V.

Since the low voltage stuff on the driver board is working, once we supply an external 180V (if successful), we should be able to re-install the PZT driver and drive PZT2. 

Since both Yaw modules that we have are burnt, I am proposing that we use the PZT2 HV board (which has been checked and modified this evening) with the 2 pitch modules.  Since we are not actively utilizing the strain gauge sensors, the fact that the calibrations on these modules are not exactly the same (rather, that PZT1's pitch is not the same as PZT2's yaw) should not matter at all.  This means that we will not be able to energize PZT1 at all, but that shouldn't be a problem.  Even when PZT 2 was working, PZT1 had very, very, very limited motion through the full range of applied voltage, so having no driver connected shouldn't have an impact.

 

  7504   Mon Oct 8 14:19:17 2012 JenneUpdateIOOPZT diagnosis - not fixed yet

Quote:

What I will do tomorrow (when there is someone here to rescue me if I crispy-fry myself) is solder a wire to the now open pin of the backplane connector on the HV driver board, so that we can supply an external 180V to the pitch / yaw modules (although, obviously we won't be using the burnt yaw modules as-is).  Tomorrow I'll start by applying a nice small voltage, check that things still look okay, no shorts, and then I'll slowly increase the voltage until I get to the nominal 180V.

 I connected a thick wire to pin 22 of the backplane connector of the transformer / power supply module of the PZT box.  This is the pin that +180V is supposed to go on, to be distributed to the other boards in the crate.  Last week I had drilled a hole in the front panel so the wire can come out (since no one on campus seems to have HV panel mount connectors in stock). 

While the transformer module was isolated, not touching anything else, I applied (slowly ramping up) 180V DC, and it all looked good.

When I plugged the module back into the crate (first turning off and disconnecting the HV), I blew the 250mA fuse again.  No HV yet, just the low voltage stuff that Koji had fixed last week.  :( 

We're now out of 250mA fuses, we're supposed to get a box of them tomorrow.

  7505   Mon Oct 8 18:45:48 2012 JenneUpdateIOOPZT diagnosis - not fixed yet, possible solution

After the fuse-blowing fiasco earlier this afternoon, Koji and I took another look at the PZT controllers.

We put an ammeter in place of the fuse, and watched the current as we turned on the transformer module.  The steady-state current with no other modules plugged in is ~15mA.  However, there is a surge current right when you turn on the box which sometimes goes as high as 330mA.  Since the fuse is 250mA, this explains the fuse blowing, even though Koji had already checked out the low voltage path.

The high voltage line was connected, with +180V to the HV out pin of the backplane connector, and the (-) terminal of the power supply connected to signal ground on the board.

We inserted the PITCH module for PZT2, and we started with ~10V as our "high" voltage, and slowly increased the value (current at this time was ~60mA).  We also had a function generator plugged into the "MOD" input, which is where the epics slider goes, so that we should see a changing output voltage.  We never saw a changing output voltage.  Increasing the HV power supply didn't help. 

When Koji spun the "DC offset" knob really fast and then stopped, sometimes the output voltage as measured on the connector-converter board between the white and red wires would jump up, and then settle back down. It came back to the same value that it always was, but it was bizzarre that it would jump like that.  We suspect that that knob is an offset for use with the closed loop setting, so it isn't relevant for us anyway.  Watching the MON output, the value never changed, even when Koji did his fancy knob twirling.

We switched to the other PITCH module, and watched the output voltage on the MON output.  This time, with the function generator unplugged, so no modulation input (so we were expecting a steady DC output voltage) the number on the LCD and the MON output fluctuated wildly.  We plugged in the function generator, and the fluctuations did not change in approximate amplitude or DC offset.  They kind of looked the same. 

So, we have concluded that (a) the PZT drivers don't work, and (b) we don't understand why.  Therefore, we don't know how to fix them.

With that in mind, we are thinking of totally circumventing the PZT drivers. 

I plugged in the PZT1 connector converter board, which has Koji's circuit that he made last time when PZT1 died.  I plugged the ribbon cable which goes to the PZT, and the +\- 30V power supply, and the PZT responded!  Just plugging in the power supply puts the PZTs near the center of their nominal range.  I then put a function generator on the epics inputs for pitch and yaw (one at a time), and saw the spot move around at the ~1Hz that I was applying.  Yay!

What I think I'll do for tonight - modify the other connector converter board so that I can just use 2 HV power supplies (current limited) to steer the PZT.  I set up a TV monitor next to the PZT electronics (1Y3? 1Y4?  I forget), and it's connected to output 20 of the video switch, so I can watch the AS camera and move the PZTs by hand.  Then maybe I can try to align some stuff. (Evan is coming to work tonight, so if I electrocute myself, someone will be here to call 5000)  Koji suggested buying 2 single-channel thorlabs piezo drivers, like we have on the PSL table for the FSS loop.  These take in 0-10V and output either 0-75V, 0-100V or 0-150V (depending on which setting you choose).  These cost $712 each. This would be a more permanent solution than me just sitting out there, since we could once again control PZT2 via epics.

  7506   Mon Oct 8 21:42:17 2012 JenneUpdateIOOPZT diagnosis - not fixed yet, possible solution

Note to self:

The ENV-40 amplifiers that we have supply -10V through +150V .... so don't exceed those limits.

piezojena link

  7509   Tue Oct 9 00:25:33 2012 JenneUpdateIOOPZTs - hacky solution in place!!

[Evan, Jenne]

We applied some volts across both the pitch and yaw pin sets of the ribbon cable that goes to PZT2.  We ended up with ~40V yaw and ~14.5V pitch.  That was the nice happy center of the clipping that we can see on the AS camera.  Once we found the center of the PZT clipping range with the ITMY beam, we recentered the AS camera (actually, this took a few iterations, but now it's good). 

We then aligned MICH, but aren't able to get it to lock.  Before falling asleep, we have decided to align the PRM and SRM, so right now we have a flashing DRMI.  Both the SRMI and PRMI look a little funny the closer you get to 'good' alignment, so I'll investigate a little more tomorrow, and include pictures.  (The video capture script has barfed again, and I'm not in the mood to deal with it today.)

  7510   Tue Oct 9 09:29:10 2012 SteveUpdateIOOthis is where we are

Quote:

Quote:

 The new cold cathode gauge CC1 is in place. We were at atmosphere for 28 days ......more later

 

 cc1 = 2.3e-5 Torr at day 6 vacuum normal

 

Attachment 1: 15days.png
15days.png
  7518   Wed Oct 10 10:55:56 2012 SteveOmnistructureIOOaccess connector at athmoshere

Quote:

Quote:

Quote:

We really need something better to replace the access connector when we're at air.  This tin foil tunnel crap is dumb.  We can't do any locking in the evening after we've put on the light doors.  We need something that we can put in place of the access connector that allows us access to the OMC and IOO tables, while still allowing IMC locking, and can be left in place at night.

 It is in the shop. It will be ready for the next vent. Koji's dream comes through.

 24" diameter clear acetate access connector is in place. The 0.01" thick plastic is wrapped around twice to insure air and bug tight barrier for the MC to lock overnight. The acetate transmission for 1064 nm is 90 % This was measured at 150 mW   2.5 mm beam size.

 

 Aluminum sheet as shown will replace the acetate. Side entries for your arms and "window" on the top will be covered with acetate using double- sided removable-no residue tape 3M 9425

Attachment 1: 10101202.PDF
10101202.PDF
  7521   Wed Oct 10 19:22:03 2012 jamieUpdateIOOAdded control for input tip-tilts to c1ass

I have added some control logic and appropriate output DAC channels for the input tip-tilts (TT1 and TT2) to the c1ass model.

The plan is for all the tip-tilt drive electronics to live in a Eurocrate in 1Y2.  They will then interface with a DAC in c1lsc.

c1ass runs on the c1lsc front-end machine, and therefore seemed like an appropriate place for the control logic to go.

I added and interface to DAC0, and a top_named IOO block, to c1ass:

2012-10-10-185707_566x330_scrot.png

The IOO block includes two TT_CONTROL library parts, one for each of TT1 and TT2:

2012-10-10-191013_470x277_scrot.png

This is just a start so that I can start testing the DAC output.

I have not recompiled c1ass yet.  I will do that tomorrow.

  7522   Wed Oct 10 20:27:40 2012 DenUpdateIOOMCL, WFS triggers

I've added MCL and WFS stop triggers into C1MCS/SUS model. Threshold value of MC_TRANS can be changed in the text entry located in MC2_POSITION medm screen. I tried 2 cases: trigger either blocks signal before MCL filter bank input or after output. Due to filter history in the 1 case MC2 was still slightly disturbed (C1:SUS-MC2_ULPD_VAR ~= 15) right after unlock. In the second case there was no disturbance as we zero output signal, but then I had to add "clear history" command to the mcup script.

WFS triggers block the signal before ASCPIT/YAW filter bank.

MC2_POS.png

Attachment 2: mcl.pdf
mcl.pdf
  7530   Thu Oct 11 12:02:15 2012 DenUpdateIOOFSS

FSS SLOW control did not drift during the lock at night with MCL path working and AC coupled.

fss.png

  7531   Thu Oct 11 12:11:23 2012 jamieUpdateIOOc1ass with new DAC0 output has been recompiled/install/restarted

I rebuilt/install/restarted c1ass.  It came up with no problems.  It's now showing DAC0 with no errors.

After lunch I'll test the outputs.

  7550   Mon Oct 15 20:45:58 2012 jamieUpdateIOOc1lsc DAC0 now connected to tip-tilt SOS DW boards

The tip-tile SOS dewhite/AI boards are now connected to the digital system.

20121015_190340.png

I put together a chassis for one of our space DAC -> IDC interface boards (maybe our last?).  A new SCSI cable now runs from DAC0 in the c1lsc IO chassis in 1Y3, to the DAC interface chassis in 1Y2.

Two homemade ribbon cables go directly from the IDC outputs of the interface chassis to the 66 pin connectors on the backplane of the Eurocrate.  They do not go through the cross-connects, cause cross-connects are stupid.  They go to directly to the lower connectors for slots 1 and 3, which are the slots for the SOS DW/AI boards.  I had to custom make these cables, or course, and it was only slightly tricky to get the correct pins to line up.  I should probably document the cable pin outs.

  • cable 0:  IDC0 on interface chassis (DAC channels 0-7) ---> Eurocrate slot 0 (TT1/TT2)
  • cable 1:  IDC1 on interface chassis (DAC channels 8-15)---> Eurocrate slot 2 (TT3/TT4)

As reported in a previous log in this thread, I added control logic to the c1ass front-end model for the tip-tilts.  I extended it to include TT_CONTROL (model part) for TT3 and TT4 as well, so we're now using all channels of DAC0 in c1lsc for TT control.

I tested all channels by stepping through values in EPICS and reading the monitor and SMA outputs of the DW/AI boards.  The channels all line up correctly.  A full 32k count output of a DAC channel results in 10V output of the DW/AI boards.  All channels checked out, with a full +-10V swing on their output with a full +-32k count swing of the DAC outputs.

   We're using SN 1 and 2 of the SOS DW/AI boards (seriously!)

The output channels look ok, and not too noisy.

Tomorrow I'll get new SMA cables to connect the DW/AI outputs to the coil driver boards, and I'll start testing the coil driver outputs.

As a reminder:  https://wiki-40m.ligo.caltech.edu/Suspensions/Tip_Tilts_IO

 

  7553   Tue Oct 16 00:08:26 2012 DenUpdateIOOc1lsc DAC0 now connected to tip-tilt SOS DW boards

Quote:

Tomorrow I'll get new SMA cables to connect the DW/AI outputs to the coil driver boards, and I'll start testing the coil driver outputs. 

 I've found a nice 16 twisted pair cable ~25m long and decided to use it as a port from 1Y3 to clean room cable instead of buying a new long one. I've added a break out board to the coil driver end to monitor outputs.

DSC_4748.JPG

  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.

ELOG V3.1.3-