Yesterday, the modified UIM coil drivers for ETMY and ETMX were tested in-situ. The transfer functions are showing an average drive increase of ~3.8 for ETMY and ~3.9 for ETMX comparing them before and after, which corresponds to the modification as described in T1400223.
A second test was carried out, using the monitor boards current channels. The test consisted in sending the equivalent of 1V to the coil drivers, to each of the UIM osem channels, and recording the current increase with channel ${QUAD}_L1_FASTIMON_${OSEM}. Jeff K helped me for the calibration of those channels.

The output voltage of the "fast current channel" of the monitor board as described in T1100378 is measured across the resistor Zout. The relation between the current and the ouput voltage is described in the last equation of Jeff's notes attached, with R1/R2 = 1/3 and Zout = 2010 ohms. In other words Current_readback_calibrated (A) = FASTIMON_Readback (cts)* 1/1638.4 (V/cts) * 3/2 * 1/2010 (ohms-1)

For ETMX I measured a transconductance of ~0.6 mA/V for each channel which matches pretty well with the design, but for ETMY it didn't quite match. First, only two channels (even though the mass was moving) were seeing a response, and secondly, the working channels were showing ~3mA increase for 1V drive. Since the transfer function shows that the driver is working as expected we certainly have something going on with the monitor board.

The non functioning channels are LL and UR osems. For UL and LR, when no voltage is sent to the coil driver, the readback sees ~4000 cts (as shown on the screenshot).
 

Days Activities

• Several ISIs were tripped this morning...perhaps due to EQ last night?
• HAM5 cleaning in morning
• Transition LVEA to Laser Safe?
• MY baking of RGA equip late morning
• EX ESD high voltage work this morning (maybe EY later)
• Praxair fill for CP6 at MX (9am?)---Sending CP6 to MAJOR alarm level
• Transition EX to Laser SAFE--probably HAZARD later
• LVEA transitioning to SAFE in the morning
• Septum removal, sealing septum gap, tapping hole in septum, & laying septum down
• Checking clean status at HAM5 (Jeff & Margot)
• Pressure Sensor at MY still is reading HIGH (MAJOR Alarm), but this is because Kyle is doing work on it (it'll be like this on the order of a month)
• LVEA transitioning to laser HAZARD at 3:45-ish
• Matt H, Aiden, and David H. heading out to work on TCS

Went through the Operator check of saturations with HEPI this afternoon.  The HEPI Saturation Counters which I had to reset were: 

HAM2, HAM4, ITMx(BSC3), ITMy(BSC1), ETMx(BSC9), ETMy(BSC10)

A pressure sensor at MY had been MAJOR Alarming the last few days, but this is due to it being worked on.  It will be displaying values of a higher pressure for a month or so while it is valved out and being worked on.  To prevent getting alarms from this, we've bumped up the MAJOR alarm setting to 1x10^-6 (originally it would alarm at 5.11x10-8).

Since the Vacuum computer was really slow, Dave ssh-ed into the computer (still was slow) & did the following:

vacuum@control0:~$ caget HVE-MY:Y5_246BTORR.HIHI
HVE-MY:Y5_246BTORR.HIHI        5.11e-08
vacuum@control0:~$ caput HVE-MY:Y5_246BTORR.HIHI 1.00e-06
Old : HVE-MY:Y5_246BTORR.HIHI        5.11e-08
New : HVE-MY:Y5_246BTORR.HIHI        1e-06

We must revert the alarm setting when the VAC work is complete.

Baking will continue for as long as a few weeks

HEPI safe.snap files had the wrong ..._L4C_THRESH_MAX values recorded, as pointed out by Dave yesterday. Those safe.snap files are now fixed. The new versions are committed under the SVN -r7796.

Details are attached.

The Apollo crew was unable to get wrenches to the large clamp bolts which retract the bellows of the chamber's west side 60" flange.  We needed to remove the Feedtrhu protection shroud and the cabling attached to the feedthru.  So the WHAM6 isi interface electronics were powered down.

model restarts logged for Wed 23/Apr/2014
2014_04_23 08:46 h1nds1
2014_04_23 08:53 h1fw1
2014_04_23 09:03 h1broadcast0
2014_04_23 10:02 h1asc
2014_04_23 11:06 h1susmc2
2014_04_23 11:29 h1susprm
2014_04_23 11:38 h1sussrm
2014_04_23 11:52 h1susmc1
2014_04_23 12:01 h1susmc3
2014_04_23 12:11 h1suspr2
2014_04_23 12:18 h1sussr2
2014_04_23 12:58 h1suspr3
2014_04_23 13:08 h1sussr3
2014_04_23 13:16 h1broadcast0
2014_04_23 13:16 h1dc0
2014_04_23 13:16 h1fw0
2014_04_23 13:16 h1fw1
2014_04_23 13:16 h1nds0
2014_04_23 13:16 h1nds1

no unexpected restarts.

815-828

mike, daniel, stefan, aiden, terry, bubba, margot, ski, matt h, jason, patrick, hugh, jeff, jodi, andres, corey, richard, pablo, david H, jimW, thomas, filiberto

• LVEA Laser HAZARD, but will be made SAFE until afternoon, and then back to HAZARD
• HAM5--cleaning being done, cleanroom modified yesterday (JeffB will inspect)
• Septum:  bolts being pulled, plan to remove today & cover septum hole
  • Will be reinstalled later, and then have windows installed (may require holes being tapped in septum?)
• TCS:  yesterday both TCS tables pushed up against BSC & alignment work
• HAM5 ISI:  SEI crew will need to strip ISI of stuff with forklift when OK to work in-chamber
• bscs press sensor work at end stations--EX first (richard & crew)
• commissioning work:  alignment work in morning & then beatnote work & electronics troubleshooting if necessary
• staging:  3ifo BSC ISI work continues

While the Gate Valves were closed and we were Laser Safe, I installed a pair of aLIGO Camera Housings on the Spool where the ITMx cameras will be. 

Re-did measurements from yesterday.  Daniel brought up point about green light leaking into IR measurements and vice versa.  So addressed this.

IR Laser Light:  Look At filters to attenuate IR

Here we wanted to see which filter was best for viewing the GREEN light, so we wanted the filter which passed green & cut out IR.  With the Prometheus laser we used its IR light.  To make sure there was no Green light, we dropped in a Hoya R72 filter (to remove any Green light from laser).  Then we looked at the filters I bought .  So this is what we had:

• IR light from laser ONLY = 420mW
• Hoya R72 in path = 414mW
• BP550 (+ Hoya) = 3.11mW---best filter for viewing GREEN light
• lp550 (+ Hoya) = 423mW
• lp920 (+ Hoya) = 431mW
• bn532 (+ Hoya) = 167mW

The BP550 is OK, but Daniel says the OD of this filter may be low and we should look for a Schott glass filter (order of 4mm thick, similar to our old iLIGO glasses).  Either that or we can see what a couple of the BP 550s filters look like in series.

GREEN Laser Light:  Look At filters to attenuate Green

Here we want to see which filter is best for viewing IR light, so we want a filter which passes IR & attenuates Green.  With the Prometheus laser we had green light.  To make sure there is no IR light leaking in, we dropped an iLIGO goggle in the beam path as a filter.

• Only Green light = 20.2 mW
• iLIGO Glasses in path = 13.18 mW
• iLIGO + Hoya R72 = less than 5nW
• LP550 (+iLIGO glass) = 39.3 uW
• LP920 (+iLIGO glass) = less than 5nW
• BN532 (+iLIGO glass) = 7.45 mW
• BP550(+iLIGO glass) =8.03 mW

LP 920 may be good...maybe have two in series?

Alexa, Stefan

- With the y-arm o.k. (the remaining glitches were actually bleeding in from x-arm locking), we realigned the x-arm.
- Note: we need to switch back to a better camera view for the x-arm transmitted light. The current one does not provide a lot of information because a) it is completely saturated and b) it is in a guoy phase that is not very sensitive to TMS alignment.
- Once we had both arms aligned and locking fairly reliable, we looked at the DIFF electronics:
- First we found 3 switches on the VCO and FDD that were left off.
- Next we noticed that the DIFF beat note was only -32dBm - we verified the EPICS read-back with the scope.
- So we hooked up the scope on ISCT1, but right then an earthquake struck and knocked out every ISI on site. Thus we went home.

Today we were able to lock the y arm for a significant period of time. Here are some settings:

PDH REFL Servo Board:

• Input 1 gain: -7dB
• Input 1 pol: pos
• Common comp: ON
• Boost 1: ON
• Boost 2: ON
• Fast gain: 0dB
• Fast pol: pos
• Slow option: EN
• rest: zero/off

I took a few measurements:

1. Power at REFL A PD: 6.5mW
2. PDH error signal peak to peak: 780mV
3. PDH loop suppressed error signal (EY_PDH_NoiseSpecV.txt)
4. OLTF: again the UGF was around 3kHz with a phase margin of 68deg (mag --> 125.txt, phase --> 126.txt)
5. With ITMX misaligned, I measured the shot noise of REFL A (EY_PDH_ShotNoiseSpecV.txt) -- this noise is partially limited by the SR785 noise; this is not "pure shot noise"
6. While blocking the PD, I measured the dark noise of REFL A (EY_PDH_DarkNoiseSpecV.txt) -- this noise is limited by the SR785 noise

I created a script, createCSD in sys/common/scripts, that sets up all required files and code for implementing a new instance of the control state definition. I also improved the makeMEDMfromOUTXML.py somewhat when dealing with sub-states.

createCSD takes the following three inputs:
  createCSD SYSTEM systemhome snapfile
   SYSTEM     has to be the capital version of the system name, i.e H1ISCEX or H1ECATX1PLC2
   systemhome is the system subdirectory name in userapps, i.e. something like als, isc, isi, lsc, omc, pem, psl
   snapfile   is the initial snapshot setting that will be enforced. If not specified, the default safe.snap will be used

It uses a burt snap file to create a very simple xml file with no states. Running this xml file will simply continously enforce that snapshot file. Any further modifications can then be done manually in the xml file.

Using this I stood up CSD-Guardians for H1ISCEY and H1ECATY1PLC2. I also manually created the same states for H1ISCEY as we have for H1ISCEX, so H1ISCEY is ready to be used.

I haven't done the manual edits for H1ECATY1PLC2.

I left H1ISCEX, H1ECATY1PLC2 and H1ISCEY running in OP. H1ECATY1PLC2 was left with the Guardian paused.

Alexa, Pablo, Keita, Stefan

We noticed that H1:ALS-Y_VCO_TUNEMON and H1:ALS-Y_VCO_FREQUENCY were only reacting to half the range of the drive from the common mode board (H1:ALS-Y_REFL_SERVO_FASTMON). We thus swapped the EX VCO ( D0900605 , S1200562 ) with a H2 spare ( S1200566 ). This fixed the issue.

Next we noticed that the PDH signal doesn't bring the arm power to a maximum.
With a H1:ALS-Y_REFL_SERVO_IN1GAIN of -13dB, and an H1:ALS-Y_REFL_SERVO_COMOFS of -4.75V we get the maximum build-up, about 1750 counts of H1:ALS-C_DIFF_A_LF_OUT_DQ. With a misaligned ITM Keita and Alexa verified that it is not an RFAM effect.

We still see transients in the arm build-up.

Jim and I have been investigating DAQ issues with HEPI ETMY which started over the weekend. Brian noticed that HPI ETMY's L4C Sat Counter started looking like the WD threshold, and was also counting down from 89k to 30k which it should no longer need to do.

We are unsure about the details, but it appears that when Jeff restarted h1hpietmy at 15:02PDT Saturday afternoon , the old INI file was archived but the newer file was used. It would appear that the INI Checksum the FE sends to the DAQ was calculated from the archived file, so DAQ did not show a 0x2000 error for this model. At a later time of 18:50PDT Saturday Jeff restarted the DAQ, at which point the FE DAQ status went to 0x2000 and the data in the DAQ was mixed up (resulting in a WD threshold being named the Sat Count). When I pressed the "DAQ RELOAD" button for HPI ETMY monday morning at 10:24PDT the FE and DAQ synced up and the DAQ data became good again.

When the model was restarted on Sauturday it read the safe.snap file which set the WD threshold level high, hence the ramping back down to 30,000. The safe.snap is being corrected by Brian and Hugo.

I had to "DAQ RELOAD" h1hpibs on monday as well, so it could have the same issues over the weekend.

We suspect the fact that the make-install and model restart occured very close to each other may be a possible cause of the INI file mismatch, but this is pure speculation.

If commissioners suspect any DAQ issues with h1hpietmy and h1hpibs we should restart the models.