Since POPX PZT rails quite often, we relocated the pzt to the upstream of the second lens which is a -172mm diverging lens. The beam now hits the PZT mirror after POP-BS1,  the beam travels to +Y direction (toward the ISCT1 door), passes POP-L2 lens, is reflected by a fixed steering mirror, travels to  +X-Y direction and hits POP-X. 

This allowed us to make the distance between the lenses and the distance between the last lens and WFS closer to LLO configuration.

I flipped the sign of YAW centering for POPX because we now one steering mirror between the PZT mirror and the WFS. I also told Jenne to flip the sign of ASC YAW input matrix element for POP_X.

I decreased the overall gain for YAW and PIT due to the increased effective lever arm due to physical length plus a diverging lens, otherwise the centering oscillated badly.

David.M, Jenne.D

Today I set up a further 13 L4Cs in the LVEA, this time they are much more spread out than last week so watch out for them around the LVEA. This means that now all of the sensors in the array except for one have been fixed on the floor. (This last L4C is right in the middle of the path on the first corner near the beam splitter chamber). All of the L4Cs have the foam box coolers taped down on top of them which should make it obvious that they are there. I'm going to finish the cables and neaten everything up one morning this week so hopefully there wont be any problematic tripping hazards. The numbering scheme has been updated so now the previous scheme is invalid. Once I finish connecting all of the sensors I will make a new post with the updated scheme and an updated map.

SUS PI code change WP6018

Carl, Terra, Jim, Dave:

New code was installed for h1susitmpi, h1omc, h1susprocpi, h1susetmxpi, h1susetmypi. The model changes went in normally, but the DAQ restart was problematic. The data concentrator error'ed on duplicate channels for H1:SUS-PI_PROC_COMPUTE_MODE9_PLL_SIG_OUT. This was surprising as I had ran my script to check for duplicates prior to the DAQ restart. We reconfigured the DAQ sans h1susprocpi to get the DAQ running again while we investigated the problem. Jim found the problem, in the sys/common/models/PLL_MASTER.mdl file, a testpoint part was named SIG_OUT in addition to a filter module at that level which was named SIG, and the filtermodule has a testpoint also called SIG_OUT. This common part had 32 such duplicates, MODE9 was just the first to be reported.

Terra fixed the models, we restarted h1susprocpi, reintroduced it to the DAQ and restarted the DAQ.

I extended the script check_daq_channel_list_for_duplications.bsh to check both INI files and PAR files.

DAQ Restarts

Jim, Dave:

h1tw0 has become fragile lately (not so h1tw1). We discovered that if we restart the DAQ while h1tw0 is in the midst of writing the raw minute files, this can corrupt the file system requiring an fsck to fix. Today we were careful to only restart the DAQ while h1tw1 was inbetween file writes. This has worked and h1tw0 has not crashed.

In two of today's DAQ restarts we needed to restart the mx-stream on a handfull of frontends.

GDS code upgrade WP6012

Jim:

New GDS code was installed, details in Jim's alog.

New LSC code

Jenne, Dave:

Jenne's new h1lsc code was installed. This added some channels to the commissioning frame (eight channels at 2048Hz).

Radio receiver spectrum analyser work

Carlos, Jordan:

The RF analyser was attached to the FLIR camera windows server, code was installed and tested.

New DAQ frame writer WP6016

Carlos, Dave, Jonathan, Jim:

we installed a new frame writer called h1fw2. It is a standard front end computer using a spare Myricom 10GE card. New SFP and RAM (48GB) were purchased for the unit. This is a dual boot machine (Ubuntu 12 and Debian 8). It has a 1TB internal HDD which we are using for testing. Jim and Jonathan did some Deb8 work on it. We determined 48GB is not sufficient for it to write all the frame types.

As the system is currently configured:

h1fw0 is writing commissioning and science frames (no trends). It is now 100% stable, has been running for 6 days.

h1fw1 is writing all frames. It is unstable, restarting on average every 2 hours.

h1fw2 is writing commissioning and science frames (no trends) to its local disk.

All three have been running for about two hours now. I've extended the DAQ overview MEDM to show all three and check their frames are identical. It would be good to run three writers for O2, if the frames were not identical a trio of writers could indicate which is the incorrect frame.

Installed new version of GDS tools, gds-2.17.1.3-2 for Ubuntu 12, Ubuntu 14, and SL6 which provides some minor changes to the control room tools as follows:

Bugzilla 1027 - Remove the ability of 'diag' to clear all test points on all models. This would clear CW injections if used.

Bugzilla 1017 - foton removes extra spaces and newlines from design strings when writing files.

Bugzilla 961 - For diaggui swept sine analysis, if the user uses the sweep point editor to manually enter sweep points, diaggui will now work if the number of points in the analysis is less than the number of points specified in the editor.

Bugzilla 628 - For awggui, implemented saving and restoring of configurations, and implemented statistics and configuration menu items.

    Swapped out the PSL in-line filters in the chiller room. The new filters are 1.0um pleated; replacing 0.5um blown-matt surface filters. The new filters are higher flow with less back pressure. 

   The original filters were causing the operational pressure to rise and were lowering the coolant flow through the system. The posted plots show after the filter change the PSL cooling pressures did drop and the various flows increased. After replacing the manifold (see aLOG #28652) we were able to adjust the pressure regulators in the PSL to bring the line pressure below 4.5 bar. 

   Will continue to monitor flows and pressures until satisfied all is well.       

Since replacing the crystal chiller flow sensor did not fix the problem with the laser tripping out,
we replaced the water manifold located under the PSL table.  Attached are two traces from when the
chiller tripped out.  Since the power meter circuit tripped before the front end circuit, this suggested
that the problem really was with the power meter flow sensor rather than the chiller (see attached
plots).

    The pressure regulators on the manifold were adjusted to give a front end flow rate of 1.7 lpm,
the power meter circuit 1.5 lpm and the laser heads 0.6 lpm as indicated by the Beckhoff PC.  Note
that the flow for head 4 is different at 0.5 lpm, although head 4 has always been a bit odd of late.
 - 4 bar for the MOPA circuit
 - 4.46 bar for the power meter circuit
 - 4.35 bar foe the laser heads circuit

    It is possible that there is a slow leak at the bottom of the power meter flow sensor.  We will be
monitoring the crystal chiller water level over the next few days to see if indeed there is a leak.

    Laser restarted.  Things seem to be okay for now, at least.


JeffB/Jason/Peter

   Checked the HEPI L4C WD saturations per FAMIS task #7046. All green, all counts were zero.  

Ran power and network cabling for the new ITM cameras that are to be installed. Cables were pulled from the X and Y manifold spool into the beer garden. This required dressing cables around BSC1, BSC2, and BSC3.

JimW, JeffK, HughR

Around 1900 utc, the pressure dropped and the servo drive went to max; from afar, this looks like a fluid level trip.  Jeff went to the end station and found that the front panel red light was still on indicating it was not a fluid level trip.  Opening the controller panel to access the VFD revealed the OU3 error indicator.  Last aLog with this problem found with quick search was at EndY July 2015.  Maybe it is a warmer weather problem.  Brought control servo output to 0, reset VFD to clear the error and then brought things back under servo control, around 2200utc.  Jeff noted the fluid levels were same as before--no fluid problems.

TITLE: 07/26 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: Travis
SHIFT SUMMARY:  Down most of the shift for maintenance
LOG:

MarcP/HughR

DeIsolated the platform to investigate the concerns on the Coil Driver.  Running an sine excitation into the H2 OUTF, things looked fine until the I_INMON reached about 50-60 counts; this occurred with an excitation of 2500 counts.  At that point, the I_INMON reversed direction and went very large (340cts.)  Looking at the actual platform motion though, this was not happening to the Actuator.  This is similar to what we observed in the second attachment of 28621. It never was observed to do anything crazier than that though such as suddenly driving the platform off to tripping.

Next step was to disconnect the output from the coil driver and confirming that what we saw on the monitors was what was going out, even though looking at the response of the platform, it was moving in a nice sinusoidal pattern and not abruptly reversing when the current hit 60 counts.  About that time is when Marc noticed that the -15V led was not illuminated on the coil driver chassis.  He pulled the coil driver and found the SG7915 Voltage regulator was producing -2V rather than -15V.

Pulled coil driver S1103341 and replaced with S1600116.  This unit had the hardware watchdog power supply enable circuitry so that enabling voltage was patched over from ITMY.

The ISI reisolated first attempt.  Took the platform back to Isolated Damped and again ran the sine (0.05Hz) until the I_INMON was surpassing ~75cts.  No clipping/flipping/scaling seen on the I_INMON signal.  Attached is this after picture, sadly the ugly before picture may be lost as we had frame writer issues during the morning and afternoon.

Jenne, Chris Whittle

I verified that the ITM oplevs will most likely be insufficient for taking charge measurements; we will need to rely on DARM. See the attached spectra, made with an excitation at various frequencies and amplitude 130k cts. Dotted reference lines were set with no excitations, solid lines show the response to the excitation in the bottom axes.

I also noticed that some of the MEDM outputs for L3 of the ITMs are incorrect. Two of the USER MODEL DAC OUTPUT (H1:FEC-30_DAC_OUTPUT_3_6, H1:FEC-30_DAC_OUTPUT_3_7) read 0 when a voltage should be present. The ANALOG SWITCH lights and quadrant VMON channels are left-right flipped relative to the control switches (i.e. flipping UL shows a reading in UR). I also had to remind myself that I should always use the longitudinal channel (rather than pitch or yaw, which will attempt a differential excitation and give zero output) when exciting ITMs.

(Chandra, Gerardo)

Removed and replaced the AIP for BSC8, no issues encountered.

An aux cart was used to pump down the system from 17:10 to 21:50 utc.

AIP system is running on its own, and maintaining pressure (system back to nominal).

Lowered LLCV from 21% to 20% after CP3 Dewar fill. Exhaust pressure was spotted at 1.4 psi.

In response to Keita's alog (here) I changed the whitening gain and number of active filters on the ITMx, ITMy, and ETMx optical levers.  They are now set as outlined in the 2nd table in Keita's alog.  I also enabled the corresponding de-whitening filters in the oplev filter medm screens (ITMy and ETMx only, as these were the only ones that had additional whitening filters enabled) and accepted the changes in SDF.

I took spectra of each segement of the QPD for each TM oplev, both before and after the de-whitening filters (channels labeled IN1 are before de-whitening, channels labeled OUT are after de-whitening) as well as spectra of the pitch and yaw signals of each oplev..  To my knowledge, ETMx and ETMy look as they are supposed to.  On the other had, the ITMx and ITMy QPD spectra do not look right to me.  When I took the spectra there were ongoing investigations into ITMx ISI coil driver issues and ITM charge measurements (ie, the optics were moving); also, the oplev lasers for both ITMx and ITMy oplevs are unstabilized lasers, sitting on the LVEA floor.  All of these could be causing issues with the measurements; they should be re-taken once things have quieted down and see if there are differences.  If there are no differences, I fear we may have made things worse for the ITMs.  There also appears to be a comb in all of the ITMy spectra.  I think this is caused by the laser glitching; as soon as I have a stabilized laser ready for install this laser is getting replaced.

This completes WP #6020.

Had bagged entire RGA assembly previously -> Removed 1.5" O-ring valve (redundant valve in series with 1.5" UHV valve) and installed turbo in its place.  Backed turbo with leak detector.  Opened 1.5" UHV valve to combine detector with RGA volume.  Helium line penetrated bag at top while O2 sensor (with internal pump) penetrated bag at bottom.  No flow meter on helium but set to "significant" flow rate.  O2% fell from 20% to 1.6% over 10 minutes.  No leaks detected with helium baseline holding @ 1.2 x 10-9 torr*l/sec or so throughout the helium application -> Once convinced that no leaks were present, I closed the 1.5" UHV valve and "cracked" the isolation valve of the external calibrated helium leak and observed the expected response; thus demonstrating that the mass spec. was sampling the test port during testing.  

Installed 5 of 6 heat tapes on RGA assembly in preparation of baking it out at the next available opportunity.

Note to self: The isolation valves for the Nitrogen and Krypton calibration gases were closed during this testing so the two "factory" double-sided mini-conflat joints did not get tested.  Also, I noticed after shutting down and decoupling the leak detector etc. that the factory 2.75" CFF joint between the RGA analyzer and its protective nipple showed a crescent shaped gap.  All of the joints tested in this excercise (12 or 13?) where ones that I bolted and are "metal-to-metal" and won't change with with baking.  This sole gappy joint could leak following a thermo cycle so I will "cinch" it up and leak check it along with the two double sided joints that I missed before baking.

Koji, Evan

We removed the unmodified BBPD S1200242 from ISCT6, and replaced it with S1200236, which has the modifications described in G1500595.