Todat we have two small changes to the initial alingment procedure:

there is now a clear history script that works for the arms, it can be used by clicking the button on the ALS OVERVIEW SCREEN or the end station screens.  

The X arm green transmission has been normalized, so now a transmission of 1 really does mean that the arm power is maximized.  

Also, as we have seen several times the OFFLOAD GREEN WFS doesn't really work for the Y arm. 

The status started reading low battery around 3:05 UTC 3/18.

Quiet day

09:42 Bubba running forklift outside by metal recycling container
09:45 Jody and Gary to mid Y, then transferring stuff to mid X
13:27 Hugh to BSC2
13:34 Hugh back

Scott L. Ed P. Chris S.

58 meters of tube cleaned today towards X-1-6 double doors.
Continuous monitoring of beam tube pressures by control room during cleaning operations.

So far not much has been done to do tilt decoupling on the the HAM ISI's, because we weren't sure it was necessary. I took some measurements yesterday to check, and I think that's still right. If you just look at my first attached plot, it seems reasonable to think that maybe we should. The GS13-Y/ISO-Y transfer function shows what looks like a  ~1/f^2 low frequency component then the normal f^3 component above 10mhz. But looking at Hugh's measurments on the BSC's the tilt component for the ETMX T240-X/ISO-X looks different (second attached plot). I also looked at Fabrice's calculations in alog 8284 and his data there looks like Hugh's BSC data, not my HAM data. Made me think I'm looking at something else. My third plot shows calbrated spectra, and I think I just looking at sensor noise at 10mhz. My calibration could be a bit  off, but the specrta going flat at 10mhz on the red trace is suspicious. I don't know what the bubble below is, maybe actual tilt? If it is, that doesn't look like an easy measurement to make, or worth doing.

Today we saw the second instance of what seems like a serious guardian bug, where the guardian executes the line of code above a return True statement, but doesn't return True and exit the state.  Screen shots of both incidents are attached.  After the first inicident (shown in the first attached screenshot) Jamie suggested that possibly the requested state could have been erroneously set to be the state LOCK_DRMI_1F.  

Today I am sure that the requested state was DRMI_ON_POP, so it should have changed states after returning true. 

Below are this weeks past 10 day trends.

The usual procedure for clearing this trip condition is to change the reset value on the MEDM screen from 1 to 0 and then back again. This had no effect, in this case. After consulting with Stuart Aston, it seemed the only other recourse was to power cycle the PUM coil driver for ITMX. This was done ~10:20PST. THis action was successful. This smells like a software issue?

PSL DBB/ISS scans for this week.  No significant change from last week.

Dan, Sheila, ITMX

While testing the vioin mode damping tonight, we had an abrupt lockloss, and for a short period my bandpass filter at 501.094Hz was sending noise x120dB into the ITMX L2 coils.  This tripped the coil current watchdog, just like a previous event on ETMY a few weeks ago.  (There are now limiters on all the violin mode damping filters...)

Unlike ETMY we can't reset this watchdog by toggling the RMS Reset epics channel.  Anyone know how to clear this error?

We suspect something in hardware is preventing a software reset.  In the CDS highbay, the SUS Independent Watchdog electronics box has red lights that won't reset when we use the 'Fault Reset' button.

Dan, Kwiamu, Sheila

We noticed last night that we had almost no gain at low frequencies in the DHARD loop.  This is a little strange, and doesn't really make sense with the suspension model and our control filters.  The beofre measurement, which doesn't have great coherence at low frequencies is shown in the first attachment. We have a ugf around 3 Hz with about 27 degrees of phase, however we also probably have some lower ugfs and not much DC gain.  This doesn't make much sense given our control filter (alog 17006).  

We added a boost, which is two poles at 0.001 Hz, and a pair of complex zeros at 1.5 Hz with a Q of 3.  The situation for this boost is a little tricky, we can't afford to loose gain below 1 Hz and we can't afford to loose the phase that we would loose if we used real zeros. We ended up with the loop shown in the second attached screenshot. We have 3dB of gain  margin on the low side, 6 dB of gain margin on the high frequency side, and 17 degrees of phase margin.  We could probably make this more stable by moving up the roll off of our control filter, which currently has a pair of conplex poles at 12 Hz.  

We are leaving the loop as it was for lock acquisition, the unconditionally stable loop is usefull durring CARM offset reduction, but engaging this boost on resonance. 

Sheila, Kiwamu, Dan

We have had several occasions where we are trying to make a driven measurement, we can clearly see our drive orders of magnitude above the DARM noise, but we get no coherence according to DTT.  The first screenshot attached shows the coherence from my drive into the DHARD pitch loop to several channels that in principle all contain the same information:

H1:CAL-DELTAL_EXTERNAL_DQ, H1:LSC-DARM_IN1, and H1:LSC-DARM_OUT_DQ.  You can see all of these channels have different coherences, but I don't understand why.  Since I'm not driving the DARM filter bank, DARM IN and DARM OUT should be exactly the same information with a linear filter applied, and the CAL channel is the sum of these two channels with some calibration applied.  

Daniel, Kiwamu,

One of the to-do items today was to study how the rotational stage behaves. There have been some suspicion with the rotational stage that:

• It does not go to an exact requested power
• It acts as if the rotational mechanics slipps and therefore it does not come back to a consistent position

Also,

• we wanted to re-calibrate the angle-power relation.

We did a simple test today to study the above issues. It looks that the variation in the adjusted laser power can reach roughly 500 mW at most when the requested power is around 10 W. We also experienced a slipping-like behavior.

(Random walk in requested angle)

To check if it behaves good or bad, I wrote a script which randomly request the angle and automatically collects the resultant power for each random walk. This time I made 200 random steps within +- 90 deg. The result is shown below:

The data points are divided into half i.e. 100 samples each in chronological order. The red dots are the ones from the 1st half and the blue dots from the 2nd half. The difference is that we hit the "search for home button" between the two measurements. Since Daniel incidentally updated and rebooted the rotational stage code during the measurement, we had to hit the "search home" button as the reboot gave us a warning sign. As shown in the above plot, clearly the two data sets have different angle offsets which are visible as sine curves in the bottom residual plot. Because of that, the resultant residuals became bigger and reached 500 mW at most. Probably if I fit only one of the halves, the residuals would be smaller. At the moment, I have no good explanation of why the angle offset seemed to be shifted. I am guessing that it is not from the actual optical hardware as each data set was consistent.

Some notes:

• PMC power = 22.7 W
• ISS first loop on, diffracted power = 8%
• RS_VELOCITY was set to 100 (which is 10 times faster than the nominal operation in order to speed up the measurement)

(Calibration)

See the attached screen shot shown below for some details. Based on all the measured data from the random walk test, I fit the necessary parameters and updated the calibration of the rotational stage. Also the safe.snap in target/h1ecatc1/h1ecatc1plc1epics/burt is updated accordingly.

Dan, SHeila, Jeff K remotely

The coil driver for ETMY L1 shut itself off this afternoon, this might have been while I was trying to measure the L2P coupling there.  We switched the rocker switch and things are fine.  The symptom was that we didn't seem to be drivig even though everything on the medm screen looked fine, the OSEM readback all had low values.  This is the same situation we had at End X a while ago alog 16511

This is one of the "errors" that we probably need better monitorinng of.  As a short term solution maybe we could add this to TJ's list, to check if all OSEM readbacks are low for a certain stage. 

Hugh and Krishna had found the BRS software had crashed pretty much on schedule, so Sheila and I went to the end-station to restart it. Pretty straightforward. Alogs 13817 and 15005 will get you everything you need to do it. The BRS is rung up right now because we went out to check the mass damper positions, but it should settle down in 30 minutes or so.