Displaying reports 68281-68300 of 82985.Go to page Start 3411 3412 3413 3414 3415 3416 3417 3418 3419 End
Reports until 21:45, Monday 17 November 2014
H1 ISC
keita.kawabe@LIGO.ORG - posted 21:45, Monday 17 November 2014 (15116)
Recentering POP sled (Kiwamu, Keita)

After IM4 alignment was moved, POP sled QPDs were recentered using a straight shot beam.

POPA and POPB SUM are about 0.33 and 0.30 right now. There is some clipping going on in the sled path (we observed these SUM went to 0.38 and 0.34 respectively with different IM alignment), but that was expected from my original IM4 scan (https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=14567).

POPA pico counts are [X, Y] = [-27491, 6688] (was originally [0,0]).

POPB pico counts are [-23206, -8455] (originally [0, -300]).


Alignment tips:

When POPB QPD is to the right relative to POPA QPD, both of the PICOs are moved in positive X (that is, the pico X count increases for both).

When POPB is higher than POPA, POPA pico is moved UP (that is, pico Y count increases) while POPB pico is moved down.

H1 AOS
evan.hall@LIGO.ORG - posted 19:52, Monday 17 November 2014 (15114)
PR3 oplev recentered

Sheila, Evan

We have recentered the PR3 oplev. The controller is in the AOS cabinet by the PSL.

H1 AOS
gabriele.vajente@LIGO.ORG - posted 17:35, Monday 17 November 2014 (15113)
Light reflected back by PRM - update

After the fix reported earlier, the contamination of ISS signals by the PRM reflection is smaller than before, but still not neglegible, see the attached plot (blue PRM misaligned, red PRM aligned).

We should investigate more to see if this residual noise is still entering from the same path or not. Maybe it would be a good idea to dump the beamp directly before the first mirror of the periscope.

Images attached to this report
H1 SEI
hugh.radkins@LIGO.ORG - posted 16:39, Monday 17 November 2014 (15112)
WBSC1 ITMY HEPI Position Controllers

With the correction (update) of the L2C2L matrices planned for possibly tomorrow, I went through the controller development (required) using generic loops Hugo designed (SEI log 489.)  These are 5hz UUG controllers.  The vertical dofs looked okay but X Y & RZ looked a bit marginal around the UUG--see first attachment.  This plot shows the 5hz generic controller for X; the gain peaking is higher than comfortable and the phase margin is marginal.  The controllers for Y & RZ are marginally less marginal.  I made a new controller set with 2Hz UUG and and reduced the boost zero from 1 to 0.7hz on X Y & RZ.  I'll keep the 5hz controllers for the vertical dofs and go with these more conservative filters for the horizontal dofs.

The pdf attachment shows all eight controllers I plan to install tomorrow if allowed.

The second image attachment is the only controller I found saved in the svn.  It looks pretty wild but it doesn't quite match the foton filter so I don't know if it really represents the controllers we've been using.  Still it sort of represents the wild west in our controller development evolution.

Images attached to this report
Non-image files attached to this report
LHO General
edmond.merilh@LIGO.ORG - posted 16:02, Monday 17 November 2014 (15096)
Daily Ops Summary

08:00 LVEA is LASER HAZARD

08:15 Re-Started Operator2 iMac (Mid and End cameras)

08:30 Morning meeting

08:59 Fil and co. to EX and then EY 

09:15 Karen to End station

09:16 Doug ino LVEA to preview OpLev work

09:19 Jeremy, Mitch, Betsy and Travis into LVEA W bay

09:36 Cris to EX

10:02 Bubba to MX to get palette jack

10:12 Karen leaving EY

11:00 Cris back from EX cleaning

12:15 Fil et al leaving EX

12:50 Mitch and Jeremy out to W Bay w/comm appr

13:46 someone on site to take water samples?

H1 SUS
betsy.weaver@LIGO.ORG - posted 14:29, Monday 17 November 2014 - last comment - 14:08, Wednesday 19 November 2014(15107)
3IFO QUAD Q7 Phase 1 testing

A second round of testing on the all-metal 3IFO QUAD unit Q7 is attached.  After we saw a few cross coupling terms and struggled with coherence in the prior measurement set, we made a few adjustments to the QUAD mechanics.  However, readjusting the lacing cabling and retuning the sensor mounting tablecloth seemed to not help much.  There is still L and R bleeding into P on the reaction chain.  We were able to improve the coherence by building a fort around the test stand however.  The main chain looks to be in pretty good shape though.

 

The first attachement below is of Q7 with damping on and off.

Non-image files attached to this report
Comments related to this report
betsy.weaver@LIGO.ORG - 14:31, Monday 17 November 2014 (15110)

The attachment below is of the Q7 (pink traces) undamped TFs compared to the 3IFO Q6 and Q8 units.

Non-image files attached to this comment
travis.sadecki@LIGO.ORG - 11:04, Tuesday 18 November 2014 (15124)

Screenshots of damping filters for DC offset diagnosis.

Images attached to this comment
travis.sadecki@LIGO.ORG - 14:08, Wednesday 19 November 2014 (15165)

Spectra for all stages of Q7 attached.  Note that the L1 and L2 stage OSEMs are not aligned and centered.

Non-image files attached to this comment
H1 ISC
alexan.staley@LIGO.ORG - posted 14:21, Monday 17 November 2014 - last comment - 15:41, Monday 17 November 2014(15109)
IM4 Optimal Alignment

(Keita, Alexa)

We moved IM2 in pitch to correct for the 60urad deviation that Kiwamu and Keita saw on Friday (alog 15081). Originally, IM2 P, Y = 17000, 5154 with M1_DAMP P, Y = 580, -51. This was adjusted to IM2 P, Y = 19200, 5154 with M1_DAMP_ P,Y = 637, -45. 

We then repeated an IM4 scan on PR2. The new good alignment values are:  IM4 P, Y = 6670.5, -2735.0

 

The scan procedure:

We moved IM4 in pitch until we saw the beam on the PR2 baffle. This allowed us to center the beam in yaw; we found that the good center position in yaw was -881.8 -- this was consistent for both top and bottom of the baffle. Then we found the pitch values for which the beam was just barely clipping the baffle:

  IM4 Pitch IM4 Yaw
Barely Top of PR2 Baffle -24329.5 ± 2000 -881.8
Barely Bottom of PR2 Baffle 37670.5 ± 1000 -881.8

 This average gave us the pitch position of 6670.5.

It turned out that yaw was bit more tricky. For whatever reason, the "barely clipping" procedure in yaw did not work; it gave us a center value of -3881. So instead we looked at the PR3 camera (with ITMs very misaligned), and determined when the beam disppeared in yaw:

  IM4 Pitch IM4 Yaw
Left on PR2 baffle, No beam on PR3 6670.5 6418.2 ±  100
Right on PR2 baffle, No beam on PR3 6670.5 -11681.8 ± 500

This difference amounted to 18,100 counts. We then looked at the PR2 baffle lower left and lower right beam positions, and found that this yaw seperation for the PR2 baffle diameter made sense.

As noted in Keita's alog 15063, the diameter of the baffle is 65.4mm, and the beam must be aligned to 26mm from the right edge (or equivalently 6.7mm from the center). So we used

yaw  = center + radius in counts/ radius in mm * distance from center

yaw = -881.8 + (6.7 mm / 32.7 mm) * (-9050)  = -2735.0

Comments related to this report
alexan.staley@LIGO.ORG - 15:41, Monday 17 November 2014 (15111)

Keita pointed out to me that as we move the beam in yaw to clip on the left side of the PR2 baffle we will actually first see a back reflected beam from PR2. This probably explains why our yaw measurements for the "barely clipping" scheme was incorrect; we were probably measuring the back reflected beam from PR2 and not the beam from IM4.

H1 SUS
sheila.dwyer@LIGO.ORG - posted 12:10, Monday 17 November 2014 (15104)
PR3 calibrations

The calibrations on PR3 angles are wrong.  In the attachecd screen shot you can see that someone moved the alignment slider -72 urad in yaw, the OSEMs sees a shift of -62 urad, and the optical lever records a shift of -26 urad

Images attached to this report
H1 IOO
gabriele.vajente@LIGO.ORG - posted 11:13, Monday 17 November 2014 - last comment - 14:09, Monday 17 November 2014(15102)
IM4 gain change

This morning the power on IM4 was about half of what it should be, even though all other readings of IMC ower were good. It turned out that the IM4 whitening gain was reduced by 6 db on Saturday night at about 9.15 LT (2014-11-16 05.15 UTC). We don't know why that happenened and if something else was also changed at the same time. For the moment being, I changed the gain back to the previous value.

Images attached to this report
Comments related to this report
daniel.hoak@LIGO.ORG - 14:09, Monday 17 November 2014 (15108)

This was my fault - apologies for not putting in the log.  The IM4_trans quadrants were saturating on Saturday evening, during the time when the CARM offset was being scanned to lock the arms; when I saw this I reduced the gain on IM4_trans by 6dB to bring the signals away from the rails.  (The IMC WFS were saturating too, but since they are in-loop I didn't adjust them.)

H1 PSL
gabriele.vajente@LIGO.ORG - posted 10:31, Monday 17 November 2014 (15101)
Temporary fix of ISS backreflected light noise

[Sheila, Gabriele]

As suggested by Keita during the morning meeting, we checked the IM4 transmitted beam coming from the PRM reflection, on the in-air table. We dumped both beams on the table, and this improved a lot the situation. When the PRM is aligned, the noise on the ISS diodes doesn't increase much anymore. However, there is still a small worsening at 18 Hz, so maybe in the future we might want to better dump the beam at the level of the upper mirror into the enclosure.

Images attached to this report
H1 SYS
daniel.sigg@LIGO.ORG - posted 10:05, Monday 17 November 2014 (15099)
Commissioning calendar for next 2 weeks
Here is the list of commissioning task for the next 7-14 days:

Locking team:
  1. Lock DRMI with ALS arm cavity offset.
  2. Common hand-off to transmitted power.
  3. Lock interferometer.
  4. Improve automatic search for red resonance.
  5. Check RF power on 2f detectors.
Modecleaner team:
  1. Investigate long-term alignment stability of mode cleaner.
  2. Investigate back reflected/scattered light.
Alignment team:
  1. Make EY green WFS work again.
  2. Install EX green WFS auto-centering hardware.
  3. Commission an arm alignment controls topology which can be used for initial alignment.
  4. Integrate green WFS into initial alignment.
RF:
  1. Make an assessment of RF cross talk into the IMC AOM.
  2. Investigate EMI radiation by the VCOs and the fixed frequency OCXO.
LHO General
edmond.merilh@LIGO.ORG - posted 09:53, Monday 17 November 2014 (15097)
Morning Meeting Summary

SEI - plans to do some upgrading/standardiing on Tuesday (maintenence day). Otherwise, standing by to assist with commsissioners.

SUS - plans to work in W bay in the mornings for the entire week

PSL - working on issues with ISS second loop. Also, issues with an apparent 30% power fluctuation that may have something to do with an errant reflection??

3IFO - gearing up for SUS baffle build. Working in VPW to clean up for Contractors

CDS - X-end work - power up and checks

           Y-end work - cabling

Facilities - bring palette jack from MX to staging building. Working to maintain temperatures everywhere. Apolllo may be here this week. Their work will include sawing asphalt which will be conidered invasive.                        operators should be kept informed as to all activities of this nature.

Op Lev - re-alignment work of SR3 (work permit #4946). This will neccessitate transitioning to full LASER SAFE at some point.

Commissioning schedule to remain the same; 12:00 cutoff for noisy work in VEAs unless otherwise granted

grouting in the LVEA discussed as imminent in the not-so-distant future.

H1 ISC
evan.hall@LIGO.ORG - posted 17:40, Sunday 16 November 2014 - last comment - 11:40, Monday 17 November 2014(15093)
No luck on DRMI3f with CARM offset reduction

Sheila, Dan, Evan

Yesterday and today we have tried to get the interferometer into a state where we can lock ALS with a CARM offset, lock DRMI on 3f, and then reduce the offset while staying locked. The lesson learned this weekend is that it is taking too long to get DRMI and ALS locked so that offset reduction can begin.

On the ALS side:

  1. Yesterday the ALS DIFF guardian was a little too agressive in turning on the DARM loop, so Sheila and I have added some timers so that the full gain and the boots are engaged more softly.
  2. We quickly remeasured the OLTF of ALS DIFF yesterday, and it looks almost identical to what was measured in LHO#15025 (i.e., a UGF of 8 Hz with 60° of phase).
  3. Locking ALS seems to be straightforward, but a bit slow. The biggest time sinks here seem to be (1) initial alignment of the arms, and (2) finding the IR resonances. For (1), Alexa, Kiwamu, and I have been working on some modified LLO scripts that use baffle PDs to align the TMSs. We want to expand these so that the ITMs are also aligned using baffle PDs. For (2), we need a better strategy for finding the resonances. Although the ALS DIFF and ALS COMM guardians have "find IR" states, they weren't successful this weekend.

On the DRMI side:

  1. Although DRMI was well-behaved yesterday, today we saw a reappearance of modehopping in the SRC. We tried realigning the corner optics several times (and the Y arm once), but this issue kept appearing and throwing DRMI out of lock. After unlocking and then relocking DRMI, it went away, for no reason apparent to us.
  2. When DRMI was stable on 1f, we were able to transition to 3f with no issue. However, the mode-hopping issue continued to reappear intermittently.
  3. We tried turning on the ASC with DRMI on 1f. It initially improved the POP18 buildup, but then overshot, so we had to turn it off.
  4. The POP18 buildup in both PRMI and DRMI varies between 190 and 270 cts. This has been true for at least a week, despite multiple realignments. Previously, we've been getting buildups in excess of 300 cts.

ALS+DRMI, other:

  1. Yesterday we were able to get ALS locked with a CARM offset. We tried getting DRMI to lock, but it refused. According to Sheila, this may mean we need to turn down the DRMI loop gains during locking to compensate for the increased optical gain from the arms.
  2. Today (like Friday), work was completely stopped by a long earthquake. It started nearly 3 hours ago (ca. 2014-11-16 22:30:00) and continues to prevent us from locking.
Comments related to this report
jeffrey.kissel@LIGO.ORG - 11:40, Monday 17 November 2014 (15103)
For the record, upon further query Evan says "[The ALS DIFF used during the efforts documented by this entry] was with ETMX only. DARM feedback to ETMY was off." (I'd asked because I wasn't sure whether my new H1 ETMY UIM L2P decoupling filter from LHO aLOG 15049 had been tried / tested.)
H1 CDS (ISC)
david.barker@LIGO.ORG - posted 13:59, Sunday 16 November 2014 - last comment - 13:20, Monday 17 November 2014(15092)
no reoccurrence yet of rapid setting of LSC PD_DOF_MTRX ramped mux matrix LOAD_MATRIX

Patrick, Dave

We have been scouring the houly conlog reports of EPICS PVs which change more than 500 times an hour for a reoccurrence of the rapid (many times a second) setting of the LSC ramped mux matrix which was observed last weekend. Unfortunately we have not seen anything yet, we will continue our vigilance.

FYI: here is the report from the last hour. (Remember that a 16Hz front end slow channel, if constanly changing, will give 16*3600 = 57,600 changes per hour.)

Process variables in conlog that have changed more than 500 time(s) in the last 3600 second(s):

H1:SUS-ETMY_L1_LOCK_L_RSET        57541        
H1:SUS-ETMX_L1_LOCK_L_RSET        57541        
H1:ALS-Y_CAM_ITM_SUM               2361        
H1:ALS-Y_CAM_ITM_YAW_POS           2361        
H1:ALS-Y_CAM_ITM_PIT_POS           2361        

Comments related to this report
rana.adhikari@LIGO.ORG - 00:13, Monday 17 November 2014 (15094)INJ, INS, SUS

The L1 RSET frequency seems bad to me. I would interperet this to mean that the Guardian is resetting the filter history on that filter bank 16 times a second. Even if this filter bank is unused it indicates some rogue/bad Guardian script.

david.barker@LIGO.ORG - 13:20, Monday 17 November 2014 (15106)

Rana is correct. Sheila, Alexa and Nic found the DOWN state of the ALS_DIFF guardian node was rapidly clearing the history of the ETM[X,Y]_L1_LOCK_L filters. This started at 8pm last Tuesday (11/11) and was ongoing until it was fixed a couple of hours ago. This highlighted a guardian logging issue with this node which Jamie is looking into.

H1 IOO
kiwamu.izumi@LIGO.ORG - posted 20:06, Friday 14 November 2014 - last comment - 10:30, Monday 17 November 2014(15081)
IM2 slipped in pitch by 60 urad

Keita, Kiwamu,

This is a follow up of the previous investigation for the input pointing issue (alog 15028). We are concluding that the IM2 is the one which messed up the input pointing the other day before the temperate issue hit us.

According to a back-of-envelop calculation, this well explains why we had to move IM4 by 88 urad in pitch to get back to good alignment (alog 15063). Also, from the OSEM spectra, there is no obvious indication of the mirror sticking to the cage or something. Therefore we don't think this is an issue.

Here are summary:

 


The attached is trend of various relevant signals:

 

Here is the spectra of the OSEMS before and after the slip. The bold curves are the ones taken on Nov 10 and the thin curves are the ones from today. All the spectra from today are consistenly lower at low frequencies supposedly due to different seismic level. Also we are having a small bump at around 2 Hz today for some unknown reason. In any case, we don't see an obivous indication of the mirror touching the cage or OSEMs. Therefore we are concluding that IM2 is still healthy. 

Images attached to this report
Comments related to this report
sheila.dwyer@LIGO.ORG - 10:30, Monday 17 November 2014 (15100)

Hugh, Sheila

This doesn't seem to be the result of either Hugh's work last tuesday or stray light reflected off of PRM. 

This slip in IM2 happened about 5 and a half hours after hugh's work, and about 5 hours before PRM was realinged.

Images attached to this comment
H1 SUS (ISC)
jeffrey.kissel@LIGO.ORG - posted 23:31, Thursday 13 November 2014 - last comment - 22:51, Monday 17 November 2014(15049)
Potentially New H1 SUS ETMY UIM (L1) L2P Filter Design
J. Kissel

I've measured new transfer functions necessary redesign of the H1SUSETMY UIM (L1) DRIVEALIGN frequency-dependent decoupling filters for L2P and L2Y. For the impatient, the last page of the last attachement shows a comparison between the proposed new design and the old, currently installed / in-use design. I have *not* installed this filter because I'd like to discuss the results with commissioners tomorrow morning (and it'll take me some time to resurrect quack to get these installed). In fact, this may argue for us to indeed just copy over ETMX's filter.

Details:
-----------------------------------------
I attach the measurement results (see 2014-11-13_H1SUSETMY_L1_drivealignfilters_rawdata.pdf), but the raw templates can be found here:

/ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMY/SAGL1/Results/Data/
2014-11-13_H1SUSETMY_L1_L2PY_WhiteNoise_ReactionChainTest.xml
2014-11-13_H1SUSETMY_L1_L2PY_WhiteNoise.xml
2014-11-13_H1SUSETMY_L1_P2PY_WhiteNoise.xml
2014-11-13_H1SUSETMY_L1_Y2PY_WhiteNoise.xml

Not that I drove through the TEST filter banks (instead of having to turn off all the existing filters in the LOCK and DRIVEALIGN banks), and made sure that optical lever damping was OFF, and local damping was the LLO design as described in LHO aLOG 14959.

I focus this entry solely on L2P, but the data exists for an L2Y filter if ever needed. in the first four pages, Pink curves are the current measurement, and black curves are what were used in the original design of the previous filter by Arnaud (see LHO aLOG 11832). The encouraging fact is that the data supports exactly what we'd model from the change in damping loop filter design (see green traces on pg 5 of first attachement to LHO aLOG 14959). As an aside -- just because Betsy made me think of it while chasing down slider values -- what effect does reaction chain alignment have on these off-diagonal, lower-stage transfer functions? One might guess that if the L2P cross-coupling isn't something fundamental but a result of dirt alignment affects between the coils on the reaction chain and the magnets on the main, then one would see a change in the L2P transfer function with different alignments of the reaction chain. The good news is that is doesn't have any effect -- see the last page of 2014-11-13_H1SUSETMY_L1_drivealignfilters_rawdata.pdf. I compare the same transfer function for 4 different reaction chain alignments. They still have the old dead-reckoned calibration factors installed, so we know they're not exactly [urads] but close enough for the scale of these offsets used; they use up about 1/2 the DAC range.

As far as the design goes, I used the same transfer function fitting routine and filter generation software suite that (I think) Arnaud used, namely the function
/ligo/svncommon/SusSVN/sus/trunk/QUAD/Common/FilterDesign/Scripts/Length2Angle_decoupling.m 
which is essentially a wrapper around the function,
/ligo/svncommon/SusSVN/sus/trunk/Common/MatlabTools/happyVectfit.m 
which Keita's wrapper around the function,
/ligo/svncommon/SusSVN/sus/trunk/Common/MatlabTools/vectfit3.m
All tweaking of input parameters to the fitting routine, and plots were made using the overarching script
/ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMY/SAGL1/design_H1SUSETMY_L1_L2P_20141113.m

Notable key additions to the design software -- a computation of the final filter's impulse response, as well as a comparison to the previous design.

As I know Arnaud had struggled, I struggled to find a fit with which I was really happy, namely because we all *know* that the L2P transfer function should fall off as some large power of frequency (again, see the models of these TFs on pg 5 of LHO aLOG 14959), but I can't find a set of parameters happyVectFit / vectfit3.m that allows for such a roll-off at high frequency. Indeed, the height of the final flat part of the L2P fit transfer function directly determines the high-frequency gain of the decoupling filter, and directly impacts the impulse response time. I settled on a filter that does a poor job at reproducing the > 2 [Hz] behavior of the L2P measurement, BUT I think it's OK because
(a) the small magnitude of the high-frequency causes a significant drop in impulse response time, and
(b) At the UIM, we're typically driving below 2 [Hz] -- especially if the crossover remains at 0.9 [Hz] as quoted in LHO aLOG 15025, so the accuracy of inversion is not so critical. Though I didn't find any design aLOGs, this seems to have been the philosophy behind the ETMX UIM L2P filter because it ends up looking strikingly similar.
I should say also that having to tune the uncertainty tolerance, the order (i.e. number of poles) in the filter, the tolerance for when to throw out adjacent poles and zeros, the frequency range over which to fit -- all free parameters into happyVectFit.m -- as one has to do to get what one wants in the end really destroys the advantage of automating the fitting process. If only there was a better way...
Non-image files attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 17:55, Friday 14 November 2014 (15076)ISC, SEI
I've installed the filter into H1:SUS-ETMY_L1_DRIVEALIGN_L2P filter bank, in FMs 5&6 via autoquack. 

HOWEVER
(1) I have not tested the filter performance with transfer functions or step response
(2) I've split the L2P and (invP2P * rolloff) into two filter banks. Even with the rolloff, the (invP2P * rolloff) filter has more zeros than poles, so foton has added a whole bunch of high-frequency poles to compensate. Though the *total* filter's -- L2P * (invP2P * rolloff) --  number of poles is equal to the number of zeros, I think the high-dynamic range, zero pole, cancellation between the two filters isn't working out. This is resulting in a HUGE calculated impulse response, which may or may not be real.
(3) This is my first time using quack to install Matlab filters into foton in a *really* long time, so I'm nervous of its functionality.

I attach a series of comparisons with ETMX's filter. The bode plot, in the frequency band we care about (pgs 1 and 2) seems reasonable. Both ETMX and ETMY have some high-frequency garbage in their impulse response, but the overall amplitude of the impulse response in ETMY is many orders of magnitude larger than that of ETMX (!!!). Further, taking the transfer function out well beyond the Nyquist frequency, we see that they behave significantly differently at the Nyquist frequency (~7 [kHz]).

As such, I'm still entirely unsure that this new filter gunna work, and may require further tweaking.

Anyways, these are installed in 
FM5 "UIM_L2P"
FM6 "UIM_invP2P"
and should be turned on TOGETHER, with no other filters engaged in the module, if one would like to be bold and try it over the weekend.

P.S. in case you've forgotten, when you autoquack in a filter who's name has a space in it, and you try to load the new filter coefficients, Foton will hate you. You will, at least, get a nasty-gram on the GDS_TP screen's filter message, ${IFO}:FEC-${DCUID}_MSG saying "bad filter coeff definition on line 259 in .txt," pointing you to the exact line of the problem. So with Jim's confirmation that "Oh yeah, you DEFINITELY don't wanna do that." I changed spaces to underscores and all worked fine.
Non-image files attached to this comment
nicolas.smith@LIGO.ORG - 22:51, Monday 17 November 2014 (15117)

These filters did indeed run away and saturate the DAC. (The EPICS values were even showing “-Inf,” I’d never seen that before). I don’t think we can get away with more zeros than poles in a filter module, even if they are compensated by some other module.

I took the two filters (FM6 and 7) and viewed them in the foton “Multiple” mode, then I took the output in the “Alternate” box of foton and copied that into FM10.

When I tried this, instead of a huge mess I got a nice step response according to foton, and the frequency response was the same as the two original filters. As seen below (new is red, old is blue):

foton
However, stupid foton wouldn’t save the filter (but gave no error message). In the end, I had to take this “Alternate” output and split it up into two filters, being careful that each had more poles than zeros. This allowed me to save the foton file and load the filters into the frontend. I tested that the impulse response behaved nicely by putting an offset into the filter bank.

The two filters are in FM5 and FM10. Their names reflect my frustration.

Images attached to this comment
H1 AOS
krishna.venkateswara@LIGO.ORG - posted 11:41, Wednesday 12 November 2014 - last comment - 12:27, Monday 17 November 2014(15005)
BRS damper controller issues

K. Venkateswara, J. Warner

The BRS damper (see 14388)  has been malfunctioning since yesterday afternoon. It's controller is an open loop system that assumes it is in the centered position when it is first started. Occasionally it can get restarted accidentally when the insulation box is bumped (probably due to a short somewhere, but I'm not sure where). It looks like this happened yesterday around noon.

This requires a manual re-centering of the turn-table for the feedback system to work as designed. I've attached the directions to do this. Jim will do this later today or tomorrow.

Non-image files attached to this report
Comments related to this report
jim.warner@LIGO.ORG - 15:56, Wednesday 12 November 2014 (15018)

I checked on the BRS this morning, and found the code frozen. I followed Krishna's fairly straightforward document up to the point of opening the box and found the masses 90 degrees out of position (NW/SE instead of SW/NE), I was unsure of what to do, so I closed up, restarted the code and called Krishna to consult.

Afterwards, I went back to EX this afternoon, and re-aligned the masses on the damper. I did this by first modifying the code as described in Krishna's document, then opening the large insulating panel on the west side of the BRS enclosure, and just turned the turn table until the masses were approximately SW/NE. The turn table moved quite easily, I was expecting more resistance.It was dark down there, so it was hard to get a good picture, but I've attached an image taken from the west side of the BRS enclosure, showing how I left the masses. I then went back to the rack, re-commenting the appropriate code and restarting. Haven't had a chance to check on the BRS since then, but it looked okay from what I could see on the laptop readouts.

Images attached to this comment
krishna.venkateswara@LIGO.ORG - 12:27, Monday 17 November 2014 (15105)

Looking back at the data, it seems that the changes made in the morning, resulted in a positive feedabck loop leading to large amplitude oscillations in the BRS. The changes made in the afternoon reversed it but it took ~5-6 hours to damp. However, the software appears to have crashed again later. Tomorrow, I'll investigate for intermittent shorts or other grounding issues.

Displaying reports 68281-68300 of 82985.Go to page Start 3411 3412 3413 3414 3415 3416 3417 3418 3419 End