Sending seismic data from h1oaf to h1pemex

Hugh, Dave:

On 27th February I modified h1oaf to add two RFM senders, one for each arm. This tested that sending the additional channel around the RFM loop did not adversely impact the existing data transfer.

Today Hugh added a receiver for the X-arm channel on h1pemex. The receiver reported continuous errors once all systems were started.

After thinking about this the answer became obvious, the h1oaf model is running way too long to be able to send an RFM signal to the end station. The Timing System reports the latency of sending a signal over the single-mode fiber-optics link to the end station is 29uS. Therefore sending models should ideally be running under 30uS total processing time, which is the case with h1omc (14uS).

To quickly test this, I moved the RFM channel H1:SEI-OAF_2_EX_MUX_RFM from h1oaf to h1pemcs (I hand edited H1.ipc to change the source model name), recompiled and restarted h1oaf and h1pemcs, at which point the receive errors at h1pemex were cleared.

The temporary solution (until we install the long-range Dolphin network) is to use h1pemcs to receive, process and distribute the ground motion data. Any signals which may also be needed by h1oaf can either be read from the dolphin network separately, or sent from h1pemcs via shared memory IPC channels.

CDS maintenace summary

WP7397 DNS server upgrade

Carlos, Ryan:

The internal CDS DNS servers were upgraded, please see alog 40855 for details.

WP7380 Squeeze model changes

Sheila, Dave:

The models h1omc, h1asc, h1sqzwfs and h1susopo were modified and restarted this morning.

Seismic STS-GND site wide data distribution

Hugh, Dave:

We modified the models h1isietmx, h1pemex, h1oaf and h1isiitmy to send RFM data between the corner station and EX. Please see secondary alog for details of the problem found and its resolution.

HWWD reset at EY.

The HWWD unit was reset at EY to permit ISI operation. I verified that the LEDs did their startup sequence at the time of the reset.

Fixed broken related display links on SDF_OVERVIEW MEDM

There were three broken buttons on the new SDF MEDM, these are fixed.

New Beckhoff C1PLC4 and safety configurations

Daniel, Patrick, Dave:

New H1ECATC1PLC4.ini and H0EDCU_SAFETY.ini files were generated. I still need to update the autoBurt.req and SDFs for these systems.

DAQ Restart.

DAQ was restarted for various changes:

new H1EDCU_ECATC1PLC4.ini

new H0EDCU_SAFETY.ini

new ini files for h1isietmx, h1oaf, h1pemex, h1sqzwfs, h1susopo

I attempted to add a new INI file for the Rate-Of-Change (ROC) system, which is supporting CP4 bake-out. But I found that some of the channel names exceed the 54 max length limit. Because of this the DAQ restart took longer than usual (about 10 minutes compared with a couple of minutes)

WP7377 h1tw0 hardware replacement

Carlos, Jonathan

The old h1tw0 (cpu and external raid) were removed from the DAQ rack, and were replaced with a single new 4U unit.

Vacuum cell phone alarms, both Thermocouples high alarm set at 130C.

Chandra, Dave:

To support CP4 bake-out, the two thermocouples which are in the cell phone alarm system had their high alarm limit set to 130C.

EY SUS work this afternoon - no progress

This afternoon, I went into BSC10 with the intent to:

1) Find something mechanical on TMSY that was causing a small peak at around 2.5 Hz to poke up out of the transfer functions.

- Thought I found something, TFs back in the CR show I didn't fix it.

2) Find something mechanical on ETMY that was causing a small peak poking out of the P TF.

- Found something on the reaction chain, but nothing on the main.

3) Center the L2 stage AOSEMs on ETMY since they moved after Travis' tweek to the pitch of the reaction chain late last week.

- Did this!  Woohoo.

4) Try to hunt down the mechanical shorts on the cables Fil reported in his alog from last week.

- Didn't have the feed thru map on me while standing in the chamber alone so couldn't figure out which cable of the 30 connections to start working on.  Fil's language of what cables doesn't help much with out further maps...  Now back in the CR, Kissel and I see that the shorts are apparently on these cables:

ETMY Face Cable

ETMY L1 (UIM stage)

ETMY L2 (PUM stage)

 

The TMS looks fine for shorts.

ETMY shared cable and R0 face cable look fine for shorts.

See attached fro spectra.

 

 

 

 

Ops Day Shift Summary

SQZ invac thermistor readouts

There are 3 in-vac thermistors mounted to the OPO. The first one is read through the TEC controller and works fine. The other 2 are reading zero Ohms. The wiring is correct up to the Squeezer EtherCAT chassis 3, indicating it has an internal wiring problem.

The Peltier heater works too. The controller parameters and loop shape were imported from LLO, and the servo works in-air.

WP 7376, rack hardware for a new h1tw0

Carlos and I racked the new hardware for h1tw0.  The old hardware has been pulled from the racks.

SEI Ground Siesmometer Mass Position Check (FAMIS #6096)

   Ran SEI seismometer mass position checks. The following are out of range:


There are 13 T240 proof masses out of range ( > 0.3 [V] )!
ETMX T240 1 DOF X/U = -0.345 [V]
ETMX T240 1 DOF Z/W = -0.578 [V]
ETMX T240 2 DOF X/U = -0.491 [V]
ETMX T240 2 DOF Z/W = -1.077 [V]
ETMY T240 1 DOF Z/W = -1.013 [V]
ETMY T240 2 DOF Y/V = -0.852 [V]
ETMY T240 3 DOF X/U = -0.912 [V]
ETMY T240 3 DOF Y/V = -0.392 [V]
ITMX T240 1 DOF X/U = -0.594 [V]
ITMX T240 2 DOF Z/W = 0.343 [V]
ITMX T240 3 DOF X/U = -0.671 [V]
ITMY T240 3 DOF X/U = -0.677 [V]
ITMY T240 3 DOF Z/W = -1.293 [V]

and 

There are 2 STS proof masses out of range ( > 2.0 [V] )!
STS A DOF Y/V = -4.67 [V]
STS A DOF Z/W = 5.894 [V]

   All other T240s and STSs are reporting in range. 

PSL Weekly Report - 10 Day Trends FAMIS #6190

Trends reflect ongoing work during 70W installation.

DNS Servers upgraded to Stretch (Debian 9)

Both DNS servers were upgrade to Stretch (Debian 9) this morning and place under puppet management. no unexpected events during upgrade process happened. Some user may experience and few (maybe 3 to 5 ) seconds delay on their  Internet browsers when accessing some website, that is due to the DNS servers updating/reloading their cache. 

All HTTS COILOUTF Gains Flipped to Obey T1200015 Sign Convention

J. Kissel

During the teething period for ZM1 (for most relevant aLOG see LHO aLOG 40847), I've identified that I have been mistakenly and blindly installing COILOUTF gains for the HTTS (Ham Tip Tilt Suspensions; OM1, OM2, OM3, RM1, RM2, ZM1, ZM2) that match the magnet configuration of a QUAD UIM (E1000617) instead of what they've been built to be (E1400316), which is exactly opposite the QUAD UIM. Thus, damping loop feedback gains have been positive for quite some time. 

I have now remedied this flaw in sign allocation on all** HTTS, and saved the the change into the SDF system (and committed the safe.snaps to the userapps svn). 
This has three main benefits:
    - The COILOUTF signs vs. Magnet polarities are now consistent with other BOSEMs / magnet systems.
    - Each DOF's M1 to M1 transfer functions now show an overall 0 [deg] phase at DC, and decreases to -180 [deg] above resonance as one expects from a single-stage suspension.
    - The allocation of signs understandable from a simple logic thread, as defined in T1200015.

Just to be explicit, the correct COILOUT gains are
    
    UL = +1 (for N), LL = -1 (for S), UR = -1 (for S), LR = +1 (for N).
    
and all feedback damping loop gains are -1.

** All excludes RM2 -- because it has always had the opposite damping loop sign as the other (now) 6 HTTS. I suspect it's because RM2 *actually* has its magnet polarities incorrectly in the QUAD UIM BOSEM configuration. Thus, I've left the COILOUTF in the configuration to compensate for it, this way we're correctly compensating for the incorrect magnet polarities, and we can have a negative feedback gain on the damping loops like every other HTTS. Thus, for RM2 only,
    
    FOR RM2 ONLY UL = -1 (for S), LL = +1 (for N), UR = +1 (for N), LR = -1 (for S). 

model changes for squeezing

Sheila, Dave Barker

I have made several model changes for squeezing with help from Dave for some debugging. 

The models which have been compiled and checked into the svn are:

omc/common/models/omc.mdl
omc/h1/models/h1omc.mdl
asc/common/models/ASC_MASTER.mdl
asc/h1/h1asc.mdl
sus/h1/models/h1susopo.mdl
sqz/common/models/SQZASC_MASTER.mdl
sqz/common/models/h1sqzwfs.mdl

I also changed sqz/common/SQZ_MASTER.mdl and sqz/h1/models/h1sqz.mdl but have not checked them into the svn because they don't compile.  Dave and I will continue to look at that tomorrow.  

The changes to h1susopo.mdl were just to add IPC receives from sqzwfs for ZM1/2 pit and yaw.  

The changes to the omc models were just to add IPC senders that send the DCPD null and sum to the SQZ_MASTER model.  There are already IPCs sending SUM and NULL to the calibration model, but with normalizations that are not quite the same for sum and null.  I decided to just add new IPCs so that we don't need to worry about settings in the calibration models for the squeezer.  

The changes in the ASC models were similarly just to add IPC sends.  We are now sending AS_C sum to SQZ_MASTER.  This is used for the seed phase locking I added a few months ago, which we haven't used yet. (You can try to lock the phase of the seed beam to generate a stable 1064nm beam out of the OPO, I was thinking this might be useful while we are in chamber trying to scan or lock the OMC, although it wasn't used at LLO.)  The rest of the senders added to ASC are AS QPDs which are added to the SQZWFS input matrix so that we can close some simple alignment loops around the ZMs while we are working on the alignment without the full interferometer.

In the SQZ_MASTER model I added some blrms for the DCPD sum and nullstream, which we can use to make monitors of the squeezing level.  I also added code for a noise lock which can dither the LO loop lock point, demodulate one of our BLRMs, and feedback to the lock point of the LO loop.  There is also the option of demodulating the CLF Q signal, or the DCPD Q signal (or the homodyne 3MHz signal), which was an idea that Lee suggested for setting the LO demod phase.  Right now this has an output matrix which only allows the signal to offset the lock point of the LO loop, but other options could be added. 

Bugs:

Dave helped me to debug a problem in the sqz wfs model.  I had originally not given descriptive names to the input and output ports on the subsystems, using the default in1, in2, ect.  I attempted to rename these to more descriptive things this time, like AS_A_RF42_I_PIT, which was fine in the SQZ_ASC block, but when I tried to do this in the ASC block the RCG gave bogus errors and would not compile. We have left these as non descriptive names. We are currently having trouble compiling h1sqz because the RCG isn't creating automatically generated medms for the new dither lock.  

ZM1 Update: Magnets Flipped to Obey E1400316, COILOUTF & DAMP Gains Make Sense -- but now rubbing... :-(

J. Kissel, T. Shaffer

TJ has flipped the flag/magnets on H1 SUS ZM1 such that they now obey E1400316 as designed. I've also flipped the sign on the COILOUTF gains, such that make sense according to T1200015. Great!

But, sadly, in flipping the flags, the suspension is now rubbing, as shown by especially the Y to Y transfer function which now shows a second, unexpected resonance at 1.17 Hz (which is *not* the first L/P mode at 1.26 Hz, nor the first P/L mode at 1.68 Hz). Also, the P to P transfer function shows an abnormal change in the mid-resonances zero, and the (what should be the only) Y to Y resonance has shifted down in frequency.

Hurumph. 

When TJ came in he was mentioning that the OSEMs weren't well centered any more, and he later guesses that it's because the re-installed flags weren't as straight as he'd liked. Sounds like he's got an idea or two on how to free up the rubbing, so hopefully tomorrow's fix will be easy.

CP4 bake update

CP4 is cooking along. Smells real good at mid-y now. I forced the enclosed air temp to rise faster than 1C/hr for several minutes to test ROC alarms, which we found work as intended, along with max temperature alarm. The setpoint is now 110C (TC#1 measuring 76C now, with some fluctuations due to testing). We will continue to monitor overnight with assurance that we have text alarms to help out.

The Y1 arm pressure is increasing. GV11 and BSC replacement spool are relatively wet compared to beam tube and thus outgassing. We discussed closing GV10 and valving in main turbo (and small IP below CP1); still contemplating that (WWJD?). May take action if/when Y1 pressures exceed the turbos ultimate pressure (~5e-8 Torr). Alarms for Y1 have been adjusted to 5e-8 Torr setpoint. CP4 pressure raised to 5e-5 Torr. 

 Bubba turned the VEA chiller on this morning to help control room temp. It was approaching 70F.

ZM1 Update: 'All HTTS Are Wrong, You Say?' No -- It's that the QUAD UIM has Magnets Are Oriented With Opposite Polarity #facepalm

J. Kissel, T. Shaffer

Last Friday, I told TJ to flip 2 of the 4 H1SUSZM1 magnets (UR and LR) because I'd found that I needed to flip the signs of the corresponding COILOUTF bank to make the transfer functions look clean (see LHO aLOG 40808 and subsequent comments). In doing so, I'd insisted that "sadly, all HTTSs (except for RM2) have their magnets oriented exactly opposite to their documentation" (the controls arrangment poster, E1400316), and concluded that -- instead of fixing every other HTTS -- we convert ZM1 to the "wrong" convention such that they're at least all the same. This statement was based on the sign of the required damping loop gain, assuming all other digital signs were correct.

This morning, he flipped magnets according to what I've insisted, so I re-took transfer functions. They revealed the phase remained zero at DC, instead of being -180 like every other HTTS, implying that I understand the magnet polarities exactly wrong.

Upon closer inspection and a review of all signs with TJ, we've identified the real problem is because I have been blindly obeying the sign convention table in T1200015 for "BOSEM 4 OSEM Stage" when it comes to the COILOUTF gains. However, this table was created for the QUAD's UIM stage (the only other 4 OSEM stage in the IFO that has BOSEMs). 
The QUAD's UIM, BOSEM 4 OSEM magnet orientation, as shown in E1000617, is exactly opposite that of the HTTS.
#facepalm.

So, after apologizing profusely to TJ, I've asked him to now flip both sides flag/magnets to be exactly as is shown in the HTTS controls arrangement poster (again, E1400316), namely
    UL        UR
    N          S

    
    S          N
    LL        LR
and now *I* need to change all HTTS's COILOUTF gains: 
          Are Now   Should Be
    UL       -1        +1
    LL       +1        -1
    UR       +1        -1
    LR       -1        +1
so that the BOSEM coils obey the correct push-pull force table at the top of T1200015, damping loop gains can be an easily understood -1.

I'll sure to check with LLO to make sure they update, if needed, and then make a new version of T1200015 that specifies the difference between a QUAD and an HTTS BOSEM 4 OSEM stage.

Opened GV2

Ops Day Shift Summary

TCSY glitch investigation, preliminary results

Plots in the attached file show a large glitch in the FLOWRATE that also shows up in other signals.  Glitch seen in QPD segments, and LASERTEMPVOLTAGE.

SQZ in-vac cabling

Sheila Daniel

We couldn't see the thermistors after connecting the in-vac sqz cables. Investigating, we found that the signals can be found on cable 303 rather than 304 at the sqz satellite chassis; and the PZTs seem to show up on cable 304 rather than 303. The DCPDs show up as expected on 305. As a side note, we noticed that for DCPD2 the case is connected to the anode, where this is not true for DCPD1. The sqz satellite chassis seems to short the case to the cathode, so this looks like an unwanted short.

We traced the cables to the vacuum flange and found them to be connected correctly, indicating that they are swapped in the chamber. Taking a look inside, we couldn't figure out how relate the cable harness routing described in D1300122 with what is installed. We gave up and left the cables disconnected at the satellite chassis.

ZM1 Infrastructure Filled In; First Driven TFs Show Rubbing or Electronics Issues

J. Kissel

I've filled in the infrastructure for ZM1, which was mostly copying over filters from ZM2, and filling in the standard OSEM2EUL and EUL2OSEM matrices for an HTTS. I found, however, that the damping loops don't work. So, I took some driven transfer functions and spectra to see if I could identify the problem. Sadly, the dynamics -- especially the common mode actuator longitudinal TF -- looks pretty dicey. See attached screen shots.

Data templates live here:
/ligo/svncommon/SusSVN/sus/trunk/HTTS/H1/ZM1/SAGM1/Data
    2018-03-02_2225_H1SUSZM1_M1_WhiteNoise_L_0p01to50Hz.xml
    2018-03-02_2225_H1SUSZM1_M1_WhiteNoise_P_0p01to50Hz.xml
    2018-03-02_2225_H1SUSZM1_M1_WhiteNoise_Y_0p01to50Hz.xml

Problem with ZM1 Identified / Diagnosed; Solution Proposed

J. Kissel

The above transfer functions -- especially the P to P and Y to Y transfer functions -- reminded me of what we typically see in the off-diagonal transfer functions (e.g. P to Y or Y to L). This lead me to suspect the basis transformation and/or the sign of actuation chain. I first confirmed that the OSEM2EUL or EUL2OSEM matrices were installed correctly, and they were (I just did it, so...).  So, then I started applying offsets in the COILOUTF bank. 

Using the conventions defined in T1200015, I expect that a positive offset in the COILOUTF bank (if I've got the COILOUTF GAIN correct, and the magnets are arranged as in the HTTS controls design description, E1400316) would cause that corresponding OSEM sensor to go more positive. This worked for UL and LL, but I got a more negative response from UR and LR.

I then flipped the COILOUTF GAIN sign on those two, and et voila! The transfer functions cleaned up nicely, and look exactly as expected (within the tolerance / varience of HTTS resonances that we've seen prior).
I conclude that the UR and LR Flag/Magnets have N and S facing magnets, respectively (when looking at them from the back of the optic) when they hould have S and N, respectively.

Nice -- "simple" solution!
For now, I've left the non-conforming COILOUTF gains that make the SUS bhave as normal in place.

I've spoken with TJ, and he'll (a) check the polarity of the flags to confirm, and (b) flip them, such that ZM1 conforms to E1400316 on Monday.

If only the OPOS was this easy to diagnose...

New data files live in 
/ligo/svncommon/SusSVN/sus/trunk/HTTS/H1/ZM1/SAGM1/Data/
    2018-03-02_2312_H1SUSZM1_M1_WhiteNoise_L_0p01to50Hz.xml
    2018-03-02_2312_H1SUSZM1_M1_WhiteNoise_P_0p01to50Hz.xml
    2018-03-02_2312_H1SUSZM1_M1_WhiteNoise_Y_0p01to50Hz.xml

 ... But #RespectThePhase

J. Kissel

A keen observer will notice that although the labels in the legend say ZM1 for the reference, I copied over the template from  
/ligo/svncommon/SusSVN/sus/trunk/HTTS/H1/ZM2/SAGM1/Data/
    2018-01-24_1909_H1SUSZM2_M1_WhiteNoise_L_0p01to50Hz.xml
    2018-01-24_1909_H1SUSZM2_M1_WhiteNoise_P_0p01to50Hz.xml
    2018-01-24_1909_H1SUSZM2_M1_WhiteNoise_Y_0p01to50Hz.xml
then text search-and-replaced ZM1 with ZM2. Long-story-short: the reference trace is ZM2. 

Now, respect the phase: see that ZM2's phase is 180 deg at DC, where ZM1's is 0 deg at DC for all DOFs? Grumble Grumble Grumble... That means where ZM2 requires a different damping loop sign than ZM1.
An inventory of our HTTS reveals that OM1, OM2, OM3, ZM2, and RM1 all require positive damping loop gains (all other digital signs being equal), and RM2 -- and now ZM1 -- requires negative.
Sadly -- this also means that ALL BUT RM2 and ZM1 ARE WRONG by an overall sign.

*now* I think that it's the *LEFT* sign of the magnets that are flipped the wrong way -- namely that UL and LL are  S and N, respectively when they should be N and S, respectively.

But -- since we have access to ZM1 right now, and I'd rather we have to change one (two, if you count RM2) suspension than five.

So -- this is what I predict TJ will find (looking at the back / AR side of the optic):

    UL        UR
    S         S

    
    N         N
    LL        LR
and he should re-arrange the magnets to be

    UL        UR
    S         N

    
    N         S
    LL        LR
which is the exact opposite of what's shown in E1400316, so that we confirm to the apparent LHO convention.

THIS aLOG AND COMMENTS ARE FULL OF LIES: Go to LHO aLOG 40847 for final answer as to what was going wrong with the sign convention.