Displaying reports 67021-67040 of 83122.Go to page Start 3348 3349 3350 3351 3352 3353 3354 3355 3356 End
Reports until 08:38, Saturday 07 February 2015
H1 CDS (AOS)
david.barker@LIGO.ORG - posted 08:38, Saturday 07 February 2015 (16551)
TCS EPICS records added to alarm manager IOC to support weekend guardian work

Alastair, Aidan, Jamie, Dave:

To support this weekend's TCS guardian development, I have temporarily added two new EPICS channels to the alarm manager IOC on script0. Their permanent location will most probably be the h1tcscs front end model, we will schedule this install for Tuesday maintenance. The channels are:

H1:TCS-ITMY_CO2_LASERPOWER_SETPOINT
H1:TCS-ITMX_CO2_LASERPOWER_SETPOINT
H1 ISC
evan.hall@LIGO.ORG - posted 05:24, Saturday 07 February 2015 - last comment - 17:38, Sunday 08 February 2015(16544)
1 hour lock at zero CARM offset

Ryan, Lisa, Evan

We have been locked for more than 1 hour with CARM controlled by digital REFL9I (at 0 pm offset) and DARM controlled by ASAIR 45Q. The power buildup is 1100 times the single-arm buildup, giving an interferometer recycling gain of 33 W/W. The REFL_A_LF power is 1.35 ct, compared to 21 ct with the arms held off resonance. This means the interferometer visibility is about 94%.

The new element today was a higher-bandwidth DHARD pitch WFS loop. The loop time constant is a few seconds or so, and is fast enough to suppress the appearance of the microseism in ASAIR 45Q. Next steps are probably to close the analogous yaw loop. Ryan had to adjust ETM differential yaw by hand several times to keep the AS beam reasonably round. Also, Ryan had to add a DC-coupled oplev servo to ETMX L1 pitch in order to keep the optic from drifting.

Details will be posted later.

Comments related to this report
lisa.barsotti@LIGO.ORG - 05:29, Saturday 07 February 2015 (16546)
These are the plots with the transition to REFL 9I, and a trend of the 1 hour long lock (starting around Feb 7, 12.11 UTC).

In the first plot, the power build up increase around 400 sec is due to the improvement of differential YAW alignment that Ryan did by hand. 

The lock loss happened right after a DARM loop measurement. 

The high wind of the afternoon was totally gone by the time we came back to the site after dinner. 

Images attached to this comment
david.shoemaker@LIGO.ORG - 05:31, Saturday 07 February 2015 (16548)
Congratulations! and thanks for staying up all night once again.
albert.lazzarini@LIGO.ORG - 07:06, Saturday 07 February 2015 (16550)
Welcome news. Great job. Congratulations to everyone who has helped bring this about. 
david.reitze@LIGO.ORG - 09:48, Saturday 07 February 2015 (16553)
Awesome! Very pleased to see this result. Nice work everyone!  
fred.raab@LIGO.ORG - 01:48, Sunday 08 February 2015 (16563)
Congratulations from Delhi! Nice to see the stability of lock at this early stage. The entire team deserves credit for undaunted persistence through all the tricky issues. Y'all rock.
lisa.barsotti@LIGO.ORG - 17:38, Sunday 08 February 2015 (16567)ISC
In my previous trends I plotted the wrong POP18 signal (before demodulation), here is the correct signal representative of the sideband power.

Once the arm cavity power increases from ~ 500 to ~1000 single arm power, the sideband power decreases by ~20% in about 10 min.
Images attached to this comment
H1 ISC
daniel.hoak@LIGO.ORG - posted 22:18, Friday 06 February 2015 (16543)
OMC alignment servos set

During breaks in the locking action this week, I have tuned up the OMC alignment loops that use OM3 and the OMC suspension to align the beam into the cavity.  These loops are now stable; I've measured the OLTFs and everything looks robust.

I also fixed the dither alignment loops, though a combination of adjusting (audio) demod phases, moving frequencies around to avoid peaks in the intensity noise, and lowpass filters to get rid of the high-frequency junk.  These might need some attention later, we should change the dither frequencies to match L1.

The first plot attached is a figure of the noise suppression with the AS WFS DC centering and the OMC ASC turned on.  Top panel is beam jitter on the AS WFS, lower panel is beam jitter into the OMC.  References 0-4 are with no loops closed, 8-11 are with the AS WFS centering loops closed, and the current traces are after the OMC ASC loops are closed.  The AS WFS centering is fairly high gain, something like 3Hz, we could turn this down.  The OMC ASC loops are around 1-2Hz UGF, when the QPD signals are used.  (The dither loops are much slower.)

Second plot attached is an example of an OMC ASC loop transfer function.  The inversion of the OMCS plant leaves a broad peak, but there's plenty of phase margin.

Third plot attached is the new output matrix, there were a few sign errors in the picture from the earlier post.

I have updated the OMC safe.snap file with the new filters, gains, etc.

This evening I also checked the balance of the OMC DCPDs, using an excitation in the cavity length, and changing the DCPD_BALANCE slider to minimize the peak height in the nullstream channel.  I found that an exact 50-50 split was the best choice.  Might need to check this again with a variety of amplitudes and frequencies, the result is seems a little too perfect.

Images attached to this report
H1 ISC
sheila.dwyer@LIGO.ORG - posted 19:21, Friday 06 February 2015 (16541)
increased bandwidth for ALS offload to suspensions

Since the wind has been bad all afternoon, we took the chance to look at the filters in the suspension offloading path known as tidal.  I copied the plant inversion we are using for the UIM in DARM, with this we were able to puch the bandwidth up to about 0.03 Hz.  We also raised the limit on this to about 10 um.  With this change we went from being able to lock the arms with green for less than about a minute to being able to lock for about 5-10 minutes.  Eventually the "tidal" feedback reaches the limit, and within a minute of that happening the VCO rails.  We could increase the limit further to possibly hold things a few more minutes, but the wind is getting worse. 

Attached is a screen shot showing the new arrangement of filters and gains for this. 

Images attached to this report
H1 General
lisa.barsotti@LIGO.ORG - posted 17:32, Friday 06 February 2015 - last comment - 06:54, Saturday 07 February 2015(16539)
How to fix firefox error message
If you are wondering what to do when you try to open Firefox and you get an error message which tells you "firefox is already running", but it is not, and you don't want to reboot your machine, here is the solution (from Dave & Jonathan):

- cd /ligo/home/lisa.barsotti/.mozilla/firefox

- rm lock

- rm .parentlock



Comments related to this report
jameson.rollins@LIGO.ORG - 17:40, Friday 06 February 2015 (16540)

rm ~/.mozilla/firefox/{,.parent}lock

keith.thorne@LIGO.ORG - 06:54, Saturday 07 February 2015 (16549)CDS
To help with this on the common login accounts (ops, controls), at LLO in eLIGO,  we created a script to invoke Firefox to uses a per-workstation profile and deletes the lock files before starting,
This works fine as long as you train users to invoke the script (on the desktop) instead of from the Gnome menu (or directly at the command line).  The move to per-user logins has eased this problem a lot. 
H1 CDS
david.barker@LIGO.ORG - posted 17:07, Friday 06 February 2015 (16538)
listing all SDF differences if the total number exceeds 40 channels

During ISI commissioning today the total number of channels being monitored by SDF which were changed exceeded 40. Hugh asked if I could give him the full list and the total number of changed channels.

Here is the procedure (h1isietmy is shown as an example)

On the H1ISIETMY_SDF_RESTORE.adl medm screen, in the yellow "save" section:

Set the "FILE TYPE SELECTION" to "EPICS DB AS SDF"

Ensure the the "FILE OPTIONS SELECTION" is set to "TIME NOW"

Press the Blue "SDF SAVE FILE" button, which will save the current settings as a time-stamped file (e.g. h1isietmy_sdf_150206_170209.snap)

In a terminal, type the following:

target

cd h1isietmy/h1isietmy/burt

listsdfdiffs.bsh

The output from this command is shown in the attached file

Images attached to this report
H1 SEI
hugh.radkins@LIGO.ORG - posted 16:48, Friday 06 February 2015 - last comment - 12:54, Tuesday 10 February 2015(16536)
ETMY HEPI Pump Servo Channel Smoothing removed

On Nov 7 I added smoothing to the terribly noisy channels generating the differential pressure.  I revert these back to no smoothing.

Comments related to this report
hugh.radkins@LIGO.ORG - 16:54, Friday 06 February 2015 (16537)

The smoothing factor was 0.75 and is now 0; see the attached for how that affects the channels.

Images attached to this comment
jeffrey.kissel@LIGO.ORG - 12:54, Tuesday 10 February 2015 (16600)
Smoothing (SMOO) parameters for the Supply and Return pressure channels of EY were restored to 0.75 Friday evening, 2014-02-06, late-ish in the evening. The EPICs subrecords are not recorded in the frames, so I can't give you an exact time.
H1 TCS (TCS)
aidan.brooks@LIGO.ORG - posted 16:43, Friday 06 February 2015 (16535)
H1HWSMSR frame grabber driver updated to v5.4.1.1 to match LLO. HWS v1.1.8 now works

I updated the EDT frame grabber driver on H1HWSMSR. The ring buffers now work. HWS v1.1.8 now works.

  1. The symbolic link /opt/HWS now points to v.1.1.8 again
H1 CDS (DAQ)
david.barker@LIGO.ORG - posted 16:26, Friday 06 February 2015 (16534)
test points for new ALS models not in DAQ

we just found out that the tpchn files for the new ALS end station models were not added to the DAQ on Tuesday (though the ini files were). We'll correct this next Tue.

H1 TCS (TCS)
aidan.brooks@LIGO.ORG - posted 16:09, Friday 06 February 2015 - last comment - 16:23, Friday 06 February 2015(16532)
H1 HWS not working with HWS_v1.1.8 code. Framegrabber drivers are old

I installed v1.1.8 of the HWS code on H1HWSMSR and it doesn't work (it worked fine at LLO). After some digging, it turns out that the EDT software that runs the camera does not run with 'ring buffers' at LHO. Basically, if you issue the command 'take -N 4' on H1HWSMSR, you get 'Bus error', where this works fine at LLO.

After some digging, I discovered that the framegrabber drivers are v4.2.6.8 at LHO and v5.4.1.1 at LLO. I'm going updating the drivers here and see if that helps.

Here are the changes that I made to H1HWSMSR computer

  1. Downloaded latest version of SVN
  2. Created symbolic link /opt/HWS that points to /opt/Hartmann_Sensor_SVN/release/HWS_v1.1.8
  3. Updated alias for HWS X&Y code in bashrc. Run_HWS_H1ITMX now points to /opt/HWS/Run_HWS_X/distrib/Run_HWS_X
  4. Couldn't get v1.1.8 of the code to run
  5. Changed symbolic link /opt/HWS so it points to /opt/Hartmann_Sensor_SVN/release/HWS_v1.1.6
  6. The aliases don't need changing. They automatically point to v1.1.6 now. V1.1.6 is running for HWSX. HWSY is down at the moment because there is no Hartmann plate on the sensor
Comments related to this report
aidan.brooks@LIGO.ORG - 16:23, Friday 06 February 2015 (16533)

The following is a message from EDT Tech Support regarding the software problems in response to my query about the software not working on the Hanford machine.

I'm pretty sure this has to do with how the driver is supporting the Linux kernel version (or not) in 4.2.6.8. I see in our changelog, the following line for PDV version 5.3.3.3:


Support for Linux kernels 2.6.18 through 3.2.7 (but excepting 3.0.1.4)

Since 4.2.6.8 is currently loaded on a Ubuntu system with 2.6.32, I am thinking the problem is the driver doesn't quite work properly with kernel 2.6.32. We can't allocate buffers correctly. There might be a clue in the included dmesg output for your "Hanford Machine", but the truth is I don't have the expertise to understand what it is telling me.

I think the bottom line is, if you are running kernel 2.6.18 and later, you'll need to update to a more current PDV driver package.

H1 General
thomas.shaffer@LIGO.ORG - posted 16:03, Friday 06 February 2015 (16509)
Ops Shift Summery

7:00 Karen, Cris - LVEA cleaning exits

8:18 Betsy - To LVEA

8:42 J. Kissel - To EX to turn on coil driver

8:43 Sudarshan - To EX for Pcal work

8:58 Andres - LVEA for 3IFO work

8:58 Doug - To EX to take pictures

8:59 P. King - To H2 Enclosure

9:00 Bubba - To LVEA Moving SEI stuff

9:25 Andres - Back

9:27 J. Kissel - Back with fixed ETMX sensors

9:39 Doug - Back

9:40 Travis - To LVEA to meet up with Betsy

9:47 Travis, Betsy - Back

9:58 Sudarshan - Out of EX

10:06 Bubba - Back

10:39 P. King - Back

11:47 R. Savage, Nutsinee - To MY for check on storage

H1 SUS (DetChar, ISC)
jeffrey.kissel@LIGO.ORG - posted 14:18, Friday 06 February 2015 - last comment - 10:15, Thursday 12 February 2015(16511)
H1 SUS ETMX UIM (L1) Driver Power Switch Trips -- Now Turned Back ON
J. Kissel

ETMX UIM Driver's rocker switch tripped last night at 8:44:30 UTC (Feb 06 2015 00:44:30 PST), which cause all OSEM output on the L1 / UIM stage (and the sensor signals as well) to fail. 

I've turned on the rocker switch, and the stage appears functional.

Other points:
-------------
There is no smoking gun for this chassis power outage. There are not enough diagnostic tools in the frames to look at all possible suspects (power surge to the chassis [no power monitors], chassis overheating [no temperature sensors], an inconsequential component on say -- a monitor board -- smoking [only one of the four monitor signals for each channel are stored], too large a current request [the NOISEMON is stored, not the FASTIMON]).

Output request of DAC (from any ISC) does not appear to coincide with trip, but difficult to tell with dataviewer. There is an Longitudinal request to drive really hard, but it's unclear whether it's a the cause of or a result of the driver's power being shut off.

Output request is roughly 42 [mA] (according to FAST_I_MON) on all four coils leading up to trip, switch trips on 3 [A]. Even the sudden, very large output request does not cause any current larger than the 42 [mA] -- as reported by dataviewer / EPICs. Reqrettably, only the severely-high-passed-at-5-[Hz] noise monitor signals are stored in the frames, but I attach the time series of one of the coils anyways to indicate the exact time. It shows a nice smooth ramp down at the time of the chassis power down. 

Serial number of this box is S0900303. I attach pictures of the box after I'd turned it back on. When I first approached the box, the front "power" LED lights were OFF, and the rocker switch was in the opposite (powered off) position. 

I'm not sure if there is good way to make this power shut-down control-room visible. I did notice that all the coil driver monitor signals were frozen at -16 [ct], and that the OSEM sensor speed dials were zero for this stage and this stage alone, which is what immediately clued me in that it was a flaw with the entire coil-driver chassis or satellite amplifier. 

This last happened (according to collective analog CDS crew's memory) on H1 SUS ITMX UIM driver, some time ago, 19 November 2013. See LHO aLOG 8635.
Images attached to this report
Non-image files attached to this report
Comments related to this report
daniel.sigg@LIGO.ORG - 13:09, Friday 06 February 2015 (16517)

What's going on here?

Images attached to this comment
jeffrey.kissel@LIGO.ORG - 13:30, Friday 06 February 2015 (16521)CDS, DetChar, ISC, SYS
Adding more to Daniel's comment -- the problem in the screen shot he shows is ONLY a problem with the reported decimation filter output for the ETMX L1 LOCK L bank. He had repeated the same test on the ETMX L1 LOCK P bank, and saw no difference between the OUTPUT and OUT16. It's not an issue progressing forward because no one and nothing uses the decimation channel but for diagnostics, but it's this kinda of stuff that makes users immediately suspicious of the entire front end code as a whole (regardless of how serious the problem actually is) and demand "REBOOT! REBOOT!" without really identifying the specific problem.

Again, all signs point to that this is UNRELATED to the coil driver switching off from a current overload.

This being said -- I agree the decimation display problem with *this* filter bank *is* weird, and we'll try to debug further.
rana.adhikari@LIGO.ORG - 15:59, Friday 06 February 2015 (16530)

I have seen this too. Good to know its not just in my mind.

daniel.sigg@LIGO.ORG - 21:17, Friday 06 February 2015 (16542)

A couple more observations from bizarro land:

  • The value actually flickers.
  • The filter module below doesn't experience this.
  • The same filter module in EY is also fine.
  • Decreasing the offset by 10 and it is fine.
  • Increasing the offset by 10 and still no good.
  • Inverting the offset to negative and it is fine.
jeffrey.kissel@LIGO.ORG - 10:15, Thursday 12 February 2015 (16692)SUS
As indicated quickly by Daniel (LHO aLOG 16604), I restarted the front-end process for h1susetmy Tuesday morning, and saw no change in this behavior.

Since this bug seems to be extremely low impact, we should toss it into the CDS bugzilla for exploration of the flaw offline on a test stand to see if we can reproduce the error and hopefully debug. Also -- just because we like to blame everything new, it might be worth a check to see if this bug appeared after the RCG 2.9 upgrade, or after Daniel's Tidal Servo installation (see LHO aLOG 15601, or from his new Integrator filter module (LHO aLOG 15560), which is installed and feeding to/through the UIM L filter bank.
H1 ISC
kiwamu.izumi@LIGO.ORG - posted 13:57, Friday 06 February 2015 - last comment - 18:25, Friday 06 February 2015(16522)
DRMI lock acquisition study (round 2)

Alexa, Kiwamu

In response to the commissioning alog from the last night (alog 16501), we spent an hour or two to study the DRMI lock acquisition with ETMs miasliged in this morning. The key item we checked this time was the BS limiter. We took a few lock acquisition samples with and without the BS limiter which was suggested by Ryan.

It seems that the limiter improved the locking time. We will tentatively keep the limiter on.

The alignment was adjusted initially so that we observed consistently high build up in each lock. We tried repeating the same test with the arm cavities aligned, but we ran into some aligment issues which prevented us from completing the test with the arm cavities aligned. Note that this limiter method is something we used to use in the past, but  apparently we decided not to use it for some reason at some point.

 

(The test without the limiter)

  time to lock [sec]
attempt #1 10
#2 120
#3 540
#4

270

(The test with the limiter)

  time to lock [sec]
attempt #1 5
#2 120
#3 60
#4 80
#5 90

 

(The limiter)

The limiter resides in BS_M3_ISCINF_LIMIT and the value was set to 5x105 cnts.

Comments related to this report
alexan.staley@LIGO.ORG - 14:07, Friday 06 February 2015 (16524)

This limiter was being engaged during lock aquisition and then turned off when lock was aquired during the MICH_DARK_LOCKED state of the LSC_CONFIGS gaurdian. However, none of this was translated over to the ISC_DRMI guardian. I have added this to the ISC_DRMI guardian now.

lisa.barsotti@LIGO.ORG - 18:25, Friday 06 February 2015 (16531)
Attaches is a plot corresponding to the test that Kiwamu and Alexa did. Once the SWSTAT is around 46000, the limit on the BS correction was turned on at 500,000, and the DRMI started acquiring lock more frequently (examples of locking attempts with this limit OFF and ON are attached as well).

Since this setting was not in the guardian managing the DRMI lock (and the MICH guardian used in the initial alignment sequence turns this off once lock is acquired), the BS correction limit was typically off, unless someone was intentionally turning this on (which I am pretty sure happened at some point in the past, as this limit is a known important variable for the locking sequence).

How critical this BS limit is for lock acquisition it depends on the seismic input. So, even assuming comparable good alignment states, the easiest explanation for "DRMI lock sometime works, sometime it doesn't" is that even when the seismic noise is not outrageously bad and it is obviously recognized like a problem, it might still be higher than "normal" and make the locking more sensitive to gain settings, and marginal.

Here is some (now old) systematic study that Den did  sometime ago  at LLO changing the locking thresholds, also known to be critical parameters. 

It would be good to do similar tests with arms off-resonant. I think Alexa and Kiwamu tried by they didn't have enough time today, we should keep this in mind and use any available "free" time to make the acquisition time as short as possible ( < 1 min). Also, it would be good if changes to whatever "nominal" settings were clearly highlighted and somewhat motivated, so we can try to make sense of what's happening.



Images attached to this comment
Displaying reports 67021-67040 of 83122.Go to page Start 3348 3349 3350 3351 3352 3353 3354 3355 3356 End