Displaying reports 71041-71060 of 85619.Go to page Start 3549 3550 3551 3552 3553 3554 3555 3556 3557 End
Reports until 15:59, Tuesday 11 November 2014
H1 General (CDS)
edmond.merilh@LIGO.ORG - posted 15:59, Tuesday 11 November 2014 (14989)
Guardian Ops Overview

Suspension MC3 had a tripped watchdog that was brought to my attention that wasn't being reflected on the Guardian Ops Overview screen. (didn't turn red).

H1 ISC
keita.kawabe@LIGO.ORG - posted 15:30, Tuesday 11 November 2014 (14988)
Clipping downstream of BS (SRC or Faraday or HAM6)

Summary:

Following the PR2 scan from last week (https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=14845), I used a single bounce beam from IX and scanned the BS while using SR2 to center the beam on AS_C. I also scanned SR3 while using the same ASC feedback on SR2.

There's at least 0.7% or so in the SRC-AS path donwstream of SR3. Tomorrow I'll roughly center SR2 by looking at the SR2 baffle and scanning SR3, then scan SR2 to maximize AS_C while keeping AS_C centered using pico.

The beam might become off-centered on SRM depending on how well the Faraday is centered on SRM, but that should be fine.


Details:

In the first attachment, the plot on the left  is AS_C_SUM normalized VS the BS Y slider value (while the ASC loop was acting on SR2 to center AS_C).  The scan started from Y=-296.5.

As the BS Y was increased, at some point PIT feedback on SR2 became large and eventually railed the SR2 BOSEMs, and that's probably why the plot shows a kink at around BS Y=0. I had to stop the scan at BS Y=83.5. During this scan BS BOSEMs never railed. Though it's not shown here, I also scanned SR3 while using the same SR2 feedback to center the AS_C, and the data also showed similar kink.

The plot on the right is a similar plot for SR3 scan. Note that these data were taken on a different days, so the laser power could be different at sub-% level, and the IFO alignment could be substantially different, but you can see that the two plots show the same kink.

Based on the above, I'd guess that the reason why SR2 had to be moved in PIT despite YAW scan is because the centering on SRM or SR2 was poor in PIT. (Remember, ROC of SR2 is -6.4m and that of SRM is -5.7m.)

In the second attachement, I just plotted the beam displacement for the BS scan at SR3, SR2, SRM and OFI input normalized by either the beam radius (left) or optic radius (right), taking into account the fact that ASC is keeping AS_C centered using SR2. This doesn't prove anything, but suggest that SR2 and OFI are kind of dangerous as far as the clipping by the beam motion is concerned in this measurement, and we don't have to worry much about SR3.

(Note: The reason why AS_C should be centered is because the centering affects SUM number at sub % level.)

Images attached to this report
H1 SEI
jim.warner@LIGO.ORG - posted 15:14, Tuesday 11 November 2014 (14984)
HAM 2,4,5 ISI's tripped at 13:15 local, no clear cause

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.

Images attached to this report
H1 CDS (DAQ)
david.barker@LIGO.ORG - posted 15:12, Tuesday 11 November 2014 (14985)
DAQ EDCU not cleanly reconnecting to Beckhoff

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.

H1 CDS
cyrus.reed@LIGO.ORG - posted 15:06, Tuesday 11 November 2014 - last comment - 13:03, Sunday 16 November 2014(14983)
Digital Camera MEDM
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.
Comments related to this report
sheila.dwyer@LIGO.ORG - 13:03, Sunday 16 November 2014 (15090)

Thank you Cyrus!

I've set the interval for most of the usefull cameras to 1 hour, if this is taking up too much space, let us know.

H1 CDS
patrick.thomas@LIGO.ORG - posted 14:01, Tuesday 11 November 2014 - last comment - 15:00, Tuesday 11 November 2014(14981)
Updated Conlog channel list
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.
Comments related to this report
david.barker@LIGO.ORG - 15:00, Tuesday 11 November 2014 (14982)

script to convert guardian byte arrays to string

I have written a convertByteArrayToString script which can take the output from conlog when viewing Guardian USERMSG channels and convert the resulting byte array into a string.

For example, the conlog display of the Guardian EPICS channel H1:GRD-ISC_DOF_USERMSG is show in the attachment below.

To convert to the array to a string, use your mouse to select and copy the array contents from your web browser, the paste it into the following command in a terminal:

echo "110 111 100 101 32 76 83 67 95 67 79 78 70 73 71 83 58 32 78 79 84 73 70 73 67 65 84 73 79 78 44 32 114 101 113 117 101 115 116 32 99 104 97 110 103 101 100 32 102 114 111 109 32 80 82 88 95 76 79 67 75 69 68 32 116 111 32 68 79 87 78 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32"|convertByteArrayToString        
-------------------------------------------------------------------
node LSC_CONFIGS: NOTIFICATION, request changed from PRX_LOCKED to DOWN                             
-------------------------------------------------------------------
completed
 

Images attached to this comment
H1 IOO (DetChar, ISC)
jeffrey.kissel@LIGO.ORG - posted 14:00, Tuesday 11 November 2014 (14980)
IMC ODC Screen Updated, Master Gain / Trigger OK Threshold Updated
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.
Images attached to this report
H1 ISC (SUS)
alexan.staley@LIGO.ORG - posted 13:49, Tuesday 11 November 2014 (14961)
work on diff today

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

Images attached to this report
Non-image files attached to this report
H1 SUS
jeffrey.bartlett@LIGO.ORG - posted 13:40, Tuesday 11 November 2014 (14979)
3IFO Suspensions Storage
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.    
Images attached to this report
H1 PSL
gabriele.vajente@LIGO.ORG - posted 13:38, Tuesday 11 November 2014 (14971)
ISS second loop: recentered

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:

Photodiode DC signal [V / counts] dP/P/dx pitch [1/m] dP/P/dx yaw [1/m]
1 2.66 / 4360 79 36
2 2.93 / 4800 185 248
3 2.87 / 4700 37 72
4 3.16 / 5180 290 1260
5 3.20 / 5250 128 15
6 2.98 / 4890 16 78
7 3.43 / 5620 205 79
8 3.20 / 5250 15 85

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.

Images attached to this report
H1 ISC (DetChar, INJ, SEI, SUS, SYS)
jeffrey.kissel@LIGO.ORG - posted 13:10, Tuesday 11 November 2014 - last comment - 13:30, Tuesday 11 November 2014(14977)
Congratulations to Kiwamu and Rie!
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
* * *

Images attached to this report
Comments related to this report
paul.fulda@LIGO.ORG - 13:30, Tuesday 11 November 2014 (14978)

Wow, congratulations!!! 

H1 CDS
daniel.sigg@LIGO.ORG - posted 11:34, Tuesday 11 November 2014 (14975)
Updated EPICS/TwinCAT interface and new PLC information

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.

LHO VE
kyle.ryan@LIGO.ORG - posted 11:28, Tuesday 11 November 2014 (14973)
Swapped pump A and pump B HV cables on back of IP1 controller
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.  
H1 CDS
patrick.thomas@LIGO.ORG - posted 11:22, Tuesday 11 November 2014 (14972)
Fixed Beckhoff link for illuminator at end X
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.
H1 CDS (DAQ)
david.barker@LIGO.ORG - posted 11:00, Tuesday 11 November 2014 (14970)
CDS model and DAQ restart report, Monday 10th November 2014

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

unexpected restart.

H1 ISC
nicolas.smith@LIGO.ORG - posted 23:20, Monday 10 November 2014 - last comment - 17:39, Tuesday 11 November 2014(14960)
ALS TRY has a huge line in it

There's a huge 364Hz line in ALS TRY.

I'm not sure if this was already there for a while. Though we probably changed the loop gain of the ALSY PDH loop when we realigned the green path on ISCTEX today.

Non-image files attached to this report
Comments related to this report
nicolas.smith@LIGO.ORG - 15:21, Tuesday 11 November 2014 (14986)

alexa, nicolas

In order to determine whether the line we were seeing on ALS TRY was a result of aliasing of something higher frequency in the ADC, we checked the analog spectrum of the ALS TRY photodiode.

Attached photo shows the line at 364 Hz in analog as in digital, so no evidence for aliasing.

Images attached to this comment
evan.hall@LIGO.ORG - 17:11, Tuesday 11 November 2014 (14992)

Sheila, Alexa, Nic, Evan

Sheila and I went down to EY to see if we could track this down.

This 365 Hz line appears to be caused by oscillation in the 2" PZT mirror on ISCTEY. If the green refl beam clips on the RFPD, this produces amplitude modulation that leaks into the PDH error signal.

nicolas.smith@LIGO.ORG - 17:39, Tuesday 11 November 2014 (14993)

Line is obvious on ALSY QPDs on the transmon.

It seems the oscillation is mostly yaw (364Hz), though there is a pitch line about 10x smaller (420Hz), as well as lines in ALSX QPDs (pit: 389Hz yaw: 363Hz).

Non-image files attached to this comment
H1 SUS (DetChar, ISC, SYS)
jeffrey.kissel@LIGO.ORG - posted 20:02, Monday 10 November 2014 - last comment - 11:51, Tuesday 11 November 2014(14959)
L1 vs. H1 QUAD Damping Loop Comparison
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.
Non-image files attached to this report
Comments related to this report
alexan.staley@LIGO.ORG - 11:51, Tuesday 11 November 2014 (14976)

In Y, LLO also has a 60 Hz notch that we have now copied over.

 

One thing to note: we have left our drive align matrices as they were installed. They are rather different than what LLO has installed; we have not copied any of these over.

H1 SUS
edmond.merilh@LIGO.ORG - posted 14:33, Monday 10 November 2014 - last comment - 11:29, Tuesday 11 November 2014(14943)
sus aux channel faults investigation

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.

Comments related to this report
jeffrey.kissel@LIGO.ORG - 11:29, Tuesday 11 November 2014 (14974)
E. Merilh, J. Kissel

This investigation concludes that the issue identified in LHO aLOG 14922 is not as pervasive as originally thought. *phew*!

The DTT templates to which Ed refers will assess the noise performance of these channels.

We'll work on resurrecting Koji's automatic SUS AUX channel characterization suite, found here:
/ligo/svncommon/SusSVN/sus/trunk/QUAD/Common/MatlabTools/ezQuadDewhitening
This will assess whether each of the monitor boards show the expect driver's driven transfer function after install.
Displaying reports 71041-71060 of 85619.Go to page Start 3549 3550 3551 3552 3553 3554 3555 3556 3557 End