After looking at all the L4C plots, Krishna suggested we look at the IPS thinking that with the loops closed by the HEPI Platform servo which has lots of gain, it should suppress the IPS signal and the L4C coherence we are seeing was from something else...like the fluid moving the piping...  Seem reasonable although really?

However, see attached:  Same times as the L4C coherence I posted Tuesday.  I show HAM5 at the local position sensor (IPS.)   It is very clear the Horizontal IPS have great coherence from 0.5 down to .02 hz when the pressure sensor loop is closed.  The Vertical IPS coherence isn't nearly as strong but certainly present.  The output drive to the HAM5 Actuators is very small both horizontal and vertical.

I attach too the coherences from the End Stations.  The second attachment has ETMX in the left plots and the ETMY in the right plots.  Both pressure servo loops are closed but ETMX pressure signals do seem to be quieter (although not as quiet as I've seen the corner station's back before December) and the ETMX is servoing on the direct output pressure at the Pump Station.  Whereas, at the ETMY, we are servoing on the actual remote pressures at the BSC10 differenced in the epics database.  The signals at ETMY have always been very noisy and so when I switched ETMY to the differential mode, I added serious smoothing to the signals before differencing.

Looking at the the comparison of the ETMs there are distinctions but what causes what them is not clear.  The quieter EndX is evident in the amplitude and dispite the smoothing, the EndY has a much sharper and higher amplitude peak at 150mhz.  Don't ask me what's happening at 3.5hz...

The lower plots at interesting in that unlike at HAM5, there is no coherence with the vertical IPS on either platform but the horizontals are very coherent.  This coherence at ETMX is narrower in band though maybe somewhat more like the band at HAM5...related to the quieter pressure signal at ETMX or due the ETMY servoing on the difference rather than the direct supply pressure or the smoothing...?

08:00 Started my solo ALS alignment

08:30 Success! I wasn't really watching the time but I knew it took longer than 20 minutes.

08:30 Rich Abbott on site.

09:00 Locked ALS solo this morning!  Attempted solo DRMI lock. Not so successful but Kiwamu found that it wasn't my fault (nocturnal commissioning shenanigans)

09:30 R Abbott and Fil out to LVEA HAM6 to work on Fast Shutter. Gerardo is monitoring vaccuum during this activity.

09:52 McCarthy in/out LVEA to HAM6 - multiple times.

10:31 Gary out to LVEA to move ISS arrays from H2 enclosure to H2 building. Using Large airlock egress for this operation.

11:53 Krishna arrived. He wasn't mentioned as an upcoming guest. 

13:00 Locked DRMI for te first time with the help of Kiwamu.

13:53 Rabbot, Fil and Rich out of LVEA

Filiberto, Richard, Rich

Installed Fast Shutter Driver Chassis S1400582 into ISC Rack 5 at U-height 6.  The system performs well in terms of reliably blocking light upon receipt of a trigger input (1.92milliseconds to block).  The remote control signals are functional in terms of the hardware, but there is still a reboot of the Beckhoff system needed to load the necessary code.  We will do this tomorrow to avoid messing with commissioning.

The solution is as follows:
1.  250 VDC on Kepco Supply, this corresponds to 243 VDC on the internal energy storage capacitors and is visible on the front panel LCD display on the shutter driver.
2.  5.4 millisecond applied pulse width
3.  20 ohms series resistor

Here is the rule for using the shutter to prevent damage to photodiodes in HAM6:
We must not lock the interferometer at high power(>10 watts) without the HV READY indicating the shutter is charged, AND no FAULT condition.  Both these parameters are reported via the Beckhoff interface from the shutter driver.

Some not so obvious factoids about the shutter system:
1.  The shutter is triggered to fire by a trigger signal that falls from 5 to 0 volts indicating the light level on the trigger diode has exceeded the maximum allowable setpoint.  Right now, the shutter controller latches this low voltage state.  The shutter driver deliberately interprets a continuous low voltage input as evidence that the shutter controller is either unpowered, broken, or disconnected, and will report a fault condition after 5 seconds.
2.  The shutter driver needs about 10 seconds to recharge after firing during which time you can not trigger it to drive the shutter.  This is deliberate as firing the shutter with an arbitrary low voltage can cause the shutter to be damaged.
3.  If the output drive cable delivering the pulse to the shutter is disconnected anywhere in the chain, the shutter will go into a FAULT state and won't do anything until the FAULT state is fixed.  The shutter driver also generates a FAULT if any internal low voltage used in the shutter driver is out of spec by more than 10% from nominal.

The attached image shows a timing measurement made by measuring the applied current to the shutter coil (shown in yellow obtained by using a clamp-on current probe) and the DC light level (taken on a breakout board on AS WFS A DC Channel 1).  The time between the rising edge of the current pulse and the falling DC voltage level is about 1.92mSec

model restarts logged for Wed 28/Jan/2015
2015_01_28 11:22 h1broadcast0
2015_01_28 11:22 h1dc0
2015_01_28 11:22 h1fw0
2015_01_28 11:22 h1fw1
2015_01_28 11:22 h1lsc
2015_01_28 11:22 h1nds0
2015_01_28 11:22 h1nds1
2015_01_28 11:34 h1broadcast0
2015_01_28 11:34 h1dc0
2015_01_28 11:34 h1fw0
2015_01_28 11:34 h1fw1
2015_01_28 11:34 h1lsc
2015_01_28 11:34 h1nds0
2015_01_28 11:34 h1nds1
2015_01_28 13:43 h1fw0
2015_01_28 19:05 h1fw0
2015_01_28 20:02 h1fw1

lsc model changes with associated DAQ restarts. Three unexpected fw restarts. Conlog frequently changing channels report attached.

Summary:

I was able to close the ISS Second Loop few times this morning. The loop performance was on-par with what we achieved when we locked it last time. The picomotor closed to the ISS PD array was also moved to optimize the light on the ISS PDs and the QPD

Details:

Noticing that the ISS QPD pitch and yaw were off, I moved the picomotor closer to the ISS array to optimize the light on the PDs and the QPD. This work improved the light on half of the PDs by about 10-20% . This also improved the beam position on the QPD. Before and after readings are listed:

I was able to close the loop without kicking the IMC out of lock. This was not robust and the previously used script wouldnot work because the second loop output fluctuation was much bigger than that we used as threshold in the script. Rather changing the script, I would want to investigate why we are not able to obtain the same robustness that we previously had. The loop performance is on par with what we have achieved in the past. With the loop closed and boost and integrator on, RIN was about 2E-8/sqrt(Hz) at 10 Hz . The attached plot shows the loop performance at different configurations.

Kiwamu, Rana Elli

Last night we comissioned Dhard WFS.  We were engaging the DHard WFS (H1:ASC-DHARD_P and H1:ASC-DHARD_Y) after the DARM handover from DIFF to AS45 had taken place. 

The WFS use signals from AS_B_RF45_PIT and YAW, and we set  H1:ASC-AS_A_RF45_Q_YAW_GAIN and H1:ASC-AS_A_RF45_Q_PIT_GAIN to 1.

We were engaging the WFS with the following settings:  (This is in the guardian but hasn't been tested yet.)

        ezca['ASC-AS_B_RF45_WHITEN_GAIN'] =  3   (we changed this from 0 to 3dB)
        ezca['ASC-INMATRIX_P_8_6'] =  1
        ezca['ASC-INMATRIX_Y_8_6'] =  1
        ezca['ASC-DHARD_P_GAIN'] =  0.003
        ezca['ASC-DHARD_Y_GAIN'] =  0.003
        ezca['ASC-OUTMATRIX_P_7_8'] =  1
        ezca['ASC-OUTMATRIX_P_8_8'] =  -1
        ezca['ASC-OUTMATRIX_Y_7_8'] =  1
        ezca['ASC-OUTMATRIX_Y_8_8'] =  1
        ezca.switch('ASC-DHARD_P', 'FM1', 'FM2', 'FM3','FM6','FM7', 'ON')
        ezca.switch('ASC-DHARD_Y', 'FM1', 'FM2', 'FM3','FM6','FM7', 'ON')
        ezca.switch('ASC-DHARD_P', 'INPUT', 'ON')
        ezca.switch('ASC-DHARD_Y', 'INPUT', 'ON')

Where FM1 is 10dB gain, FM2 is 20dB gain, FM3 is z1p0 integrator, FM6 is an approximate inverse of the suspension response with a sneaky 1e-5 gain thrown in  (zpk([1],[50+i*86.6025;50-i*86.6025],1,"n")gain(1e-05)), FM7 is a 1Hz low pass filter.

The pressure sensor noise is not a function of the cable run or the satellite amplifier.

See attached--60 days of sensors in PSI.  The channels are in order: 1) The low pressure return at BSC2, 2) the high pressure supply at BSC2,[these two signal are amplified at the BSC and then run ~120ft to the ADC,] 3) The 'CALC' difference of the previous two--this channel is what the servo controls, 4) the Main Supply line pressure after all the Pump Stations [In parallel,] 5 & 6) the final pressure on two Pump Stations before joining the Main Supply Line.

Again, the first two channels are the remote sensors traveling ~120ft to the ADC.  Channel 3 is the difference of the first two.  The last channels travel <20ft to the ADC.

I've zoomed the graphs to be all the same and the noise level on the far sensors is not more noisy than the close sensors.  Channel1, the return pressure signal in fact appears to be the least noisy.  I don't see the difference there to be too signiicant but maybe it is.

One thing that is clear is seen in channel 3.  Before the large shift to 70psi on 14 January, that calc record was servoing on the Main Supply Pressure, Channel 4.  Now that the Differential channel is actually a difference of two channels, its noise has increased.

Finally, the actual quieter nature of these channels is just seen at the beginning of the traces on Channel 3 4 & 5.  Before this time, the remote sensors from BSC2 were not available.  This shift in the noise occurred whilst I was connecting up  these channels.  Somehow at that time when I was shifting cables around to dress them, a cleaner environment was lost.  I have tried to put everything back to as it was, that is, reconnecting the unused terminal to the servo computer etc but no luck.  Maybe the ground is floating around or something but it isn't clear.

Further, see the second plot.  Here is 65 days of the differential pressure and the output of the servo driving the motor speed.  This VOUT would be flatlined when the servo is not on.  My clear recollection of this 'quiet' period is that the VOUT might change 1 digit every few seconds, not several counts every second.

New code was loaded into h1ecatc1 which required a restart of the associated plcs.

Ed and Kiwamu,

In the morning of today and yesterday, we went through all the initial aligment steps. In the course of the process, we found that there were a few settings that were hidden and not set correctly. So we made a couplle of modifications on the guardians and filter in order to automate them:

• edited LSC_CONFIGS such that it takes out the 160 dB attenuators (alog 16315) out of ASAIR_RF45 in the LOCKING_X(Y)ARM_IR states.
• edited LSC_CONFIGS such that it sets the whitening gain of REFL_A_RF9 back to 0 dB.
• added a new filter in LSC-ASAIR_A_RF45 in order to compensate the 20 dB attenuation (alog 16334).
• also, added another new filter in LSC-ASAIR_A_RF45 which gives another 20 dB. This got rid of the gain factor of 10.

The attached screenshot shows the current good settings in order to go through the alignment sequence. This configuration should be automatically achieved by the guardians.

Kiwamu, Elli, Alexa, Evan, Rana, Daniel, Sheila

Today we were able to reach CARM offsets around 30 pm.  

We transitioned DARM to AS45Q, at a CARM offset where sqrt(TRX+TRY) was -7, we then normalized the signal by sqrt(TRX) (with a factor of 0.23).  One important step in getting there was to implement the ezca servo that adjusts the ALS DIFF offset to bring AS45Q into the linear range.  We are now using that both at a CARM offset of 1 (in SQRT TRX+TRY), and after we transition to the QPDs.  We then change the DARM loww pass filter from a 33Hz low pass to a 80 Hz low pass, to get better phase margin since we are no longer saturating the ESD with ALS noise.  We did this transition several times sucessfully.  As Rana mentioned in alog 16334, we installed an ND1 filter on ASAIR A.  Since this we haven't transitioned to RF DARM again (for reasons that seem to be unrelated to the ND filter), so we will need to check the gain before we transition again. 

After making this transition, Elli, Kiwamu and Rana worked on the DHARD WFS, which we turned on to reduce the fuctuations in AS DC.  This allowed us to go to CARM offsets -25 in sqrt(TRX+TRY), which is about half of the total power we expect in the arms.  If you assume that the recyling gain is 30 (we don't really know) it is something like 30 pm.  In Refl DC we saw the power drop by about 20%.  We saw that the linearized REFL 9 I signal had turned over, and that without linearization the signal had reached the peak.  We made a few attempts to transition, and we were able to turn down the gain of the TR CARM signal to 50% of the nominal and turn the REFL 9 signal to what we think the nominal gain should be (-100 in the input matrix).  We lost the lock when we turned off the TR CARM signal.  Our next plan was to leave the TR CARM engaged with reduced gain, and keep reducing the CARM offset.  

However, we have been having a hard time locking in the last few hours.  We think that it might help to try transitioning to DARM to RF a little sooner, so that we could use WFS.  

The sequence that was working earlier this afternoon is in guardian up to the RF DARM transition, although this might need to be re-worked.  We have added but not tested a state for the DHARD WFS. 

Attached is a screenshot of our striptool durring the sequence, which was all handled by the guardian this time.  

To get bigger plots in dataviewer (i.e. getting the plot window to auto-scale) for both playback and 'real-time' plots, you can now just set up an option in your GRACE environment:

1) In your user directory make a directory called .grace:      mkdir .grace

2) Change to that directory:                                   cd .grace

3) Copy my gracerc file into your directory:                   cp /ligo/home/rana.adhikari/.grace/gracerc.user .

Now, when you restart dataviewer, you will have autoscaling.

BTW, this is described somewhat in CDS Bugzilla #377 from Tobin Fricke, Jim Batch, & Keith Thorne.

Looks like lock was from about 9:14 UTC to 16:09 UTC. For posterity.