Displaying reports 72021-72040 of 77031.Go to page Start 3598 3599 3600 3601 3602 3603 3604 3605 3606 End
Reports until 10:08, Friday 18 January 2013
H1 IOO
kiwamu.izumi@LIGO.ORG - posted 10:08, Friday 18 January 2013 (5151)
restarted PLC2 on h1ecatc1

  The PLC2 process on h1ecatc1 got stopped again [1] and because of it the MC servo board was unable to control, resulting in trouble with the IMC locking.crying

 I did the same recovery procedure as I did before and it came back OK. The settings of the MC servo board was burtrestored to 11pm of yesterday. However we lost the settings of the delay line phase rotator (which is used to adjust the demodulation phase of the IMC PDH signal at 24 MHz) as there is no snapshot file prepared for it yet.
 At the moment it is unclear to me when the process stopped and why it happened.

[1] LHO alog #5021

X1 SEI
vincent.lhuillier@LIGO.ORG - posted 10:07, Friday 18 January 2013 (5150)
BSC-ISI Unit 4 - Healthy

Transfer functions on the fourth BSC-ISI showed some unusual resonances in corner 2 (figures 2013_01_10). I have attached transfer functions from the stage 1 actuators to the L4Cs and the stage 2 actuators to the stage CPSs. After checking/re-torque bolts in this corner and changing the Vertical L4C, the new set of transfer functions look good (figures 2013_01_15). This unit looks healthy. More details will be given in the testing report.

Non-image files attached to this report
H1 CDS
kiwamu.izumi@LIGO.ORG - posted 09:27, Friday 18 January 2013 (5149)
Affinity set on h1ecatc1

[Patrick, Kiwamu]

  Yesterday the IMC commissioning team complained that the EPICS values associated with the corner Beckoff system did't look correctly updated. This was causing confusion --- they tried zeroing the electronics offsets in the MC servo board, but the values in the MEDM screen didn't change at all. It turned out that the slow digital system itself had been running fine and had been under control regardless of whatever the values shown in a screen. Therefore it seemed that something was wrong between the Beckoff and EPICS.
 We suspected that this might be due to the fact that we have so many EPICS channels managed in a single Windows machine, namely h1ecatc1. To alleviate the heavy load on the processors we have set the affinity of all the EPICS OPC servers such that they can run any of the CPUs (from CPU0 to CPU9) via the regular task manager application. Note that we have 17 OPC severs running on this machine. This solved the issue and so far it looked running OK.

Though we think we need to come up with a more reliable solution since we maybe having the same issue in some future.
 

H1 SEI
hugh.radkins@LIGO.ORG - posted 08:13, Friday 18 January 2013 (5148)
Late Entry--WHAM2 HEPI Unlocked Thursday AM
Forgive the omission please.  I unlocked HAM2 HEPI right after the 0815 meeting Thursday morning being fully unlocked by maybe 0930pst.  Some of the signs may not be right; I'll correct hem asap.
H1 IOO
lisa.barsotti@LIGO.ORG - posted 18:52, Thursday 17 January 2013 - last comment - 16:49, Friday 18 January 2013(5145)
IMC working, left locked for the night
Giacomo, Paul, Keita, Hugo, Matt, Lisa

The IMC is locked and happy.
The stability problems were due to the ISI, Hugo put it in a configuration which allowed us to recover a stable lock.

We measured the open loop TF of the whole system, it was stable up to 30 kHz UGF.
We also measured the cross-over VCO/MC2_M3: it is about 15 Hz (it can be stable as high as 100 Hz).

The MC2_M3/M2 cross over is well below 1 Hz.

A detailed entry with the measured transfer functions and gain settings will follow.

We also centered the WFSs on IOT2 and found that a 90/10 beam splitter was used instead of a 50/50 in front of WFS_A, 
explaining the factor 10 power difference between the two WFSs.

We leave the IMC locked for the night, and we should be able to start checking the WFSs signal path tomorrow.
Comments related to this report
lisa.barsotti@LIGO.ORG - 19:00, Thursday 17 January 2013 (5146)
We were trying to get a direct measurement of the M2/M3 cross over..we will try again tomorrow.
Clean data starting at 1042513275 .
giacomo.ciani@LIGO.ORG - 16:49, Friday 18 January 2013 (5156)

Paul has implemented a notch filter to push the UGF further up. He has measured the OLTF again and will post the new data in another entry.

 

The fast/slow path crossover frequency was measured by injecting an excitation signal before the MC2_M3 lock filters (H1:SUS-MC2_M3_LOCK_L_EXCMON) and taking the ratio of the signals immediatly before and after the injection point. With the settings of the relevant parameters specified below, the crossover is between 10 and 20 Hz (15 Hz? the shape of the TF is a bit funny there...). See attached plot.

Fast path gain (H1:IMC-REFL_SERVO_FASTGAIN): -2 dB

MC3 lock filters gain (H1:SUS-MC2_M3_LOCK_L_GAIN): -1000

MC3 lock filters enabled: FM5 (150:4) and FM8 (CLP100)

 

We used a similar setup to measure the MC3/MC2 crossover frequency, injecting an excitation signal before the MC2_M2 lock filters (H1:SUS-MC2_M2_LOCK_L_EXCMON). With the settings fo the relevant parameters specified below, the TF is well below unity at 1 Hz. See attached plot.

MC2 lock filters gain (H1:SUS-MC2_M2_LOCK_L_GAIN): 0.005

MC2 lock filters enabled: FM3 (0.1:1), FM4 (100:1) FM5 (0.01:0.1) and FM8 (ELP70)

Images attached to this comment
LHO General
patrick.thomas@LIGO.ORG - posted 18:50, Thursday 17 January 2013 (5144)
plots of dust counts
Attached are plots of dust counts > .3 microns and > .5 microns in particles per cubic foot from approximately 6 PM Jan. 16 to 6 PM Jan. 17. Also attached are plots of the modes to show when they were running/acquiring data. Dust monitor 10 in the H1 PSL enclosure is indicating a calibration failure and will probably need to be replaced.
Non-image files attached to this report
LHO General
patrick.thomas@LIGO.ORG - posted 18:34, Thursday 17 January 2013 (5143)
plots of dust counts
Attached are plots of dust counts > .3 microns and > .5 microns in particles per cubic foot from approximately 6 PM Jan. 15 to 6 PM Jan. 16. Also attached are plots of the modes to show when they were running/acquiring data. I used h1nds1 because h1nds0 was reporting an error. 6300 seconds of data was not available for each plot.
Non-image files attached to this report
LHO General
patrick.thomas@LIGO.ORG - posted 17:42, Thursday 17 January 2013 (5136)
Ops Summary
MC locking work
9:19 - 9:52 Hugh to unlock HAM2 HEPI
Dust monitor 10 calibration failure
11:00 Richard turning up voltage on ISC DC racks
11:37 LN2 delivery
ITMY SUS, ISI models restarted
Genie lift delivered
12:46 H1SEIB6, H1SUSB6 models restarted
12:54 Jim shutdown H1SEIH16 frontend, swapped ADC card, restarted frontend
Apollo removing items from end Y VEA in preparation for BSC10 de-install
15:31 DAQ restart
15:35 PEM model on H1OAF frontend restarted
H1 CDS
david.barker@LIGO.ORG - posted 17:16, Thursday 17 January 2013 (5142)
code changes and restarts

h1seih16: was rebooted several times to verify that the ADC originally in the second slot was bad by moving it to the third slot. It was then removed and the spare good ADC installed.

h1hpiitmy model had some mx_stream issues until I realized I have not included it in the rtsystab file. After this was done and the mx streams restarted on h1seib1 its data is now good.

The DAQ was restarted several times because of the ITMY SUS and ISI changes (slow chans renamed) and the H1EDCU_ECATC1.ini file was added to trend the mode cleaner servo board channels. At this point the new h1peml0 ini file was taken by the DAQ, so the h1peml0 model was restarted (FLOOR->VERTEX name change on Seismometer).

Later DAQ restart to update the front end DAQ status channel list in H1EDCU_DAQ.ini.

H1 COC
gerardo.moreno@LIGO.ORG - posted 16:10, Thursday 17 January 2013 - last comment - 22:04, Thursday 17 January 2013(5140)
BS06 in Oven

(Betsy, Gerardo)

Optic is now in the oven.

Images attached to this report
Comments related to this report
betsy.weaver@LIGO.ORG - 22:04, Thursday 17 January 2013 (5147)

The heat cycle was initiated at ~10:30am, intending to ramp to 34 degC over 2 hours and then soak for 6 hours before returning to room temp.  At 3pm the sensor on the glass probe inside the oven showed 28degC while the controller had reached 34 degC.  I attempted to increase the temp of the controller and add more time to the soak, but during the hour of messing with it the temperature started to slowly drop.  Apparently the controller does not like ramps less than 2 hours and could not resume heating quickly.  Because we were mid cycle, I opted to kill the power since I was leary of adding more time at increased temp during unattended evening hours.  A lesson learned for the next optic/glue cure cycles - set the controller temp to ~40 degC and don't mess with it mid-cycle. 

The BS cure cycle was 28 degC for 4.5 hours - not quite up to spec, but going to have to be good enough.  The optic was left to ramp down to RT naturally overnight.

H1 SUS
travis.sadecki@LIGO.ORG - posted 15:37, Thursday 17 January 2013 (5139)
BS payload work

Today, I added the BS elliptical baffles (both HR and AR) to the suspension in addition to the remaining lower structure support brackets.  As of now, the payload of the SUS is as accurate and complete as it can be without having the optic installed.  It should not change much once the optic is installed (probably on the order of 10s of grams difference?).  Once a decision has been made with regards to the placement of the structure on the ISI table, SEI can rebalance and begin their testing.

Images attached to this report
H1 AOS
patrick.thomas@LIGO.ORG - posted 15:34, Thursday 17 January 2013 (5138)
restarted EPICS OPC gateways for Beckhoff h1ecatey
Did the same as was done for h1ecatc1. There are now three gateways running on this machine. I set the affinities for these tasks to all of the CPUs. This had to be done earlier for h1ecatc1 to fix problems with the EPICS update rate.
H1 SUS
mark.barton@LIGO.ORG - posted 14:14, Thursday 17 January 2013 - last comment - 15:05, Thursday 17 January 2013(5135)
PRM and PR3 OL
Mark B.

Andres backed out the BOSEMs on PRM and PR3, and the AOSEMs were already out, so we measured the OL counts:

prettyOSEMgains(logOLs('H1','PRM'),'PRM')

M1T1 24867 1.206 -12434
M1T2 27695 1.083 -13847
M1T3 26803 1.119 -13401
M1LF 27765 1.081 -13882
M1RT 29899 1.003 -14949
M1SD 26998 1.111 -13499
M2UL 24409 1.229 -12204
M2LL 25575 1.173 -12787
M2UR 25475 1.178 -12738
M2LR 26427 1.135 -13214
M3UL 24962 1.202 -12481
M3LL 24710 1.214 -12355
M3UR 26711 1.123 -13356
M3LR 25557 1.174 -12778

prettyOSEMgains(logOLs('H1','PR3'),'PR3')

M1T1 25835 1.161 -12917
M1T2 30072 0.998 -15036
M1T3 28666 1.047 -14333
M1LF 25623 1.171 -12812
M1RT 25798 1.163 -12899
M1SD 28238 1.062 -14119
M2UL 17706 1.694  -8853
M2LL 20285 1.479 -10142
M2UR 18746 1.600  -9373
M2LR 17714 1.694  -8857
M3UL 17313 1.733  -8656
M3LL 22891 1.311 -11445
M3UR 24376 1.231 -12188
M3LR 17159 1.748  -8580
Comments related to this report
mark.barton@LIGO.ORG - 15:05, Thursday 17 January 2013 (5137)
Mark B.

I entered all the above gains and offsets into the various OSEMINF blocks for PRM and PR3, checked that OSEM2EUL, SENSALIGN, DAMP, DRIVEALIGN, EUL2OSEM and COILOUTF were all correct, and updated the safe.snap files (in the new locations that Jeff K had just moved them to!).
H1 CDS
vincent.lhuillier@LIGO.ORG - posted 13:13, Thursday 17 January 2013 (5134)
SUS-ISI ITMY-ETMY models updates

RCG 2.6.1 now authorizes 512 IPC channels (previously limited at 64 channels with RCG 2.5). The communications channels between the BSC-ISIs and the QUADs were added at ITMY (BSC1) and renamed at ETMY (BSC6).

H1 SUS
jeffrey.kissel@LIGO.ORG - posted 13:04, Thursday 17 January 2013 (5133)
All H1 SUS safe.snap files re-organized
After assessing the location of every subsystem's safe.snaps in the userapps repository, then discussion on the CDS software meeting yesterday, we determined that each subsystem's safe.snap should live here:

/opt/rtcds/userapps/release/${subsystem}/${ifo}/burtfiles/${modelname}_safe.snap

where ${subsystem} = [isi, sus, psl, etc.] , ${ifo} = [l1, h1, i1] , and ${modelname} = name of simulink model (sans the .mdl extension) . ISI and PSL already obey this convention, but SUS had put the .snaps in subfolders of the burtfiles directory named after the optic motivated by still-under-developement Guardian work at LLO. 

As of this entry, all SUS (including h1susim, and h1sustmsy) safe.snaps have been moved out of their sub-folder into the "top level" burtfiles folder, and the corresponding soft link in the target directory has been updated:

controls@opsws1:target 0$ ls -l h1sus*/h1sus*/burt/safe.snap
lrwxrwxrwx 1 controls controls 65 2013-01-17 12:46 h1susbstst/h1susbststepics/burt/safe.snap -> /opt/rtcds/userapps/release/sus/h1/burtfiles/h1susbstst_safe.snap
lrwxrwxrwx 1 controls controls 64 2013-01-17 12:46 h1susetmy/h1susetmyepics/burt/safe.snap -> /opt/rtcds/userapps/release/sus/h1/burtfiles/h1susetmy_safe.snap
lrwxrwxrwx 1 controls controls 62 2013-01-17 12:46 h1susim/h1susimepics/burt/safe.snap -> /opt/rtcds/userapps/release/sus/h1/burtfiles/h1susim_safe.snap
lrwxrwxrwx 1 controls controls 64 2013-01-17 12:46 h1susitmy/h1susitmyepics/burt/safe.snap -> /opt/rtcds/userapps/release/sus/h1/burtfiles/h1susitmy_safe.snap
lrwxrwxrwx 1 controls controls 63 2013-01-17 12:46 h1susmc1/h1susmc1epics/burt/safe.snap -> /opt/rtcds/userapps/release/sus/h1/burtfiles/h1susmc1_safe.snap
lrwxrwxrwx 1 controls controls 63 2013-01-17 12:46 h1susmc2/h1susmc2epics/burt/safe.snap -> /opt/rtcds/userapps/release/sus/h1/burtfiles/h1susmc2_safe.snap
lrwxrwxrwx 1 controls controls 63 2013-01-17 12:47 h1susmc3/h1susmc3epics/burt/safe.snap -> /opt/rtcds/userapps/release/sus/h1/burtfiles/h1susmc3_safe.snap
lrwxrwxrwx 1 controls controls 63 2013-01-17 12:47 h1suspr2/h1suspr2epics/burt/safe.snap -> /opt/rtcds/userapps/release/sus/h1/burtfiles/h1suspr2_safe.snap
lrwxrwxrwx 1 controls controls 63 2013-01-17 12:47 h1suspr3/h1suspr3epics/burt/safe.snap -> /opt/rtcds/userapps/release/sus/h1/burtfiles/h1suspr3_safe.snap
lrwxrwxrwx 1 controls controls 63 2013-01-17 12:47 h1susprm/h1susprmepics/burt/safe.snap -> /opt/rtcds/userapps/release/sus/h1/burtfiles/h1susprm_safe.snap
lrwxrwxrwx 1 controls controls 67 2013-01-17 12:47 h1susquadtst/h1susquadtstepics/burt/safe.snap -> /opt/rtcds/userapps/release/sus/h1/burtfiles/h1susquadtst_safe.snap
lrwxrwxrwx 1 controls controls 64 2013-01-17 12:48 h1sustmsy/h1sustmsyepics/burt/safe.snap -> /opt/rtcds/userapps/release/sus/h1/burtfiles/h1sustmsy_safe.snap
controls@opsws1:target 0$ 

H1 IOO
paul.fulda@LIGO.ORG - posted 00:01, Thursday 17 January 2013 (5132)
IMC locking issues

[Cheryl V, Giacomo C, Paul F]

Today we tried measuring the OLTF at the IMC 'common mode' servo board. This required locking the IMC of course, which we were able to do at about 1pm without much trouble (as previously). With the settings that we were using for the initial locking, we saw a UGF of about 1.8kHz. To compare with William Korth's LLO alog entry 4182 where a UGF of 14kHz was reported, we increased the common mode gain until we matched the UGF of 14kHz. We required a common mode servo gain of 10dB to reach a UGF of 14kHz, whereas at LLO the corresponding gain was -2dB. The difference in gains required (12dB~ factor 4) was close to what we would expect given the different laser power (200mW here versus 1W at LLO). 

However, there was still some work going on around the chamber at that time, so we decided to go for lunch before recording an OLTF to post. After coming back, we then found it very difficult to lock the mode cleaner again. We could get short locks, but nothing more than 15 seconds. As far as we could tell, nothing had changed in terms of gains or offsets inbetween (we had brought the common gain back to our previous locking value of -4dB). We then spent a lot of time trying unsuccessfuly to adjust gains, offsets, and filters to get a stable lock. We did eventually get some longer locks (~30 seconds) after increasing the watchdog limits for MC2 M2 and M3, but then we noticed an oscillation in the length feedback channel after M2 feedback was applied (see attached plot). 

Some possible causes for the change in the locking situation are:

We'll keep trying to get the IMC locking up and running again tomorrow so we can look at some WFS signals.

Non-image files attached to this report
H1 IOO
giacomo.ciani@LIGO.ORG - posted 23:58, Wednesday 16 January 2013 (5131)
IOT1 (aka IOT2L) in the works

[Paul, Cheyl, Giacomo]

 

Between Monday and Tuesday we worked at the IOT1 (also very confusingly known as IOT2L = IOT HAM2 Left). We rearranged the IMC refl beam path according to the layout D0902284 (it had previously been layed down temporarily to get an error signal for the IMC locking asap) with the following exceptions and notes:

- the high power beam dump is not there, so we are going on a normal razor-blades beam dump (we will not be using high power though). Also, the other components on that path are not there/in place.

- as per Chris suggestion, we placed that HWP in front of IO_MCR_BS1 instead of in its original location. However, we noticed that it reduced the power at the RFPD by about 50% (independetly from its orientation), so we decided to remove it untill we are confident with IMC locking.

- the shutter is not there

- the GiGe camera is not yet available, so we put an analog camera in its place

- some adjustment has been done to the WFS path, to accomodate for the focal lenses of IO_MCR_L2 and _L3 that are slightly different than the design values. See the following for details.

A few pictures attached.

 

For the WFS path, we placed IO_MCR_L2 in its nominal position, and performed a beamscan using the Ophir Nanoscan. Beamscan1.pdf shows the fit to the horizontal and vertical beam sizes (w0 is ~50 um for both  horizontal and vertical)

Also, we measured the beam at a fixed position for different rotations of the nanoscan head around the beam axis, to look for systematics in the observed ellipticity, but we didn't find a relevant effect.

After putting IO_MCR_L3 in a position (it turned out to be about 2" further downstream wrt nominal) that would give about the same waist size quoted on the layout (300 um) we repeated the beam scan, shown in Beamscan2.pdf (w0 is ~275 um for horizontal and ~250 um for vertical).

We then placed the two 45 deg mirrors, put the beamscan downstream and identified the positions (in front and after the waist) in which the beamsize was sqrt(2)*waist (this corresponds to +-Zr from the beam waist, or +-45 deg Gouy phase). As these positions are different wrt the horizontal or vertical beam profiles, we placed each WFS at an intermediate one.

Note that, because the optic mounts have slotted bases, we used temporary clamps to place the 45 deg mirrors in the ideal position (beam centered on the mirror and reflecting at 90 deg). However, later on it was decided to slightly move the mirrors so that they could be screwed to the closest usable hole on the table, thus modifying the pathlength to the two WFS (wrt the waist) by a few mm each. The position of the WFS was not corrected, so for now it can be sxpected to be off by that much (the error is anyhow comparable to the difference between the ideal position for the horizontal or vertical beam profile).

It's also worth mentioning that after a few hours that the WFS were connected to the electronics, we noticed that the metallic enclosure of WFS_A (and only that) was unusually hot to the touch(about 40 C?). We disconnected it and run a series of electrical tests both Tuesday evening and Wednesday morning, without finding any evidence of malfunction. It has been connected since this morning and the temperature seems equal of that of WFS_B (i.e. slightly warmer than ambient). We'll occasionally re-check the temperature of the WFS during the next days.

Finally, Cheryl routed the IMC transmitted beam down the periscope and into another analog camera.

Images attached to this report
Non-image files attached to this report
Displaying reports 72021-72040 of 77031.Go to page Start 3598 3599 3600 3601 3602 3603 3604 3605 3606 End