(R. Weiss, B. Abbott, C. Torrie, J. Worden, B. Gateley, G. Moreno)

We assembled one TMDS*, and is currently being tested in the corner station mechanical room.
We are using dry air from the corner station purge air system to test the unit.
The corner station purge air will remain on until testing is complete.

*TMDS = Test Mass Discharging System.

700 Cris - LVEA

800 Cris - Out

807 Ken - LVEA working on tables

900 Jeff K. - To EY

901 Jim B. - To CER

902 Bubba - LVEA to move a 3IFO pallet

915 Richard - To CER

916 Hugh - To LVEA to clean up presentation from yesterday

919 Bob, Steve - H2 room

919 Filliberto, Andres - To EY cable pulling for low noise ESD

951 Karen, Cris - To MY and MX

1005 Sudarshan, Darkhan, Rick - To EX for PCal work

1035 Richard - out of CER

1043 Richard - LVEA to talk to Ken near HAM 6

1051 Karen - Leaving MY

1105 Nutsinee - To EY, tagging cable

1112 Dave B. - To EX

1119 Richard - Out of LVEA

1129 Jim B. - Out of CER

1148 Dave B. - Back from EX

1209 Jeff K. - Done with activities at EY

1255 Filliberto - To LVEA to help Ken

1256 Sudarshan, Darkhan, Rick - Leave EX for lunch

1307 Richard - To LVEA

1320 Marco - To EY

1352 Richard - To LVEA

1448 Jodi - To LVEA placing barcodes

1503 Jodi - out

1504 Kiwamu - To EX and EY transitioning to laser hazard

1517 Elli, Nutsinee - To LVEA to restart CO2 laser

1528 Elli, Nutsinee - out

1546 Richard - out

1548 Rick, Sudarshan, Darkhan - To EX

Because Kissel turned on the timing check IOP switches (H1:FEC-7_DACDT_ENABLE), I wrote them into the burt file with SDF.

Nutsinee, Elli

CO2 lasers are back on after transitioning to laser hazard.  As before, CO2X is sending 0.23W of central heating to ITMX.  CO2Y is on, but is not sending any power to ITMY.  We restarted the CO2 laser chillers, which had stopped at yesterday at 15-05-19 17:00UTC and were displaying a "low temperature" fault.  At Peter and Richard's request, we have left the CO2 laser keys in their respective chassis in the LVEA.

I have remotely commited a new revision of the h1psliss model that recovers the recent ODC upgrades that were mistakenly wiped out in the most recent revision of that model. The changes are, as in the SVN log, as follows:

• all cdsEpicsOutputs in the h1psliss/ODC block are now cdsEpicsOutLong
• the #DAQ Channels entry in that block now defines CHANNEL_OUT as uint32
• the ‘STATUS’ output in the h1psliss/ODC_ISS block is now cdsEpicsOutLong

After an 'svn up h1psliss.mdl', the model should be rebuilt, reinstalled, and restarted, followed by a daqd restart, which should restore the PSL ODC channels written to frames to a working state.

The RMA replacement of the broken power supply for h1hwinj0 was delivered today. I have installed the PS as the UPS-powered unit in h1hwinj0.

At roughly 10:40 PDT h1iscex stopped running its models with an ADC timout. Rick and the PCAL team were in the VEA at the time, but we could not link any activity with a potential glitch of the IO Chassis. I restarted the system using a full power cycle of both CPU and IO Chassis. We burt restored h1calex from earlier this morning.

Per Jeff Kissel's request Betsy and I (Xavi) looked at several SYS subsystem channels to perform timing checks on the IO chassis.

These checks were in slides by Shivaraj and the slides should be added to this alog and references to the slides added. 

The channels we looked at (shown in the attached green medm screen shot) are:

H1:SYS-TIMING_C_MA_A_PORT_2_SLAVE_CFC_TIMEDIFF_1 (Master1)
H1:SYS-TIMING_C_MA_A_PORT_2_SLAVE_CFC_TIMEDIFF_2 (Master2)
H1:SYS-TIMING_Y_FO_A_PORT_9_SLAVE_CFC_TIMEDIFF_1 (Y-arm)
H1:SYS-TIMING_X_FO_A_PORT_9_SLAVE_CFC_TIMEDIFF_1 (X-arm)

Two of them are in the Master, one in the y-arm, and the third in the x-arm. It does not appear that any other channels are active at this time.

We took a week of data (in the past of today) for each of these channels and attach figures that show the time series (to check for trends) as well as histograms.  

All in all these plots look reassuring. Notable features:

1) The timing differences between adjacent points are integer multiples of 7.45ns. Mostly the integer is 1 (see Master1TimeseriesDiff.jpg, only posted it for Master 1, others look the same).

2) There do not appear to be significant drifts (e.g. < 50ns for 1 week in Master 1)

3) The spread is about 50ns (shown in figures labeled Histograms)

4) there is ~1 day periodicity in the time series for Master 2

5)  There seem to be common glitches (small ones at the level of ~0.25 us, e.g. see all time series toward the end)

Betsy and Xavi

Elli, Nutsinee

Following LHO alog17941 (PSL accelerometer detected 1Hz glitches) and LLO alog17844 (1Hz peak seen in a magnetometer). Elli left the HWSX camera on from the night of May 16th until the morning of May 18th. I have compared and attached the spectrum from two lock stretches where the  HWSX camera was turned on (May 17th 12:00:00 UTC) and off (May 15th 12:00:00 UTC). There's no evidence of HWS camera at the corner station coupled into DARM at ~45 Mpc.

At LLO, elevated 29-30Hz signal on ground sensors at EndY found the HVAC Fan Frame sitting on a rock.  I checked all I could at LHO and only found a couple things that if they were to move into the wrong spot, they could short out the springs.  I removed what I could and told bubba about what I could not.  Almost because I was unable to open the far west door in the south hallway at the corner station.

Power was interrupted to Comtrol serial adapter, so the EPICS IOC for the weather at end Y needed to be restarted.

EndX has been  transitioned to laser Hazard for Pcal work.

SEI: Getting things back up after AA/AI/IOC work

SUS: EX and EY are back, Jeff will be at EY this morning measuring AI chassis

CDS: All AA/AI boards are swapped

    Power supplies on IO all swapped.

    Some problems overnight to investigate.

    Installing cables at EY.

PSL: Going ot EX to turn on Pcal.

Fac: Moving 3IFO pallet

There will NOT be a safety meeting today

J. Kissel

I'm heading down to the X end to begin measurements of the QUAD's AI and Coil Driver Chassis. I've brought the QUAD to SAFE in prep. No signs of the trouble I briefly saw last night (see LHO aLOG 18519).

As part of the investigation into the cause of the laser trips, I looked at the
status of a few bits of the TwinSafe codes.  This is a rough core dump of my notes
from the session.

    The status screen was red on "Interlock OK".  The following values were recorded
bAmpNPRORunning = 0
bAmpShutterOpen = 1
bAmpShutterClosed = 0
bILOK = 0
bILTwinSafeFBError = 0
bILSoftwareEvent = 1

StandardQX1[0-7] = 11111111
StandardQX2[0-7] = 11100000, this indicates bILDChilFlow, bILXChilFlow and bILDiodeRoomSafetyKeyLock
                             are 1
StandardQX3[0-7] = 00000000
Standard1X1[0-7] = 00100000, this indicates that bILSoftwareEvent is 1 consistent with the
                             above observation
Standard1X2[0-7] = 00000000
Standard1X3[0-7] = 00000000

Seemingly the above suggests that at some point there was a problem with the chiller.
No indication on the chiller of a problem, in fact both chillers were still running.

    TwinCAT indicates that 1 frame (out of many tens of thousands) was lost.  I don't
know if this is enough of a loss to trigger the TwinSafe safety relay or not.

J. Kissel

In order to facilitate studies of the timing systems inside the "important" (i.e. those involved in the DARM loop) IO chassis, I've turned ON the DAC DuoTone Enable switches for the h1susex, h1susey, and h1lsc0 front end computers, i.e. 
EX SUS Front End (h1susex) = H1:FEC-87_DUOTONE_TIME_DAC 
EY SUS Front End (h1susey) = H1:FEC-97_DUOTONE_TIME_DAC
OMC DCPD's Front End (h1lsc0) = H1:FEC-7_DUOTONE_TIME_DAC
which, because all of the 32nd and 31st channels on these chassis' ADC0s are otherwise empty should now pipe the DAC0's DuoTone signal back into ADC0.
Recall that the 32nd ADC0 channel on each front end is that ADC's DuoTone signal it has received from the timing slave also internal to the I/O chassis, e.g. 
H1:IOP-SUS_EX_ADC_DT_OUT_DQ
H1:IOP-SUS_EY_ADC_DT_OUT_DQ
H1:IOP-LSC0_ADC_DT_OUT_DQ
and the 31st ADC0 channel (if the H1:FEC-${DCUID}_DACDT_ENABLE button is ON) is DAC0's DuoTone, e.g. 
H1:IOP-SUS_EX_DAC_DT_OUT_DQ
H1:IOP-SUS_EY_DAC_DT_OUT_DQ
H1:IOP-LSC0_DAC_DT_OUT_DQ
should contain some useful timing diagnostics. Note, the inherent assumption in the system is that if one ADC and one DAC is well synchronized to the timing slave, then all DAC and ADCs in the IO chassis are well synchronized.

Unclear whether we'll ever need to turn these off, so they should probably go into the IOP model's SDF system when someone's more awake than I am right now.

Also -- just because I can't think of a better place to put them at the moment since there're so many open questions, I attach my notes on further data-mining-type Timing System studies that can be done now that Jim has set of the auxiliary timing system check (see LHO aLOG 18384).

Day's Activities

• 8:30-8:40:  Peter/Jeff moving chiller back from Large Equip to Receiving
• 8:34:  Hugh removing STS2 from beer garden
• 8:45-8:55:  Jeff inventory work in Cleaning Area
• 10:06:  Pepsi on site
• 10:10:  Nutsinee checking to see if irises were left closed at Hartman Sensor Table (at HAM4)
• 10:15- afternoon:  MX cleaning Christina/Karen
• 10:46:  MY trip for Jodi
• 11:00:  Ops Training
• 12:15:  Possible nds0 reboot by Dave/Dan M
• 1:45:  Filiberto roll up door
• 2:13:  Filiberto at MX
• 2:57:  DAQ restart (Dave)
• Robert had a few trips out to EY throughout the day

H1 Operator Locking Notes For Today

Came in to find the Arms not locking on GREEN in the morning.  Alignment was OK, but when I tweaked up alignment and engaged WFS & this would drop the arm powers.  With Daniel & Ellie's help (& Evan's alog), saw that there were issues with the Pit/Yaw M0 Lock Filters for the ITMs.  So Inputs were disabled, Cleared Histories & turned off FM2 (+20dB) & FM3 ("empty") filters for ITMx & ITMy.  After this we were able to take the arms to "Locked_No_Slow", and then walked through the rest of Initial Alignment.

When we went to locking the full ifo, the first steps is "Check IR" via ISC Lock Guardian Node.  We had nice ALS arm powers, but when we got to the "Find IR" state, the arms would break lock and the MC would break lock (not sure of the order though).  I believe Sheila caught the issue here (she noticed Tidal issues and then some filters being turned OFF on the ETMs).

Summary

Our current quad distribution scheme for DARM should be compatible with the new low-noise ESD driver. Most of our rms drive to the ESD happens below 3 Hz, so the extra compensation required for the new 2 Hz / 50 Hz pole/zero pair shouldn't cost us anything.

Details

In the ETMY ESD drive we currently have passive filters installed (D1500113), with a pole at 1.6 Hz and a zero at 53 Hz. We digitally compensate for these in the L2L drivealign filter for L3.

If we remove these passive filters and install the new low-voltage driver (D1500016), we will instead have two poles at 2.2 Hz and two zeros at 50 Hz, and we'll compensate these digitally in the same way. So we will effectively have an extra pole around 2 Hz and an extra zero around 50 Hz, compared to what we have now.

I've attached a set of spectra of the ETMY ESD drive in full lock. The blue is our current drive. The red is my projection of the drive we would have if we install the new driver and compensate accordingly. It seems that most of the rms in the drive comes from 3 Hz and below, so the total rms (about 3×10³ ct) won't change much when we change the digital compensation.