For the 35W beam
Yesterday, as Gerardo noted, the PSL tripped. This was due to the NPRO shutting off, which then tripped the power watchdog and shut off the amplifier. The attached plot shows the power for the 2 NPRO diodes dropping out shortly before the power watchdog trips and shuts off the amplifier. The rack where the NPRO power supply is looked fine, so I don't know what exactly caused this.
[Keita, Corey, Kiwamu]
We worked at HAM2 and HAM3 to get the POP QPD path aligned and this is ongoing.
We have set up a fiber-coupled green laser with a telescope at the stage by HAM2. This laser mimics the actual forward infrared beam (going toward PR2 from PRM). Since the laser launching setup is on the stage which is not quite stiff we found that the injection angle of the laser can be statically misaligned when a person stands on the same stage (typically a few mm shift of the beam spot at the iris in HAM3).
After tweaking the green laser and a temporary in-vac steering mirror to get it through two existing irises (one at HAM2 and the other at HAM3), we moved on to alignment of the optics behind PR2. The position of the first steering mirror (3 inch mirror) was corrected such that the green beam hits a point which is 9 mm off from the center of the mirror in yaw. This is because that this mirror is supposed to catch both forward and backward POP beams who are separated by 18 mm from each other in yaw. Then we started tweaking two steering mirrors to let the beam go in to the QPD sled. An issue at the moment is that the green light is too dim on one of the QPDs and this is a known issue : the HR surface of the pick-off-BS is extremely transparent for 532 nm [1]. We tried a half-wave-plate to make the HR beam brighter like we did at EY [2], but this didn't help. We will try aligning them using the AR beam since the AR beam is bright enough to work with (although we have to do a math to predict the beam position of the HR beam from that of AR).
[1] LHO alog 5774 "50-50 IR beam splitter is a good AR for green"
First check is to the wall - PSL input beam reflected off the vacuum input viewports. Picture attached is annotated with progression of beam positions. Beam is mapping out a space that is neither here (under vacuum position) nor there (in-air position), and currently at some new in-between position. Two pictures attached. Second check is in HAM2 at the periscope - beam is off in yaw by a beam radius, 2-3mm (on card). One picture attached. Third check - MC2 - centered there to the 2mm I could see on PRM. Fourth check - MC3 - less precision but not off by a centimeter. Beam from MC2 is going through the iris in front of MC3. I found that the markers for the irises in front of MC1 and MC2 were gone, along with the irises (taken to align PRM). This can be recovered, if we chose to do that, but unfortunately the original marked position is no longer. - Cheryl, with help from Giacomo and Joe
[Cheryl, Joe, Giacomo]
First thing today, we relived the yaw offset on PRM. As a fiducial, we placed an iris in the rejected beam, at the edge of th table before it goes into HAM1. We then gradually remove the yaw offset from PRM and rotated the cage to keep the beam centered on the iris. After re-clamping the cage, our best estimate of the centering of the beam is with yaw = +50 (pitch is still +2000).
We also directed the parking beam through its baffle on top of HAM2. This required adjusting the position of the baffle slightly (pushing it towards the center of the viewport by ~1/4"). Parking values are yaw = -6000 and pitch = +2500. With this settings, the beam hits comfortably the parking mirror.
We also:
Attached are plots of dust counts > .3 microns and > .5 microns in particles per cubic foot requested from 5 PM March 26 to 5 PM March 27. Also attached are plots of the modes to show when they were running/acquiring data. Data was taken from h1nds1. T0=13-03-27-00-00-00; Length=86400 (s) 1440.0 minutes of trend displayed
Starting a round of matlab transfer functions overnight for the beamsplitter.
see aLog 5927 for summary
Our first complete look at the BS position told us we were 4.6mm south (-X), 2.3mm west (+Y) of nominal. Elevation is <0.1mm away from nominal. Seismic is in the middle of correcting this and we are in an intermediate state. Will continue in the morning.
- Pablo and Michael, Pcal assembly work inside the "assembly" room in the LVEA.
- Apollo crew craned several items over XBM.
- Filiberto and Sheila, Removal of frequency discriminator at Y-End.
- Sheila, install frequency discriminator at Y-End.
- Michael R., is working on bringing the H1 PSL back, unknown cause as to why it failed, Michael is investigating now and trying to bring it back, as of now he continues to work inside the H1 PSL room.
Late yesterday I had a conversation about PCal crates with Rick: he is planning on sorting things with me Thursday-Friday of this week. The "shortie" OpLev piers were moved to the VEA of X Mid. I spent a majority of the day working on documenting (drawings, ICS updates), marking and sealing these crates. Specific details below. I worked documentation and marking on the two Giraffes already at X Mid and started documentation of the leaners and the periscope. Shortie OpLev Piers and Base Plates 3 x D1000452 + 3 x D1000434 2 x D1001301 + 4 x D1000434 3 x D1001854 + 3 x D1000434 In addition, I started to work documentation for baffles.
- Joe, Giacomo, Cheryl, Keita Tonight we started by revisiting the retro-reflected beam between PR3 and PRM. We used fringes to tweak the alignmet of the second reflection from the PRM to be aligned to the transmitted beam at PR2, which we estimated to be good to the beam radius of 6mm. PRM was estimated to be aligned to within 0.1mrads in pitch and yaw. Good PRM alignment is: pitch = +2000 on the slider yaw = -4000 on the slider With this alignment of PRM, the REFL beam clears all apertures and goes to HAM1! REFL to it's parking spot out of the top viewport is not reachable. Full bias in yaw, meaning we are saturating the output, gets the beam fully onto the steering mirror and onto the SiC baffle, but there is not enough drive to get the beam through the baffle aperture. PRM is at -4000 in it's a aligned position, and we had to drive it farther from zero to get the beam on the steering mirror, and saturated at -7800 on the slider. REFL can reach the SiC baffle but not the aperture position is pitch = +3000 on the slider yaw = -7800 on the slider Our suggestion is that we relieve/recenter yaw for the PRM at some point, so we can reach the baffle aperure, but that it's not necessary to do this immediately. For IO, Alignment checks and power measurements continue in HAM2 tomorrow. There is a steering mirror in HAM2 for Keita to use to set up the green beam for HAM3 alignment.
I forgot to say that with the current alignment of the PRM and PR2, I saw a beam on PR3, though didn't evaluate centering, and we saw a beam on the soft cover in HAM3 heading toward the Beam Splitter.
PRM angle estimate breakdown:
Two irises over 16m: This is our primary reference. 2mm over 16m = 0.1mrad, there are two irises and in the worst case these add up to 0.2mrad.
Retro reflected beam going back to PRM: The beam becomes big at PRM, and it's difficult to center on the iris with 2mm accuracy. I'd say 5mm over 16m = 0.3mrad but this might be pessimistic.
PRM alignment itself: We formed a FP cavity by PRM and the retro reflecting mirror, and aligned PRM to the point where the fringe spacing was 1cm (when we were in HAM2) to 5mm (when we moved to HAM3, don't know if this is the wave front curvature coming into play, or if this is simply that the alignment of things were drifting around at this level), so the angle here is 1um/1cm to 1um/0.5cm or 0.1 to 0.2mrad.
All in all, even if these things all add up in the same sign, we're still within 0.7mrad.
After removing the retro reflector mirror in the path, we were able to see the beam from PR3 coming into HAM3 and hitting the cover of the North opening of HAM3.
I'd say the position of the beam was somewhat off to the East from the center of HAM3, maybe about 4 inches or so but I cannot say for sure.
Anyway it seems like we already know the good ball park numbers for alignment offsets of all PRs. The question is if we tare off these offsets.
It looks like the phase frequency discriminator in the Y end remote rack used for the fiber laser lock was damaged during the power sequencing problems yesterday. The output doesn't go negative, even when the signal frequency is lower than the LO frequency. Maybe it lost its negative rail. I tried to take it out of the rack to bring into the shop but I couldn't find a screwdriver to get the power cables out at the Y end, so I will go back for it in the morning. Sheila
Attached are plots of dust counts > .3 microns and > .5 microns in particles per cubic foot requested from 5 PM March 25 to 5 PM March 26. Also attached are plots of the modes to show when they were running/acquiring data. Data was taken from h1nds1. T0=13-03-26-00-00-00; Length=86400 (s) 1440.0 minutes of trend displayed
The out-of-loop PD for the PSL intensity stabilization (H1:PSL-ISS_PDA_OUT_DQ) was used to produce the fake strain channel during engineering run 3 in February. It was very clean overall, but there were a lot of low-frequency glitches. The glitches are all short and below about 55 Hz, and there seem to be more in the 10-25 Hz range. The glitches are every few seconds, not regular, but the rate was pretty much constant during the day. These glitches are still there in recent data. Robert Schofield told me that this frequency range isn't environmental but is likely to be electronic. The glitches are also seen in QPD_DX and QPD_DY. If we can help diagnose this, don't hesitate to contact detchar@ligo.org and andrew.lundgren@ligo.org. The attached plots are: 1. A typical day of ER3 as seen by Omicron (the replacement for the OmegaOnline web reports). 2. A similar plot for 5 minutes of recent (last weekend) data. 3. As above, but QPD_DX. 4. As above, but QPD_DY. 5. A selection of 2-second spectra, showing the instability.
In answer to a few questions: 1. L1, before the work on the photodiodes started, was perfectly clean and did not have similar glitches. The first plot below compares the two spectra. They are nearly identical except at low frequencies. The next two plots show several spectra from L1 and H1, showing that L1 is stable and H1 has a lot of spectrum variability at low frequencies. 2. Jan Poeld suggested that PSL-PWR_PMC_TRANS might be interesting. But unfortunately it's not recorded. 3. The fourth plot shows the spectra of the four PDs. The in-loop PD, PDB, is fairly nasty around 60 Hz, although this doesn't show up as glitchiness, just in the spectrum. QPD_DY also has some lines in it. 4. The attached PDF has SNR versus frequency of the four PDs. The in-loop PDB shows no glitchiness, probably because the glitches are suppressed by the loop. QPD_DY has the loudest glitches of the other three.
Chris, Daniel, Patrick In short: Swapping the real time Ethernet card in the h1ecatc1 computer appears to have resolved a problem with it periodically crashing and restarting. Last week and possibly the week before, the computer running the EtherCAT system at the corner station, h1ecatc1, had been spontaneously crashing and restarting. Each time this occurred there was a message upon login that Windows had recovered from an unexpected error. My first inclination was that one of the installed programs, OpenOffice.org, which periodically asked for Java updates, was causing the problem. To this end I removed this application. I also removed some others that I can not recall at this time. However, the problem persisted. Looking at the Windows minidump file, it appeared that the issue was with one of the TwinCAT processes. The system manager was also reporting CRC errors and lost frames. I attempted to narrow down the problem by systematically disconnecting EtherCAT chassis. I removed the fiber connected to the test setup of end X in the MSR. This fiber was broken on one end, and I destroyed it. I also disconnected the fiber to end Y. I tried various combinations of the remaining chassis in the H1 electronics room. At one point suspecting the ISC Common Chassis, I swapped it with one from H2. While it may have appeared at one point that things were running better with fewer chassis attached, the problem eventually returned. I also tested the fiber connection from the MSR to the H1 electronics room. I removed the fiber connection from the ISC Common Chassis in the H1 electronics room and attached it to a communications tester that Daniel had made. With this setup, the h1ecatc1 computer was connected to the Corner MSR Chassis and this was connected by the existing fiber to the communications tester. This appeared to work. Nevertheless, the problem persisted after reconnecting to the chassis. However, it was realized that the orange multi mode fiber patches from the Beckhoff chassis in the MSR and H1 electronics room did not match the type of fiber running between these rooms. These patches along with the fiber in the chassis itself should be swapped for 50/125 (aqua). This has not been done yet. Last Friday (March 23) I looked closer in the system manager at the diagnosis for just the Realtime Ethernet card. I had the impression that it may have been reporting errors itself, and decided to try and swap it. I replaced it from the slow computer in the rack in the computer user's room. It appeared to fix the CRC errors and I left it running over the weekend. It was still running on Monday morning and appears to have done the trick. Caveat: My memory is somewhat fuzzy and the above steps may not have occurred in exactly the order described.
My handwritten notes: 1:00 PM lost PSL environment channels, H1ECATC1 restart? jucheck.exe, Oracle America, Inc. "C: Program Files Common Files Java Java Update jucheck.exe" -auto -scheduled H1:SUSH34 <- not sure what this means, if even related restarted again trying to browse to EPICS target directory C: Windows Minidump 030513-30139-01.dmp C: Users controls AppData Local Temp WER-55941-0.sysdata.xml removing OpenOffice.org 3.3 remove Java 7 Update 11 remove Adobe Flash Player 11 ActiveX burtrestored 2013/03/04/00:00
After taking spectra on the beamsplitter, and looking at a comparison between damping on and off, I realized the damping was not providing the intended effect.
I double checked a few things before starting to blame other crews :) :
-damping filters loaded and activated
-watchdogs untripped
-model correctly wired
-signal is going to the dac
When looking at the current and voltage channels at the ouput of the coildrivers when sending a signal to the osems, it seems like the coildriver is not receiving anything.
Will discuss tomorrow with Richard to see if that's a simple cabling issue.
Fixed
