Ed reported that HAMS 2,4 and 5 all tripped at about 13:15 today. All tripped on actuators, but the spikes are small, and none of the in chamber instruments show much prior. HAM4 shows a trip that looks like something maybe hitting the chamber, so more understandable, but that trip was much later. HAM2's and 5's trips happened within 2 minutes  of each other, and look very similar. HAM2 first, then HAM5, I don't know when HAM4 happened as therehas been a subsequent trip. I've attached the HAM5 watchdog plots.

similar to last week's restart of the end stations beckhoff computers, when h1ecatx1 was restarted after lunch today the DAQ EDCU did not completely reconnect to all the channels. This is a strange reconnection event, with the EDCU code giving conflicting reports on the connection status:

daqd>
23363 channels
23335 connected
28 disconnected
74179 connection events processed
126179362 value change events processed
Total 0 disconnected.
daqd>
 

(normally the list of disconnected channel names would be given)

The number of connected channels as reported in the DAQ EPICS PVs is the total number minus 28.

Cyrus suggested we try restarting the EPICS gateway between the H1 front end LAN and the Slow Controls LAN. I did this at 14:15 but we still have 28 missing connections. I have asked the slow controls group for a copy of the Beckhoff h1ecax1 databases to see if the number 28 relates to particular epics records.

At the moment the only way to cleanly reconnect all Beckhoff channels to the DAQ is to restart the DAQ.

I've added the archive image settings to the camera MEDM, and updated the INI files to make it work.  Currently, the archiving on all cameras is disabled by setting the interval to 0.  To enable archiving, set this value to 60 to save an archive image every hour (do not use a value less than this without good reason - we don't have infinite amounts of disk space available).  Archive images are saved to /ligo/data/camera/archive/YYYY/MM/DD when enabled.

added 196 channels
removed 6 channels

Guardian user message channels are now being recorded, however the web and command line interfaces need to be updated to display them as strings instead of integer arrays.

J. Kissel

The front-end logic for calculating the IMC ODC state vector (primarily looking at IMC WFS signals) had been updated in September (see LHO aLOG 14098), but the ODC MEDM screen and EPICs records didn't get updated accordingly. 

I've svn up'd the 
/opt/rtcds/userapps/release/ioo/common/medm/IMC_CUST_ODC.adl
ODC screen, which fixed some white channels that were a result of some of the channel changes. 
Further, I've reduced the Master Gain / Trigger OK Threshold, H1:IMC-ODC_WFS_GAIN_GT_EQ_TH to 0.1 (was formerly 0.604), after recent commissioning of the WFS loops have reduced the overall WFS gain from ~0.6 to 0.2 (e.g. LHO aLOGs 14301, 13280, etc.). 

Finally, I've captured a new safe.snap (with makeSafeBackup, saved to the userapps location), ensured that safe.snap in the target area is a soft-link to the userapps location (where the front end looks for safe.snaps upon boot) and committed
/opt/rtcds/userapps/release/asc/h1/burtfiles/h1ascimc_safe.snap

The IMC is currently locked happily, and the IMC ODC now agrees. It's interesting to see that only the MC2 TRANS and IM4 TRANS SUMs are used in conjunction with the Master Gain / Trigger Threshold (as indicated by the bitmask for what is used to compute the summary bit). Why aren't we using the error points? If we don't use them we should remove them from the vector as the filter calculations are wasting computation time (though we're far from being clock-cycle limited at 28 out of 480 [usec] or 5%). 

P.S. Gabriele has now been made aware of the state vector, and will ensure that when he's finished tuning that the ODC vector will be green again.

Alexa, Evan, Nic, Jeff, Sheila

Today we changed our damping loops for ETMX and ETMY, to be more similiar to the LLO ones (Jeff's alog ).  The power sprectrum for ETMX (M0 damping filters and optical levers)  and ETMY attached.

We started by using filters similar to the Livingston design, and measuring the actuation transfer functions to both the ESD and the UIM. 

We set up the loop so that we think it should be unconditionally stable, and we have been able to get the ugf to 1.5 Hz.  The measurement agrees reasonably well with the model for the open loop. We also made measurements by injecting in the UIM lock filter bank in each arm, which can be compared to the green trace in the plot on the left in the second attachment.  The two arms match each other reasonably, and we think that our cross over is at a lower frequency than we want. 

The gains we have been able to use stably so far are 50 in the DARM filter bank, 0.4 in ETMX L1 locking and 0.67 in ETMY L1 lock, 1 in ETMX L3 lock and 1.12 in ETMY L3 lock. 

It seems like we might need to fix the oscillation in the Y arm before we can move on. 

(This is Sheila, logged in as Alexa)

UPDATED: I have added some pdfs of TFs produced by the models -- AS

Jeff B., Andres R., Mitch R., & Joe D. 

   We secured the last two suspensions in the HAM ISI Storage Container #1 this morning. After replacing the top, Bubba craned the container back over the beam tube to its parking position next to the N2 manifold. 
   
   Counts before and during work were <100 0.3 microns and larger range. After the C3 cover was put over the suspensions the counts spiked to 50 of 0.3, 320 of 0.5, and 70 of 1.0 microns. These dropped back to the normal levels within 5 minutes after the cover was secure. 

   The LVEA has been returned to full laser hazard. The cleanrooms have been turned off. The work area is ready to receive HAM ISI Storage Container #2. We will move this into place when the next group of suspensions are ready for storage.    

I spent the morning playing the picomotor game, to improve as much as possible the beam centering on the ISS photodiodes. The procedure is the same explained in 14211: I moved picomotor #8 and then used a python script to recenter the beam on the QPD using picomotor #1. My figure of merit was the sum of the power read by all photodiodes. I improved the total power by something like 0.5%, which isn't impressive, but at least now I know that I'm very close to a maximum. For future reference, the total sum of all PD signals, in counts, as measured by the IOP-PSL0_MADC1_EPICS_CH24-31, is about 40050.

After this, I injected a 1 Hz line on IM3 pitch and then yaw, and looked at the variation of the PD powers. I moved a bit the beam with both picomotors, to reduce the oscillation that was clearly visible only in PD2 and PD4. Now I'm close to be dominated by the two omega oscillation in both diodes. The optimal position does not correspond to a exactly centered QPD: PIT = -0.06, YAW = 0.35. Note that PIT and YAW for the QPD are reversed with respect to PIT and YAW for IM3!

Then, I took some (medium) high resolution spectra of all PDs, to estimate the coupling of beam motion to RIN. I used a IM3 pitch excitation at 1 Hz, with an amplitude of 300 cts. This gives me a signal on the QPD of 0.67 1/rHz, corresponding to 105 um/rHz. I used the same frequency for yaw, but with an amplitude of 200 cts, corresponding to 0.80 1/rHz on the QPD or 125 um/rHz. Spectra of all signals are shown in the attached figures.

Here are the results:

In general, those numbers are not too much different from the best we could get in the past. The only exception is PD4, which looks quite bad.

From all of us at LHO, a hearty congratulations to Kiwamu and Rie Izumi, celebrating the 0th birthday of Hana Izumi (和泉はな)! 

* * *
Birth date: Nov.1st
Height: 19.5 inches
Weight: 6lbs 5oz
* * *

The TwinCAT/EPICS interface was updated to version 1.1 which includes an alias feature for symbols and structure items. This now makes it possible to export PCAL channels under the system CAL. See also here.

New PLC information has been added to describe the runtime and each configured online task. The update rate for the latency readbacks has been increased to 1Hz.

Previously, it was possible to circumvent the configuration control by making online changes and bypassing the installation scripts. The installation scripts will patch the svn revision number into an EPICS channel, if they were run from a fully updated source tree. A subsequent online change is now recorded and reported as a code error.

IP1 controller has indicated that pump B (1/2 of pump) has been inoperative for awhile now -> Swapping cables didn't change the indication at the controller that pump B still isn't working but has resulted in the "cold" 1/2 of the ion pump to be pumping now (i.e. problem is controller not HV cable or pump) -> CS pressure shows a "bump" reflecting this exercise -> IP1 controller is old style "MultiVac" type and cabling will need to be modified for, as yet to be acquired, new type replacement.  

Aaron S., Richard M., Patrick T.

I rescanned PLC1, PLC2 and PLC3 in the h1ecatx1 system manager. I then moved the link under 'End Link L0:End Link L3_4:ALS Laser Table Relay:Channel 2:Output' from 'PLC2:Standard:Outputs:AlsEndLaserHeadOut:NoiseEaterRelayOff' to 'PLC1:Standard:Outputs:IlluminatorOut:IlluminatorRelayOn'. I committed the change to svn. Richard and I switched it on and off in EPICS and Aaron verified that it turned on and off at end X.

model restarts logged for Mon 10/Nov/2014
2014_11_10 06:41 h1fw0

unexpected restart.

Okay, recall: WHAMs 2 & 3 HEPI had incorrect signs for the three rotational dofs on the Input matrices.  The output matrix, converting the cartesian drives from the control loops to the local actuator basis also had incorrect signs on the rot dofs but there were also screwy magnitudes with errors from 25% to 8x so all over the map.  While all the dofs run closed loop, having the output matrices correct will ease the burden on the loops and better enable open loop running.  It may also reduce unneeded strain cycling.  Remember, I have lots of opinions!

Anyway, unlike last week when the matlab script was using incorrect matrices for my controller development(obviously unbeknownst to me) and the switch I attempted was a spectacular failure, this time, turning the loops back on with correct matrices and new controllers was anticlimatic.  No problem turning things on, no trips, and the ISI remained isolated.  The most notable thing is that I learned

The HAM2 ISI OpLev Pitch and Yaw are Reversed.

I'll suspect HAM3 is similar.

See the attached for 50 minutes of trends with chans 1-8 being the HEPI Local Sensors, chans 9-14 being the HEPI Cartesian Locations, and the last two are the OpLev Pitch & Yaw.  Notice the right most vertical line I've drawn through the RZ steps as I'm trying to drive the OpLev 'Yaw' back to whense it came.  Of course you'll see that the Yaw doesn't move and the Oplev Pitch does.  Of course you say, "Hugh, why do you think your RZ channel is better than the OpLev channel?"  Well, notice too the other vertical lines positioned at the same time through the HEPI Local Sensors.  You should notice the at the RZ move is seen by the local horizontal channels and the vertical channels see nothing.  Okay, I know that is circular...just take my word huh.  We can do some physical sensor disconnects or something if you insist.

I did tweek the ultimate RZ Reference location to recover the OpLev actual Yaw of ~-8.2 units but the change was <200nrads.  I tweeked in the Pitch too but after taking the system down and back up with Guardian, the Pitch and Yaw numbers on the OpLev are changed, slightly.  We didn't have the mode Cleaner while I made this change but it relocked as soon as the LASER was back on.  The Beams on the AS AIR camera view are up in the upper right though, I don't know but that may be different.

The commissioners shoudl feel free to steer HEPI as they wish.

Finally, I may suggest a guardian change that isolates and steers the DOFs we want to restore and then get the steered free hanging position and isolate the remaining dofs.  Certainly you can see how that wold reduce the strains and possibly provide more repeatable position recovery.

A new safe .snap and the updated foton file has been commited for the HEPI.

The state of the PSL upon my arrival this morning was that it showed NO output power.

J. Kissel

Continuing to compare L1 vs. H1 damping loop designs (see ), I've made a comparison of the QUAD's design, and also with the original low-noise design from which they're derived (see LHO aLOG 6760). Attached are the H1 and L1 designs compared against each other, 
dampingfilters_comparison_2014-11-07_LHOvs2014-11-10_LLO.pdf, as well as both against the original low-noise design dampingfilters_comparison_2014-11-07_LHOvs2013-06-14vs2014-11-10_LLO.pdf. 
As Sheila's quick comparison pointed out (see LHO aLOG 14923), the differences aren't that large (and detailed below).

In summary, both LHO and LLO have modified the low-noise design, but only slightly -- both apparently in order to get a reduction in test-mass impulse response. LLO took the "more sophisticated" in longitudinal by adding a boost instead of just increasing the overall gain, hence their modification preserves some phase margin. 

Because we're giving the LLO ALS DIFF control loops a try, however, we have copied over and installed the LLO design -- assuming that any little bit of difference will matter for these complicated global control transfer functions. Stay tuned...

- T, V, R loops are identical to the original design
The differences are the following modicifations:
- In L
     - LLO "resg1" boost ( resgain(f=1.07 [Hz], Q=4, height=13 [dB]) * gain(6, "dB") )
     - LHO overall gain increased by 2 (from -1 to -2).
- In P
     - LLO "notch60" 60 [Hz] notch ( notch(f=60 [Hz], Q=50, depth=40 [dB]) )
     - LHO overall gain increased by 3 (from -1 to -3).
- In Y
     - LLO "+12db" gain of 3.9811 ( gain(12, "dB") )

Comments:
In L, 
 - The extra "resg1" at LLO, significantly reduces the Q of the *second* (~1 [Hz]) L mode, and therefore significantly modifies the L to L and L to P global control transfer functions -- not only the resonant feature at 1 [Hz], but also the zero at 0.75 [Hz]. Other features are moved around a little, but no such significant change in shape. 
 - As such, the displacement from residual ground motion at 1 [Hz] has been reduced by a factor of 3, though (at least from the modeled input seismic motion) it doesn't contribute much to the over all RMS.  
 - The impulse responses of the two designs are comparable.

In V, and R,
 - As expected from the HSTS design studies, the impulse response of these DOFs reveals that without other local damping (say from optical levers), the highest V and R modes (at 9.7 and 13.8 [Hz]) get excited when the PUM and TST are kicked, and continue undamped at their original extremely large Q. 
 - If needed, both the fundamental V (at 0.55 [Hz]) and R (at 0.86 [Hz]) could use an increase in their resonant gains to decrease the 1/e time for those modes, which seem to dominate the amplitude of the time series for the initial 10-20 seconds. V would be much easier than R, as the LUGF phase margin for R is already pretty small.

In P, 
 - As with the HSTS, the global control transfer functions are barely affected by the differences in design, though -- to be fair -- the differences in design are much less dramatic than in the HSTS. 
 - Test mass impulse times are comparable.
 - The first "pitch" mode at 0.51 [Hz] is more damped (by about a factor of ~2) in the LHO model because of the increase in overall gain. However, since the second mode at ~1 [Hz], is more L motion at the test mass than P, increasing the gain at this frequency by a factor of 5 with the "resg1" in the L design seems to have reduced this "P" mode by the same factor at the test mass. Interesting!
 - The notch at 60 [Hz] has little affect on the loop design -- I suspect this was installed to kill a ground-loop feature in a particularly bad OSEM.

In Y,
 - This is pretty straight forward -- the yaw loop is not particularly limited in phase margin, only in noise re-injection. If we're willing to sacrifice a factor of 4 in noise, cranking up the gain reduces the impulse response by 4, and the Qs of the global transfer functions.

Upon taking a look at all large suspensions and small suspensions aux channels only ETMY stage L1 was found to have a noise aux channel which is showing some possible issue. ie ~ -4300 cts. This is showing on "noise" (4), volt (UL) and fast_I (LR). I have begun setting up DTT templates for all aux sus channels to further examine questionable readings.