Displaying reports 67161-67180 of 77164.Go to page Start 3355 3356 3357 3358 3359 3360 3361 3362 3363 End
Reports until 10:05, Tuesday 25 February 2014
H1 CDS
david.barker@LIGO.ORG - posted 10:05, Tuesday 25 February 2014 (10307)
rebuild and install of all models against 2.8.3 ongoing

We are compiling and installing all models using RCG2.8.3. The following models will not be upgraded:

h1iopseib1 - compile error we are currently investigating (see below)

h1susitmy - testing Hardware Watchdogs and is built against trunk to include the HWWD part

h1iscey - wont compiile

To further investigate the h1iopseib1 error, I emptied the H1.ipc file and compiled the h1iopsusb123 model (the sender). I then tried h1iopseib1 and it again failed. So it does not look related the the IPC file shuffle yesterday and I restored the IPC file.

I am editing the cds/h1/rtsystab file to customize the "make World" model list.

When all software is in place, we will restart all the models (in about an hour)

H1 SUS
betsy.weaver@LIGO.ORG - posted 09:25, Tuesday 25 February 2014 - last comment - 15:30, Friday 28 February 2014(10305)
PUM ITM03 ear bonding commences

We thought it prudent to have a spare PUM in-hand for the upcoming monolithic builds, so yesterday we started bonding ears to the PUM ITM03.  Gerardo sucessfully placed an ear on the S4 surface with an error of under 0.01mm misplacement (0.1mm is the tolerance, so well done Gerardo!).  On to the S3 ear...

Comments related to this report
betsy.weaver@LIGO.ORG - 12:44, Tuesday 25 February 2014 (10312)

Like NBC jinxed all of the ice skaters by praising them just before they fell at the latest Olympics, I spoke too soon about the PUM ITM03 ear.  Just after writing the above alog, Gerardo and I inspected the S4 ear and discovered a large bubble near the corner of the ear.  It had a small fiberous particulate in the bubble.  SOmehow, after monitoring for 2-3 hours, this fiber migrated into the bond.  We had placed a LIGo-approved Vectra Alpha 10 cleanroom wipe over the S4+ear flat for the night in the event a random bug decided to perch, so possibly this added to the particulate.  Da*m.

 

With Mr. Barton's assistance, we loaded the mass into the ultrasonic cleaner and bathed it in water.  Within 4 minutes the ear came off.  The mass is now reloaded at the wash station and we'll work on the S3 ear we were already prepped for today.

Images attached to this comment
betsy.weaver@LIGO.ORG - 13:20, Tuesday 25 February 2014 (10315)

Bubble is shown in far corner of ear in this picture.

Images attached to this comment
betsy.weaver@LIGO.ORG - 15:30, Friday 28 February 2014 (10421)

Further comment to the events above - Margot and Gerardo found this PUM to be dirtier than normal when they pulled it out of the cake tin many weeks ago.  AT that time, they did a methanol cleaning of the entire mass.  When Gerardo and I were cleaning the flats of this mass, we also noticed that it still seemed dirtier than "normal" - meaning, when rinsing, the water did not run on the surface as we had seen on other flats.  After we performed the standard cleaning of the flat, the water behaved "normally", meaning it clung to the full surface and "sheeted" off.  After we removed the contaminated ear, we recleaned the flat, expanding the surface area getting cleaned to the entire flat, not just the area when the ear gets bonded as is the typical procedure.  We hoped this would remove particulate that was previously closer to the bond area.  During the second ear bond attempt, we also did not cover the bond overnight with an alpha 10 wipe, since we were skeptical of the origin of the fiber which showed up in the bond.

H1 SEI (ISC)
fabrice.matichard@LIGO.ORG - posted 01:02, Tuesday 25 February 2014 (10302)
BSC-ISI Beam Splitter saturations during MICH locking
We have been investigating the saturations of the BSC-ISI occurring during the locking process of MICH. Kiwamu has set MICH in a state that triggers and drives the BS but don't lock, so I can investigate the effect of the triggers and transients. 

Some observations and preliminary results:

- The beam Splitter M2 longitudinal drive saturates the ISI Stage 2 actuators as soon as the locking filter triggers and the OSEM start driving the SUS mass. An example is shown in first page. The yellow line in the top left corner shows the OSEM drive. The purple line in the top right corner shows the ISI DAC saturation. 

- It also saturated the GS13s, though the actuators always trigger the watch dogs trip. I turned the GS13 analog electronics in low gain mode. It reduces the GS13 signal to a few thousands counts (Red line, bottom right figure in the first page)

- This is happening even with Level 1 controller that has less loop gain at high frequency than level 2 or 3. An example is shown in first page of the document attached: Orange lines is for the compensator, Dark blue lines is for the Open loop, Dash lines show the boost (low frequency integrator). Turning off the boost doesn't change anything (it's really a high frequency problem, but I wanted to double check)

- After disabling the locking filter, I took transfer functions from OSEM actuator to ISI actuator output signal (SUS DAQ to ISI DAQ). It is shown by the black line in page 3. The ratio is near or above unity at many frequencies, meaning 1 count on the SUS DAQ output produces roughly 1 count at the ISI DAQ output. The SUS drive spectra is pretty white. The SUS DAQ is 18 bits, the ISI is 16 bits. Those three factors combined lead to the saturation of the ISI DAC.

- I added significant filtering in all six dofs of Stage 2 ISI loops to reduce the ISI controls reaction. The new SUS DAC to ISI DAC transfer function is shown in page 3.

- With this controller, the ISI remains on much longer while the BS OSEMs attempt to lock, but it eventually saturates (see p. 4 just before it trips). In the five tests I did, the ISI stayed on 40 seconds minimum, and about 2.5 mn max (versus tripping on the first rising edge with the standard level 1 controller). We'll do more analysis and full lock tests tomorrow.






Non-image files attached to this report
H1 IOO (ISC)
sheila.dwyer@LIGO.ORG - posted 00:48, Tuesday 25 February 2014 - last comment - 12:37, Tuesday 25 February 2014(10298)
What is happening with our IMC?

There is a large wandering peak in the IMC error signal.  (measured at Imon).  A movie is attached.  We tried several things to try to pin down where this comes from.  This wandering peak also shows up in the end station PLL and goes away when the IMC is unlocked.  

This afternoon I checked out some signals from the PSL to see if there were any similar wandering peaks in them and didn't see anything.  I looked on the TTFSS Field box mixr(in2) fastm test2, on the ISS Photodiode A output Photodiode B output. PMC mixer out. Unless there are better signals to look at, I would conclude this isn't from any of the PSL loops, but the IMC itself.  

Alexa and I also tried a few things to see if the wandering peak would go away under different conditions.  It does sometimes go away, but this seems unrelated to the things we tried.  We tried:

We saw the wandering peak in each of these situations. We also had a look at Imon with the IMC unlocked, it wasn't clear what we were looking at when the mode cleaner was flashing.  We misalinged MC1 to look at the dark noise, and didn't see any wandering peak there. We also looked at the IMC open loop gain, there are no resonances or notches there, I remeasured several times and got the same result each time. (53kHz ugf 45 deg phase margin).

Alexa noticed that the UGF is higher than it used to be: she measured it in alog 10069 to be 28 kHz. The neither the settings on the MC board nor the transmitted power have changed.  

We have not been able to do the COMM handoff tonight, although the arm cavity and COMM PLL seem to be quite stable.  

We also attempted to measure the COMM PLL spectrum using the single shot green beam, to get a measurement of the laser frequency noise.  the beat note was about 10mV peak to peak (measured with 1MOhm impedance on the scope) which was not enough for us to lock the PLL. 

Images attached to this report
Non-image files attached to this report
Comments related to this report
sheila.dwyer@LIGO.ORG - 12:37, Tuesday 25 February 2014 (10311)

We also had a quick look at the crossover last night, it is 15Hz 40 degrees of phase. This is normal, at least according to recent measurements (10048 10071)  A screen shot is attached.

Images attached to this comment
H1 SEI (SYS)
jameson.rollins@LIGO.ORG - posted 23:56, Monday 24 February 2014 - last comment - 00:08, Tuesday 25 February 2014(10300)
ISI_HAMX guardian testing on HAM4

Fabrice and I did more testing on the HAM4 guardian today.   I've been lacking in posting, so I bit of recap.  Last week we started testing the ISI_HAMX guardian code on the HAM4 ISI:

USERAPPS/isi/common/guardian/ISI_HAM4.py

This links against the isi/common/guardian/isiguardianlib that Charles Celerier wrote.  A graph of the full system is included below.

The code has been behaving very well, but there have been a few discrepancies between the code and the desired mechanical behavior that we're ironing out.  As of today we were able to cycle through all the states without tripping the watchdogs.  Ultimately a couple of tweaks to the deisolation process did the trick.

It seemed that the shutting off of the ISO Boost_F filters was causing the isolation loops to saturate.  We fixed this by adding a 5 second ramp to all ISO Boost_* filters for all degrees of freedom.  Similarly, the ramp down of the isolation gains, which happens right after the boosts are shut off, was also happening too quickly.  This was particularly true when the platform location was far from the equilibrium position.  After a bit of trial and error we were able to survive the full deisolation process with 150um/urad offsets with a 20 second gain ramp to zero.  Preferably we'll come up with a more systematic way to set these ramp times down the line, but these should do for the moment.

Some additional comments:

The cart bias offsets are set right before reaching full isolation. However, the guardian reaches its fully isolated state (*_ISOLATED) before the platform location has reached it's final position.  I suggest the global guardian behavior would be more robust if the guardian does not transition to the full *_ISOLATED state until the platform reaches the desired location, within some tolerance.  This might be accomplished by tuning the loops to ramp slower to the desired offset and eliminate some of the ringing after the ramp.

We're getting a bunch of guardian notifications about ISO filter states during _RESTORYING_CART_BIAS_OFFSETS states.

Another day of testing and I think we're ready to stand up guardian nodes for HAM2 and HAM3 ISIs.

Images attached to this report
Non-image files attached to this report
Comments related to this report
jameson.rollins@LIGO.ORG - 00:08, Tuesday 25 February 2014 (10301)

A note about the ISI_HAMX state graph:

There are 36 total states, 7 of which are "requestable" (darker color blue and purple in the graph).

There are three potential isolation levels, reprented by the three states ROBUST_ISOLATED, MEDIUM_ISOLATED, HIGH_ISOLATED.  There are 6 intermediate states for each isolation between the DAMPED state and the fully isolated states.

Here is a guardutil "print" of the module, which lists all code loaded from USERAPPS

controls@operator1:~ 0$ guardutil print ISI_HAM4
ifo: H1
name: ISI_HAM4
path: /opt/rtcds/userapps/release/isi/common/guardian/ISI_HAM4.py
prefix: ISI-HAM4
usercode:
  /opt/rtcds/userapps/release/isi/common/guardian/isiguardianlib/const.py
  /opt/rtcds/userapps/release/isi/common/guardian/isiguardianlib/errormessage.py
  /opt/rtcds/userapps/release/isi/common/guardian/isiguardianlib/util.py
  /opt/rtcds/userapps/release/isi/common/guardian/isiguardianlib/masterswitch/const.py
  /opt/rtcds/userapps/release/isi/common/guardian/isiguardianlib/masterswitch/__init__.py
  /opt/rtcds/userapps/release/isi/common/guardian/isiguardianlib/isolation/const.py
  /opt/rtcds/userapps/release/isi/common/guardian/isiguardianlib/ligoblend.py
  /opt/rtcds/userapps/release/isi/common/guardian/isiguardianlib/isolation/__init__.py
  /opt/rtcds/userapps/release/isi/common/guardian/isiguardianlib/watchdog/const.py
  /opt/rtcds/userapps/release/isi/common/guardian/isiguardianlib/watchdog/__init__.py
  /opt/rtcds/userapps/release/isi/common/guardian/isiguardianlib/damping/const.py
  /opt/rtcds/userapps/release/isi/common/guardian/isiguardianlib/decorators.py
  /opt/rtcds/userapps/release/isi/common/guardian/isiguardianlib/watchdog/decorators.py
  /opt/rtcds/userapps/release/isi/common/guardian/isiguardianlib/damping/decorators.py
  /opt/rtcds/userapps/release/isi/common/guardian/isiguardianlib/isolation/decorators.py
  /opt/rtcds/userapps/release/isi/common/guardian/isiguardianlib/masterswitch/util.py
  /opt/rtcds/userapps/release/isi/common/guardian/isiguardianlib/masterswitch/states.py
  /opt/rtcds/userapps/release/isi/common/guardian/isiguardianlib/watchdog/util.py
  /opt/rtcds/userapps/release/isi/common/guardian/isiguardianlib/damping/__init__.py
  /opt/rtcds/userapps/release/isi/common/guardian/isiguardianlib/watchdog/states.py
  /opt/rtcds/userapps/release/isi/common/guardian/isiguardianlib/damping/util.py
  /opt/rtcds/userapps/release/isi/common/guardian/isiguardianlib/damping/states.py
  /opt/rtcds/userapps/release/isi/common/guardian/isiguardianlib/isolation/util.py
  /opt/rtcds/userapps/release/isi/common/guardian/isiguardianlib/cartbias.py
  /opt/rtcds/userapps/release/isi/common/guardian/isiguardianlib/isolation/states.py
  /opt/rtcds/userapps/release/isi/common/guardian/isiguardianlib/masterswitch/edges.py
  /opt/rtcds/userapps/release/isi/common/guardian/isiguardianlib/watchdog/edges.py
  /opt/rtcds/userapps/release/isi/common/guardian/isiguardianlib/damping/edges.py
  /opt/rtcds/userapps/release/isi/common/guardian/isiguardianlib/isolation/edges.py
  /opt/rtcds/userapps/release/isi/common/guardian/isiguardianlib/HAM/states.py
states (*=requestable):
  0 INIT *
  1 ROBUST_ISOLATED *
  2 OFFLINE *
  3 READY *
  4 MEDIUM_ISOLATED *
  5 HIGH_ISOLATED *
  6 DAMPED *
  7 LOADING_CART_BIAS_FOR_ISOLATION
  8 ENGAGING_FIRST_MEDIUM_ISOLATION_FILTERS
  9 ROBUST_RESTORING_CART_BIAS_OFFSETS
  10 RAMPING_DAMPING_FILTERS_UP
  11 WATCHDOG_TRIPPED_DEISOLATING
  12 DISENGAGING_DAMPING_LOOPS
  13 ENGAGING_FIRST_ROBUST_ISOLATION_FILTERS
  14 MEDIUM_RESTORING_CART_BIAS_OFFSETS
  15 WATCHDOG_TRIPPED_FULL_SHUTDOWN
  16 ENGAGING_SECOND_ROBUST_ISOLATION_FILTERS
  17 RAMPING_FIRST_ROBUST_ISOLATION_FILTERS_UP
  18 RAMPING_FIRST_HIGH_ISOLATION_FILTERS_UP
  19 HIGH_DISENGAGING_BOOST
  20 RAMPING_SECOND_HIGH_ISOLATION_FILTERS_UP
  21 TURNING_ON
  22 HIGH_RESTORING_CART_BIAS_OFFSETS
  23 MEDIUM_DISENGAGING_BOOST
  24 TURNING_OFF
  25 ENGAGING_SECOND_HIGH_ISOLATION_FILTERS
  26 RAMPING_SECOND_ROBUST_ISOLATION_FILTERS_UP
  27 DEISOLATING
  28 ENGAGING_FIRST_HIGH_ISOLATION_FILTERS
  29 ENGAGING_SECOND_MEDIUM_ISOLATION_FILTERS
  30 RAMPING_DAMPING_FILTERS_DOWN
  31 ENGAGING_DAMPING_LOOPS
  32 WATCHDOG_TRIPPED_DAMPING
  33 RAMPING_SECOND_MEDIUM_ISOLATION_FILTERS_UP
  34 ROBUST_DISENGAGING_BOOST
  35 RAMPING_FIRST_MEDIUM_ISOLATION_FILTERS_UP
H1 ISC (SEI, SUS)
sheila.dwyer@LIGO.ORG - posted 23:41, Monday 24 February 2014 (10299)
Green arm locking stably today, sensor correction

Fabrice, Hugh and I had a look at the arm cavity signals with sensor correction on and off this afternoon.  The arm cavity locking was not stable because there was no feedback to the top mass, (it turns out the PRMI guardian was reseting the XARM gain to 0).  Anyway, I learned something usefull....

With the sensor correction on, the ETM Stage 2 X drive is in phase with our refl controls signal as well as the slow feedback from the COMM PLL to the IMC VCO, using up about 1/4 of the range of each.  With the sensor correction off (Which Fabrice did by setting H1:ISI-ETMX_ST2_SENSORCOR_X_MATCH_GAIN to 0 from the normal setting of 1.15) this signal is greatly reduced, and we use less of the range of both VCOs.  However, the OPLev sees more pitch motion.  Fabrice says that we can also use a compromise sensor correction that would give less benefit in pitch and also introduce less longitudnal motion. 

Once Daniel and I got the top mass feedback going, the loops are all fine.  Our drive to the top mass clearly introduces pitch motion on the optic, so we need to diagonlaize the drive to the ETM, which Arnaud and Jeff agreed to help us with. 

Right now the arm cavity has been locked for about an hour, I will leave it that way for the night, with the alignment dithers, and top mass feedback on.  The COMM PLL automation is also running overnight. We have low winds (below 50th percentile) and low microseism tonight.

I also started a rudimentary LSC_XARM Guardian just to manage the feedback to the top mass, so we will not shoot ourselves in the foot as much in the future. It's not working yet, but coming soon.

H1 ISC
evan.hall@LIGO.ORG - posted 22:08, Monday 24 February 2014 - last comment - 09:18, Tuesday 25 February 2014(10296)
Missing/wrong components in the noise budget model

Written by Yuta

Now that the mystery of the PD signal chain and the BS actuation efficiency for Michelson are solved (see alog #10213 and #10127), I corrected what we've found missing/wrong in the noise budget (NB) model.

[Motivation]
We wanted to check the validity of the NB model.


[What are missing/wrong?]
Things that were missing/wrong in the NB model "DRMI_Live.slx" copied from LLO was;


[What files do I use?]
The NB model and functions for our Michelson lives in /ligo/svncommon/NbSVN/aligonoisebudget/trunk/MICH/H1. They are based on LLO DRMI NB model but corrected the things mentioned above.
The essential files are

run_NB.m: main script
make_MICH.m: function called from run_NB.m
./Params/paramNbH1MICHtest.m: parameter file
MICH_Live.slx: simulink model

They use the following Optickle files which live in /ligo/svncommon/IscCVS/iscmodeling/LentickleAligo/PRMI/ParamFiles for optical simulation.

optL1DRM.m: constructs Optickle model
probesH1DRM_00.m: puts probes for the Optickle model
paramH1MICH.m: parameter file


[Result]
Attached plot shows the comparison of the OLTF of the MICH loop from the measurement (see alog #10127) and from the NB model. They agree within ~20%. This error mainly comes from the power measurement error.

Note that the Matlab function "linmod" doesn't work correctly when the Optickle block is put in the NB simulink model. Do something like;

[systm,flexTfs] = linFlexTf('MICH_Live');
systm = prescale(systm,{freq(1) freq(end)});
systm = linFlexTfFold(systm,flexTfs);


to plot transfer functions (Thanks to Chris Wipf!).

Images attached to this report
Comments related to this report
christopher.wipf@LIGO.ORG - 09:18, Tuesday 25 February 2014 (10304)

yes Thank you for the excellent work on validating this model!

H1 SYS (SYS)
corey.gray@LIGO.ORG - posted 21:44, Monday 24 February 2014 (10295)
Photos of BSC10 Cartridge Installation

Photos of the BSC10 Catridge installation are in ResourceSpace, here.

Images attached to this report
H1 ISC
keita.kawabe@LIGO.ORG - posted 19:44, Monday 24 February 2014 - last comment - 19:52, Monday 24 February 2014(10293)
Green WFS Monday (Jax, Stefan, Keita)

After painful trial and error process we've found a solution that converges.

Comments related to this report
stefan.ballmer@LIGO.ORG - 19:52, Monday 24 February 2014 (10294)
We hooked up H1:ALS-X_WFS_DOF_2_P_OUTPUT to the end X PDH servo board, EXC A input. This allowed us to drive a clean length signal, providing a nice way to set all demod phases.

In the end the servos converged nicely, but we noticed that the power went up some with a -200ct offset in DOF_2_P. RFAM?

We also tried guessing the output matrix by sticking in an error offset. However the underlying drift proved too big for a clean result.

H1 CDS
david.barker@LIGO.ORG - posted 18:15, Monday 24 February 2014 - last comment - 22:25, Monday 24 February 2014(10291)
status of model rebuild work

h1isiham3: Fabrice fixed h1isisham3, there was a new input port not grounded.

h1susitmy: is running a special trunk version with HWWD parts installed, will leave this model out of the upgrade

h1iscey: not spoken with the ISC group on this one yet

h1iopseib1: a real puzzler. the model has not been changed since 14 Nov, it compiled 16 Dec but wont compile on either 2.8.3 or 2.8.2 today. the H1.ipc file was changed, but this model receives the same IPC channel as h1iopseib2,3 and they compile fine. Comparing the models by eye shows no difference. I copied the Rx part from seib2 to seib1 and still b1 fails and b2 compiles. Will need to scratch our heads a little more. Perhaps a regeneration of H1.ipc from scratch is in order.

Comments related to this report
daniel.sigg@LIGO.ORG - 22:25, Monday 24 February 2014 (10297)

h1iscey probably needs to be updated to the EX version. We made some changes in the common blocks to include the ALS WFS which have not been propagated to EY. Not sure why we need to keep separate configuration files for EX and EY.

H1 CDS (ISC)
david.barker@LIGO.ORG - posted 16:49, Monday 24 February 2014 (10289)
h1asc IPC errors corrected

I noticed some cut-n-paste IPC errors in the h1asc model which needed resolving before we upgrade to rcg2.8.3.

1. IPC from h1asc to sus PR2,PR3 and PRM:  RFM parts instead of Dolphin (PCIE). These were done today, so it was easy to hand edit H1.ipc and remove these 6 parts from the end of the file. I then edited h1asc.mdl and replaced the RFM parts with PCIE parts.

2. IPC from ASC to SUSHTTS: Dolphin (PCIE) parts used instead of Shared Memory parts (SHMEM). Slightly more difficult to fix as subsequent PCIE parts have been added. I removed the ASC parts and shuffled the later parts down in index. Then changed h1asc.mdl to replace PCIE with SHMEM.

Finally using rcg2.8.3 I performed a "make h1asc" which populated H1.ipc with the correct ASC part types. I verified the additional parts were correctly indexed.

H1 CDS
david.barker@LIGO.ORG - posted 16:42, Monday 24 February 2014 - last comment - 17:26, Monday 24 February 2014(10288)
compiling all models against RCG2.8.3, refrain from model changes until tomorrow

In preparation for an RCG upgrade to version 2.8.3 tomorrow morning I am recompiling (but not installing) all models against 2.8.3. Please do no make any model changes or builds for the remainder of today.

In detail:

/opt/rtcds/rtscore/advLigoRTS-2.8.3 is a new checkout of the tags/advLigoRTS-2.8.3 released by Rolf today

/opt/rtcds/rtscore/release relinked to 2.8.3

New build area created

/opt/rtcds/lho/h1/rtbuild-2.8.3 and release pointer relinked to it

inside of rtbuild-2.8.3 the advLigoRTS-2.8.3/configure script was ran.

Comments related to this report
david.barker@LIGO.ORG - 17:26, Monday 24 February 2014 (10290)

Performed first round of builds on all models, four did not compile:

h1isiham3, h1iopseib1, h1susitmy, h1iscey

we are investigating why these are failing. 

H1.ipc file did not get modified after the first build of h1asc before the full build.

H1 SEI (INS, ISC, SEI, SUS)
hugh.radkins@LIGO.ORG - posted 16:21, Monday 24 February 2014 - last comment - 10:05, Tuesday 25 February 2014(10287)
ETMY Cartridge Landed in Chamber--Last for H1!

No issue to report other than missing zippers on the SEI Ceiling Sock.

Clean room back up with the Cartridge ready to go down at lunch.  Torqued to Support Tubes and closed up by 1430pst.

Thanks to Apollo Scott, Mark & Bubba, SUS Travis and SEI Jim.

Corey helped too and took lots of photos.

Images attached to this report
Comments related to this report
michael.landry@LIGO.ORG - 10:05, Tuesday 25 February 2014 (10306)INS
Congratulations all for reaching this milestone safely.  That's five H1 cartridge insertions, plus the two for H2 chambers BSC6 and BSC8.  Nicely done!

Remaining in-chamber installation includes:
  • close out BSC10 at EY and pump down for dual arm experiment
  • populate existing HAM5 ISI with SUS, AOS components
  • temporarily pull septum at HAM6 and align SRs in HAMs 4 and 5 from the end door of HAM6
  • vent the vertex, swap ITMs for production masses in BSC1 and BSC3
  • pull associated manifold spools and align ITMs; install y-arm CPB and ACB
  • pull the temporary septum at HAM4 and align HWS in HAM4
H1 ISC
alexan.staley@LIGO.ORG - posted 15:48, Monday 24 February 2014 - last comment - 18:46, Monday 24 February 2014(10286)
EX Measurements

After discovering that the MPC polarization controller creates a peak at 27kHz in the EX PLL noise spectrum, I decided to take some more measurements at the end station with the controller off.

PLL Servo Board

PDH Servo Board

PLL error signal measured out of PFD IMON, and PDH error signal measured out of demod IMON.

The lowest RMS comes from the PLL Boost 1: OFF, and the PDH Boost 2: ON. With the PLL Boost 1 off there is no gain peaking and the the OLTF of the PLL is stable with a UGF of 22kHz and a phase margin of 50 deg. I need to take an OLTF with the PDH Boost 2 on.

Non-image files attached to this report
Comments related to this report
alexan.staley@LIGO.ORG - 18:46, Monday 24 February 2014 (10292)

Adjusting EX PLL boost 1 ON/OFF and EX PDH boost 2 ON/OFF as above, the various Comm PLL Error signals (PFD IMON) were measured.

Non-image files attached to this comment
H1 SUS
arnaud.pele@LIGO.ORG - posted 19:57, Monday 03 February 2014 - last comment - 08:51, Tuesday 25 February 2014(9774)
Op lev damping ETMX ITMX (WP 4427)

As we might need feedback loops from the optical lever to stabilize the motion of the test mass of ETMX and ITMX, the simulink models were temporary modified to include a link from the optical lever to the PUM and UIM masses.

This was done by copying over what has been done for the beamsplitter optical lever :

A backup of the models h1sus{etmx/itmx}_Feb3rd2013.mdl was made under /opt/rtcds/userapps/release/sus/h1/models

Images attached to this report
Comments related to this report
arnaud.pele@LIGO.ORG - 08:51, Tuesday 25 February 2014 (10303)

I missed a few alogs explaning some modifications on the models. so here's the current status :

  • h1susetmx and h1susitmx both have a disabled link with the common part FOUROSEM_STAGE_MASTER (L1 L2). Those two parts have been modified locally two add a path for the oplev
Displaying reports 67161-67180 of 77164.Go to page Start 3355 3356 3357 3358 3359 3360 3361 3362 3363 End