For the records. GPS time 1078083583. Tripped on Actuators. Level 2 isolation on both stages, no ST1-ST2 sensor correction on. Had been running on "Start" blends on both stages for quite some time, T240s were pleasantly green. Tried moving ST1 from "Start" to "TCrappy", tripped halfway through on actuators. First glitch in captured screen show is start of switching third spike killed it. Since glitch appears much larger in horizontal, we'll try switching vertical first (Z, RX, RY), then horizontal (X, Y, RZ).
Blending from "Start" to "TCrappys" on verticals (Z, RX, and RY) then horizontals (X, Y, and RZ) worked much better. I've tried twice (thanks to another trip from unstable ST1 ST2 SC). We should change the SWITCH ALL script to performed the blend switching as such. Note that it also might be the difference between starting the switch process at human-button-click speed vs. computer speed, so we might wanna consider staggering the start of the blend switching.
All is within spec, we are ready to move forward with HEPI actuator attachment; IAS will take another look afterwards to ensure we are still within spec.
Back from end X.
going to end Y.
Done
Done. It was a bad belt.
Has been for about 20 min.
Done
Per work permit 4479.
GV7 is soft closed.
Output power is ~ 28 W (should be 30 W) Watchdog is active 'check Xtal chiller' status is red PMC PMC has been locked for 19 hours Reflected power is 11% of transmitted power (should be 10% or less) FSS Reference cavity has been locked for 10 hours Trans PD threshold is set to .5 V (should be at least .9 V) ISS Last ISS saturation event was 10 hours ago Diffracted power is about 4% (should be 10%)
(Jax, Keita)
Today Keita and I marked out the rough position of the back corners of ISCTEY at BSC10 to facilitate its move to its final location next to the BSC. The nominal position of the table is 18" away from the ALS viewport in the -X direction, with the left edge of the table 22" in the +Y direction from the ALS viewport (lower left viewport on BSC10). The numbers are given in inches because none of the measuring tapes we found had metric markings. Here is the information and calculations used to determine this position.
The beam angles from the TMS were taken from sheet 7 of D0902163. Since this is the layout for EX, we need to consider the mirror image of this layout. Therefore, the horizontal angle is not in the -X direction, but in the -Y direction. The horizontal angle phi is determined from the alignment angles as outlined in the attached pdf.
For the ALS beam angle of 12.4 degrees, the horizontal shift per meter is 22cm. The table is placed approximately half a meter from the viewport, corresponding to a shift of 11 cm/~4.25". The center of the table opening for the ALS beam is 27.5" from the edge of the table enclosure, so add this displacement to 27.5" to determine the shift in position. This gives our layout position of 22" in the +Y direction from the ALS viewport.
The only question we have remaining is the position of the table in the X direction. We have laid out and calculated a position consistent with the table installed at EX, but there is some possibility the mode-matching on the table was set with a distance of 1 m in mind. If the table has to come back half a meter, this would add 11 cm to the horizontal displacement. The clearance on either side of the ALS table after moving the E-module will be 9" (ref. Bubba), so if the position has to be modified to address this, the additional 11 cm/4.25" will be attainable with our available space. Alternatively, the mode-matching telescope on the table can be adjusted to be optimal for this position, which is more consistent with the table as installed at EX.
(Edited because the equations were exported as PDFs instead of PNGs and didn't show up... and AGAIN because despite showing up just fine in the previews, the equations refuse to show up. Attached the work as a pdf.)
Sometime between leaving the cartridge test stand and yesterday inside of BSC10, the optics in the suspension got really dirty. The barrels of the ETM test mass, ERM optic, and PUM have accumulated alot of particulate. I wiped these clean just prior to welding in Jan and recall them looking much better than they do in the pictures below when they were hanging on the test stand. So, between the last bit of cartridge work, the cartridge flight and the in-chamber work over the last week lots of particulate has swirled around the in-vac hardware (about a 2 week duration). Here's the sequence of cleaning in case Calum wants to know:
On test stand, just prior to flight:
- I wiped and vacuumed SUS, bagged both SUS and TMS
- Hugh wiped all of the ISI above, then bagged ISI
Cartridge flight Feb 24th
~2 days after in-chamber I wiped entire floor and viewport surfaces of BSC10 chamber, I did NOT inspect optics
- cabling, TMS payloading, SEI float/balance
- yesterday, I see this gross particulate accumulation, some on the suspension structure too, harder to see since it's metal surfaces though
- I wipe the entire floor of chamber again
More cleaning to follow, obviously.
Note, the particle counter which was hanging around in the test stand area was worked on early last week and then parked under the tube in the chamber cleanroom. This wasn't a particularly useful place to count particles so I moved the counter to in front of the door yesterday. Long story short, no particle data is useful before yesterday. Par.
Done
Done
[Ed, Yuta, Stefan, Arnaud, Sebastien, Jeff, Evan]
Temperature loop
On Sunday, Stefan helped me get a stable temperature loop going for the auxiliary laser PLL. The lasers now stay frequency-locked for about 5 minutes. We take the fast control signal, feed it into an SR560 for gain/rolloff control, then attenuate a bunch, and feed it into another SR560 which sums this signal with a trimpot-controlled DC offset signal. This signal then goes into the slow control of the laser. I suspect the short lock time is due to the fact that the SR560 has no integrating feature; right now I've just set it to have a DC gain; the pole of the temperature loop is set by the thermal pole of the laser. A diagram of the loop topology will be uploaded soon.
PRMI FSR sensing: no success
On Monday, the EE shop made me a 60-ft BNC cable with LMR-195. I used this to take the raw RF signal from REFLAIR_B and bring it over to the IOT2R setup. This signal is demodulated using the PLL offset frequency as the LO, and the resulting DC trace is monitored on a scope.
This afternoon, Yuta and I stole time from the green team in order to lock PRMI and try to see if the demodulated REFLAIR_B signal would show any kind of error signal in response sto the PLL offset being swept across an FSR of the PRC. We swept from 58 MHz to 62 MHz, but did not see a clear DC response from this error signal; the DC was between -1 mV and 0 mV, with an rms noise of a few hundred millivolts. If the offset frequency was set to be near a harmonic of 9.1 MHz, the error signal would become dominated by the beat of the harmonic against the offset frequency (as one would expect).
Next, we tried looking at POPAIR_B_LF to see if we could see a DC power buildup as a function of PLL offset. We didn't see anything; the DC power fluctuated between 70 and 90 counts at all times, and showed no change in response to the PLL offset.
Addendum on PRMI Iocking
Yuta tried for some time this afternoon to get PRMI locked. The biggest stumbling block was that PRY showed no fringes. Eventually, with the help of Arnaud, Sebastien, and Jeff, it was realized that
A schematic of the PLL loop and a diagram of the table are attached.
Started ETMY TF at gps 1077929299 on opsws0 for M0 and R0 in undamped and damped config. The measurement will be running for ~15 hours. This is to assess for rubbing after installation in chamber, and before tomorrow's alignment check.
The measurement returned 0 for all excitations data. I tried again yesterday night with SR2 as a guinea pig and it did the same thing. I suspected some awgstream issues, so I tried running the awgstream command we use in get_sch_TF_M0_v9DQ_sma.m from the terminal, and it returned some error, cf below. Jim is curently taking a look at it
awgSetChannel : failed awgnewchannel_1(chntype = 1,arg1 = 0,awg_clnt[41][0] =o) H1:SUS-SR2_M1_TEST_L_EXC
Error code from awgSetChannel : -5
Error while opening SIStream: Error setting up an awg slot for the channel