K. Venkateswara

After the problems with BRS last week (15005), it was left off for the last ~five days. I tested the damper controller and it looked like the issue with vibration driving the BRS had cropped up again (14596). It wasn't clear why this problem had reappeared but since the foam sheet had worked previously, I went back to that configuration. With the foam sheet under it, the damper appears to be working fine. However another issue with it is that the zero position of the turn-table appears to change, seemingly randomly. It is possible that the stepper motor is occasionally getting stuck. As it's not servo'd this may explain the drift in the zero position. For the moment, I think it requires periodic checking to ensure its zero hasn't changed too much. If it changes by 90 degrees, it can drive the BRS in a positive feedback loop like last week. A servo loop is a better long term solution.

I have also modified the following filters:

1. BRS transfer function inversion filter to correctly account for the imaginary zero at 7.3 mHz (due to the finite d). I was using pairQ(7.3e-3,3) before whereas pair(7.3e-3,0) should be the right choice.

2. The tilt-subtraction filter has also been changed - the high-pass filter (2-pole) has been changed from 2.5 mhz to 4.3 mHz to correctly compensate for the T240 resonance.

The attached pdfs show the ASD for the BRS and the ground T240 in angle and displacement.

J. Warner, J. Kissel, K. Venkateswara

After improved modelling of sensor correction (SC), thanks to Rich M. (615, 623), we re-attempted SC along X (and along Z). X sensor correction was to stage 1 ISI, while Z was on HEPI. Unlike our previous attempt (14896), we used Rich's SC_filter described previously in 14570.

The first pdf shows the ASD from before SC for X and Z. Stage 1 T240, CPS and ground motion is shown and the coherence between them. The second shows the platform motions after SC. The third pdf shows a comparison between the configurations as measured by the T240 showing the expected 2-5 factor improvement between 0.1 to 0.5 Hz. It also shows an improvement below that which is more surprising (maybe from Z SC?). There is no visible re-injection of noise (factor of ~2 is epxected between 20-40 mHz), because we are probably dominated by pre-existing noise which is larger. More testing will be done tomorrow. The OpLevs are currently mis-aligned so I can't see the effect of SC on them.

Note that the we did not use tilt-subtraction at the moment because wind-speeds were practically zero. We will test the tilt-subtraction when winds pick up a bit.

Once again, if this appears to be adding noise instead of helping, the comissioners can turn it off from the ETMX ISI medm screen as before.

Gabriele, Jeff, Dave

Two sets of DAQ restarts today:

11:27 Resync INI files for SUS changes made by Jeff (HAM4,5)

11:57 Resync INI file for h1psliss model change, made by Gabriele

No Beckhoff INI changes seen over the past week.

Jamie, Dave [WP4947]

Today we reconfigured and restarted all the guardians to ensure that no log files will be deleted.

The process involved running guardctrl create --all and then stopping and restarting the entire guardian supervision. The guardian nodes did not restart, which Jamie tracked down to default settings after the re-creation. He started all the nodes, but one of the 71 nodes did not restart cleanly (SUS_MC2). A subsequent restart of this node was successful, Jamie is investigating why this happened.

We will most probably reboot the guardian machine next week for OS security patching and at that time check for any node failing to start correctly. Today we just patched bash.

We will keep WP 4947 open to cover next weeks patching.

New  SR3 offset: [452.9, -155.3].

There could be +-120-ish measurement error for YAW due to difficulty in finding the PR2 baffle right edge, so later if somebody gets suspicious about the clipping finer YAW scan of SR3 might be a good idea. This problem is not present for PIT.

New SR2 offset: [2800, 800].

Tolerance is +-100, but the center value strongly depends on the SR3 offset.

Since Doug is not available for finding the SR3 oplev beam with new offset, and since we use SR3 oplev for damping, we reverted SR3 and SR2 back to the original angle.

Tomorrow morning SR3 oplev will be done with Doug.

Plots will be posted later.

Patrick, Dave

The conlog reporting of frequently changing EPICS channels has discovered several code issues in the past week. Conlog reports hourly those channels which have logged 500 or more changes in the previous hour. I have written a python script to concatinate 24 hourly reports into a daily report, which I'll post in the alog. 

Below is the log from yesterday (Monday 11/17). We discovered a guardian node which was setting the end station SUS L1_LOCK_L filters RSET (clearing history) at 16Hz. This was fixed between 1pm and 2pm.

The per-second number is calculated as total/(hours-active * 3600). Numbers in the 16 range are most probably front end or guardian related, higher than 16 most probably Beckhoff or scripts.

11/17/2014                                         hs    total per-sec

                        H1:SUS-ETMX_L1_LOCK_L_RSET 14   751286 14.9

                        H1:SUS-ETMY_L1_LOCK_L_RSET 14   751286 14.9

                         H1:ALS-C_COMM_VCO_TUNEOFS 02    90021 12.5

         H1:ALS-Y_FIBR_LOCK_TEMPERATURECONTROLS_ON 06    62062 2.9

                          H1:ALS-Y_CAM_ITM_PIT_POS 24    58548 0.7

                          H1:ALS-Y_CAM_ITM_YAW_POS 24    58548 0.7

                              H1:ALS-Y_CAM_ITM_SUM 24    58539 0.7

                           H1:GRD-ALS_YARM_USERMSG 05    16658 0.9

                         H1:ALS-X_REFL_SERVO_IN1EN 05    11208 0.6

                 H1:SUS-IM4_M1_OPTICALIGN_Y_OFFSET 03     6052 0.6

                 H1:SUS-IM4_M1_OPTICALIGN_P_OFFSET 02     3136 0.4

                            H1:GRD-ALS_XARM_STATUS 02     3082 0.4

                           H1:GRD-ALS_COMM_USERMSG 03     1781 0.2

              H1:SYS-MOTION_C_PICO_A_CURRENT_DRIVE 02     1516 0.2

                          H1:GRD-ALS_XARM_TARGET_S 01      632 0.2

                           H1:GRD-ALS_XARM_STATE_S 01      550 0.2

                 H1:SUS-PRM_M1_OPTICALIGN_P_OFFSET 01      504 0.1

I've restarted the web snapshot tool for the vacuum screens to incorporate updates by G. Moreno.

LVEA: Laser Hazard
Observation Bit: Undisturbed, Switched to Commissioning  

06:45 Karen – Cleaning in the LVEA
08:24 Krishna – End-X to work on the BRS system
08:30 Karen – Out of the LVEA
08:35 Filiberto & Aaron – going to End-Y and End-X to switch power for PEM and PCal
08:46 Karen – Going to End-Y
08:48 Mitch & Jeremy – Working in west bay on ACB assembly
09:50 Dave – Restarting Guardian
09:55 Joe – Going into the LVEA to check fire extinguishers and emergency lights
10:25 Cyrus  – Going to end-y to reboot computers
10:30 Keita – Taking a tour through the LVEA 
10:33 Dick – Checking electronics at ISC Rack #1 
10:41 Joe – Out of the LVEA
10:50 Praxair - N2 delivery to CP8 
11:01 Karen – Back from End-Y
11:08 Keita – Out of the LVEA
11:35 Praxair – N2 delivery to CP4
12:00 Dave & Ops – DAQ restart
12:25 Filiberto & Aaron – Back from the end stations
13:00 Dick – Out of the LVEA
13:15 Betsy – Working in LVEA west bay
13:35 Mitch & Jeremy – Working in LVEA west bay on ACB assembly
14:24 Richard – Escorting fire department to Mid-Y
14:37 Kyle – In LVEA checking vacuum equipment
14:48 Kyle – Out of the LVEA
14:52 Andres – Going to LVEA west bay
14:55 North Coast – Delivering parts for Richard

J. Kissel

I've installed IPC broadcasters into the h1isiham4 and h1isiham5 front-end models in order to broadcast the HAM4 & HAM5 ST1 GS13s. Subsequently, I've installed IPC receivers into the h1sussrm, h1sussr2, and h1sussr3 models. With this installation, it completes the signal chain such that each SUS can now compute their own suspension point motion. All that computational infrastructure had already been in place (calibration filters, transformation matrices, etc), but they were just not receiving any input signals. I attach a pdf demonstrating the power of this fully operational battle station for SR3. The pictures attached show trends of displacement SRM, SR2, and SR3 indicating that their positions have been restored to what they were before I started.

Detailed, roughly chronological notes:
---------------------------------------------------
Alignment Offsets before getting started:
        P [urad]    Y [urad]
SRM   -934.049    430.123
SR2   2963.7     2728.0
SR3    430.3      142.6

- made and saved mods to h1isiham4.mdl, h1isiham5.mdl, h1sussrm.mdl, h1sussr2.mdl, h1sussr3.mdl by adding 6 cdsIPCx_PCIE (i.e. corner station dolphin network IPCs) sender parts to each HAM ISI top-level model, with the following "channel names" H1:ISI-HAM[4,5]_2_SUS_GS13_[X,Y,RZ,Z,RX,RY], and created a corresponding 6 cdsIPCx_PCIE receiver parts in the SUS models.
- paused HAM4 and HAM5 SEI manager guardians
- changed ISI guardians to "EXEC", brought ISIs to "READY", turned off master switch (and left HEPIs alone)
- brought SUS guradians to "SAFE"
- captured new safe.snaps for SUS (forgot to do ISI, but J. Warner / H. Radkins are confident that their safe.snaps are up-to-date. I've confirmed that all local to cartesian matrices still obey the conventions defined in T1000388)
- logged onto h1build as controls, used cdsCode alias to get to build directory, /opt/rtcds/lho/h1/release/
- compiled models, e.g. make h1isiham4, making sure to compile the sender models first (i.e. the HAM ISI models)
- installed models, e.g. make install-h1isiham4, again making sure to install sender models first
- logged on to each model's front end, i.e. for the ISIs h1isih45, and for the SUSs, h1sush34 and h1sush56
- restarted models, e.g. starth1isiham4, again restarting sender models (the ISIs) first. Out of habit, I made sure to have the GDS_TP screens open and hit the BURT button as soon as it became available. I don't thin it's necessary, but for big models with tons of EPICs channels, I can click the button faster than the BURT restore can install the right value.
- Brought SUS back to "ALIGNED", confirmed that all SUS had the same alignments restored as mentioned above.
- Brought ISIs back up to "HIGH_ISOLATED,"
- changed ISI back to managed, SEI manager guardian back to exec
- DAQ restart, because I found nonsense (and its needed when one adds new *receiver* parts)
- Went through each model's GPD_TP screen and hit "diag reset" to clear initial, start-up transient, errors from both the timing and IPC- Started trending alignments of SUS to confirm they've gone back to the same place.
- SR3 optical lever damping came up with both stages (M2 and M3) on -- maybe turning this on is hard coded in an ISC guardian somewhere? 
- Turned the SR3 M3 optical lever damping OFF, now both filter modules' SWSTATs report what they were before I got started.
- Now SR3 optical lever reports the P and Y position has been restored to within 1 [urad].
- Found SRM in the same place (according to M3_WIT_P and Y OSEM sensor channels) with larger noise on trend, found with getting constantly pulsed by ISC L from. 
- Changed ISC_DRMI guard state to DOWN (it had been in INIT, and its background RED indicating an error; probably because it had lots communication with one of its subordinates, i.e. SRM). Noise in trend went away. Now restored to with 0.5 [urad] in P and T.
- Not sure about exponential shape of SR2's M3_WIT_P and Y signals, but they appear to be asymptotic toward the previous original position. Spot on AS camera appears centered, and as of this entry, Dan has been able to re-lock the OMC using an IX single-bounce.
- Committed modified top-level isi and sus models and safe.snaps to userapps repo.

This completes work permit Work Permit #4944. Note that this installation is simply completing what had been installed for the rest of the SUS in H1 back in October 2012 - Jan 2013, see e.g. LHO aLOG 4553. The theory behind the matrix transforms (that were already installed) can be found in T1100617.

I don't want to jinx anything, but I have misaligned OM3 to steer the beam away from the OMC and the DCPDs, in case of big power spikes at the AS port.

I found that moving the OMC SUS itself was useless for moving the beam away from the cavity axis (vice-versa, really).  Moving the PIT and YAW sliders rail to rail only moved the beam on the OMC QPDs by a small amount.  (It was clear the sliders were doing something, but it was puny compared to the tip-tilt actuation.)  FYI the OMC SUS pitch slider rails the output to the DAC at +/-6000, for the T2 and T3 actuators.  The yaw slider doesn't rail the DAC output until +/-12000 (LF and RT actuators).  I was expecting the OMC SUS to have a little more oomf than this, we should check that everything is working correctly.

So, I've moved OM3 to get the beam away from the OMC.  Current slider settings are PIT = 1800, YAW = -1800.  The sign was determined by looking for the best extinction on the OMC QPDs and DCPDs with the DRMI flashing.  The magnitude of the slider value puts the DAC just at the saturation point.

The good slider values, which will restore the alignment into the OMC, are:

PIT = -437

YAW = 657

Note that this only protects the OMC diodes from bright flashes, not the AS WFS.  Those guys need the toast to work before they'll be safe.

Intesnity noise was bad in transmission of the IMC, so I added some offsets to the angular controls: -20 counts to DOF_1_P and -9 counts to DOF_2_Y. Intensity noise improved a lot, see attached plot (blue/red after, green/brown before)

This morning we disconnected all DC power to PEM electronics (SEIS, TILT, MAG, MIC ect) and connected them to the dedicated PEM power supplies. This should start cleaning up some of the clutter in the VEA, example power supplies sitting on the floor used for temporary power. Everything should be up and running, but let me know if we missed something.

[Sudarshan, Gabriele]

To understand why intensity noise was worse than usual, we had a look again at the beam dumps we installed yesterday on the two beam coming out into IOT2R. 

After yesterday's realignment of the main beam, the two dumps were no more in a good position. To be more precise: the two beams coming into the enclosure are very close to the edge of the periscope upper mirror; one of the beams is hitting the bottom mirror in a reasonable position but was partially missing the beam dump; the other beam was hitting the edge of the mirror and the mount. Therefore, we moved the first beam dump to a better position, and we dumped the second beam before it hits the periscope bottom mirror. See attached picture

This improved the intensity noise, but we can still see a bit of 18 Hz peak. 

Intensity noise was very high this morning, see the red trace in the first attached plot. It started to be like that yesterday night, during some of the locking tests. After some investigations, it turned out to be due to the LSC correction sent to MC2 and generated by the ALS. After switching it off, intensity noise returned to reasonable values, even though a bit larger than usual, inicating a not optimal alignment of the IMC.

Another pecualir thing is that yesterday night, while IM4 ws moved, the power on IM4_TRANS changed as well. This is a bit unexpected...

Looked like commissioners were still working on the alignments so I held off on doing similar to WHAM3.  So, I went to the ITMY which also needed some matrices corrections.  These corrections required new controllers so I just went with Hugo's standard controllers and some mods to those, see 15112.

I brought down the HEPI at ~0805pst, the ISI watchdogs tripped very soon after.  About 0813 I loaded the new matrices and attempted to restart the HEPI after adjusting the X dof Target Location.  The RZ loaction did not change as the matrix errors I'm correcting are amplitudes in X & Y and the output matrix which was all 1s.  Did you notice I forgot to mention loading the new controllers (required with changed matrices?)  Well I did forget them, so then I prepared and loaded the new controllers and tried again.  Okay, not so good...the vertical dofs are tripping quickly when the boosts turn on.  Well, if you remember from my yesterday's alog, I elected to leave the vertical controllers at 5hz UGF.  So I lowered them to 2hz like all the horizontals (I hadn't actually tried the horizontals yet, but I later did and they were fine.)  Still the verticals blow up quickly when the boost is engaged.  So, I continued and reduced the zero of the boost from 1.0 to 0.7hz as I did with the horizontal dofs.  But, still no luck so I lowered them to 0.5hz and again no good.  Alright, I tried the horizontals and they worked, I did the verticals manually and they are fine without the boosts.

Next I set up to do an open loop, this would reveal if my controller's matrices did not match my installed matrices.  Well, the boosts would not engage at all for Z RY or VP!  We attempted all sorts of things like resaving the file from foton, confirming the turn on method, comparing the boosts, putting the boost in another module (where it did turn on.)  Finally, restarted the model, and HEPI isolated first attempt (3 hours later!)

So, the new matrices and new controllers work--why did these filter modules stop engaging properly and sending some wacko spike into the output--they would not have done any harm if they actually weren't doing anything?  I thought about reverting the controllers back to where I started to see if at first it was actually my boosts but the the shape changes were actually quite minor: the gain peaking dropped from less than 3 to less than 2, and phase margin went from ~30 to ~50 degrees.  Too little time so I didn't change them back.  So unless my controllers were very bad to start and the repeated loading of fotons and tripping the watchdogs did something, the first attempt with the non-updated controllers must have done something to the filter module/model, or, it was a problem waiting to happen.

I noticed that the Guardian was restoring the RX & RY Target Location.  I'm confused with that.  I thought we were only restoring RZ everywhere, with Pitch at the ends, and X on ITMY (initial alignment.)  I'll research the history and maybe I'll learn something but again, I did not think we were restoring these.  It might make sense to do so as these are the tilting of the platforms but that is another issue.

I'll put an updated image of the controllers in shortly.

Updated safe.snap and latest foton file filed in the svn.