We studied one year data taken from May 01, 2014 to April 30, 2015. The results agree with the earlier findings from 4-months data (here), i.e., EY tilts twice as much as EX along the beam line. Figure shows 1 year of the 0.03 to 0.08 Hz beamline seismic band at EX and EY plotted against wind speed measured at EX. The full study is documented here.

Dipongkar Talukder & Robert Schofield

During ER7, the alignment of the IMC was adjusted to minimize the jitter peaks in DARM around 312 and 347 Hz (Link). We examine the stability of the tuning here. The top two traces in the figure are BLRMS bands centered on the peaks, and the tuning is the sharp drop at the left of the plot. The dashed horizontal lines on the plots show the pre-tuning and post-tuning level.  

The tuning seems to have been fairly stable, the peak height at the end of the run was about what it was right after tuning. The peak height increased during the period when the power was increased to 24 W, which is indicated on the plot by a yellow background. This was expected because the alignment was not retuned for this power. But when the power was returned to about 17W (cyan background) the tuning returned to its good state. 

The main drawback that we found was that the peak height started high after each lock and drifted down to the tuned level over tens of minutes.

Dipongkar Talukder & Robert Schofield

Filiberto, Patrick

Filiberto moved the cable for the gauge and I made the update to the system manger, committed it into svn, and activated it.

Filiberto then removed chassis 3 for his work on it. I disabled that chassis and the one following it in the target system manager, activated and ran that configuration. I have not restarted the PLCs because I am not sure they will run without the missing chassis. The gauge appears to still be operating however, as it does not need a PLC program.

So the end X Beckhoff PLCs are not running while Filiberto works on the chassis.

Richard, Patrick

Did essentially the same work as yesterday (https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=19310), except the gauge was connected at the end of the photodiode chassis.

Kate, Matt and a wee bit of help from Calum Omc black glass shroud is installed. More to follow ... To do list 1) balance mass 2) beam dump 3) beam diverter 4) laser beam check 5) cables. Please note should look at cable from omc bench. Dan and Matt are going to look at this in am.

L. Prokhorov, J. Kissel

All the quadrants of ETMX ESD work Ok. 

The charge level at all quadrants of ETMX is much lower after the venting and discharging procedure. 
See plots of today's results and Long-term* plot below. 

* Points for LL quadrant (red) are correct only before May and the last point. At May and June,12 we had LL ESD broken.

Sheila, Kiwamu, Jim, Dave:

It appears that following the last successful build of h1ascimc on April 21 of this year, the file was modified to use a fastPZT version of the common ASCIMC_MASTER part. This part was not found, and the model would not compile. For now I have modified h1ascimc.mdl to use the standard ASCIMC_MASTER/ASCIMC part. The common part's input ports aligned correctly, but I had to manually connect the output ports up in the order found. Someone should verify that the DAC channels are correct, they are (counting from 0 through 15)

ch08 = PZT_P_OUT

ch09 = PZT_YAW_OUT

ch10 = SPAREOUT2

ch11 = MCREFL-SHUTTER_OPEN

The output IPC parts are labeled so I'm confident  they are connected correctly.

I have not installed this model, it needs checking before we do this.

Scott L. Ed P.

6/22/15
Cleaned 59 meters ending at HNW-4-086. Serviced diesel generator.

6/23/15
Cleaned 39.8 meters ending at HNW-4-088. Removed lights and cords and begin relocation to next section north. Test results posted on this A-Log.

6/24/15
Made run to town for fuel in all support vehicles and diesel tank. Filled water tank and cleaned vacuum machines. Restring cords, hang lights, vacuum support tubes, spray diluted water/bleach solution on floor.
This is an exceptionally dirty section.

Jeff, Dave:

Jeff noted that the SUS ITMY SDF was reporting a difference for the HWWD STATE epics variable. This was due to the HWWD testing I did last Wednesday Link

The hardware watchdog (HWWD) is read out by the h1susitmy model via binary I/O. For a long period of time the unit was powered on but had its monitor cables disconnected. It was this state which was recorded in the safe.snap file. Last Wednesday, following the conclusion of my tests, I disconnected the input cables and then powered the unit down, which raised the SDF difference. Today I accepted the current STATE to clear the SDF difference.

Day's Activities:

• HAM6 work continues today
• 8:55:  Garb Supply check in Receiving (Bartlett)
• 9:00:  MY septum viewport protectors (Jodi, Gerardo)
• 9:11:  Katie & Jordan (SURF students) heading into LVEA for misc PEM work (checking accelerometers, installing sensors, etc.)
• 9:30:  Hugh at EX for new power supply for HEPI, tripped Watchdogs at 9:54.
• 9:35:  Matt/Calum/Kate--HAM6 in-chamber work begins
• 9:35-10:07:  Bubba:  EY (for supplies) & then to EX to install TMDS (Test Mass Discharge System) piping
• 9:42:  JimW working on ITMy SEI FeedForward
• 9:48:  Dale tour (smaller group)
• 11:20:  TJ noticed that ITMy watchdog tripped.  This isn't related to Jim's work, but we're not sure what could have caused this(!).
• 1:15 Next Dale tour (bigger with two groups)
• 12:48-1:20: Testing ESD interlock at EX (Richard/Patrick T)
• 1:09 ESD Interlock work beginning at EY (Fil/Andres)
• 1:27 Dick heading out into the LVEA to look for parts
• 1:52-2:39 Jordan/Katie heading to an end station for magnetometer install
• 3:00 Presentation by Richard Oram on the Fault Reporting System (FRS)
• HAM6 work continues.

R. McCarthy, J. Kissel, L. Prokhorov

Richard has restored the functionality of the ETMX High Voltage ESD driver. In addition to simply turning on the high voltage, he had to disconnect and reconnect the temporary, Beckhoff binary input control cable for the "MSR" light to engage on the driver. Once the Beckhoff's binary control was restored, we were able to drive. 

After aligning the suspension, we briefly confirmed the functionality of the ETMX optical lever since it's health had not been check since being replaced (LHO aLOG 19290). We looked at an ambient pitch and yaw performance ASD (looked OK -- saw SUS resonances, no apparent combs, and a noise floor of sub- 1 [nrad/rtHz] above 1 [Hz]), and trending the SUM to check for glitches (I don't know what glitching does or doesn't look like, but over the past 6 hours the SUM time series does not at ALL look Gaussian). So still unclear whether the optical lever is perfect (i.e. still probably can't use it for damping), but should be good enough for now (i.e. measuring charge). 

Once the optical lever health was confirmed good enough, we drove a 4.7 [Hz] sine wave through each quadrant and confirmed, with a 5e4 [ct] amplitude, that ALL quadrants (even LL, which had previous been busted; LHO aLOG 19097, 19060). Looks like the replacement of the feedthrough (LHO aLOG 19221) was a success.

Nice work in-vac and CDS team!

Leo has begun to take charge measurements.

Richard, Patrick

Richard attached a BPG402-SE Pirani/Cold Cathode combination gauge to the end X End Link Beckhoff chassis. I downloaded the device description file from the Inficon website (http://products.inficon.com/en-us/Product/Detail/BPG402-S?path=Products%2Fpg-wide-range-vacuum-gauges) and copied it into C:/TwinCAT/Io/EtherCAT/Inficon.xml on h1ecatx1.

I scanned for new devices in the system manager and added it after the ALS Laser Table Relay (EP2624-0002). I updated the CoE - Online parameters to set:

(800E:02) Low Trip Point Enable TP1: TRUE
(800E:14) Low Trip Point Limit TP1: 1E-5
(800F:02) Low Trip Point Enable TP2: TRUE
(800F:14) Low Trip Point Limit TP2: 1E-5
(F840:01) Data Units: 0x00A10000 (Set pressure reading to Torr)

I stored these to non-volatile memory by writing 0x65766173 to (1010:01) Store all parameters.

We tested the functionality by setting to the low trip point limit to 1E-7, verified that the high voltage tripped off, and put it back to 1E-5.

I committed the change in C:/SlowControls/Scripts/Configuration/H1ECATX1/SYS/H1ECatX1.tsm to svn. I then used Daniel's GUI to copy it to the target area, activate and run it. The high voltage tripped off when it was restarted (a good thing). At some point the EPICS IOC stopped and I had to restart it. I burtrestored PLC1, PLC2 and PLC3 to 6:10 this morning.

Since some of the HEPI L4C Watchdog Monitors were non-zero, I went ahead and zeroed multiple counters.  These are the counts they used to have:

• HAM2 = 22 (counts)
• HAM4 = 1837
• ITMX = 7592
• ETMX = 1100 (was 114,000 yesterday but zeroed yesterday morning)

wp 5305 RichardM HughR

The HEPI Pump Servos have forever been powered by bench test power supplies and these should be available for that purpose and they are expensive for use in a permanent setup.  Additionally at EndX, the pressure sensors have been excessively noisy since 26 Feb, relative to the other locations and we've suspected the power supply.  So Richard procured/built a supply for permanent install.  We swapped it over but there was no improvement on the noise of the pressure sensors.

We tried a number of additional things.  Disconnect grounds of the power supply; disconnect pressure sensors, power down the VFD of the motor Controller.  No real changes.  If you compare the pressures on the three servos at LHO, the EndX is way noisier so we know it can be better.  Richard has some suspicion of the Servo itself now.

I have installed RCG version tag-2.9.3 on h1build and made it the default version. Any model builds from now onwards will be using 2.9.3. I performed a "make World" on all FE models, all built except for h1ascimc. I have not performed an install. There was no modification to the H1.ipc file.

There is no DAQ update for this version, it addresses SDF and guardian issues

==================================================================================================

Changes for 2.9.3 release

==================================================================================================

- Bug Fix (850): SDF changes.

- As requested for Guardian, changed skeleton.st to read filter module ramp time values before

  offsets and gains.

From Ed's summary yesterday, assumed to be the same, since no emails about changing to Laser Hazard:

We are currently LASER SAFE in the corner and the ends. PSL is shuttered, CO2 LASERs are OFF. End station Viewports and tables are closed and locked. Not sure about the on/off statues of the ALS.

• Dust - all monitors, except optics lab and bakeout, are green, i.e. low counts.
• CDS overview - some red
• CDS DAQ - all GPS readbacks updating

Timeline - Last night:

• 6:38PM - HAM6 people out of LVEA

Timeline - This morning:

• 7:40AM - MattH into LVEA
• 7:48AM - Karen and Christine in LVEA
• 7:58AM - MattH out of LVEA
• 8:10AM - MattH into LVEA
• 8:15AM - Corey to Squeezer Bay - and back
• 8:35AM - Hugh to EX
• 8:47AM - Patrick/Daniel, WP5298
• 8:55AM - FilibertoC/PeterK/RichardM - WP5299 & WP 5300
• 9:06AM - Jason/Ed - EX Oplev
• 9:11AM - JoeD - Mids and End Stations to check fire extinguishers / lights

Data extracted for the three week period of ER7 (since the timing system would nominally be running steadily the entire time). The histograms show:

- Tight grouping of the minute trends in the data; min and max values for each minute end up in discrete bands. 
- The Time Code Generators show nearly identical histograms for their mean minute trends.
- The mean minute trends of the GPS clock are much more tightly grouped with a width of roughly 20ns; with minimum and maximum offsets included, the width roughly doubles.

Issues:

- There was a single second during which the MSR Time Code Generator was off from the timing system by approximately 0.4 seconds. The issue self-rectified before the start of the next second. Second-trend data was not available through dataview (or at least I couldn't get any out of it). This did not happen in the EY and EX time code generators. It did not happen again in the MSR time code generator. The anomaly happened at GPS time 1117315540.

I've attached histograms as well as screenshots of data taken from Grace.

I set up an accelerometer on the beam tube and measured the accelerations as I simulated the tapping that I observed during cleaning, and my tapping experiment mentioned here: https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=19038. Examination of the time series indicated that accelerations during typical taps reached about 1 m/s^2.  I suspect that some taps reached 1g. The figure shows spectra for metal vs. fist taps. The above link notes that I was unable to produce glitches while hitting the beam tube with my fist. The fist and metal taps both had about the same maximum acceleration of 1 m/s^2 (ambient acceleration levels are about 4 orders of magnitude lower), so the source of the difference in liberating the particles is probably not acceleration. Instead, it may be the change in curvature of the beam tube, which would be expected to be greater at higher frequencies. The responses from metal taps in figure 1 peak at about 1000 Hz while the fist taps peak at about 100 Hz. These results are consistent with a hypothesis that the metal oxide particles are liberated by fracture associated with changes in curvature rather than simple vertical acceleration.

When I was producing glitches in DARM for the link above, I noticed that we did not get glitches every metal tap but every several metal taps. I tried to quantify this by making many individual taps at several locations along the beam tube. Unfortunately, we lost lock with the first loud glitch and I did not get a chance to repeat this before the vent. Nevertheless, it would be good for DetChar to look for smaller glitches at the time of the taps given below. Allow a 1 second window centered around the times given below for my tap timing uncertainty. I tapped once every ten seconds, starting at ten seconds after the top of the minute so that there were six taps per minute.

UTC times, all on June 14

Location Y-1-8

20:37 - 20:38 every ten seconds

20:47 - 20:50 every ten seconds

Next to EY

20:55 - every ten seconds until loss of lock at 20:56:10