Displaying reports 65281-65300 of 77210.Go to page Start 3261 3262 3263 3264 3265 3266 3267 3268 3269 End
Reports until 14:37, Tuesday 10 June 2014
H1 SUS (AOS, COC, INS, SYS)
jeffrey.kissel@LIGO.ORG - posted 14:37, Tuesday 10 June 2014 (12286)
Photos (and Video!) From H1 SUS ITMY Install
M. Phelps, T. Sadecki, G. Traylor, B. Weaver, [and J. Kissel as photographer]

Since LHO was disconnected from the outside world this morning, I decided to tag along and recall what awesome installation work is still on-going. Here's a slide show of pictures for the H1 SUS ITMY, BSC3 install [[2014-06-10_H1SUSITMY_Install.pdf]], and I attach some of the highlights as raw images. The movie fits in between photos 3943 and 3949, and captures the move from mounted in the installation arm to staged in-chamber -- download the video from . Congrats on another successful install to Margot, Travis, Gary, and Betsy! 

#positivitytraining
Images attached to this report
Non-image files attached to this report
H1 SUS (ISC)
jeffrey.kissel@LIGO.ORG - posted 12:51, Tuesday 10 June 2014 (12285)
ECR E1400078 M1V&R to M2P&Y Damping Path installed on H1SUSBS
J. Kissel

As per ECR E1400078, I've installed the infrastructure for damping the highest vertical and roll modes of H1 SUS BS (a BSFM triple suspension), sensed at the top (M1) stage, and actuated upon using the middle (M2) stage pitch and yaw drive. Many thanks to Stuart for prototyping; install was as simple as an update to the userapps repository, and then a recompile, reinstall, restart, and restore. A new safe.snap has been captured and committed with the input to the new filter banks turned off. The DAQ was restarted later in the afternoon to account for new channels (and other bugs from the network outage).

This closes out ECR E1400078, and completes integration issue 723.

Once we get back under vacuum, we'll begin to commission the loops in a similar fashion as LLO -- hoping that we have a similar amount of SNR and control authority.

Follow the development story from LLO:
Original Investigation: LLO aLOG 11069
Original Implementation: LLO aLOG 11076
Loop Design Description: LLO aLOG 11233
Reimplementation: LLO aLOG 12973
Integration to Library Parts: LLO aLOG 12991

LHO General
patrick.thomas@LIGO.ORG - posted 10:10, Tuesday 10 June 2014 (12278)
morning meeting notes
HAM6 is fully payloaded. Hugh will unlock and balance the ISI and inspect the cabling.
Keita and Corey are done with HAM6 in chamber work.

ITMY is ready to come out.
ITMX will be installed today.

A first cleaning has been done in the spool area at GV7.
Kyle will install a vacuum pump.
Thomas and Jason will remove the optical lever components. Apollo will remove the optical lever piers.
Apollo will break bolts and remove the annulus piping.
A second cleaning will be done.
The spool will probably be removed tomorrow.

The H1 PSL laser diodes are reaching the end of their life.

Filiberto will be working on SUS watchdog cabling at end Y in addition to the ongoing AA/AI chassis work.

Jeff K. will add damping software infrastructure for the BS.

The storage container for the 3IFO BSC1 needs to be craned into its LTS location. The 3IFO HAM4 and 5 ISIs need to be moved from their shipping containers to their LTS containers.

GV11 and GV18 will be closed for Y2 accumulation pressure measurements.

Temporary plugs will be put in the annulus ports on the HAM5 and 6 door flanges to allow leak checking of the septum between the chambers.

Cyrus is doing maintenance on the CDS switches.
Logbook Admin General
jonathan.hanks@LIGO.ORG - posted 10:02, Tuesday 10 June 2014 (12281)
aLOG maintenance 10:30am pacific (Complete)
Please save or post any aLOG entries prior to 10:30.  I will be rebooting the system to apply patches.

The work is completed
LHO General
patrick.thomas@LIGO.ORG - posted 09:47, Tuesday 10 June 2014 - last comment - 09:52, Tuesday 10 June 2014(12279)
GC networking is currently down


			
			
Comments related to this report
patrick.thomas@LIGO.ORG - 09:52, Tuesday 10 June 2014 (12280)
GC should be back.
H1 CDS (DAQ)
david.barker@LIGO.ORG - posted 08:19, Tuesday 10 June 2014 (12277)
CDS model and DAQ restart report, Monday 10th June 2014

no restarts reported.

H1 SEI
sebastien.biscans@LIGO.ORG - posted 07:19, Tuesday 10 June 2014 (12275)
Watchdogs trips summary - Lock Loss

Here's the presentation that I'll be giving today during the Seismic call.

I'm focusing on lock losses, and how they are linked to the ISIs trips.

Non-image files attached to this report
H1 CDS
cyrus.reed@LIGO.ORG - posted 06:56, Tuesday 10 June 2014 - last comment - 11:23, Tuesday 10 June 2014(12274)
CDS Switch Maintenance Today

I'll be starting work on the CDS core switch soon, as specified in WP4660.  This will impact most network traffic within CDS, and by extension offsite access to CDS.

Comments related to this report
cyrus.reed@LIGO.ORG - 07:58, Tuesday 10 June 2014 (12276)

I have finished with the core switch, and have now started on the other internal CDS switches.  Rebooting the core switch freed the used memory, so it is probably an issue with a slow memory leak.  The subsequent firmware update will hopefully address this.

cyrus.reed@LIGO.ORG - 11:23, Tuesday 10 June 2014 (12283)

I have finished with all of the major work on the switches, there should be no more network interruptions.  The GC offsite network outage was just unhappy coincidence, and was unrelated to the CDS work.

H1 ISC
keita.kawabe@LIGO.ORG - posted 16:34, Monday 09 June 2014 - last comment - 16:38, Monday 09 June 2014(12268)
All electronics tests that needs the HAM6 door to be off was done.

Beam diverters good.

At first neither of two beam diverters worked, using Beckhoff driver. The sensors are good, the motors tried to move but they couldn't fully move the mirror.

We brought a beam diverter testor, and one of them (OMC_REFL_AIR_BDIV) moved slowly, but the other (AS_AIR_BDIV) didn't. The difference between the testor and the Beckhof thing is that the latter has a maximum current set in software, thus the tester is beefier.

When pushing the BDV by hand, it was obvious that the friction was big (and they both squeaked and squauked screeched). I loosened the front/back plate screws to make the plates more aligned with the axle, tightened them, and loosened the axle collar screw so there was more space between the front/back plate and the jewel bearing. This seemed to help, and after doing this for both BDVs the one that worked slowly started moving smoothly, and the one that didn't move started to move.

Switching back to Beckhof, the AS_AIR_BDIV didn't move. After another round of loosening screws and aligning, it finally started moving.

One thing is, open/close logic in AS_AIR_BDIV is reversed, which should be fixed in Beckhof.

Picos good.

We brought a picomotor driver and a testor because ISCT6 is not in position.

At first none of three AS picos (AS_A and AS_B for WFS centering, AS_C for AS QPD centering) worked, but QPD sled picos were good.

We swapped the in-air cable and the AS picos started working. Swapped the in-air cable back and the AS picos still worked.

One of the shafts for the in-air pico DB25 connector on the feed through was bent, and it was kind of hard to screw it in. Maybe the cable was not fully seated because of that.

Anyway, all picos work.

Note to self: M10 is the first pico on the QPD sled cable, M9 is the second.

Comments related to this report
keita.kawabe@LIGO.ORG - 16:38, Monday 09 June 2014 (12273)

Remaining tasks can be done from outside without going into the chamber (unless, of course, something is found to be bad in chamber):

  1. Ground loop check (I don't know/remember which cable was done, but at least we need to do this for newly installed QPD sled and AS_C QPD).
  2. Measure capacitance of OMC PZTs + cables.
H1 ISC
filiberto.clara@LIGO.ORG - posted 16:21, Monday 09 June 2014 (12271)
ISC Electronics - CER
Did not get as far with the modifications of the AA/AI ISC electronics in the CER. All AA/AI units are currently powered off and not connected. Will continue with work tomorrow morning and try to bring them back up around noon.

Filiberto Clara
LHO VE
kyle.ryan@LIGO.ORG - posted 16:20, Monday 09 June 2014 (12270)
Valved-in RGA mounted on BT port Y2-1 at Y-mid
Adhered temp recorder to Y2 BT -> Dumped unpumped volume seen be PT246 dead space into RGA assembly at port Y2-1 -> Isolated turbo pump from RGA -> Opened 10" gate valve -> Energized PT246B (eventually had to "tap" lightly with wrench to get gauge to fire) -> RGA scanning in Faraday MID, amus 2,5,14 and 28 -> will isolate Y2 BT from ion pump tomorrow by hard-closing GV11 and GV18  

This exercise is part of the Y2 pressure accumulation data collection 
H1 General
andres.ramirez@LIGO.ORG - posted 16:00, Monday 09 June 2014 (12269)
OPs Shift Summary
8:00 Work on Genie and Forklift behind the Highbay – Mid Columbia Forklift
9:13- 11:38 Heading to HAM6 to continue on ISI work – Hugh
9:22- AA-AI Chassis modifications for ISC in Electronics room – Filiberto/Aaron
9:28- Going to EndX to grab some parts to work on HAM6 – Corey
10:00-12:11 Baffle work in LVEA (West bay) – Gerardo/Scott
10:30-Heading into HAM6 to do some testing – Corey/Keita
13:00- Back into LVEA   (West bay)  for more Baffle work– Gerardo/Scott
13:13- Installing SUS Watchdog chassis and running cable at EndY – Filiberto/Aaron
13:51- Dump unpumped volume seen by PT246 into RGA turbo*isolated turbo from RGA*open 10" BT valve thus exposing RGA and PT246 to BT* Begin scanning at MidY/EndY – Kyle
13:55- 14:45 Heading back to HAM6 to continue on ISI work – Hugh
14:07- De-install receiver pylon for PCAL welding at EndX VEA – Thomas
14:15- Heading into the LVEA to relocate dust monitor – Jeff B.
14:35-Going into the H2 PSL enclosure – Peter
14:54 SPRAGUE on site.
15:00 EX VEA transitioned to laser SAFE
H1 SEI (INS)
hugh.radkins@LIGO.ORG - posted 14:53, Monday 09 June 2014 (12267)
WHAM6 payloaded per D1201388-v3
I'll attempt unlocking and continue with balancing the ISI later when Keita & Corey are not working there.
H1 SEI
richard.mittleman@LIGO.ORG - posted 19:41, Friday 06 June 2014 - last comment - 14:54, Monday 09 June 2014(12256)
BSC-ISI Z to rZ coupling on ETMX

 

  For the past few months we have been suffering from an unwanted stage 1 Z to stage 1 rZ coupling (the attached plot Z to Z Subtraction shows an example).  It seems to have two component which show up in the T240 rZ signal.

   There is a 1/f^2 component (in Force to displacement units, the plot is in force to velocity) and a flat component (again in Force to displacement)

   The 1/f^2 part does not seem to represent center of mass motion of the platform, as shown by the optical levers (the black line in the Z to OpLev Yaw plot), it is not clear

for the flat component yet.

   Speculation for the 1/f^2 has centered on magnetic coupling or local deformation of stage 1, current measurements and FEA on these two effects are off by about the same amount.

   Since we believe that the signal is not CoM motion we are going to subtract it from the T240 rZ signal.  The plot Z to Z Subtraction shows the predicted amount of subtraction based on the fitted filter.

where the red line is (TF - FIlter)/TF so we are hoping to get a factor of~ 50 subtraction.

 

    The plot Z to OpLev Yaw  shows some results.

 

  The BLUE lines shows the transfer function from ISI stage 1 Z drive to the optical lever (solid line is yaw, dotted it pitch) while the ISI is in high blend with no T240 in the control path. So we expect to see

any mechanical coupling. 

   The PURPLE lines shows the same transfer function with the stage 1 of the ISI in low blend (~40mHz) and the T240s in the loop. Whatever extra pickup exists in the rZ T240 signal will be imposed onto the motion of the ISI

and show up in the optical lever signal (pitch as well as yaw because the suspension is not at the center of the ISI table and there is a translation to pitch coupling).

   The Black lines are the same transfer functions with the subtraction path enabled (i'm not even going to try and explain how we got 3 orders of magnitude of suppression)

 

   One disclaimer I calculated a filter gain of 3 and ended up using a gain of 3.24

Images attached to this report
Comments related to this report
richard.mittleman@LIGO.ORG - 17:13, Saturday 07 June 2014 (12259)

This is the subtraction results from ETMY

 

  Also I've changed the basis matrices back to what they are supposed to be a defined in T1000388, I used the script Populate_ETMY (X)_Matricxs.m which is in the MISC folder under Scripts

  It is just a reduced version of the Populate_MEDM_Screens function

 

  The OPLEV Yaw signal shows the expect factof of ~50 improvement

Images attached to this comment
richard.mittleman@LIGO.ORG - 14:54, Monday 09 June 2014 (12266)

Some Performance Data on ETMX and EtMY (both are running level 3 controllers with TBetter Blends)

  the only new thing here is that the optical lever signals are mostly in the noise. Since we are looking at in loop sensors the injected noise would have been suppressed, so what is new is that

the r suppression is (most likely) real

 

   the xml files are /ligo/svncommon/SeiSVN/seismic/BSC-ISI/H1/ETMX/Data/ETMX_Performance_060914.xml

      and  /ligo/svncommon/SeiSVN/seismic/BSC-ISI/H1/ETMY/Data/ETMY_Performance_060814.xml

 

  Sheila has for less gain peaking at the microsiesim in rX and rY and at 60mHz in rZ so i'll make a new set of blends

Images attached to this comment
H1 SUS
arnaud.pele@LIGO.ORG - posted 14:13, Friday 06 June 2014 - last comment - 17:14, Wednesday 11 June 2014(12228)
X1 QUAD08 TF

[Mark B Jeff B Arnaud P]

Yesterday we did some software debugging in the staging building in order to run transfer functions on the assembled quad 08.
When driving the top mass, we usually monitor the lower stages osems, in both osem and euler basis. For some reason the model running for the quad doesn't record those channels (particularly the ones in the euler basis "WIT_{L/P/Y}_DQ"). We decided not to spend too much time understanding what the model situation was, and instead simply not monitor the lower stages channels during the top mass TFs.

The undamped transfer function measurements for the main and the reaction chain are attached.
 

Non-image files attached to this report
Comments related to this report
arnaud.pele@LIGO.ORG - 13:12, Tuesday 10 June 2014 (12255)

[Mark Jeff Arnaud]

QUAD08 should be compared to the model called "wireloop"  (=wires from UIM to PUM looping around PUM) instead of the "wire" one (=cable segments between UIM and PUM). The first attachment from the alog above was modified since I was using the wrong model for comparison. With the wireloop model there is still a small discrepancy in the second pitch mode (modeled at 1.33Hz and measured at 1.45Hz). By playing with the d values (defined p7 of T080188) I came up with a good match, cf attachment.

Here are the modified d values for reference :
new_dm = old_dm + 0.7mm
new_dn = old_dn + 0.7 mm
new_d4 = old_d4 - 0.8 mm

Also, after an other round of matlab debugging (pb with channel sampling rates in the matlab scripts, path definitions etc...) we were able to get spectra of TOP and UIM osems, with the suspension undamped. Results are attached in the second pdf.
The only thing to notice is the noise content at high frequencies for the left osem of M0 (cyan curve, 1st page). This might be harmonics from the large 60Hz signal.

Non-image files attached to this comment
arnaud.pele@LIGO.ORG - 18:31, Tuesday 10 June 2014 (12305)

Jeff B Andres Arnaud

This afternoon we tested the noise seen in the left bosem of the main chain. We swapped left and right osem cables (at the osem output), and measured a spectra before and after. When plugging the right channel to the left osem, the noise was still present in the spectra (cf screenshot) meaning the noise comes from the left osem itself.

Second attachment is a comparison of the transfer functions between different "wireloop" quads. The 2nd pitch mode frequency is varying from quad to quad, but the largest discrepancy is on QUAD08.

Images attached to this comment
Non-image files attached to this comment
arnaud.pele@LIGO.ORG - 17:14, Wednesday 11 June 2014 (12319)

[Andres Arnaud]

Today we replaced the left osem of the main chain of QUAD08 in the staging building with an other BOSEM (stolen from one of the 3rd IFO TMS). New OLV were stored, offsets and gains were set in medm.
 Results of individual osems spectra are attached. The M0 LF channel dosen't show the elevated noise seen yesterday anymore

Non-image files attached to this comment
H1 SEI (CDS, SUS)
jeffrey.kissel@LIGO.ORG - posted 11:03, Friday 10 January 2014 - last comment - 16:29, Monday 09 June 2014(9204)
SUS Hardware Watchdog Threshold Test
J. Kissel, R. Bork, B. Abbott, D. Barker

In order to determine a good threshold for the new SUS Hardware Watchdog, we've shaken the ITMY chamber vigorously in various states of excitation. 
In summary, with 
- the HEPI and SUS user watchdogs disabled (actuator and inertial sensors set to un-tripably high values)
- ISI damping, SUS damping, and HEPI loops OFF (I just left the ISI tripped the whole time) and 
- driving HEPI at the limit of its DAC range (in Y, RX, and RZ), 
we shook the suspension (and ISI) enough that I would say "Wow, that's a *lot* of motion; it's giving me the willies. We should cut off SEI excitation after 10-20 minutes of this." 

This level of excitation produces roughly 110 [mV] RMS* from the RMS circuit of the SUS Hardware Watchdog. 
* The Hardware Watchdog currently does not expose the output RMS variables, either to analog or digital, so we've replicated what we believe is the SUS Hardware Watchdog's signal chain in the IOP model for the h1susb123's computer, based on the limited documentation available (namely Fig 4 of T1200306), and the DC gain of 31.2 [V/V] from the SUS Hardware Watchdog Chassis, measured on an identical setup in the H1 DAQ Test Stand (thanks Ben/Rolf!).

My figures of merit were 
- the ISI BLRMS Performance matrices, in which 
     - ST1 was solid red above the 0.3 [Hz] band in XYZ, 
     - ST1 was solid red in all frequency bands, and 
     - ST2 was solid red in all bands in all DOFs
- the QUAD M0 OSEM speed dials (the raw ADC input version), in which (for these particular DOFs of excitation from HEPI)
     - F1, F2, and F3 (which are the L, P, and Y sensors) were swinging quickly over *most* (not all) of their range (which is 0.7 [mm])
     - LF, RT, (which are the V and R sensors) showed signs of abnormally large movement, say 25% of their range
     - SD was moving minimally
- The DAC saturation counter screen for HEPI, which was showing several channels off-and-on saturating
- The ITMY Optical Lever, which was not swinging out of its range, but moving abnormally large, say 50% of its range



For future forensics, the rough times that I had this large excitation going was roughly between 
GPS: 1073411801 and 1073412182
UTC: Jan 10 2014 17:56:25 - Jan 10 2014 18:02:46
PST: Jan 10 2014 09:56:25 - Jan 10 2014 10:02:46 

Drive was 0.1 to 10 [Hz] "uniform" white noise, using three independent awggui sessions, driving channels
H1:HPI-ITMY_ISO_Y_EXC    100000 [cts]
H1:HPI-ITMY_ISO_RX_EXC   100000 [cts]
H1:HPI-ITMY_ISO_RZ_EXC   100000 [cts]

The QUAD, ISI, and HEPI survived admirably (as expected), and after the excitation was turned off, SUS and ISI damping loops were immediately functional again, and it quieted down to normal damped motion with ambient input motion from an unisolated chamber. All software watchdog values have been set back to their nominal values.
Comments related to this report
jeffrey.kissel@LIGO.ORG - 14:51, Friday 10 January 2014 (9208)CDS, SUS
Regarding what it means for the ISI BLRMS performance matrix elements to be "solid red" -- remember the color corresponds to the ratio of the band-limited RMS of the motion currently and the aLIGO requirement for that stage. If the elements are red, the platform motion is greater than 100x the motion requirement for that isolation stage in that frequency band. For example, the RMS of the 1-3 [Hz] requirement is 6e-12 [m] RMS for ISI ST2, so the motion at ST2 caused by the excitation exceeded 6e-10 [m] RMS. Check out figure 2 of section 3.5 in E990303 for the full requirements, and T1100613 for details of the RMS calculation. I don't think there's specific documentation on the performance matrices themselves. 
jeffrey.kissel@LIGO.ORG - 16:29, Monday 09 June 2014 (12272)CDS, SUS, SYS
Just for posterity, I've trended the former version of the IOP, software watchdog's, RMS output values during this excitation test; see attached. 

Recall that this watchdog's trip threshold had been set arbitrarily at 15000 [ct] RMS. One can see that at this threshold, it would have never tripped for this amount of motion rendering it useless. The maximum (minute trend) peaked at roughly 8500 [ct], half of what the threshold has been for these trigger channels.

This version of the watchdog's RMS algorithm is known to be buggy, ringy, and will be replaced in the next release of the RCG, meaning this test will have to be performed again to properly tune its threshold. 
Images attached to this comment
Displaying reports 65281-65300 of 77210.Go to page Start 3261 3262 3263 3264 3265 3266 3267 3268 3269 End