Results from STS Centering Script:

All STSs prrof masses that within healthy range (< 2.0 [V]). Great!


Here's a list of how they're doing just in case you care:
STS A DOF X/U = 0.426 [V]
STS A DOF Y/V = -1.085 [V]
STS A DOF Z/W = -0.267 [V]
STS B DOF X/U = 0.688 [V]
STS B DOF Y/V = 0.468 [V]
STS B DOF Z/W = 0.405 [V]
STS C DOF X/U = 0.533 [V]
STS C DOF Y/V = -0.546 [V]
STS C DOF Z/W = -0.956 [V]
STS EX DOF X/U = 0.521 [V]
STS EX DOF Y/V = -1.057 [V]
STS EX DOF Z/W = 0.456 [V]
STS EY DOF X/U = 0.519 [V]
STS EY DOF Y/V = 0.741 [V]
STS EY DOF Z/W = -0.28 [V]

I forgot to alog this, its been usable for a few weeks now.

I made a script that will create a map of all the nodes and who is managed by whom. It uses the same packages as the normal Guardian maps for a similar look, and the same colors as the medms. The script will only map the current management, so if managers change, it will have to be re-ran for a new map. I will try to make this better later, but for now this will have to work.

Location: /opt/rtcds/userapps/release/guardian/manager_map.py

I attached a sample output.

T240 Centering script results:

There are 18 T240 proof masses out of range ( > 0.3 [V] )!
ITMX T240 1 DOF X/U = -3.297 [V]
ITMX T240 1 DOF Z/W = 0.439 [V]
ITMX T240 2 DOF Y/V = 0.505 [V]
ITMX T240 3 DOF X/U = -3.301 [V]
ITMX T240 3 DOF Z/W = -0.341 [V]
ITMY T240 1 DOF X/U = -0.433 [V]
ITMY T240 1 DOF Y/V = 0.359 [V]
ITMY T240 1 DOF Z/W = 0.34 [V]
ITMY T240 2 DOF Y/V = 0.43 [V]
ITMY T240 2 DOF Z/W = -0.345 [V]
ITMY T240 3 DOF X/U = -0.941 [V]
ITMY T240 3 DOF Y/V = -0.319 [V]
ITMY T240 3 DOF Z/W = -3.275 [V]
BS T240 1 DOF Y/V = 0.904 [V]
BS T240 1 DOF Z/W = 0.384 [V]
BS T240 2 DOF X/U = 0.96 [V]
BS T240 2 DOF Z/W = 0.481 [V]
BS T240 3 DOF Z/W = 0.927 [V]


All other proof masses are within range ( < 0.3 [V] ):
ETMX T240 1 DOF X/U = 0.158 [V]
ETMX T240 1 DOF Y/V = 0.143 [V]
ETMX T240 1 DOF Z/W = 0.19 [V]
ETMX T240 2 DOF X/U = 0.061 [V]
ETMX T240 2 DOF Y/V = -0.052 [V]
ETMX T240 2 DOF Z/W = 0.168 [V]
ETMX T240 3 DOF X/U = 0.153 [V]
ETMX T240 3 DOF Y/V = 0.008 [V]
ETMX T240 3 DOF Z/W = 0.113 [V]
ETMY T240 1 DOF X/U = 0.066 [V]
ETMY T240 1 DOF Y/V = 0.006 [V]
ETMY T240 1 DOF Z/W = 0.046 [V]
ETMY T240 2 DOF X/U = -0.126 [V]
ETMY T240 2 DOF Y/V = 0.059 [V]
ETMY T240 2 DOF Z/W = 0.148 [V]
ETMY T240 3 DOF X/U = 0.045 [V]
ETMY T240 3 DOF Y/V = 0.038 [V]
ETMY T240 3 DOF Z/W = 0.152 [V]
ITMX T240 1 DOF Y/V = -0.16 [V]
ITMX T240 2 DOF X/U = -0.227 [V]
ITMX T240 2 DOF Z/W = 0.219 [V]
ITMX T240 3 DOF Y/V = 0.18 [V]
ITMY T240 2 DOF X/U = 0.219 [V]
BS T240 1 DOF X/U = 0.207 [V]
BS T240 2 DOF Y/V = 0.182 [V]
BS T240 3 DOF X/U = 0.072 [V]
BS T240 3 DOF Y/V = 0.241 [V]

Feb. 3 2016 16:38 UTC Reconnected conlog-test-master to the same 99,560 channels are h1conlog1-master.

Added 350 ml of water to the diode chiller, as I noticed the red LED was on with the error
message about low water level.

4f H4 looks clean except for a small wipe mark near 1 o'clock close to the
retaining ring.

4f H1 has streaks visible with green light.  Wipe spots between 3 and 6
o'clock.  Possible spot/damage mark in centre of optic.  Hard to see.
Try cleanroom cotton tip to wipe pump light side.  Drag wipe removed
centre smudge.

4f H2 has a streak mark around 6 o'clock near the edge.  Also has a
hard to spot streak lined up with 12 o'clock and is ~3 mm wide.  Not
visible with white light, only seen with green light.

4f H3 has a spot around 7 o'clock near the edge.  Does not blow off.
Spot is ~2-3 mm from the edge.  Possibly on the pump light side of
the optic.  Hard to get to with the quartz rotator in the way.

Re-examined 4f H4 with green light.  Smudge in middle visible.
Vague spot visible under green light from the pump light side.
Spots visible from the pump light side, not visible from the H3 side.
Drag wiped surface, spot is now gone.

Quartz rotator surfaces look good under white and green light.

Spot on resonator side of output coupler, a little more than half
way from the centre to the edge, around 2 o'clock.  Drag wiped
clean.

Perhaps out of an abundance of caution it was good that we examined
the surfaces with green light.  Certainly a few wipe marks that were
present and not visible under a bright light source, were just visible
in green.  It might be that the wipe marks are inconsequential but at
this moment, it seemed prudent to deal with them.

Replaced intra-cavity shutter blade with new model.  The shutter
blades shipped from Livingston do not fit the external shutter as
there is a handedness problem.  EXTERNAL SHUTTER STILL
NEEDS UPGRADING.

Front end laser beam centered through MM2 iris, slightly off
to the left of centre as you look at the MM1 iris.  It is not clear
whether or not the beam was centred in the first place.

12:46 (PT) Turned on front end laser power watchdog.

Original mode matching lens positions:
L02 = 13.38, L03 = 6.42
L02 = 14.26, L03 = 6.35

PMC we have an offset somewhere as it does not lock to the
maximum transmission level unless the power on the locking
photodiode is turned down below the nominal 1.5V unlocked.
Upon some navel gazing, the offset might be due to some light
in the wrong polarisation falling on the photodiode.

ISS - adjusted waveplate until PDA DC = -10.0V and 
PDB DC = -10.16V.  Zeroed ISS QPD; new readings are 
dX = 0.0005 mm, dY = 0.0013 mm.





Jason, Peter

Summary:  Fairly straightforward recovery from maintenance day activities, which didn't end until after 4pm PST.  Several locklosses due to commissioning effort. 

Activity log:

0:04 Kyle back from MY

0:30 PSL crew done

0:39 Fil done

1:07 Jeff K to turn on EY ESD driver

3:37 cleared H1SUSETMY tim error

There seem to be two new rf oddities that appeared after maintenance today:

• AS90 seems to jump back and forth between two different offsets, maybe about once every hour or so.
• POP90 and AS90 both show irregular low-frequency motion, similar to what we see when an in-loop OSEM (or its sensing chain) goes bad. Ease of locking doesn't really seem to be affected, unlike the previous experience with bad OSEM electronics.

Jeff Kissel graciously made 4 StripTool templates for OPS use when having issues with WFS running away during green locking, as happened today.  These templates are:

ALSX_GreenWFS_Pitch_Metrics.stp
ALSX_GreenWFS_Yaw_Metrics.stp   
ALSY_GreenWFS_Pitch_Metrics.stp 
ALSY_GreenWFS_Yaw_Metrics.stp

and can be found in the usual place for OPS templates: /ligo/home/ops/Templates/StripTool.

These will likely be used with the assistance of a commissioner since I didn't catch all the intricacies of manipulating the WFS enough to explain it here, but they are there to save some time when needed.

I have reset all WD saturation counters for the platforms with warning. 

Also, I reset the HAM6 watchdog counter, which is not found on the OPS_HEPI_L4C_WD_SAT_CUSTOM.adl screen.  However, I was notified that HAM6 watchdogs were beyond 75% full via DIAG_MAIN.  Perhaps we should add HAM6 to this MEDM screen?  Or maybe not, since this seems to have been an ACT saturation, not an L4C??

See attached pics for details of what was reset.

[Jenne, JeffK, EvanH, Travis]

On our very first lock attempt (that made it past DRMI) after today's maintenence, we lost lock during the BS coil driver switching state.  Thanks to today's data saving work (see alog 25329), we now have some data to look at!

Attached are 2 figures of the same lockloss, one of which shows the whole time we were in the COIL_DRIVERS state, and the other zoomed in on the lockloss itself. On the top row of these figures, the left 3 plots are just power buildups, to indicate when the lock was actually lost.  The right-most plot is the ISC guardian state - state 505 is COIL_DRIVERS.  The bottom row of plots are the new FASTIMONs for each OSEM of the BS M2 stage.

These channels are plotted in units of ADC counts, but we have 40V/2^16 counts over a 40 ohm resistance, and the BS M2 actuation strength is about 1N/A.  The features in the LL channel are of order 100 counts, which corresponds to about 15 microNewtons.  For longitudinal, this is of order 60 nm of a kick to the BS.  The rms for MICH control above 10Hz is only 1e-14 m, so this is 6 orders of magnitude above the rms.  For pitch and yaw, this corresponds to about a 2 urad kick to the BS.  (Newtons to meters or radians from T1200404).

This seems like plenty to explain our locklosses. Next up: what to do about it?

When you have an xml file made by older diaggui, opening that file using the latest diaggui will cause some problem.

If you do that right after launching the new duaggui, the problem is most obvious because hitting the "Start" button will raise an error message: "No measurement channel defined: Unable to setup test channels."

You need to click and reselect each and every measurement channel. It seems as if these channels are already "selected", but select manually anyway. Hit "start" and this time the measurement starts.

OTOH, once you make any measurements using the new diaggui and open an old file later, hitting "start" will not cause an error, but sometimes not all channels are measured (but sometimes all channels are measured, not sure about the condition).

FRS ticket 4333 was filed.

J. Kissel

I'd found it frustrating that the ALS control system overview screens were not linked on the overall ALS overview screen, so I've added links. See attached screenshot.

Changes have been committed to the userapps repo, 
/opt/rtcds/userapps/release/als/common/medm/ALS_CUST_MAIN.adl

Today, Kissel and I worked through completing the following (taken from ECR E1600033) for the SUSAUX QUAD and BS models.  This meant recompiling and restarting h1susauxb123, h1susauxex, and h1susauxey with CDS and building new medms screens.

1) Remove SUS NOISE and VOLT MONs from all UPPER stages of SUSes, and non-globally controlled LOWEST stages, and replace with FAST_I_MONs with same data rate.

2) Remove SUS NOISE and VOLT MONs from frames of 10 SUSes under global control and replace with FAST_I MONs (or Fast LV ESD MONs where applicable) with increased data rate of 16k.

3) We will add associated filter banks for every FAST_I_MON.

Data rate calculations show that there will be a zero sum gain to the Science frames by performing the above (see supporting spreadsheet on DCC page).

New FASTIMON screens are shown below.  All model and medm changes have been committed to the SVN.

H1 has 30 sender RFM channels on each arm, of which only 26 have corresponding receiver(s). So 4 are being sent and no model is using the data.

L1 has 29 senders on the X-ARM (of which there are 26 receivers), and 30 senders on the Y-ARM (of which there are 26 receivers).

So the two sites are very close in number of sending channels.

Analysis details: The base number of potential senders was derived from the main IPC file, looking for RFM0 and RFM1 ipc types. This resulted in 30 for H1-X and H1-Y, and 42 for L1-X and L1-Y. Because the ipc file is only appended to during compilation, if it has not been cleanly regenerated recently it may overcount the number of sending channels.

For each channel, I searched the models' RCG generated IPC_STATUS.adl medm file for the channel name (e.g. H1LSC_IPC_STATUS.adl). Assuming that no two ipc channels share the same name, if I found the channel name in the adl file this means it is a running sender with a receiver. For the remaining possible senders without receivers (H1-X=4, H1-Y=4, L1-X=16, L1-Y=16) I looked for the channels in the top level simulink source files (e.g. /opt/rtcds/userapps/release/*/l1/models/l1*.mdl). This showed that all four channels on H1-X and H1-Y do have sending models, and for L1-X 3 of the 16 had sending models, and for L1-Y 4 of the 16 had sending models.

If we can possibly remove some of the RFM channels which are not being received, additional RFM channels can be added to the loop with no risk.

For H1 the sending channels with no receivers are:

• H1:OAF-PEME[X,Y]_RFM
• H1:ASC-[X,Y]_TR_A_SUM_RFM
• H1:ALS-[X,Y]_ARM_RFM
• H1:ALS-[X,Y]_REFL_B_LF_RFM