Displaying reports 67321-67340 of 83002.Go to page Start 3363 3364 3365 3366 3367 3368 3369 3370 3371 End
Reports until 10:23, Friday 16 January 2015
H1 PSL (IOO, PSL)
sudarshan.karki@LIGO.ORG - posted 10:23, Friday 16 January 2015 (16111)
ISS Second Loop Power Level Issue

Sudarshan, Keita, Evan, et al.

The source of excess power on ISS PD is  Aux laser at IOT2R.

We were seeing a lot of power on the ISS PD than usual. This power level in the PD changed (went up significantly- about a factor of 4) sometime around 12/11/2014. I was trying to figure out if this was the real signal or something in the electronics went bad but with no luck. However I noticed that the power level on ISS PD was reasonable since 3:30 on Wednesday. These power level on PD corresponded with the power on IM4_TRANS_QPD as well (See trend plots below).

Yesterday after looking through a lot of possible explanation about the power level changes in IM4_TRANS_QPD with Keita and coimmissioning crew, we realized this excess power was coming from the Aux Laser setup on IOT2R for Schnupp asymmetry. The power level change coincides with the timeline of Schnupp measurment setup (alog 15566), and on Wednesday at 3:30 PM  Evan blocked this aux laser beam with the beam dump. Evan and I went down to IOT2R this morning to do a sanity check if this was indeed the source and no surprise.

Images attached to this report
H1 General
jim.warner@LIGO.ORG - posted 09:58, Friday 16 January 2015 (16109)
Morning meeting minutes
Hugh doing tilt-decoupling measurements on BSC hepi's
HAM ISI iso loop touch up
3IFO
HEPI actuators are palletized ready for moving
PEM microphones are being added
Riebolt on site repairing obs deck door
Laser eyewear is missing, please return
LVEA Laser safety screens have been moved, make sure these are returned to their locations if you have to move them
LVEA is not in a bifurcated state, TSOP only applies to SUS work in the LVEA
H1 SUS
daniel.sigg@LIGO.ORG - posted 09:54, Friday 16 January 2015 (16108)
ETM Vertical SUS motion

Attached are trends of the vertical ETM OSEMS for the past 64 and 4 days, respectively.

Non-image files attached to this report
H1 SUS (ISC)
brett.shapiro@LIGO.ORG - posted 08:56, Friday 16 January 2015 (16107)
ETMX F1 OSEM may be out of range, limiting the pitch damping

Last night we saw ETMX had large 0.43 and 0.5 Hz modes in the oplev, despite the damping. These are long-pitch modes.

To investigate I made some top mass measurements. See the osem centering image. The M0 F1 (top left speed dial) is far from center, with the large alignment offsets. It might be beyond the linear range. I measured some TFs on the top mass. See the second image. Black and read are undamped, without and with the offsets. The these should match, but they don't at the first two modes. Blue and cyan are the same, but with damping. They should match, but they don't. It might be that the first two modes are dipping into the non-linear range. This could limit the damping, and permit these modes to ring up.

Images attached to this report
H1 CDS (DAQ)
david.barker@LIGO.ORG - posted 08:31, Friday 16 January 2015 (16106)
CDS model and DAQ restart report, Wednesday, Thursday 14th,15th January 2015

model restarts logged for Wed 14/Jan/2015
2015_01_14 06:42 h1fw0
2015_01_14 12:06 h1dc0
2015_01_14 12:08 h1broadcast0
2015_01_14 12:08 h1fw0
2015_01_14 12:08 h1fw1
2015_01_14 12:08 h1nds0
2015_01_14 12:08 h1nds1

2015_01_14 12:51 h1iscey
2015_01_14 17:41 h1fw0
2015_01_14 19:04 h1fw0
2015_01_14 19:28 h1fw1
2015_01_14 20:27 h1fw1

Several unexpected fw restarts. New h1iscey code with associated preceding DAQ restart.

model restarts logged for Thu 15/Jan/2015
2015_01_15 09:52 h1fw0
2015_01_15 19:26 h1fw1

Two unexpected fw restarts.

H1 CDS (SUS)
jeffrey.kissel@LIGO.ORG - posted 19:38, Thursday 15 January 2015 - last comment - 11:41, Friday 16 January 2015(16101)
First Attempt at Defining SUS SDF File for H1SUSMC2
J. Kissel, T. Sadekci, B. Weaver

We've made a first attempt to use the State Definition File (SDF, see e.g. LLO aLOG 15907, or G1500060) system on H1SUSMC2. You can find a play-by-play below, but most importantly, we think we've found a major flaw in the system. 
Here's the use case:
Taking MC2 from SAFE to ALIGNED using the SUS guardian, then using the IMC_LOCK guardian to lock the IMC, uses several _SW1S or _SW2S channels (i.e. those bit words that define the first and second halves of the switchable buttons in a filter bank) in H1 SUS MC2 -- for the exact list, see first attached screenshot. For example, in the M1_LOCK_L bank, the input, and FM1 are regularly switched ON and OFF by guardian, but FM2 should always be ON. As such, we'd want the SDF system to monitor FM2, but not FM1 or the input switch. The second attachment, captured *after* we changed all settings to being monitored, and then brought the SUS up from SAFE to the IMC LOCKED, shows this. BUT, all three are controlled by the SW1S channel, which we must chose to be *either* monitored or not. So, if we chose to not monitor the input and FM1, we loose the ability to monitor FM2.

Jonathan and Dave inform me that monitoring each bit individually has been considered, but not yet implemented. I think this IMC use case scenario (which is representative of a LOT of suspension and ISC filter banks) demonstrates that we DEFINITELY need a bit-by-bit monitoring system before we can reliably roll out the SDF system for filter banks. Note -- for EPICs channels with unique identifiers, like the a GAIN, MASTERSWITCH, or matrix elements, the SDF system is already great.


Play-by-play:
- Find the directory in which a given user front end code's safe.snap lives:
    jeffrey.kissel@opsws8:~$ cd /opt/rtcds/lho/h1/target/h1susmc2/h1susmc2epics/burt/
    jeffrey.kissel@opsws8:/opt/rtcds/lho/h1/target/h1susmc2/h1susmc2epics/burt$ pwd
    /opt/rtcds/lho/h1/target/h1susmc2/h1susmc2epics/burt
- Make sure it's a soft link to the userapps repo:
    jeffrey.kissel@opsws8:/opt/rtcds/lho/h1/target/h1susmc2/h1susmc2epics/burt$ ls -l safe.snap
    lrwxrwxrwx 1 controls controls 63 Jan 11 15:19 safe.snap -> /opt/rtcds/userapps/release/sus/h1/burtfiles/h1susmc2_safe.snap
- Add a "1" to the end of the line for all EPICs settings channels in the safe.snap file, such that all settings go from being unmonitored to monitored -- do so using Jamie's USERAPPS/sys/common/scripts/sdf_set_monitor, documented in LLO aLOG 15907:
    jeffrey.kissel@opsws8:/opt/rtcds/lho/h1/target/h1susmc2/h1susmc2epics/burt$ sdf_set_monitor 1 safe.snap
- Try to be too clever, and use the command line to push the "LOAD Table Only" button:
    jeffrey.kissel@opsws8:/opt/rtcds/lho/h1/target/h1susmc2/h1susmc2epics/burt$ caput H1:FEC-39_SDF_RELOAD 1
    Old : H1:FEC-39_SDF_RELOAD           0
    New : H1:FEC-39_SDF_RELOAD           1
- Watch with sadness at the MC2 suspension get immediately forced to a safe.snap and the IMC lose lock. Why? Because *all three* SDF load buttons are the same channel, but a request of "1" performs the "Load Settings and Table" action. Too greedy.
- Use SUS guardian (just because that's the screen I had open) to request ALIGNED again, so no action, realized it was because MC2 was managed by the IMC_LOCK manager, which eventually requested the same, and restored the IMC.
- Begin to hand edit the modified safe.snap
    jeffrey.kissel@opsws8:/opt/rtcds/lho/h1/target/h1susmc2/h1susmc2epics/burt$ gedit safe.snap&
- Get scared that you're not changing the right channel, make a few mistakes, hit the reload button, eventually run into the fundamental flaw described above and stop.
Images attached to this report
Comments related to this report
daniel.sigg@LIGO.ORG - 11:00, Friday 16 January 2015 (16113)

This was one of the main findings with our test setup past summer. The control values for the standard filter modules need support at the bit level. This required both a mask field to indicate which bits are watched, and support for command strings which are modelled after ezcaswitch. Back then we used the following convention:

The supported command strings were of the form “keyword [[bit]+ cmd]+”. The keyword is either “bits” or “switch” supporting a generic bit encoded value or a standard filter module. The allowed fields for ‘cmd’ can be one of the following:

  • ON: indicates that the switch or filter stage is on,
  • OFF: indicates that the switch or filter stage is off, and
  • MAN: indicates that the switch or filter is in manual mode (i.e., not watched).

For the type “bits” the allowed values for bit are B0 to B31 and ALL. For the type “switch” (standard filter module) the allowed values for bit are one of the following:

  • INPUT: denotes the state of the input switch,
  • OFFSET: denotes the state of the offset enable,
  • FM1, … FM10: denotes the state of the individual filter stages,
  • LIMIT: denotes the state of the limiter,
  • DECIMATION: denotes the state of the decimation filter,
  • OUTPUT: denotes the state of the output switch,
  • HOLD: denotes the state of the hold output switch,
  • ALL: includes all of the above,
  • IO: includes INPUT, DECIMATION and OUTPUT, and
  • FMALL: includes all filters stages.

All switches which are not listed were set to off.

jameson.rollins@LIGO.ORG - 11:41, Friday 16 January 2015 (16114)

I really don't think the filter module monitoring is such a big deal, assuming we can get guardian internal settings monitoring working . If a guardian node is flipping bits in a filter module, then that node can just monitor the entire filter bank.  We shouldn't have multiple different guardian nodes touching the same filter module, so this really shouldn't be an issue.  This is not a "fundamental" flaw in the system, so no need to panic.  We can easily work around this.

H1 ISC
kiwamu.izumi@LIGO.ORG - posted 19:24, Thursday 15 January 2015 - last comment - 10:00, Friday 16 January 2015(16105)
locking tonight; DRMI + arms, but no CARM reduction yet.

Sheila, Kiwamu, Evan, Nergis, Alexa,

Since we got ALS diff working again, we moved onto the full lock attempt. So far we got back to a point where DRMI was locked with the arm cavities held by ALS at a off resonance. We locked DRMI twice this evening and each time DRMI dropped the lock right after the ASC loops came in. We need to look into this issue.

Even though we had aligned the DRMI before attempting the full lock, the DRMI looked misaligned a lot when we restored PRM and SRM. It seems that we ran a wrong ASC offloading script by accident in the initial alignment process which left a unneccessary offset in the M2 stage of PRM. We realigned PRM by misaligning SRM and locking PRMI while keeping the arm cavities locked. This gave us back good alignment in DRMI. However it took more than 15 minutes to get DRMI locked for some reason in both times. The DRMI unllocked right after the ASC loops came in both times. According to a brief look at the first lock loss, it seems that all three DRMI length error signals showed monotonically-increasing-oscillation for 0.5 sec before it unlocked (see the attached 0.5 -ish sec time series). Interestingly, IMC transmitted power increased at the same time by 10% or so. It is unclear what was going on at this point. Another thing is that it seems that the DRMI pulled ALS diff down when it unlocked and therefore this resulted in unlock of IMC.

Images attached to this report
Comments related to this report
alexan.staley@LIGO.ORG - 10:00, Friday 16 January 2015 (16110)

Note: at one point we had DRMI locked without the arms, and we had trouble engaging the INP1 wfs loop which feeds back to IM4 and PRM. We decided to leave this loop off for now. It's also possible that we can only turn on the PRC1 loop after the other loops are at high BW, but this theory is not well confirmed.

H1 PSL (CDS)
david.barker@LIGO.ORG - posted 17:10, Thursday 15 January 2015 (16102)
PSL ISS SDF changes

I set all channels to be sdf monitored on h1psliss,fss,pmc,dbb using the "sdf_set_monitor 1 " command. I then unmonitored the 4 channels which are changing daily on PSL ISS

H1:PSL-ISS_REFSIGNAL, H1:PSL-ISS_SECONDLOOP_REF_SIGNAL_ANA, H1:PSL-ISS_SECONDLOOP_SERVO_ON, H1:PSL-ISS_SECONDLOOP_PD_SW

I loaded all four tables into the four FE models.

H1 SEI (SEI)
sebastien.biscans@LIGO.ORG - posted 16:30, Thursday 15 January 2015 (16100)
HAM3 new configuration

By switching the RY blend from 01_28 to 250mHz, we make the 0.6Hz peak disappear (see this log).

Until we find from where this peak is coming from, we'll stay in this new configuration on HAM3. The performance seems pretty similar, except in X where we reinject more noise at low frequency.

Images attached to this report
H1 General
jim.warner@LIGO.ORG - posted 16:24, Thursday 15 January 2015 (16099)
Shift Summary
8:15 Aaron to CER swapping8:158:15 Aaron to CER swapping back HAM3 ISI coil drivers
8:30 Jeff & Andres to LVEA 3IFO SUS
8:45 Mitch to LVEA 3IFO signage and parts hunting, out 9:30
9:00 Travis to EY for PCAL parts
9:30 Corey to Squeezer bay
9:30 Betsy to LVEA, out 9:45
9:30 Rick & Jason to PSL and Diode room
10:00 Fil taking down PEM AA chassis
10:00 Travis to EX
10:15 Bubba to EX to turn off clean room, back at 11:00
10:45 Kyle to LVEA biergarten to turn on ion pump controller
11:00 JeremyB to MR then MX
12:45 Travis & Sudarshan to EX
13:00 Kyle back to biergarten, valving out aux cart
12:45 Fil to LVEA
13:45 Jason & Doug to MY
14:00 Bubba to Ex to turn on a heating unit
 
 Aaron to CER swapping back HAM3 ISI coil drivers
8:30 Jeff & Andres to LVEA 3IFO SUS
8:45 Mitch to LVEA 3IFO signage and parts hunting, out 9:30
9:00 Travis to EY for PCAL parts
9:30 Corey to Squeezer bay
9:30 Betsy to LVEA, out 9:45
9:30 Rick & Jason to PSL and Diode room
10:00 Fil taking down PEM AA chassis
10:00 Travis to EX
10:15 Bubba to EX to turn off clean room, back at 11:00
10:45 Kyle to LVEA biergarten to turn on ion pump controller
11:00 JeremyB to MR then MX
12:45 Travis & Sudarshan to EX
13:00 Kyle back to biergarten, valving out aux cart
12:45 Fil to LVEA
13:45 Jason & Doug to MY
14:00 Bubba to Ex to turn on a heating unit
 
back HAM3 ISI coil drivers
8:30 Jeff & Andres to LVEA 3IFO SUS
8:45 Mitch to LVEA 3IFO signage and parts hunting, out 9:30
9:00 Travis to EY for PCAL parts
9:30 Corey to Squeezer bay
9:30 Betsy to LVEA, out 9:45
9:30 Rick & Jason to PSL and Diode room
10:00 Fil taking down PEM AA chassis
10:00 Travis to EX
10:15 Bubba to EX to turn off clean room, back at 11:00
10:45 Kyle to LVEA biergarten to turn on ion pump controller
11:00 JeremyB to MR then MX
12:45 Travis & Sudarshan to EX
13:00 Kyle back to biergarten, valving out aux cart
12:45 Fil to LVEA
13:45 Jason & Doug to MY
14:00 Bubba to Ex to turn on a heating unit
H1 PEM (PEM)
dale.ingram@LIGO.ORG - posted 16:24, Thursday 15 January 2015 (16098)
Friday Seismic Forecast
Expect the usual day shift and swing shift 1-3 Hz noise on Friday.  No weekend Hanford transportation activity is scheduled.  It's possible that Hanford hauling through the Wye barricade could decrease by 30-40% after March and make another significant decrease in July as excavation operations in the 300 area wind down.  Hauling from the 618-10 remediation area on Stevens will continue.  The uncertainty associated with these forecasts is large, however.
H1 ISC
alexan.staley@LIGO.ORG - posted 15:59, Thursday 15 January 2015 - last comment - 18:38, Thursday 15 January 2015(16097)
ALS DIFF OK

Sheila, Kiwamu, Evan, Nergis, Alexa

We have been able to lock ALS DIFF for +20 min.

I have attached screen shots of the ALS DIFF filter configuration. In addition, I have attached the ALS_DIFF Spectrum, UIM/ESD crossover, and OLTF. The ALS DIFF spectra shows that the noise is suffeciently low to move onto locking.

Images attached to this report
Non-image files attached to this report
Comments related to this report
alexan.staley@LIGO.ORG - 18:38, Thursday 15 January 2015 (16104)

We have gone back to FM1, FM2 ON, FM10 OFF, Gain -1 for the ETMX L1 L2P. We also turned off FM3 of the top mass L and Y dampling filters.

H1 ISC
koji.arai@LIGO.ORG - posted 14:27, Thursday 15 January 2015 - last comment - 18:29, Monday 19 January 2015(16089)
H1 OMC cavity length noise measurement with PDH locking

[Koji, Dan]

This is a followup entry for LHO ALOG 16034.

Summary

- The OMC cavity was locked with PDH locking by implementing a bypass optical path from at the OMC REFL to the AS resonant RF PD.
- The OMC cavity length displacement was measured. It is found in the 4th attachment.
- It is mostly consistent with Zach’s measurement LLO ALOG 8674 and has x3 better floor level at some frequencies.
- There is a forest of peaks above 400Hz to 1.3kHz. They were very easily excited by light tapping on the HEPI crossbars


Motivation

- The length noise of the Output Mode Cleaners at LHO and LLO were so far locked with the transmission DCPDs with length dither or mid fringe with CDS.
- The measurement bandwidth with these techniques was limited by the CDS bandwidth (8kHz) or the dither frequency (2~3kHz). The cavity length noise above these frequencies wer e unknown.
- The measurements were also prone to the intensity noise on the beam. As the base band is at audio frequency in either cases, it is hard to be shot noise limited without proper setting of the intensity stabilization. Some features in the spectrum were not distinguishable from the intensity noise.

- PDH locking of the OMC was expected to provide an independent measurement of the OMC length noise with possibly better sensitivity, as the PDH locking is in principle insensitive to the intensity noise.
- In fact, the most of the conmponents for the PDH locking were already there. If we use the single bounce beam from one of the ITMs, the beam is already phase modulated. An RF PD is at the same table with the OMC REFL beam. The detection system and actuator are on the field racks next to HAM6. Therefore the effort of the PDH locking was minimal.

Configuration

- The ITMY single bounce beam was guided to the OMC. i.e PRM/SRM/ITMX/ETMX/ETMY were misaligned.
- The beam alignment to the OMC was controlled using OMC QPDs. The dither alignment servo has not been configured and was not functional at the time.
- The OMC REFL beam was aligned to the OMCR path on ISCT6 by moving an in-vacuum picomotor as Dan described as Dan described.

- The OMCR beam was introduced to ASAIR_A PD without moving existing optics on the table. As found in the figure (attachment 1), an additional optical path was added to the OMCR path. The OMCR beam was deflected between two lenses and brought to AS45 PD going through the space between the mirrors in the AS path. The beam on the PD was focused by a lens with the focal length of 150mm. This made the spot sufficiently small for the 2mm aperture of the PD.

- With the single bounce configuration, the optical power from the chamber was ~10mW.

- The servo configuration is found in the figure (attachment 2). The AS 45MHz demodulator was used for the PDH sensing (i.e. no rewiring was necessary). We found our bad luck that the proper demodulation phase was about 45 deg off and the signal size in the I and Q phases were almost the same with opposite sign. This meant that we could combine these two with another SR560. But we decided to use the I signal for the error signal.

- Since there is no digital signal path from LSC outputs to the OMC PZT, we implemented an analog servo. The error signal from the demodulator I-phase monitor channel was fed to an SR560 with gain of -2 and LPF (-16dB/Oct, fc=300Hz). The 50 Ohm output of this SR560 was fed to another SR560 with the gain of the unity. The second SR560 was used as a summing point for an openloop TF measurement. The 50Ohm output of the second SR560 was connected to an aux drive port of the HV driver.

Servo modeling

- You may wonder how just a 300Hz 2nd order LPF could make the servo stable!? In fact, we could lock the cavity even with gain of -1 with flat response. This is a subtle combination of the dewhitening and the poles and zeros formed by the PZT capacitance and the output RC network of the driver.

- The open loop transfer function of the servo was measured (attachment 3) by injecting the excitation at the second SR560 while the "after sum" (denominator) and "before sum" (numerator) signals were observed with SR785.

- Driver/actuator response: The HV Piezo driver (D060283) has two dewhitening stages and an output RC network. The dewhitening stage, which are common for the digital and external analog inputs, have two poles at 0.923Hz and two zeros at 10.15Hz with the DC gain of the unity. Note that the signal is reduced by a factor of 0.9989, as the input impedance of the driver (47.5kOhm) and the 50Ohm output impedance of the SR560 form a voltage divider. The main HV stage has the gain of 10. The output stage has the output series resister of 50k (R51) and then the parallel capacitors including the PZT capacitance of 0.51uF (Noliac NAC2124). (C11 - 0.47uF // C26+R55 - 0.47uF // Cpzt - 0.51uF). This imposes two poles at 2.19Hz and 502.1Hz, and one zero at 338.6Hz. Finally the OMC PZT2 has the calibration of 12.9nm/V (measured at Caltech), and the beam incident angle of theta = 4.04deg, and parasitic mechanical resonance of the PZT tombstone (pole at 9.5kHz Q=100 and zero at 11kHz Q=100). Don't forget that the factor of 2 i.e. cavity length change = 2/cos(theta) * PZT displacement

- The model of the openloop transfer function agrees exteremely well with the measurement. From this model, we determined the slope of the PDH signal to be 4.0e9 V/m.

Cavity displacemen noise

- Calibrated cavity displacement noise is found in attachment 4.
- The red curve is the error signal calibrated in the unit of displacement. The compensation of the loop supression was applied to this red curve in order to obatin the "estimated free running motion" of the cavity (Blue curve).
- The estimated cavity displacement seems to have better floor level by a factor ~3 compared to the half-fringe measurement at LLO. Also the spectrum below 300Hz looks cleaner and smoother. We wonder what is the cause of this noise.
- Similar to the LLO measurement, the spectrum has forest of peaks from 400Hz to 1.3kHz. There is very eminent peak at 9.5kHz which is associated with the prism resonances of the cavity.

- The dark noise was estimated to be 3.3x10-17m/rtHz. I made the simplest estimation of the shot noise level. The dark noise was assumed to be limited by the PD noise. The shot noise intercept current is 2mA and the photocurrent was ~8mA. Therefore the shot noise level was estimated to be 3.3x10-17x Sqrt(8/2) = 6.6x10-17 m/rtHz.

Peaks between 400Hz and 1.3kHz

- It is unlikely that the OMC cavity itself has such many mechanical resonances from 400Hz to 1.3kHz. It is known that the OMC cavity has one high Q resonance at 1kHz (body bending mode). But any other resonances are above 3kHz.

- We tapped the ISCT6 tables, theHEPI crossbars, and chambers in order to see if we can excite these forest somehow.
- Basically everything is accoustically coupled. But we dare to say that the table does not excite the noise much. The most sensitive one was the HEPI crossbars. Just light touch of a HEPI cross bar excited the modes nearly x100 (attachment 5). This excitation was more eminent at the HEPI crossbars than at the chamber or the flange for the windows.

Still to do

- The displacement data is to be compared with the measurements with the other techniques.
- The displacement with PDH while the cavity is locked with the dither locking.
- Noise coupling from the OMC ASC.
- Evaluate frequency noise coupling.
- Actuator noise from the PZT driver.

Images attached to this report
Non-image files attached to this report
Comments related to this report
koji.arai@LIGO.ORG - 12:28, Friday 16 January 2015 (16115)

The PZT HV/LV driver outputs were measured. They were calibrated to be equivalent to the cavity displacement.
There are AC and DC outputs for each of the HV and LV PZT voltages. The plot shows min(disp. AC, disp. DC) to give the upper limit of the driver noise.

They look suspiciously close to the measured OMC length displacement. However, we can't exclude the possibility that the readout circuit noise is limiting this measurement.

Images attached to this comment
Non-image files attached to this comment
koji.arai@LIGO.ORG - 18:29, Monday 19 January 2015 (16146)

There was some mistake in the shotnoise calculation. The revised plot is here.
This tells us that the sensing noise is well below the measured noise level.

Images attached to this comment
Non-image files attached to this comment
LHO VE
kyle.ryan@LIGO.ORG - posted 13:54, Thursday 15 January 2015 (16095)
~1315 hrs. local -> Decoupled pump cart from BSC3 annulus -> New ion pump Ok


			
			
H1 IOO (IOO, SUS)
sheila.dwyer@LIGO.ORG - posted 22:37, Wednesday 14 January 2015 - last comment - 18:12, Thursday 15 January 2015(16087)
MC1+MC3 tripping

We have had at least three incidents today where MC1 and MC3 both tripped, we haven't had time to investigate why but this is a new phenomenon.  

Comments related to this report
john.worden@LIGO.ORG - 18:12, Thursday 15 January 2015 (16103)

Kyle and Gerardo were operating the large Genie manlift at BSC3 on Wednesday and I believe also used the overhead crane in that region in order to replace a failed annulus ion pump. Were the trips related to excess motion?

H1 PEM
filiberto.clara@LIGO.ORG - posted 16:16, Wednesday 14 January 2015 - last comment - 14:49, Thursday 15 January 2015(16076)
H1 AA PEM Chassis - D1001421
Removed one of the PEM AA chassis to troubleshoot some bad channels. Troubleshooting/repairs is taking longer than expected but should have the unit back in service sometime tomorrow morning.

D1001421 Serial Number S1001053.
Comments related to this report
filiberto.clara@LIGO.ORG - 14:49, Thursday 15 January 2015 (16096)
Unit has been repaired and reinstalled.
Displaying reports 67321-67340 of 83002.Go to page Start 3363 3364 3365 3366 3367 3368 3369 3370 3371 End