Richard, Fil, Dave:

at MY we powered down: h1pemmy front end computer, its IO Chassis, its AA Chassis and both fiber-eth-converters (h1fe and h1daq).

These will remain powered off for the duration of the bake-out.

The interlock test was sucecssful. Both laser used by the squeezer shut down.

 Jeff B.,Peter K.

   Used vacuum to remove water remaining inside the PSL HPO and four diode boxes, which have been disconnected from the cooling system and are being mothballed. Closed WP #7407   

NikoL, Rick S

We switched on the the Pcal laser to check the beam pointing after the vibration damper and baffles installation work last week.

We (with Corey's help) pointed the ETM to center the optical level signals.

With this alignment the Pcal spots are way off, more than 1 cm (see attached photo, both beams should be (and were earlier last week) centered on the integrating sphere aperture).

Keita is going to check on the TMS alignment so we can try to discriminate between the possibility that the Pcal periscope shifted during the alignment work and the possibility that the ETM pointing (or OptLev) has changed.

If the ETM pointing is off, it would be on order 10 mm over 10 m, or about 1 mrad.

This morning I started the ZM1 Guardian node. I had made the code changes for it back with ZM2 (alog40256), so it was just an easy create and start.

It is also on the Guardian overview screen, and while I was there I checked that all nodes were on it. All good!

• In my alog 40843, the drawing I included shows the laser thermistor being read into box D1300649, which is incorrect.  The laser temperature is an un-labled connection further down the drawing that shows the signal going into the control box, D1200745.
• That said, both boxes have signals that either glitch or drop in DC level at the time that the flow rate glitches.
• The instant recovery of the flow rate doesn't match an actual recovery due to a temporary reduction in flow due to debris in the chiller lines.
• With Fil's help, I can confirm that the D1300649 box, and the D1200745 box, and the flow meter have all been swapped out, and the glitches persist.
• Attached files show the glitching signals and the where they're read.

17:00 Chris to LVEA to inner receiving for scaffold gathering

16:00 Vent meeting

16:36 M² to MY to move a ladder

17:00 Betsy and Travis out to EY

17:10 Tour group into CR

17:34 Tour group into CR

17:45 Corey sitting in for the remainder of my shift to allow my work in the PSL

VAC - pumping down in the corner station. Bake is going slow at MY

PSL - ongoing 70W installation work. Mode matching into the new amplifier is the plan for today.  Camera work in PSL; moving GigE cameras to new locations

SQZ - squeezer work will continue. If there's a break in it SEI will take the advantage to do balancing

SUS - OPO Model work (Tues)

SEI - Target of opportunity work contingent on squeezer work. ISI model changes contingent on ECR

CDS Ele - Access control work will be going on at MY

EX - Extraction of the Quad

EY - Pcal maintenance work this week. Vac work this week.  SUS closeout w/doors today.

HVAC- work ongoing in optics lab

HAM6 - Target of opportunity work: 

•   Installation of modified Septum viewport cover.   
•  Installation of in-vacuum accelerometer.
• purge off. 

Trends reflect ongoing work during 70W installation.

Laser Status:
SysStat is good
Front End Power is 33.97W (should be around 30 W)
HPO Output Power is -0.04668W
Front End Watch is GREEN
HPO Watch is RED

PMC:
It has been locked 0 days, 0 hr 0 minutes (should be days/weeks)
Reflected power = 0.02522Watts
Transmitted power = -0.02523Watts
PowerSum = -0.001669Watts.

FSS:
It has been locked for 0 days 0 hr and 0 min (should be days/weeks)
TPD[V] = 0.0672V (min 0.9V)

ISS:
The diffracted power is around 3.3% (should be 3-5%)
Last saturation event was 6 days 19 hours and 17 minutes ago (should be days/weeks)

Possible Issues:
FSS TPD is low
LRA out of range, see SYSSTAT.adl

Same issue with invalid json data. Updated channel list attached.

TITLE: 03/12 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
    Wind: 4mph Gusts, 2mph 5min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.23 μm/s
QUICK SUMMARY:

Attached are the VPW desiccant plots with the last month's added data.  Nothing out of the ordinary shown.

Output has been at 100& for days now so this won't impact anything.  If situation were different, i.e. were weren't already at 100% output but still ramping up, then this "bug" could have resulted in an over temperature condition.  The program is behaving as if the "HOLD" condition is a function of run time based on 1C / hour expected rate of rise and time needed to get to SETPOINT value from measured temperature recorded at start of profile.  If so, then this is a novice programmer mistake.  The program should switch to the HOLD segment upon reaching the SETPOINT value as a function of the measured temperature irregardless of time so as to always be limited to the 1C / hour maximum rate of rise.   

Following on from the driven electric field meter (EFM) measurements presented in alog lho-40878, I've made a rough conversion of the EFM noise floor into meters of DARM. It looks like the EFM might just be sensitive enough to see fields which could contribute to DARM. This calibration is very dodgey and is really just an order-of-magnitude (or 3) estimate. Based on the the transfer function from volts-of-ESD-shield-drive to meters-in-DARM, in alog llo-28675 (strongly dependent on which test mass was looked at), the EFM noise floor lies somewhere between the red and purple traces in the first plot.

How I made this plot:

First I fit our measured electric field strength vs volts of ESD shield drive measurement, to get a conversion from V_shield to electric field strength [V/m] (second plot, data read off the plots in Jeff's previous log post)

I fit Anamaria's transfer functions for m_DARM per V_shield as shown in llo-28675. I just did a linear fit and extrapolated it to 500Hz, since their measurements only go to 200Hz.

I converted this transfer function into m_DARM per electric field [V/m], using the fit in step 1 (shown in the third plot)

Finally I took the EFM noise floor, and multiplied it by the transfer function (x 5 since we drove all 5 shields where LLO only drove 1) to get the EFM noise floor in m_DARM (plot 1).

EFM measurements will continue at EX in the future, we still need to look at the frequency-dependence of the ESD shield electric field, and take measurements where we drive the ESD signal/bias, ISI horizontal actuators, and anything else in-chamber that might generate electric fields.

I noticed that the displayed value in the TC1 field was "#..." or absent a numeric value this morning at 0110 hrs. during a random check.  I monitored for 10 minutes and noted displayed values as 

TC1="#..." TC2=85.5 TC4=83.0 %(can't determine due to pixel resolution) 

TC1="#..." TC2=85.8 TC4=83.2 %(can't determine due to pixel resolution) 

TC1="#..." TC2=85.7 TC4=83.1 %(can't determine due to pixel resolution) 

TC1="#..." TC2=85.6 TC4=85.2 %(can't determine due to pixel resolution) 

TC1=99.9 TC2=85.5 TC4=85.5 %71 

TC1="#..." TC2=85.9 TC4=83.3 %76  

Thus, displayed value of TC1 is alternating between gibberish and valid values.