The beam scan (which has been living in the bridge subbasement for a bit now) is in a state of imperfection.
I noticed that:
I took some pictures to try and illuminate the situation - The inverted images are included to make it easier to see the flecks (?) in the slits
I am not sure how to figure out if any bit of the scan is/has been fried.
Pending further investigation, enjoy large error bars in your scan measurements!
PICTURES OF BOTH SLITS ON THE BEAMSCAN HEAD:
I came into the 40m to sign things out briefly then swiftly return them, and the alarms were going off on op540m at 1am.
The cat and donkey? were making much noise.
A cosmic ray struck the RFM in the framebuilder this afternoon, causing hours of consternation. The whole FE system is just now coming back up, and it appears the mode cleaner is not coming back to the same place (alignment).
Jenne, Rana, Koji
The mode cleaner has been realigned, using a combination of techniques. First, we used ezcaservo to look at C1:SUS-MC(1,3)_SUS(DOF)_INMON and drive C1:SUS-MC(1,3)_(DOF)_COMM, to put the MC1 and MC3 mirrors back to their DriftMon values. Then we looked at the MC_TRANS_SUM on dataviewer and adjusted the MC alignment sliders by hand to maximize the transmission. Once the transmission was reasonably good, we saw that the spot was still a little high, and the WFS QPDs weren't centered. So Koji and I went out and centered the WFS, and now the MC is back to where it used to be. The MC_TRANS QPD looks nice and centered, so the pointing is back to where it used to be.
cosmic rays in cars
quake coming through. I've re-enabled optic damping (except ETMY), and left off the oplevs for now. We can do a resonant-f check over the weekend.
Looks like it was a magnitude 5 near Olancha, where they sell really good fresh jerky. quake
latest news: there's actually been about a dozen earthquakes in Keeler in the last couple hours: http://earthquake.usgs.gov/eqcenter/recenteqsus/Maps/special/California_Nevada_eqs.php
Came in, found all front-ends down.
Keyed a bunch of crates, no luck:
Requesting coeff update at 0x40f220 w/size of 0x1e44
No response from EPICS
Powered off/restarted c1dcuepics. Still no luck.
Powered off megatron. Success! Ok, maybe it wasn't megatron. I also did c1susvme1 and c1susvme2 at this time.
BURT restored to Nov 26, 8:00am
But everything is still red on the C0_DAQ_RFMNETWORK.adl screen, even though the front-ends are running and synced with the LSC. I think this means the framebuilder or the DAQ controller is the one in trouble--I keyed the crates with DAQCTRL and DAQAWG a couple of times, with no luck, so it's probably fb40m. I'm leaving it this way--we can deal with it tomorrow.
I found the red sea when I came in this morning.
I tried several things.
I'm now going to restart the single front -ends and burtgooey them if necessary.
Everything is back on.
Restarted all the front ends. As usual c1susvme2 was stubborn but eventually it came up.
I burt-restored all the front-ends to Nov 26 at 8am.
The mode cleaner is locked.
Today I measured the max output power at the EOM output of one of the RF AM Stabilizers that we use to control the modulation depth. I needed to know that number for the designing of the new RF system.
When the EPICS slider of the 166 MHz modulation depth is at 0 the modulation depth is max (the slider's values are reversed : 0 is max, 5 is min; it is also 0 for any value above 5, sepite it range from 0 to 10).
I measured 9.5V from the EOM output, that is 32 dBm on a 50 Ohm impedance.
Taking a cue from entry 2346, I immediately went for the nuclear option and powered off fb40m. Someone will probably need to restart the backup script.
Backup script restarted.