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.

J. Kissel

I've modified all HAM SUS front end code to receive dither alignment signals from the ASC front end. Currently, however, the sending channels have dummy constants as input at the top level of the h1asc model, because there's work internal to the ASC library block that needs doing. I leave the ASC model changes in the very capable hands of the ISC team.

Thankfully, recovery was easy from these changes went much more smoothly than Monday's. We had no guardian machine failures or IOP DAC FIFO errors, and the MC REFL path stayed put. As such, once we went back to laser hazard, the IMC popped right back into business. Obviously, everything went smoothly because plenty of relevant parties were here on site. #sarcasm

I have not yet begun to make the necessary MEDM screen modifications (which is how I was able to get through the changes so fast). I'll begin doing so in a bit and post shots later.
I also have not committed any of the changed library parts mentioned below, because I'm not sure yet how LLO would like to roll out these past few days of changes. However, all top level models have been committed, since they don't affect LLO.

Details
-----------------
Of the list of front end models mentioned this morning, I got through
h1asc

SUS top-level models:
h1susprm
h1suspr2
h1suspr3
h1sussrm
h1sussr2
h1sussr3
h1susmc1     
h1susmc2
h1susmc3

SUS library parts:
FOUROSEM_STAGE_MASTER
FOUROSEM_STAGE_MASTER_OPLEV
SIXOSEM_T_STAGE_MASTER
HLTS_MASTER
HSTS_MASTER
MC_MASTER
Though the IMC models do not receive dither, they use the HSTS_MASTER and MC_MASTER parts, so the dither inputs had to be terminated at the top level. Minor mod, but still a mod.

I've also added place-holder IPC receivers to the top level of all BS, and all QUAD models, but they're terminated at the top level, since I've not yet made changes to the QUAD or BSFM library parts.

I attach lots of screenshots of the affected simulink models, to show how I've implemented the path.

The y-arm was locked to a seoncd order mode. The transmitted power was 4uW, whereas it is 30uW for the fundamental. This gives a rough estimate of the mode matching with ~13%.

JeffK doing model updates all day, various IMC sus's and isi's going down, then up.

8:45 Heintze and Hosken to LVEA for TCS work

9:00 Jodi moving stuff in the LVEA west bay

9:00 Justin transitions LVEA to laser safe

9:00 JeffB, Hugh, Patrick to HAM5 for HEPI lock up

9:00 Alexa and Apollo Mark to H1 PSL area to move carts for fork lift access

9:15 Gerardo soft-closes GV5&7

10:00 MarkB and Gerardo to H2 PSL for OFI work

10:15 TVo to LVEA

10:30 Jodi to Y-Mid

12:30 Fil to EX for cabling

12:30 Travis to LVEA test stand area

13:00 Karen to EY and MY for cleaning

13:00 Margot to EY looking for equipment

13:00 Heintze and Hosken back to LVEA TCS

13:00 Gerardo opening GV5&7

13:30 TVo to LVEA for Oplev work

13:30 Travis to HAM3 for mobility camera work

13:30 JeffK and Dale to LVEA with tour

14:00 TVo to EX and EY

14:30 LVEA Laser Hazard

15:00 Aidan to LVEA for TCS

15:00 Alexa at EY

I changed the group permissions of all files under the /opt/rtcds/userapps/release area to permit individual accounts modification access to these controls owned files. Please report any file permission problems to me, thanks.

This is the first step in implementing this change. Not all users accounts belong to the controls group.

I restarted the DAQ at 13:12PDT today to support SUS and ASC model changes made this morning. 

h1dc0 monit did not restart the daqd process after I shut it down. I logged into h1dc0 as root and restarted monit (which seemed to be running) which in turn started the daqd process.

After the DAQ restart h1susprm and h1suspr3 showed a 0x2000 DAQ error. I pressed the DAQ RELOAD button on their GDSTP MEDM screens and cleared the error.

Mark B. and Gerardo

Yesterday (4/22/14) Gerardo and I measured the vertical mode Q of the OFIS for three different positions of the ECD block to try to get the Q in the specified range of 25-30.

The OFIS was set up on the optical bench in the H2 laser enclosure. The ECD block sits on a tray below the payload which is supported by four groups of vertically pointing screws at accessible positions around the edge of the structure. Gerardo had earlier attempted to set the ECD block at the nominal height using the spacer tool provided but found that this was too high and caused interference. He therefore lowered the block until it was just barely clear plus approximately an extra two turns of the 1/4-20 screws. This was our starting point for further adjustments.

To measure the vertical Q, we used the laser pointer and QPD from the monolithic violin mode setup and used a convenient screw on the top of the payload to partially block the beam. We displayed the "pitch" output of the QPD box on a digital oscilloscope with a 1 sec/div timebase and photographed the screen to capture the data. I read off the peak positions with GraphClick, and worked out the logarithmic decrement and Q with Mathematica.

For the initial position, the Q was 10.7. We lowered the ECD by one turn on all the screws and got Q = 18.9. We lowered the ECD another half turn and got Q = 23.3. Finally, today (4/23/14) we lowered the ECD another 3/4 turn and got 27.8, which is in spec.

Attached is a JPG of the setup, a PDF of all the screenshots, and for the fourth and final run, the Mathematica notebook, PDF thereof and the raw data.

In addition, I pulled the Dial Indicators from the East side, Turned off the ISI Sensor/Driver electronics, unplugged all the the East air-side cabling, and removed those Feed-Thru protection shrouds.  This will give access to the final bolts of the Septum flange.  Be mindful of the CPS Feedthrus on the North side--long and vulnerable.

For the operators or future HEPI Lockers, attached are trends from before starting thru after stopping the HEPI down.  We shoot for < +-200 IPS Counts (655cts/mil) and it looks like we did pretty well here.  Also are trends of the Cartesian values.  These are nanos(meters/rads) for the horizontal/rotation dofs.  We shifted 7um in X, less for Y & Z and 5urads RX and less for RY & RZ.  RZ is likely the most important for the upcoming alignments, it shifted 2urads.

Bartlett, Thomas

Aidan, Dave H, Matt H, Greg G.

We aligned the X-arm CO2 laser through the first 40% of the optics on the table, including:

• M1: Beam is centered on this optic
• P1: The first polarizer dumps the majority of the s-polarization from the laser. With the laser running CW, 51.1W was transmitted, 121mW was reflected. 
• D1: Dumps the s-polarization from the laser
• AOM: We aligned the AOM by driving it with maximum RF input and rotating the unit until the transmitted beam was minimized on a viewing card. This yielded ~80% DE.
• DM1, D2: dumps 1st order beam from AOM.
• PO1: 99% reflector. Transmitted beam goes to ISS photodiodes
• IBS, IM2, IL1, IL2, IM1: All ISS optics aligned
• PD1, PD2: Not yet installed
• PM1, PM2: Beam steering picomotor mirrors - beam is centered on these optics
• L1: 6" focal length lens (part of telescope to image beam onto the masks)
• PO2: 99% reflector.
• QBS: 50/50 beam splitter for beam positioning
• QM1, LQPD: Lens and mirror aligned
• QPD1, QPD2: installed and beams roughly centered on these sensors. We've not confirmed the output from these yet.

We measured the DE of the AOM as a function of applied voltage (via the front end model). The results are posted in the table below. The AOM is quoted as having a maximum DE of ~85% at the exact Bragg angle.

The Y-arm table laser is ready to test on Wednesday.

[this is something new.  We would like the Operator to post minutes for the morning meeting]

Morning Installation Meeting Minutes

Attendees:  Vern, Keita, Jeff K, Jeff B, Hugh, Corey, Justin, Jim W, Jodi, Aiden, Mark (apollo), Cyrus, Aaron, Richard, Pablo, John.....(sorry if I'm missing others, this is from memory over an hour after the fact)

Topics Brought Up:

• HAM5--Locking up HEPI, SEI removing payload with forklift
• Craning (TCS Table(s) & cleanroom)
• Close LVEA Arm Gate Valves
• Transition to LASER SAFE this morning
• Dust monitors look good around HAM5
• Wipe down HAM5 requested
• Putting optic in HAM5 (SR) on Fri?
• TCS:  alignment yesterday, AOMs characterized, QPDs set up, Y-arm going
• Integration:  craning OK in morning, until not OK as determined by commissioning crew
• Software changes to SUS during craning by JK
• Camera work with sheila at endstations
• Reboots on the daq by cyrus
• SEI at staging has full crew
• No safety meeting today

Soft closed GV5 at 9:00 am, and GV7 at 9:07 am.  They are to remain soft closed for TCS table work near BSC1 and BSC3.

The new drivers installed on the DAQ yesterday as part of WP4583 did not improve performance as expected, and in fact made it worse, so I have rolled back the changes to h1nds1, h1fw1, and h1broadcast0.  I have left h1dc0 as it is since the change there does not seem to have had any ill effects.  It's not clear to me why the same change showed an improvement on the DAQ test stand, other than the traffic level is significantly higher on the production system and must influence the driver behavior or the system configurations have diverged enough to affect the results of testing of this nature.  Here are the downtimes for reboots:

h1nds1:  15:40:35 - 15:45:54 UTC

h1fw1:  15:48:23 - 15:52:30 UTC  Frames starting/ending in this period will be missing - use h1nds0/h1fw0 for data in this gap.

h1broadcast0:  16:00:40 - 16:02:40 UTC

This is a tabletop photodetector interface (D1002932-V5, S1103811) in ISCTEY that was misbehaving yesterday. I opened it and found this.

None of the power connectors for Thorlabs PDs and BBPDs were soldered to the board. And one of the connectors was loose (right-most one in the video). See how the legs move as I wiggle.

It's a miracle that it worked at some point. I soldered all of the connectors.

(If avi doesn't play, try mov file, though the time of the mov file seems to be out of whack.)

I am about to start upgrading drivers on the DAQ as specified in WP4583.  There will be NO DATA recorded during the period when the data concentrator is rebooted - as it is due for a full FSCK at boot, this will be a period of 10-15 minutes.  For the remaining system upgrades, there will be intermittent access to the recorded data as those systems (h1nds1, h1fw1, h1broadcast0) are rebooted.  Changes to h1nds0 and h1fw0 will happen at a later time.  Further updates will be posted to this entry with specific downtime.