aLIGO LHO Logbook

Displaying reports 70041-70060 of 83317.Go to page Start 3499 3500 3501 3502 3503 3504 3505 3506 3507 End

Reports until 23:01, Thursday 28 August 2014

H1 ISC

Print this report.

koji.arai@LIGO.ORG - posted 23:01, Thursday 28 August 2014 - last comment - 12:15, Friday 05 September 2014(13656)

OMC Locked

[Dan, Nic, Koji]

After we tamed the OMC QPD spot motions by the alignment servo, we turned on the high voltage supply
as the vacuum pressure allowed to do that.

Then we did notice that the OMC is already locked. WHAT? Did we miss the most exciting moment!?
Well, it was okay. It was a higher order mode. We shifted the PZT offset and locked at the highest peak that gave
us about 13mA total current.

We went down to LVEA and checked the mode shape. Yes. It was TEM00.

Statement: The OMC was locked

The position of the OMC trans spot was checked at ISCT6. Unfortunately the spot was hitting a pillar of the ISCT6 enclosure.
It is not nice to make a hole on the pillar. We probably need to move the table and think carefully how to connect the tube
to the table enclosure...

The OMC REFL with the best alignment looked a bull's eye as we suspected (attached photo #1). Dan is now measuring the mode scan for the mode matching ratio.

For the celebration, Nic cut open an OMC locking cantaloupe. Thanks Gerardo!

Images attached to this report

Comments related to this report

nicolas.smith@LIGO.ORG - 23:15, Thursday 28 August 2014 (13657)

Title: gains moved around in OMC servo

The OMC NORM output was not ~1.0, this was because the input to the normalization was less than 0.1, and the denominator has a lower saturation at that point.

I put a gain of 10 into 'H1:OMC-DCPD_NORM_FILT_GAIN' and 'H1:OMC-DCPD_NORM_GAIN'. Thus bringing the denominator above 0.1 and allowing the normalization to work. There was a gain of 1000 in 'H1:OMC-DCPD_NORM_GAIN' which I moved into 'FM8' of 'H1:OMC-LSC_SERVO' (called 60dB).

Finally, the gain change due to the normalization fix had to be corrected by putting a gain of 1 into 'H1:OMC-LSC_SERVO_GAIN'.

nicolas.smith@LIGO.ORG - 23:32, Thursday 28 August 2014 (13658)

Old pictures.

Images attached to this comment

daniel.hoak@LIGO.ORG - 23:48, Thursday 28 August 2014 (13660)

Here are images of a mode-scan of the OMC, and spectra that show the control signal, the normalized DCPD Sum (called DCPD Norm, in units of RIN), and coherence between some interesting channels. The noise on the DCPDs is limited by the OMC, not the intensity noise from the IFO; only a little bit of the noise on IMC_TRANS is making it to the DCPDs. Note that the ISS is currently disabled. The two DCPDs are coherent so we're not shot-noise limited.

I took 60-second averages of the sum of OMCR_A with the OMC locked and unlocked. Unlocked the sum was 9316.68, locked was 1834.33. The visibility/mode-matching into the OMC is about 80%. (A small but nonzero fraction of this is due to the power in the sidebands, the modulation depth is 0.3.)

A text file for the mode scan can be found here. The columns are [time, PZT_VMON, DCPD_SUM].

Note, all of this data was taken with a single bounce off ITMX., with one stage of whitening on the DCPDs.

Also I've attached a figure of the OMC open-loop gain measurement. UGF is 90Hz.

Images attached to this comment

william.korth@LIGO.ORG - 16:00, Friday 29 August 2014 (13681)

Nice!

A few things in reply to Dan's comment:

1) I wonder why the mode scan looks so messy. Ramping the PZT over the full range should deform the cavity slightly, so we usually see a couple-percent difference in transmission from mode to mode, but the variation seems much wider here. Was the alignment not stable? Also, what's going on with those PZT readback saturations?

2) Was this RIN plot from before the NORM calibration was fixed? If not, it seems crazy high. It looks like your input beam is pretty noisy, since you see some coherence with IMC TRANS, but I guess this is somewhat expected at lower frequencies with ISS off. However, there is no way the OMC should be adding noise at that level.

3) Now would be a good time to balance the DCPDs. I believe Keita made a precise measurement of the electronic TFs which can be used for frequency-dependent correction, and then Koji should have the responsivity numbers for the diodes. Those should take care of most of the difference, and then the rest can be done with the balance slider (we needed 0.6% gain bias at LLO). The easiest way to do this is to put an intensity modulation line in and cancel it in the NULL signal.

koji.arai@LIGO.ORG - 12:15, Friday 05 September 2014 (13777)

I believe this was done with a single bounce of ITMX.
ITMY had an oplev issue at the time as you can seen in https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=13654

H1 SUS

Print this report.

keita.kawabe@LIGO.ORG - posted 19:13, Thursday 28 August 2014 - last comment - 02:59, Friday 29 August 2014(13654)

Optical lever issues (Nic, Kiwamu, Keita)

One of the difficulties of locking PRMI yesterday, according to Kiwamu, was that something was moving too much, so we started looking at optics, and in the process identified two OL problems, one for BS and the other for ITMY.

1. BS OL laser problem

Every 70 seconds, the beam coming to the AS port showed quick (as in 1 to a few Hz) jiggling motion mainly in YAW. This seems to be caused by intensity glitch of BS OL laser that takes place every 70 seconds, making a fake angle signal for BS, which is fed back to the BS by OL damping. The thing is that it's difficult to feed back to BS without BS OL damping.

Attached is the time series of the BS OL SUM (top left), BS OL YAW (bottom left) and PIT (bottom right) during the glitch.

For now, since the effect is mostly in YAW, Kiwamu disabled the OL damping for YAW, but we'd like to swap the laser.

2. ITMY OL problem

When you look at ITMY OL, it looks as if the optic is moving by 10 urad pp in YAW with a period of about 10 minutes , but nothing in BOSEMs and ISI sensors and such (second attachment), and we couldn't see that motion in the AS camera either. We convinced ourselves that the motion is not real.

We had a look at various temperature and some archane signals of PEM and FMCS but found nothing. Maybe the laser itself is moving.

This is not a serious problem for now, but it should be fixed eventually.

Images attached to this report

Comments related to this report

kiwamu.izumi@LIGO.ORG - 02:59, Friday 29 August 2014 (13663)

See the blue trace in the attached time series. The trace represents the sum of the optical lever of BS. It shows a funny drop every 70 sec.

Images attached to this comment

LHO General

Print this report.

patrick.thomas@LIGO.ORG - posted 16:00, Thursday 28 August 2014 (13653)

Ops Summary

08:30 Fire department on site to perform pump maintenance
08:36 Peter K. to H2 PSL enclosure
08:41 Hugh to end X, end Y to look at HEPI pump stations
08:51 Aaron pulling cables for cameras and optical levers in LVEA
08:59 Fire department returning
09:57 Jason starting work on SR3 optical lever
10:53 Sudarshan to end X to calibrate tiltmeter
10:54 Hugh done at end X and end Y
10:58 Car arrives to access roads for shrub steppe project
11:25 Peter K. out of H2 PSL enclosure
11:33 Jason done
12:37 Filiberto starting camera work (WP 4819)
12:42 Karen to end Y
13:21 Ed to LVEA to help Aaron pull cables
14:04 Karen done at end Y
15:54 Sudarshan back

LHO VE

Print this report.

kyle.ryan@LIGO.ORG - posted 15:47, Thursday 28 August 2014 (13652)

~0830 hrs. local, resumed roughing HAM6 -> ~1200 hrs. local, spun up turbo on HAM6

HAM6 total rough pump time ~ 1 + 3 = 4 hours

H1 AOS (SUS)

Print this report.

jason.oberling@LIGO.ORG - posted 15:19, Thursday 28 August 2014 (13650)

SR3 Optical Lever Complete (for now)

The SR3 oplev installation is now complete. It is aligned to the current pitch/yaw bias of SR3; if this changes let me know and I'll re-align the oplev. An initial calibration has been performed and the pitch/yaw gains updated (calibration data attached, yaw gain is negative in the graph due to the mounting of the QPD w.r.t. the horizontal translation stage of the receiver; the signs in the SR3 oplev MEDM should be correct). The new gains are:

Pitch: 34.9
Yaw: 36.2

This is an initial calibration to get a working system for initial commissioning work and will be refined in the future. This will need to be added to the save.snap as well.

Also, for this installation we installed the first of the 18 V to 5 V DC-DC converter boards to power the laser. While in operation the laser only pulls 0.24 A, but it should be noted that upon startup the laser briefly requires approximately 2 A and then settles back to 0.24 A. We need to keep this in mind when we start upgrading the remaining oplev lasers.

Non-image files attached to this report

SR3OpLevCalibration8-28-2014.xlsx

H1 SUS

Print this report.

kiwamu.izumi@LIGO.ORG - posted 12:15, Thursday 28 August 2014 (13649)

ITMX L2 stage coil driver was found to be off, I switched it on

Last night, when I tried the oplev damping on the L2 stage (PUM) of ITMX, the damping loop did not improve the angular motion at all. This morning, Keita noticed that the OSEM read out at the L2 stage were all reading small numbers, indicating some electronics are not properly functioning or maybe disconnected. So I investigated this issue.

It was the coil driver which had been turned off for some reason -- the mechanical switch on its back panel was in the off position. So I switched it on. Now we can see some reasonable readout coming in to the digital system. We now should be able to use the oplev damping if necessary.

H1 SEI

Print this report.

hugh.radkins@LIGO.ORG - posted 11:30, Thursday 28 August 2014 (13647)

EndX HEPI H2 Parker Valve Leak cleaned up

While trouble shooting the EndY problem I reviewed the EndX Pump Station settings. While there I noticed the fluid level in the reservoir was notibly lower than just a week or so ago. So, I inspected the system and again only found the known leaks. I cleaned the fluid catch on H2 Actuator as it was full. I plan on changing this leaking Parker valves next week.

H1 SEI

Print this report.

hugh.radkins@LIGO.ORG - posted 11:24, Thursday 28 August 2014 (13646)

EndY HEPI Pump Station problem found fixed

I found the FWD/CM jumper was actually behind the lugs of the terminal block in the VFD. It made contact intermittently and once started it doesn't need to remain closed so it was never a failure mode on the Pump Station. I'll again cycle the Pump Station on Tuesday to confirm I got the jumper properly installed.

LHO VE

Print this report.

kyle.ryan@LIGO.ORG - posted 10:33, Thursday 28 August 2014 (13639)

Restored end station pumping to pre-Borja configuration

Data collection for Borja's charge measurements are done (for now) -> Spun-down turbo and shut down QDP80 @ Y-end -> Valved-out IP12 @ X-end, X-end now pumped only by turbo 

Also, turned on BSC9 annulus ion pump (in parallel with aux. cart)

H1 CDS

Print this report.

james.batch@LIGO.ORG - posted 09:53, Thursday 28 August 2014 (13637)

Cleared testpoints on H1LSC model

At about 23:23 PDT Aug. 27, too many testpoints were requested on H1LSC and the DAQ bit in the state word for the model was set.  All test points were manually cleared at 09:40 PDT Aug. 28.  The model did not need to be restarted, the DAQ state bit cleared immediately.

H1 CDS

Print this report.

patrick.thomas@LIGO.ORG - posted 09:25, Thursday 28 August 2014 - last comment - 11:44, Friday 29 August 2014(13635)

removed 3 frequently changing channels from Conlog

These 3 channels started rapidly changing sometime around 3 or 4 this morning (I'm having trouble getting data for them from dataviewer).

H1:ALS-X_SPARE_A_DEMOD_RFMAX
H1:ALS-X_SPARE_B_DEMOD_RFMAX
H1:LSC-X_TR_A_DC_RESPONSIVITY

I ran camonitor on them. Here is a snippet of the results for H1:ALS-X_SPARE_A_DEMOD_RFMAX. The others were similar.
...
H1:ALS-X_SPARE_A_DEMOD_RFMAX   2014-08-28 09:07:40.377320 -5.47624e+66  
H1:ALS-X_SPARE_A_DEMOD_RFMAX   2014-08-28 09:07:40.387320 2.67673e-83  
H1:ALS-X_SPARE_A_DEMOD_RFMAX   2014-08-28 09:07:40.398321 7.40505e-305  
H1:ALS-X_SPARE_A_DEMOD_RFMAX   2014-08-28 09:07:40.407321 -1.97952e+288  
H1:ALS-X_SPARE_A_DEMOD_RFMAX   2014-08-28 09:07:40.417322 -4.52984e+42  
H1:ALS-X_SPARE_A_DEMOD_RFMAX   2014-08-28 09:07:40.428322 4.45211e-194  
H1:ALS-X_SPARE_A_DEMOD_RFMAX   2014-08-28 09:07:40.438323 -3.29246e+177  
H1:ALS-X_SPARE_A_DEMOD_RFMAX   2014-08-28 09:07:40.448324 4.60892e+278  
H1:ALS-X_SPARE_A_DEMOD_RFMAX   2014-08-28 09:07:40.457324 3.91205e-35  
H1:ALS-X_SPARE_A_DEMOD_RFMAX   2014-08-28 09:07:40.467325 7.40505e-305  
H1:ALS-X_SPARE_A_DEMOD_RFMAX   2014-08-28 09:07:40.478325 2.06671e+235  
...

I think they originate in Beckhoff. I have instructed Conlog to stop recording them for the time being by adding them to the exclude list and regenerating the channel list.

Comments related to this report

patrick.thomas@LIGO.ORG - 09:41, Thursday 28 August 2014 (13636)

As Jim B. pointed out, the end X Beckhoff PLC 2 has gone haywire. The new medm readback of its system time is being rapidly overwritten by random numbers. From a trend of H1:SYS-ETHERCAT_X1PLC2_CURRENTTIME_WSECOND, it appears to have started around 3:18 PDT this morning.

james.batch@LIGO.ORG - 10:03, Thursday 28 August 2014 (13638)

Dataviewer shows the X1_PLC2 time display going bad at 03:19 PDT Aug. 28.

patrick.thomas@LIGO.ORG - 10:49, Thursday 28 August 2014 (13641)

Further information:
H1:ALS-X_LOCK_STATEREQUEST got changed to 256 at ~ 3:18.

patrick.thomas@LIGO.ORG - 10:53, Thursday 28 August 2014 (13642)

Restarting the end X Beckhoff computer has not helped.

patrick.thomas@LIGO.ORG - 15:34, Thursday 28 August 2014 (13651)

Upon Daniel's suggestion I did a restart of TwinCAT and then a burtrestore of PLC2 to 08:10 yesterday morning. PLC2 then crashed and I got the error in the attached screenshot. I acknowledged the error and then clicked 'Activate and run' for PLC2. This appears to have fixed it.

Images attached to this comment

patrick.thomas@LIGO.ORG - 11:44, Friday 29 August 2014 (13672)

It appears that an automatic Windows update restarted the computer at 3:15:29 AM PDT.

The relevant events from the Windows system log are attached.

Non-image files attached to this comment

H1 CDS

Print this report.

david.barker@LIGO.ORG - posted 08:33, Thursday 28 August 2014 - last comment - 11:09, Thursday 28 August 2014(13633)

some front end IO Chassis have ADC/DAC cards on PCIe adapter cards

First some background; there are two ways of installing an ADC card in the front end IO Chassis: either as a single PCIe card or as a PCIX card sitting on a PCIe adapter card. Recent ADC errors when running RCG2.9 on the IOP model for SUS EY have been resolved by Keith and Rolf as being caused by ADC/adapter cards being used in certain slots. The hope was that the installed H1 system was not using any adapted ADCs, but when I scanned all the front end IOCs I found the following front ends do indeed have cards on adapters:

h1susey (2 ADC)

h1seiex (3 ADC)

h1oaf0 (1 DAC-16bit)

During next Tuesday's maintenance, we will replace these with PCIe cards to ensure all front ends are hardware identical. We will also check the 3rd IFO IO Chassis are hardware identical to H1 and L1.

Comments related to this report

keith.thorne@LIGO.ORG - 11:09, Thursday 28 August 2014 (13644)CDS

Note that the problem only occurred if a PCIX ADC was used in the very first ADC slot (ADC0).  As long as a PCIe ADC was used as ADC0, both kinds of ADCs could be used in other slots.   Also, we have not found any problems with DAC cards at present.

H1 ISC

Print this report.

kiwamu.izumi@LIGO.ORG - posted 05:06, Thursday 28 August 2014 - last comment - 11:37, Thursday 28 August 2014(13631)

no luck locking PRMI

We tried locking PRMI with no success. Some optics seem loud. More details will be posted later.

Comments related to this report

kiwamu.izumi@LIGO.ORG - 10:49, Thursday 28 August 2014 (13640)

Dan, Kiwamu

We tried PRX, PRY, MICH and PRMI. PRMI did not lock, but the other configuration locked. Also I am worried that either ITMs or BS may be moving a lot.

(MICH)

ASAIR_A_RF45_Q
- demod phase = -91 deg
whitening gain = 18 dB, stage 1 and 2 ON.
servo gain -200
we did not change the digital filters at all (i.e. the same old filters were used)
UGF --> forgot to measure, must be higher than 10 Hz.
The BS pitch was wobbly with an amplitude of about 2 urad in peak-to-peak, observed by oplev. Engaging the oplev damping servo successfully got rid of the pitch wobbliness.

(PRX and PRY)

REFL_A_RF45_I
- demod phase = -2.2 and 12 deg for PRX and PRY sideband resonance respectively
Also checked the demod phase for REFL_A_RF9_I (out-of-loop)
- demod phase = 77.0 and 79.7 deg for PRX and PRY sideband lock respectively
whitening = 0 dB, no whitening stages engaged.
servo gain = -200
we did not change the digital filters at all (i.e. the same old filters were used)
UGF --> 60-ish Hz

(PRMI)

tried a smaller gain in PRCL and MICH by a factor of 500 and 20 respectively according to LLO's locking instruction (DCC-T1300991).
- I did not see a momentary lock at all
fiddled with the gains. No momentary lock was observed

(ITMX mysterious oscillation in pitch)

At the beginning, we saw a quite steady oscillation in pitch of ITMX at 0.5 Hz with an amplitude of 2 urad according to the uncalibrated oplev. We suspected a hidden excitation somewhere and therefore cleared all the excitation using the diag command. This did not solve the oscillation. Then I increased the pitch damping gain by a factor of 3 to suppress the oscillation and this worked well. Setting the gain back to the nominal value (i.e. -1), I saw no ring up in pitch and the oscillation still stayed small. So I left the damping gain as nominal. Strange. Since ITMY oplev is off from the QPD, we did not check the angular motion in ITMY.

(I feel that the mirror motion is bigger than it used to be. Maybe ?)

Since the last PRMI commissioning in this winter, we have kept a couple of limiters in LSC and SUS for preventing the servos from unnecessarily kicking the optics during lock acquisition. The limiter values and their associated filters had been carefully adjusted so that they don't limit the in-lock DC values but they limit some impulsive signals. However, the limiters were limiting the in-lock feedback signal at DC when PRX(Y) or MICH was locked. I had to increase some of the limiter values by more than a factor of 5 or take them out last night.

I have not done a quantitative spectral analysis yet, but I am feeling that the motion of the suspensions are greater than before.

kiwamu.izumi@LIGO.ORG - 11:37, Thursday 28 August 2014 (13648)

As for the limiter issue, we need only two limiters to be enabled, which is BS_ISCINF and PR2_M3_LOCK (see this old entry 10559). In addition, I had a wrong limiter on at LSC_PRCL last night.

Anyway, the one limiting the DC value yesterday was BS_ISCINF. This used to be 5 x10⁵ and it was 2 x 10⁵ in eariler yesterday for some reason. I then increased this limiter to 2 x 10⁶ in order to avid the signal being cut at this limiter.

H1 INS

Print this report.

keita.kawabe@LIGO.ORG - posted 15:43, Tuesday 26 August 2014 - last comment - 10:55, Thursday 28 August 2014(13607)

H1 installation milestone: The last chamber was closed.

Gerardo has just torqued down the bolts for HAM6 viewports. We're done with H1 in-chamber installation (for the current configuration)!

Images attached to this report

Comments related to this report

jeffrey.kissel@LIGO.ORG - 10:55, Thursday 28 August 2014 (13643)

Congrats everyone!

H2 TCS

Print this report.

greg.grabeel@LIGO.ORG - posted 14:53, Tuesday 26 August 2014 - last comment - 10:27, Friday 29 August 2014(13602)

Removed Ring Heater and Cable Assemblies from H2 ITMy

Removed the Ring Heater Assembly from the ITMy quad structure going into 3IFO storage. Before starting I noticed the lower ring heater assembly had a crack in the glass former. Not sure when the break happened, but this one also displayed a lot of movement inside the ring heater shield. The pictures show how the former has pushed pretty far out of position. 

The ring heater cables were also removed. This includes the "antlers" (D1001755) but not the plate (D1002420) which the earthquake stop is attached to.

The assemblies removed were:

ASSY-D1001895-V5 #001 (lower ring heater, broken)
ASSY-D1001517-V7 #612 (cable assembly)
ASSY-D1001838-V6 #005 (upper ring heater)

Images attached to this report

Comments related to this report

greg.grabeel@LIGO.ORG - 19:20, Wednesday 27 August 2014 (13630)

That should read

ITMx (not y)

and

ASSY-D1001838-V6 #002 (upper ring heater)

not #005. typos.

betsy.weaver@LIGO.ORG - 11:11, Thursday 28 August 2014 (13645)

Note, when the 40kg optics are installed and removed from the QUAD lower structures that these ring heaters are mounted to, there is some torquing of the structure (and therefore the RH). Possibly this adds to these failure modes.

greg.grabeel@LIGO.ORG - 10:27, Friday 29 August 2014 (13669)TCS

One more fix. The lower ring heater should be:

ASSY-D100195-108

Made a mistake with a V5 and V6 part.

Displaying reports 70041-70060 of 83317.Go to page Start 3499 3500 3501 3502 3503 3504 3505 3506 3507 End