Displaying reports 75961-75980 of 83394.Go to page Start 3795 3796 3797 3798 3799 3800 3801 3802 3803 End
Reports until 16:10, Friday 06 September 2013
H1 SEI
hugo.paris@LIGO.ORG - posted 16:10, Friday 06 September 2013 (7670)
HEPI Commissioning progress

This week, I worked on HAM-HEPI commissionig with HughR and JimW.

I perfomed what could be called "assembly validation" tests on HAM2 and HAM3 HEPI. Those tests allow checking the good mechanical behaviour of the platforms, as well as the good functionning of the sensors and actuators. Tests performed include, but ar enot limited to: Local Static Offset test (small drive in one corner, we read the IPS sensors responses in every corner), sensor spectra, and Linearity tests. Thests were concluded with transfer function measurements which confirmed that the whole chain (actuation, platform, sensors) is functional, on both platforms. Transfer functions are attached.

All results are commited under the SVN, and testing reports are ongoing.

I also started designing Isolation loops (actually position loops, using IPS sensors only). I could not get thoses loops to be stable and I don't know why. I tried different designs, lowering the ISO block gain, and decreasing the ramp time on the boost filters, with no success. I am hoping Sebastian, who is coming next week, could give the problem a fresher look.

 

In parallel, I showed HughR and JimW how to use the SEI commissioning tools on HAM6-HEPI. They noticed that one of the acutuators (V1) was performing in the reverse direction. Their throughout troubleshooting, revealed a misconection at the actuator's hoses, which they fixed.

Images attached to this report
LHO VE
kyle.ryan@LIGO.ORG - posted 16:05, Friday 06 September 2013 (7674)
Replaced scroll compressor #1 on X-end purge-air skid
Kyle, Gerardo
H1 SUS
betsy.weaver@LIGO.ORG - posted 16:05, Friday 06 September 2013 (7673)
ITMx SUS alignment - mulligan

Jason, Betsy

So after fighting the ITMx reaction chain into it's appropriate yaw and x-direction position behind the main chain all day, it was totally out in height (darn coupled mechanics).  After then adjusting it to be at the appropriate height it was totally out in yaw and x-position.  We'll start again on Monday.  I guess.

H1 ISC
jeffrey.kissel@LIGO.ORG - posted 16:03, Friday 06 September 2013 (7672)
H1 IMC up after power outtage
J. Kissel, M. Barton, H. Paris [D. Feldbaum via phone]

After getting the PSL back up, it took very little time to get the mode cleaner re-locked. 
Hugo - restored the HAM2 and HAM3 isolation systems to proper alignment
Mark - restored the mode cleaner suspensions to yesterday's alignment
JSK / Mark - burt restored h1ascimc model to regain the input periscope's PZT alignment

Mark had left Stefan's MClockwatch running on opsws3, as I had done Wednesday which happily picked it up the mode cleaner flashes and brought us to a pretty nice* lock. 

Win! Boy are we close to having a fully automated input optics chain...

*The alignment looks a little funky, but Mark's seeing plenty enough SNR to get what he needs done up at 500+ [Hz], so we're not gunna bother tweaking it.
H1 General
andres.ramirez@LIGO.ORG - posted 16:01, Friday 06 September 2013 (7671)
Ops shift Summary
Corey to LVEA East area to get items
Crane work by BSC3 (LVEA) – Apollo
Taking Measurements on ITMx (LVEA) – Dough
Cable work at End X (TMS) – Corey
H2 PSL enclosure work – Sheila/Jeff K.
Hanford Fire Department on site
Work on LVEA (Switch fixing) – Cyrus
Post mount on LVEA roof – John/Bubba
Computers Power Cycling – James/David
Doing some work at ITMx (LVEA Test Stand) – Betsy
LVEA transitioned to Laser Hazard – Justin
Concrete has been poured!
Baffle work on East Bay (LVEA) – Thomas/Lisa
Work on Dust Monitor at End X – Patrick
Measurements on Beam Splitter – Arnaud
LVEA transitioned to Laser Safe – Justin
H1 PSL
jeffrey.kissel@LIGO.ORG - posted 15:54, Friday 06 September 2013 - last comment - 00:29, Monday 09 September 2013(7663)
Getting the PSL running after 2013-09-05 Power Outage
S. Dwyer, J. Kissel, D. Barker [with help from R. Savage, P. King, D. Feldbaum, and K. Thorne by phone]

Since Sheila was the only cognizant PSL operator on site, and I wanted to learn, I followed her around as she made attempts to bring the PSL back up from yesterday's power outtage. As of ~2:00p PT (21:00 UTC), the PSL is now running in the following state: 
- Low Power (32.1 W NPRO "front end" output power)
- FSS on, ISS off (see details below)
- PSL Enclosure is in "Science Mode" with air conditioning, fans and lights turned way down or off.

The full story:

We began with the latest start-up procedure: T1200259. However, after getting through all the steps to turn on the PSL to a low-power state (as advised by Rick -- though we couldn't find an aLOG indicating that it had been left in low power), we had found two error messages left on the STAT sub-screen of the PSL Beckhoff Overview Screen (see T0900641_Figure8p8_PSLStatusScreen.png from pg 54 of T0900641): "EPICS ALARM" and "VB PROGRAM ONLINE" were red. In addition, the DIODE CHILLER (DC) [water] flow rate was a little bit below nominal threshold (> 22.5 [liters per minute]) at 21.8 [lpm] on the the CHIL screen (see T0900641_Figure8p7_ChillerScreen.png from pg 53 of T0900641). In this condition, we also found that the High Power Laser's [HPL's] external shutter would not open from the Beckhoff Overview Screen -- needed  regardless of whether you want to run in high- or low- power mode, because this shutter prevents light from continuing on to the Pre-Mode Cleaner (see T0900641_Figure7p1_HPLShutters.png from pg 27 of T0900641.)

After a couple of hours of chasing our tails flipping switches, redoing the procedure, and calling the available experts, David clued us in to a "one line" solution that Keith had put together, which Keith then pointed us to: LLO aLOG 2322, indicating that the H1:PSL-EPICSALARM is the culprit. Regrettably, Keith's network layout and computer configurations are arranged just differently enough that we couldn't use his exact solution. Instead, Dave and I looked for this channel, and found the channel buried in the 
${userapps}/opt/rtcds/userapps/trunk/psl/h1/models/h1pslpmc.mdl,
(which was, of course, tough to find because the model is two years old, and still uses the now-defunct pink EzcaRead block, with the full channel name hard-coded at the top level),
and as Dave mentions, we traced the logic back to a latched flow rate alarm in the MIS sub-block (this inside of which is shown in h1pslpmc_MIS.png). Another interesting point: though the four channels in the front end which control define the H1:PSL-EPICSALARM,

H1:PSL-MIS_FLOW_OK
H1:PSL-MIS_CLOSE_SHUTTER_IO
H1:PSL-MIS_CLOSE_SHUTTER_ISC
H1:PSL-MIS_CLOSE_SHUTTER_CTRL_ROOM

are displayed on the MEDM / EPICS version of the PSL Overview Screen (as seen from the control room, see PSL_OVERVIEW_SCREEN.png), H1:PSL-EPICSALARM is not shown and therefore the link between these EPICS variables and the Beckhoff alarm is unclear. It turns out, as Dave mentioned, only H1:PSL-MIS_FLOW_OK was still red after Sheila and I gave up poking around, so Dave and I queried the threshold and trigger variables "manually" via caget (because they're also not shown on the EPICS or Beckhoff screens) and found the trigger variable comfortably in the range, so we reset it. For future reference,

controls@opsws8:models 1$ caget H1:PSL-MIS_FLOW_INMON
H1:PSL-MIS_FLOW_INMON          -5373.77
controls@opsws8:models 0$ caget H1:PSL-MIS_FLOW_UPPER
H1:PSL-MIS_FLOW_UPPER          -5000
controls@opsws8:models 0$ caget H1:PSL-MIS_FLOW_LOWER
H1:PSL-MIS_FLOW_LOWER          -6000

(Note: these threshold and trigger variables are uncalibrated, so it's unclear how these counts relate to [lpm] shown on the Beckhoff screen.)

As soon as we reset this variable, the STATUS screen started blinking wildly, and we appeared to be back in business as all of the automated loops took over. Nice!

However, we noticed after a few minutes that the reference cavity would not remain locked for more than 10 - 30 seconds. I had assumed this was because the laser still needed to warm up, and there was some sort of mode mismatch and/or thermal issues with the ISS/FSS. After a few hours (telecons) of letting the PSL warm up, we found the reference cavity still blinking in and out of lock. Sheila and I sat down to diagnose, but found ourselves too ignorant of the FSS and ISS to really figure out what the problem was. We simply tried various combinations of switching the autolockers for both ON and OFF, and found that the refcav stayed locked with only the FSS running. Since we just want to get the mode cleaner locked enough for Mark to continue violin mode hunting and for Jamie to play around with Guardian, we figured leaving the ISS off -- until those with further expertise return -- would be just fine.

Images attached to this report
Comments related to this report
christina.bogan@LIGO.ORG - 00:29, Monday 09 September 2013 (7678)
The reset button on the Laser.adl was implemented and accepted by the PSL team in July. As announced on the PSL mailing list this should prevent the model from opening and closing the external laser shutter each time the flow sensor triggered without any user interaction. We observed in Hannover that this could happen, when the flow is close to the threshold. 

We should definitely add that point to the startup procedure. 

The values for the flow watch cannot be calibrated into lpm, because they just refer to the flow in comparison to the manual slide bar position onto the flow sensor. 
LHO General
bubba.gateley@LIGO.ORG - posted 15:28, Friday 06 September 2013 (7669)
Apollo crew
We relocated the E-module to the east side of BSC 3 and placed the small garbing/clean room back on the platform. We positioned the BSC clean room over the chamber and started retro fitting the curtains and entry access from E-module.
Tyler had some small jobs in the machine shop for Corey G.
LHO General
patrick.thomas@LIGO.ORG - posted 15:18, Friday 06 September 2013 (7668)
couldn't bring the end X dust monitor back
I tried:

restarting the IOC
power cycling the dust monitor (Corey did this for me)
power cycling the Comtrol
removing the weather station from the Comtrol (I left it removed)
screwing in the DB9 connector from the Comtrol on the breakout box (it was connected but not screwed in)
checking the fuse in the breakout box (it looked fine)

The IOC can connect to the port, but it doesn't seem to be able to establish communication with the dust monitor. Corey looked at the dust monitor from inside the clean room and said that it is showing numbers on the front panel.
H1 SEI
hugh.radkins@LIGO.ORG - posted 15:15, Friday 06 September 2013 (7667)
WHAM6 Corner1 Vertical HEPI Actuator Hoses Switched
Well the problem reported previously was caused by an issue we did not imagine we could have done.  However, it was not only possible but in fact was done.  We crossed the hoses so the flow was backwards through the Actuator.  Not sure how/why this causes it to perform so well only backwards but it does.  This has been corrected and the Actuator is now back in bleed mode.  We did lose some fluid (expected and all captured) so we will remain in bleed mode at least through the weekend.

We also checked the hoses on HAM 4 & 5 and believe there are no other instances of this error.  Thanks Celine!
H1 SUS
arnaud.pele@LIGO.ORG - posted 12:09, Friday 06 September 2013 (7662)
ITMX clear of rubbing

A spectra of ITMX has been taken this morning, and the frequencies of the peaks were compared with the ones from the "wire-hang model". They were matching very well, meaning the main chain of ITMX is currently freely suspended.

H1 PSL
david.barker@LIGO.ORG - posted 12:05, Friday 06 September 2013 - last comment - 14:21, Friday 06 September 2013(7661)
opening the PSL shutter, latched closed by the PMC front end model

The PSL PMC model controls a PSL shutter via ezcawrites to the EPICS record H1:PSL-EPICSALARM which runs on the Beckhoff IOC/OPC in the diode room. It was discovered that the shutter was being driven closed. We tried reading the status of H1:PSL-EPICSALARM using caget on the OPS and H1FE LAN, but did not get a value. Later we found that caget does not work with this PV, but PROBE and EDCU are able to give its value. This slowed up our investigation slightly. Looking at the MIS part of the PMC model, we found that the coolant flow is in range, but the FLOW_OK was latched bad. We pressed the FLOW_ERR_RESET button, and the FLOW_OK came good and the shutter opened. Trending H1:PSL-EPICSALARM shows it transitioning from ONE to ZERO at this time.

Comments related to this report
keith.thorne@LIGO.ORG - 14:21, Friday 06 September 2013 (7664)
which would be why I suggested looking at this LLO aLOG entry which detailed the use of ezcaread/ezcawrite for setting/reading this variable.
H1 AOS
lisa.austin@LIGO.ORG - posted 11:51, Friday 06 September 2013 (7660)
SLC activities at LHO
Thomas Vo, Mitchell Robinson, Tyler Guidry, Lisa Austin

Arm Cavity Baffle for ETM-x (BSC9) assembly complete and ready for balancing.
For balancing, Extender Shelf distance must be set; Sliding Weights must be set; & Magnet damping spacing must be set.

SR2 Scraper Baffle ready for installation in H1-HAM4. Needs to be packaged for transport from cleanroom. [pic3]
 
SR2 Scraper Baffle ready for packaging and storage for 3rd IFO - HAM4. [pic2]

H1-HAM5 SR3 AR, SR3 HR and SRM Baffles ready for installation. Needs to be packaged for transport from cleanroom. [pic 1]

H1-HAM4 SR2 AR and Hartmann Baffles ready for installation. Needs to be packaged for transport from cleanroom. [pic 4]
Images attached to this report
H1 CDS
david.barker@LIGO.ORG - posted 11:05, Friday 06 September 2013 (7659)
Front ends power cycled, daq restarted

The MSR UPS unit did not log any power problems yesterday, but h1susb123 froze up completely and all Dolphin connected front end computer models crashed. Following previous power glitches we have had supposedly running models not actually working correctly until the computer was power cycled, so this morning we power cycled all H1 front ends to be safe.

h1seih23 showed an initial IRIGB/DuoTone error which went away after about 10 mins, this phenomena has been noted at LLO as well.

On Christina's request, the PSL models were burt restored to 19:00 29th August rather than using the safe.snap.

Vincent had made an INI change to h1hpiitmy, I restarted the DAQ to capture the new configuration.

X1 SUS
james.batch@LIGO.ORG - posted 10:49, Friday 06 September 2013 (7658)
X1 Triple Trest Stand IOP Started, Other Test Stands OK
The IOP model for the X1 triple test stand has been restarted following the power glitch Thursday evening.  The DAQ was restarted as well.  

The other staging building test stands are also OK.
X1 DTS
james.batch@LIGO.ORG - posted 10:31, Friday 06 September 2013 (7657)
X1 DAQ Test Stand restarted
As a result of the Thursday evening power glitch, all computers on X1 DTS have been restarted.  The system is now functional.  
H1 CDS
cyrus.reed@LIGO.ORG - posted 10:26, Friday 06 September 2013 (7656)
Updated h0digivideo0 and 1
h0digivideo0 and h0digivideo1 both restarted last night as they are not on UPS power.  Before restarting the camera iocs, and the camera code (h1cam12 on h0digivideo1 only as it is the only one currently installed), I took the opportunity to run the Ubuntu OS updates for both servers and reboot them.
H1 SEI
hugh.radkins@LIGO.ORG - posted 10:23, Friday 06 September 2013 - last comment - 15:04, Friday 06 September 2013(7655)
WHAM6 Corner1 Vertical HEPI Actuator Response still backward
Since it seems like we have done all we can (although Richard is game to look at a few more things), we have inserted a -1 gain  in the Output Filter bank of HAM6 V1.  This is not standard and none will rest peacefully with this pea under our mattress.
Comments related to this report
hugh.radkins@LIGO.ORG - 15:04, Friday 06 September 2013 (7666)
Found the problem--Installation error!
H1 SUS
mark.barton@LIGO.ORG - posted 17:14, Thursday 05 September 2013 - last comment - 14:26, Friday 06 September 2013(7644)
PRM and SRM model updates

Following on Filiberto's upgrade of the M2 driver boxes on PRM and SRM per alog 7630, I updated the h1susprm and h1sussrm models to match, piggybacking on his work permit 4117:

* I changed the PRM and SRM blocks at the top level to use the MC_MASTER part (as for MC2 which was modified earlier) rather than HSTS_MASTER.

* Per Stuart's suggestion, I terminated the three new outputs MC_X_M*_OUT on the new part (rather than feeding them into an IMC block as for MC2).

* I copied the matching M2_COILOUTF filter definitions from the latest copy of L1SUSMC2.txt in the SVN after checking that they corresponded to LLO alog 4495.  (Ideally I would have gotten them from H1SUSMC2.txt, but it appears we've never updated them there. I held off doing that at this time because it will need a separate WP and because there's a risk of breaking the IMC locking if something is counting on the existing poor compensation, but we should get to it soon, after we confirm that it's working for PRM and SRM.)

* I rebuilt and restarted both models. h1sussrm came up with no problems except for a few bad entries in the safe.snap, which I corrected. (There were lines like H1:SUS-SRM_M1_DAMP_L_STATE_GOOD 1 H1:SUS-SRM_M1_DAMP_L_STATE_GOOD 100676356" which were hangovers from a faulty script used at one time. I deleted the first half of each line. The PRM safe.snap had the same issue, but BURT didn't complain (see next item). I fixed it in the same fashion anyway.)

* Initially the PRM model showed a red DC bit and many of the EPICS values were not properly initialized. I realized after posting the initial version of this alog that I hadn't saved after the last edit, so the MC_MASTER block was still called MC_MASTER, so all the channel names were wrong. I saved the model, rebuilt and restarted it and this time the DC bit was green. I'll follow up with Dave Barker tomorrow to see if there's any corrective action needed re the MC_MASTER channels that were being written temporarily. The hourly backup for 16:00 hours is corrupt but the 15:00 and 17:00 ones are good.

* I committed the new models, filters and safe.snap files.

Comments related to this report
mark.barton@LIGO.ORG - 14:26, Friday 06 September 2013 (7665)

My  fix of yesterday for the dud lines in the PRM and SRM safe.snap files wasn't quite right - I had deleted the erroneous second copy of the channel names, but I should have left the "1":

H1:SUS-PRM_M1_DAMP_L_STATE_GOOD 1 100676356
H1:SUS-PRM_M1_DAMP_P_STATE_GOOD 1 113258548
H1:SUS-PRM_M1_DAMP_R_STATE_GOOD 1 113258548
H1:SUS-PRM_M1_DAMP_T_STATE_GOOD 1 113258548
H1:SUS-PRM_M1_DAMP_V_STATE_GOOD 1 113258548
H1:SUS-PRM_M1_DAMP_Y_STATE_GOOD 1 113258548
 

H1:SUS-SRM_M1_DAMP_L_STATE_GOOD 1 100676356
H1:SUS-SRM_M1_DAMP_P_STATE_GOOD 1 113258548
H1:SUS-SRM_M1_DAMP_R_STATE_GOOD 1 113258548
H1:SUS-SRM_M1_DAMP_T_STATE_GOOD 1 113258548
H1:SUS-SRM_M1_DAMP_V_STATE_GOOD 1 113258548
H1:SUS-SRM_M1_DAMP_Y_STATE_GOOD 1 113258548

I committed the new fix.

Displaying reports 75961-75980 of 83394.Go to page Start 3795 3796 3797 3798 3799 3800 3801 3802 3803 End