Displaying reports 80521-80540 of 88261.Go to page Start 4023 4024 4025 4026 4027 4028 4029 4030 4031 End
Reports until 12:19, Friday 04 October 2013
H1 SEI
hugh.radkins@LIGO.ORG - posted 12:19, Friday 04 October 2013 (7995)
WBSC8 ETMX Friday Noon Update
Thomas, Mitchell & Jason got the majority of the fixturing out of the chamber, bagged & wrapped, and out of the VEA.  They then got the retroreflector hanging on the Quad.
We then unlocked the HEPI and leveled & set the elevation of the Optical Table per D0901152.  I set the system ~.5mm low as IAS found the Optic 0.4mm high on the Test Stand.  The level is within +-0.1mm and the elevation is within 0.3mm; good enough since we still likely have much horizontal adjustment to do.
With the retroreflector in place, we then shot an X position.  IAS is still evaluating that result.
LHO General
patrick.thomas@LIGO.ORG - posted 11:25, Friday 04 October 2013 (7993)
Turning off dust monitor 8 appears to kill dust monitor 9
I noticed this morning that dust monitor 9, which had previously been dropping in and out of communication, was no longer coming back. I went out and looked at it, but didn't notice anything obvious. I also managed to smack my head on one of the light pipes between the H1 PSL enclosure and HAM1.

I connected to the IOC screen, pressed Start on the medm for the dust monitor, and got a read timeout reported by the IOC.

I then trended the mode back, which should oscillate from 'holding' to 'running' every minute, to see when communication was lost. Seeing that it stopped yesterday, I compared it to dust monitor 8, which I had turned off and removed yesterday. The two times are in close agreement (see attached plot).
Non-image files attached to this report
H1 CDS
david.barker@LIGO.ORG - posted 10:30, Friday 04 October 2013 (7992)
DAQ restart last night caused some DAQ errors

The DAQ was restarted twice yesterday evening at 20:15 and 20:50 local time. The second restart precipitated two problems:

The front ends affected were: h1susauxex, h1susex, h1pemmx, h1lsc0, h1susauxey, h1seib2, h2seib3, h1susbstst, h1susauxh2, h1sush56, h1sush34, h1sush2b.

All data from these front ends will have been marked as bad (zero'ed) in the frames between 03:51 and 16:11 UTC today, 4th October.

Jim restart h1broadcast0 and restart MX-Streams on the affected front ends to restore the DAQ.

LHO General
patrick.thomas@LIGO.ORG - posted 10:27, Friday 04 October 2013 (7991)
plots of dust counts
Attached are plots of dust counts requested from 4 PM October 2 to 4 PM October 3.
Non-image files attached to this report
LHO General
john.worden@LIGO.ORG - posted 10:00, Friday 04 October 2013 - last comment - 12:06, Friday 04 October 2013(7990)
LVEA Purge Air Compressor Kobelco

The purge air system is up and running again. The Kobelco air compressor had shut down on an over temperature alarm which has been determined to be an open circuit RTD.

As a temporary fix a 1k resistor has been installed in place of the RTD.

 

Temps now after one hour of run time are:

 

1st air discharge - 287F

2nd air suction - 85 F

2nd air discharge - measured at 210F Front panel says 65F(1k resistor)

lube oil - 104F

Comments related to this report
john.worden@LIGO.ORG - 12:06, Friday 04 October 2013 (7994)

Temperatures remain the same at 12:00

H1 ISC
christopher.wipf@LIGO.ORG - posted 08:08, Friday 04 October 2013 (7986)
EY Beckhoff running

Yesterday Filiberto cabled the EY Beckhoff system, and we started it up.  We now have the full complement of Ethercat systems up and running for H1.

Fiber links from the corner to both end stations were verified to be working (by looking at their keepalives in Twincat).  Also, the Acromag binary I/O at both end stations was checked, by looking at the whitening readbacks in EPICS.  At EY, you could move the whitening sliders and switches around and everything worked fine.  But the EX screens showed errors.  It turned out that the Acromag chassis (S1203593) needed to have its network settings configured (following the procedure in T1100607). After this was done, the EX screens worked, and using the digital I/O test harness, I verified that the Acromag chassis outputs were actually switching.

Finally, I made a script to start Maggie's EPICS IOC on h1ecaty1 (analogous to the one found on h1ecatx1). This temporary EY script is located at: C:\SlowControls\EPICS\Utilities\Bin\start_h1y1.bat

H1 ISC
jeffrey.kissel@LIGO.ORG - posted 23:17, Thursday 03 October 2013 (7984)
Online Detector Characterization Channels implemented to the H1 IMC ASC
J. Kissel, S. Ballmer, D. Macleod, R. Fisher  

In order to further my quest to have data analysts use the IMC as their new fake gravitational wave channel, such that the *real* DetChar can begin, (and OK, because the ODC is now a blessed and essential portion of the aLIGO scope) I've installed the an Online Detector Characterization channel into the H1 ASC IMC model. This new channel is H1:IMC-ODC_CHANNEL_OUT_DQ, sampled at 2048 [Hz]. Details of the bit descriptions are outlined below. I have tested its functionality by creating a disgustingly basic MEDM screen linked off the top left corner of the IMC Overview screen (see attached) and testing that the bits all have the expected behavior -- all but one behave as expected*. The IMC runs as smoothly as it did before I got started.

Since there are a few new filter banks, a whole bunch of new epics records, some screen changes, and a front end model change, I've made sure to re-capture a new safe.snap, and have committed all of the following to the repo:
/opt/rtcds/userapps/release/asc/h1burtfiles/h1ascimc_safe.snap
/opt/rtcds/userapps/release/asc/h1models/h1ascimc.mdl
/opt/rtcds/userapps/release/asc/h1filterfiles/H1ASCIMC.txt
/opt/rtcds/userapps/release/ioo/h1/medm/IMC_CUST_OVERVIEW.adl
/opt/rtcds/userapps/release/ioo/common/medm/IMC_CUST_ODC.adl

where "safe" is a fully operational system, just with the WFS master switch off. Note that I've made several modifications to the prototype version provided to me by Ryan and Duncan, but the modifications were based on conversations with Stefan, and to otherwise increase clarity of the system.

Note that the addition of new filter banks meant I had to restart the DAQ / Data concentrator (twice, because I'd misspelled one of the new filter banks).

Also, it really seems like these WFS loops are oscillating way too much. We should look into why, or Paul's going to be very sad tomorrow when he measures the beam jitter of the IMC.

Finally, though Cheryl said she'd just aligned the Broad Band PD gathering the leakage beam at the bottom of the PSL periscope to determine the power going into vacuum, its channel (H1:IMC-PWR_IN_OUTPUT) is showing a dead -29.89 [ct].

----------------
Bit description:
----------------
There are 13 bits associated with this channel:
BIT1 : Indicator of whether the IMC ASC control system is requested to be on. This compares 
- the final product of the trigger from IMC transmission PD (just after IM1, indicating the length control is on and the cavity is locked [H1:IMC-TRIG_MON]), 
- the WFS masterswitch (H1:IMC-WFS_SWTCH), and
- the WFS master gain (H1:IMC-WFS_GAIN) 
against unity. If all are three components are one, then their product will be one, the WFS are requested to be turned on, and the bit goes high.
* I can't get this bit to turn green. I think it's because the master switch is and EPICs Binary as opposed to a standard EPICs Input. The product of these three things seems to be zero, yet the WFS are on and servo-ing just fine. We'll have to debug this tomorrow.

BIT2, BIT3, BIT4, BIT5 : Indicative of the control pitch system operating as expected, with small error signals, and therefore the IMC is well-aligned. (The equivalent of) H1:IMC-DOF_[1,2,3,4]_P_IN1 -- the error points of the WFS loops -- are low-passed in the banks H1:IMC-ODC_DOF[1,2,3,4]_PIT_ERRFILT. If the absolute value of those low-passed error points are less than a pre-defined threshold (H1:IMC-ODC_DOF[1,2,3,4]_PIT_MAX), then BITS 2, 3, 4, and 5 go high. 
As the IMC ran while commissioning the ODC channel, I found that threshold values of 10000, 10000, 10, and 10 [ct] for DOFs 1, 2, 3, and 4 PIT make these bits go green most of the time. However, we should use the H1:IMC-ODC_DOF[1,2,3,4]_PIT_ERRFILT banks to calibrate the WFS Error points into physical units, and use thresholds that make sense. 
Just for testing purposes, I've tossed in a 0.3 [Hz], 4th order Butterworth as the low pass. I'm sure more thought could be put into this. These filters are in FM1 of the ERRFILT banks, and called "0.3HzLP."

BIT6, BIT7, BIT8, BIT9 : Indicative of the control yaw system operating as expected, with small error signals, and therefore the IMC is well-aligned. (The equivalent of) H1:IMC-DOF_[1,2,3,4]_Y_IN1 -- the error points of the WFS loops -- are low-passed in the banks H1:IMC-ODC_DOF[1,2,3,4]_YAW_ERRFILT. If the absolute value of those low-passed error points are less than a pre-defined threshold (H1:IMC-ODC_DOF[1,2,3,4]_YAW_MAX), then BITS 2, 3, 4, and 5 go high. 
As the IMC ran while commissioning the ODC channel, I found that threshold values of 10000, 10000, 10, and 10 [ct] for DOFs 1, 2, 3, and 4 YAW make these bits go green most of the time. However, we should use the H1:IMC-ODC_DOF[1,2,3,4]_YAW_ERRFILT banks to calibrate the WFS Error points into physical units, and use thresholds that make sense. 
Just for testing purposes, I've tossed in a 0.3 [Hz], 4th order Butterworth as the low pass. I'm sure more thought could be put into this. These filters are in FM1 of the ERRFILT banks, and called "0.3HzLP."

BIT10 & BIT11 : Indicative of whether there is the expected amount of power input into the IMC, as measured by the MC2 TRANS QPD behind MC2 on HAM3 . The QPD's SUM (H1:IMC-MC2_TRANS_SUM_OUT_DQ) is compared against a threshold (H1:IMC-ODC_MC2_TRANS_SUM_MIN). If higher than the threshold, BIT 2 goes high. If the the SUM is greater than the input power (as measured by a Broadband PD measuring the leakage beam just behind the PSL's Periscope, H1:IMC-PWR_IN_OUT) times some multiplier (H1:IMC-ODC_MC2_TRANS_PWR_IN_MULT, the expected loss between the output of the PSL and the MC2 TRANS QPD) then BIT3 goes high.

BIT12 & BIT13 : Indicative of whether there is the expected amount of power coming out of the IMC, as measured by the IM4 TRANS QPD behind IM4 on HAM2. The QPD's SUM (H1:IMC-IM4_TRANS_SUM_OUT_DQ) is compared against a threshold (H1:IMC-ODC_IM4_TRANS_SUM_MIN). If higher than the threshold, BIT 4 goes high. If the the SUM is greater than the input power (as measured by a Broadband PD measuring the leakage beam just behind the PSL's Periscope, H1:IMC-PWR_IN_OUT) times some multiplier (H1:IMC-ODC_IM4_TRANS_PWR_IN_MLT, the expected loss between the output of the PSL and the IM4 TRANS QPD) then BIT5 goes high.
Images attached to this report
LHO General
patrick.thomas@LIGO.ORG - posted 18:18, Thursday 03 October 2013 (7982)
dust monitor swapped at end X
This morning I turned off the dust monitor at location 8 in the LVEA. It was along the H1 input arm between HAM2 and HAM3. It was not in a clean room. I gave it to Betsy and she swapped it for the suspicious one at end X.
H1 ISC
sheila.dwyer@LIGO.ORG - posted 18:17, Thursday 03 October 2013 - last comment - 09:20, Friday 04 October 2013(7981)
HAM1 mode matching

If the beam entering HAM1 has the parameters that Paul calculated it should have, we could optimize the refl telescope by moving RM1 1.6 inches closer to HAM5, and M5 1 inch closer to the PSL. This would give us gouy phase seperations close to 90 for both the tip tilts and the WFS.  If we do this, and the beam entering HAM1 is in reality the value we measured yesterday, the gouy phase separations will still be above 70 degrees.  

Here are the separation caluclated in both cases:

  Paul's beam X Pauls beam Y Measured X Measured Y
WFS -89 89 74 76
TT -89 -88 84 77

I've attached the a la mode script I used.  

figure(11)
zz = 2:1e-2:5;
PaulsBeamX.plotSummary(zz)
shg
 
figure(12)
PaulsBeamY.plotSummary(zz)
shg
Non-image files attached to this report
Comments related to this report
sheila.dwyer@LIGO.ORG - 09:20, Friday 04 October 2013 (7988)

Even if we move both RM1 and M5 both 1 cm too far, all the gouy phases (for both the measured and calculated beams) stay above 60 degrees.  (same is true if we move them both 1 cm less than we should).  So the tolerances on these positions are fairly loose.  

Non-image files attached to this comment
H1 INS
jim.warner@LIGO.ORG - posted 17:18, Thursday 03 October 2013 (7980)
Report for BSC3 posted

HugoP, JimW

Temporary testing report for BSC3 is posted to the DCC, E1100848. Few loose ends to wrap up, but submitted in time for review for SEI telecon tomorrow.

LHO General
cheryl.vorvick@LIGO.ORG - posted 17:13, Thursday 03 October 2013 (7979)
OPS

From Patrick:

CP2 being filled
9:40 Richard heading to end Y to help S & K electric with work on electrical circuit for fluorescent lights
9:40 Praxair delivery truck leaving
14:00 Kiwamu: PSL transition from commissioning to science (Paul want to make precise measurements) - delayed, so PSL is in commissioning mode.

EX:

Betsy and crew.

Chris doing electronics.

Disgnosis of odd dust monitor reading from yesterday, but not sure there's an alog yet.

 

OSB:

Roofers here working.

 

HAM1 work delayed - purge air is currently off - JohnW working on getting fixed

H1ASC went into alarm on overlow, which was real due to intentional misalignment of the IMC.

LHO General
patrick.thomas@LIGO.ORG - posted 16:21, Thursday 03 October 2013 (7977)
plots of dust counts
Attached are plots of dust counts requested from 4 PM September 27 to 4 PM October 2.
Non-image files attached to this report
LHO FMCS
mark.lubinski@LIGO.ORG - posted 16:20, Thursday 03 October 2013 - last comment - 18:39, Thursday 03 October 2013(7978)
Kobelco Purge air compressor is down
The purge air compressor(Kobelco) is down for the LVEA.  This means there is no purge air available.  Kyle and John have been informed, we have done some trouble shooting to no avail.
Comments related to this report
john.worden@LIGO.ORG - 18:39, Thursday 03 October 2013 (7985)

The service tech has been consulted and provided some diagnostic suggestions which I will follow up on tomorrow. If the problem is a failed RTD then we may be able to temporarily bypass it until we can get replacement parts.

john

H1 SEI
hugh.radkins@LIGO.ORG - posted 15:51, Thursday 03 October 2013 (7975)
WHAM6 HEPI Calibration Measurements
Couple weeks ago before some holiday time I ran some Cartesian DC shifts to confirm my Inductive Position Sensor (IPS) to cartesian input matrix(IPS2CART) numbers.  I have Dial Indicators still mounted on HAM6 so it seemed like a good opportunity to really close the loop on the calibrations.
Attached are four data viewer trend plots showing the IPS raw count readings and the calculated cartesian moves based on the IPS2CART numbers.  The four plots show the vertical drive to Z result, the horizontal to X & Y results, the horizontal to Rz result, and the vertical to Rx & Ry results.
The calibration chain is the counts are converted to nm with FM1 in the IPSINF filter bank.  The nanometers then go through the IPS2CART matrix to apply the sensor/cartesian angles and moment arms where required to get nm cartesian or nrads for the rotations.

The Dial Indicators mounts are very close to the ends of the support tubes and are oriented in the cartesian basis.  This compares to the IPS sensors which are mounted out at the piers.  The verticals sensors are oriented in Z but the horizontals sensors/actuators are aligned on the tangential rather than X or Y.  To me this says the DIs are good for X Y Z Rx & Ry but not so great for Rz.  Also, as the the DIS are at the Support Tubes rather than out at the ends of the crossbeam, they are a pretty good indicator of what is actually happening to the platform.

The numbers read from the IPS converted to nm and then to cartesian suggest the filter calibration and the IPS2CART numbers do as expected, no surprise there.
However, the DIs suggest the platform as seen at the ends of the Support Tubes do not move as much as the IPS readings/calibration theory would suggest: I'll tabulate these as a measured motions (DIs)/calculated motion ratio:
Z: 0.83
X: 0.60
Y: 0.35
Rz:0.56
Rx:0.96
Ry:0.70

So why do I observe this?  The horizontal numbers, X Y & Rz, are dependent on the theory that the platform is stiff and the actuator sensor/tripod is soft.  However, there may be some resistance in the sensor mounts and compliance in the beams that make the theory a bit more complicated in practice.  Z: the actuators push and the beam (Crossbeam) bends in response to the Expansion Bellows resistance?  X/Y: given the orientation of the Horizontal actuators I would have guessed that the Y response would have been larger than the X response but maybe it is more dependent on which way the bellows are being distorted or maybe it is HAM6 dependent where the bellows are DC positioned and pushes easier one direction than the other.  Finally it could be mostly dependent on the orientation of the Crossbeams.  At HAM6 in X, the crossbeam has no option to bend whereas in Y it has a lot of freedom to bend.  This would be opposite for HAMs 1 2 & 3 (to X & Y.)  To calculate Rx & Ry I must apply the rotational moment to the DI mount point and maybe that is sloppy but otherwise I would have believed Rx & Ry are similar given they are just vertical push & pulls.

So if any future operators or commissioners wish for these DC positional calibrations to be better, these measurements should be run again, repeated with negative displacements, and also performed on an input HAM to compare.
Images attached to this report
H1 SUS
douglas.cook@LIGO.ORG - posted 15:27, Thursday 03 October 2013 - last comment - 09:10, Friday 04 October 2013(7976)
SI Fibers in Dry Storage Cabinet Damaged from Soot and from Pulling Process
While investigating the smoke/fire damage to the dry storage cabinet used to store the finished SI fibers I also noticed an excessive amount of soot on most of the fibers caused by overheating the fibers at the end of the pulling process. The amount of soot would likely have render the fibers unusable due the the soot coating the fibers. During the pulling process it is necessary to shut the laser down within 1 second of completing the pulling cycle or a concentrated heat load occurs that emits a white soot that covers the end of the fiber which also rains down the fiber and under cuts the fiber. We use a vacuum system to pull the fumes away during this process that also showed excessive amount of soot in the clear vacuum hose. We need to be more aware of this during the next run. I will reiterate this on the next run and possible automate a laser kill switched.

Image 2799 shows the soot from both sources, white from over heated fiber and black from dry cabinet smoke.
Image 2806 fiber coated with white soot and ring where the fiber was under cut.
Image 2810 ring groove
Image 2811 assembly with clamp block, fibers and angle stiffeners.
Image 2820 is the dry storage cabinet showing the soot from the fried power supply in the desiccant regenerating box. Cause is under investigation, possible power surge(?)

Images attached to this report
Comments related to this report
norna.robertson@LIGO.ORG - 09:10, Friday 04 October 2013 (7987)
I have sought comments on the white "soot" on the fibre ends. I quote Angus Bell's response.

"I see nothing here that would require any change in procedure. The fibre ends showing the white soot also show the clear line between "soot" and "no soot" as the polish "up" stage removes the soot that accumulates on any part of the fibre that will be used. These white bits are scribed off. The polish stage lasts about 20 mins whereas the pull is 20 seconds and the time when the laser is on after the pull is only a couple of seconds. So any vapour production at each stage will be proportional to that time. The tube that goes to the vacuum will slowly fill with soot - that's what it does."

With regard to the time between switching the laser off, Alastair Heptonstall informs me
"I would say that the laser is shut down time after the pull is less than one second.  There's an audible click when the solenoid brakes are applied to the motors, and I use that as the cue to turn off the laser."

In conclusion these fibres would have been usable. It is very unfortunate that we had a problem with the cabinet. This is under investigation.
LHO General
patrick.thomas@LIGO.ORG - posted 10:58, Wednesday 03 July 2013 - last comment - 18:25, Thursday 03 October 2013(6977)
high .3 micron dust counts at end Y
Corey G. told me that the dust monitor at location 2 in the end Y VEA had started reading exceptionally high counts at .3 microns, but nothing at .5 microns. I went out to take a look, but didn't find anything obvious to account for it.

However, this dust monitor was shoved up against the west side of BSC 10 under the beam tube. I moved it farther southwest out into the VEA. The dust monitor at location 1 was near a table next to the electronics racks and I moved it northwest away from the table. I will post pictures of them before and after the moves once I can get them off my phone.
Comments related to this report
patrick.thomas@LIGO.ORG - 18:25, Thursday 03 October 2013 (7983)
Pictures attached.
Images attached to this comment
Displaying reports 80521-80540 of 88261.Go to page Start 4023 4024 4025 4026 4027 4028 4029 4030 4031 End