[Jenne, Q, Diego]
I don't know why, but everything in EPICS-land froze for a few minutes just now. It happened yesterday that I saw, but I was bad and didn't elog it.
Anyhow, the arms stayed locked (on IR) for the whole time it was frozen, so the fast things must have still been working. We didn't see anything funny going on on the frame builder, although that shouldn't have much to do with the EPICS service. The seismic rainbow on the wall went to zeros during the freeze, although the MC and PSL strip charts are still fine.
After a few minutes, while we were still trying to think of things to check, things went back to normal. We're going to just keep locking for now....
We looked at the spectra of POX and POY during IR lock, and Q saw a peak at 1285 in POX only. We're actuating on the ETMs, so it must be an ETMX violin mode, although it doesn't match the others that are in the table.
Anyhow, I added it to FM9. While I was doing that, I realized that yesterday I had forgotten to put back the 3rd order ETM violin notch, so that is also in FM9.
OMG, today sucked alignment-wise. Like, wow.
I think that the problem with the ASS is with the input pointing part of the system. I found that if I disable the TTs for the Yarm (iin practice, the outputs are held at zero), I could run the Yarm ASS at full gain of 1, and it would do an awesome job. The first time I did this, I by-hand optimized the TTs by running the test mass loops to make them follow the input pointing. After that, I haven't touched the TT pointing at all, and we've just been running the test mass loops for the Yarm ASS. The Xarm seems to not have this problem (or at least not as drastically), so I left it as it was, touching BS as well as ITMX and ITMY, although the gain still needs to be about 0.3.
I feel pretty good about the IFO alignment now, although it is slightly different than it has been. The transmitted arm powers are higher than they were before I changed the ASS procedure, and there seems to be a little less power fluctuation with alignment. Q points out that I don't have concrete evidence that this is a good alignment, but it feels right.
It was a significant enough change that I had to go down to the Yend to realign the green to the new arm axis. Xgreen we did with the remote PZTs. I also realigned both of the beatnotes on the PSL table.
While I was on the PSL table, I quickly touched up the PMC alignment.
The biggest problem, the one that sucked up more hours and energy than I'd like to admit, is ETMX's jumping. So frustrating. Sometimes it is time-coincident with engaging the LSC, sometimes not. I thought that it might be because there are too many violin filters, but even if I turn off all violin filters to ETMX, it jumped a few times while the cavity was locked. Sometimes it moves when the cavity is just locked and seems happy, sometimes it moves when nothing is resonating except for the green. It takes a few minutes to recover the alignment enough to lock, and then it'll jump again a few minutes later. I haven't gone down to squish the cables today, although I did it yesterday and that didn't seem to do anything.
We had a few hours of time when it wasn't jumping, so we tried a few times to lock the IFO. The last several times we have lost lock because the PRC loop rang up. We measured the loop at low-ish arm powers, but it kept losing lock at higher powers before we could measure. At least 3 times, the PRC lockloss took out CARM and DARM too.
Anyhow, it has been a long day of not accomplishing anything interesting, but hopefully the IFO will feel better tomorrow.
Apparently, some time ago Larry Wallace installed a new, fast ethernet switch in the old nodus rack. Q and I have just now moved nodus' GC ethernet cable over to the new switch. Dan Kozak is going to use this faster connection to make the data flow over to the cluster not so lag-y.
With the re-do of the IFO alignment last week, I think that the beam was no longer about halfway on the POP22 razor blade. To fix this, I locked the PRMI on sideband, removed the razor blade, and then put it back in such that it occluded about half of the light.
I'm not entirely sure why, but when I put the razor in, POP22 went from 104(ish) to 45(ish) but POPDC went from 5200(ish) to 1600(ish). [The 'ish'es are because the PRC wasn't angularly stabilized, so there was some motion changing the power levels that leaked out to the POP port]. The ETMs were misaligned, so this should not be a carrier vs. sideband effect, since they'll both share the cavity axis defined by the ITMs and the PRM. It is possible, although I didn't check, that there is some oplev light scattered into the POP photodiode that is now blocked by the razor blade. This light would only be at DC and not the 2f frequencies. Since the signal levels for POP22 vs. POPDC didn't change with and without the table top on (and with and without room lights on), I don't think that it is an effect of ambient light getting into the diode. To check if it is oplev light I should (a) just look, and (b) try to lock the PRMI without the ITMX oplev laser being on to see if there is a difference in the POPDC signal.
Anyhow, under the assumption that the POP22 signal level is correct, I tuned up the PRCL ASC a little bit. These changes are now in the carm_cm_up script, and the carm_cm_down script resets things. Before the PRC is locked, I have FM1 and FM7 (the basic servo shape and a 40Hz lowpass) on, the gain set to zero, and the input off. After lock is acquired, the input is turned on, and the gain ramps from 0 -> 10 in 3 seconds. Then FM2 and FM6 (boosts at 1 and 3Hz) are engaged.
In the plot below, the dark blue and red curves were taken when there was no angular control on the PRC. Pink was taken last week with the old QPD yaw ASC on. Light blue is today's version of the in-loop performance of the POP22 yaw ASC loop. I didn't save the trace unfortunately, but the DC QPD saw out-of-loop improvement between about 0.8Hz - 4 Hz.
Also, has anything happened with the LSC rack in the last few weeks that might be causing lots of 60Hz noise? I saw these large lines last week, but I don't think I remember them from the past.
After I got the PRCL ASC working, I tried several iterations of locking. ETMX is still being annoying, although the last hour or so have been okay. CARM keeps getting rung up right around the transition to the sqrtInv error signal. Since CARM and DARM are kind of entangled, it took me a few iterations to figure out that it was CARM that is ringing up, and not DARM. I'm a little worried about the phase loss from the 1kHz lowpass that we turn on just before the transition to sqrtInv. I want to keep the lowpass off until after we have transitioned DARM also over to DC transmission. I tried once, but I lost lock before starting the CARM transition. Anyhow, the ETM alignment issue is annoying.
Also, Jamie, Q, Diego and I were discussing last Friday, but none of us elogged, that we think there might be something wrong with one of the Martian network switches. I'll start a separate thread about that right now, but it slows things down when you can't trust EPICS channels to be current, and I (without evidence) am a little worried that this might also affect the fast signals.
[Jamie, EricQ, Jenne, Diego]
This is something that we discussed late Friday afternoon, but none of us remembered to elog.
We have been noticing that EPICS seems to run pretty slowly, and in fact twice last week froze for ~2 minutes or so (elog 10756).
On Friday, we plotted several traces on StripTool, such as C1:SUS-ETMY_QPD_SUM_OUTPUT and C1:SUS-ETMY_TRY_OUTPUT and C1:LSC-TRY_OUTPUT to see if channels with (supposedly) the same signal were seeing the same sample-holding. They were. The issue seems to be pretty wide spread, over all of the fast front ends. However, if we look at EPICS channels provided by the old analog computers, they do not seem to have this issue.
So, Jamie posits that perhaps we have a network switch somewhere that is connected to all of the fast front end computers, but not the old slow machines, and that this switch is starting to fail.
My understanding is that the boys are on top of this, and are going to figure it out and fix it.
In April, Koji logged that he had made some changes to the Yend QPD whitening board (elog 9854). Today, I pulled the Xend board to see if it had the same modifications. The filter shapes all seem to be the same (as in, the capacitors at the output filters were removed, etc.), and the final gain is the same. I just realized that I didn't explicitly check if the whitening switches were pulled to ground to permanently turn on the whitenening, but hopefully I'll be able to see that in the photo.
I have not made any changes today (yet) to the board, so the overall gain is still accessible via EPICS. I wanted to do a quick check that we won't be saturating things at full power with the maximum gain, before I make a change.
EDIT: After comparing the photos here and in elog 9854, the X end board has the filter shape modifications that were done some time ago, but the whitening is not permanently enabled. For the Yend board, Koji added a jumper wire connecting (for example) R97 and R106 to the grounded side of C69. This jumper wire is not in place on the X qpd board.
Before I re-pull the board and modify it, I want to make sure I know what I'm going to do for the gain slider override.
Here is a little PDF of what I plan to do to both of the transmission QPD whitening boards later today. The idea is to take away the remote gain slider inputs, and force the gains to always be at +30dB.
The red and blue notes are from Koji's elog 9854, and the green are my plans for today.
I will cut the traces from the gain slider inputs, and pull the negative input of the AD620 to ground. The positive input will be connected to the +5 voltage line, with a divider so that the positive input to the AD620 is about 666mV.
The AD602 will be maxed out at +30dB with anything over 625mV.
Unless there are objections, I will start these modifications in an hour or so. I will also make the Xarm whitening always-on, just like Koji has already done for the Yend.
EDIT, JCD, 12Dec2014: These are not the modifications that were made. Please see ____ for actual modifications.
I missed to elog this earlier. I have temporarily removed the DC photodiode for GTRY to install the fiber holder on the PSL table. So GTRY will not be seeing anything right now.
After some confusion, I discovered this a few hours ago.
We decided that tonight was the night for ASS tuning.
We started from choosing new frequencies, by looking at the transmission and the servo control signals spectra to find areas that weren't too full of peaks. We chose to be above the OpLev UGF by at least a factor of ~2, so our lowest frequency is about 18Hz. This way, even if the oplevs are retuned, or the gains are increased, the ASS should still function.
We set the peak heights for the lowest frequency of each arm to have good SNR, and then calculated what the amplitude of the higher frequencies ought to be, such that the mirrors are moving about the same amount in all directions.
We re-did the low pass filters, and eliminated the band pass filters in the demodulation part of the servo. The band passes aren't strictly necessary, as long as you have adequate lowpassing, so we have turned them off, which gives us the freedom to change excitation frequencies at will. We modified the lowpass filter so that we had more attenuation at 2Hz, since we spaced our excitation frequencies at least ~2.5 Hz apart.
The same lowpass filter is in every single demodulator filter bank (I's and Q's, for both length and transmission demodulation). We are getting the gain hierarchy just by setting the servo gains appropriately.
We ran ezcaservos to set the demodulation phase of each lockin, to minimize the Q-phase signal.
We then tuned up the gains of the servos. Rana did the Y arm, but for the X arm I tried to find the gains where the servos went unstable, and then reduced the gain by a factor of 2. The Xarm is having trouble getting good alignment if you start with something less than about 0.7, so there is room for improvement.
Rana wrote a little shell script that will save the burt snapshot, if the gains need adjusting and they should be re-saved.
The scripts have been modified (just with the new oscillator amplitudes - everything else is in the burt snapshots), so you should be able to run the start from nothing and the start from frozen scripts for both arms. However, please watch them just in case, to make sure they don't run away.
Okay, I have finished modifying the Xend QPD whitening board, although I will likely need to change the gain on Monday.
Rather than following my plan in elog 10782, I removed the AD602's entirely, and just use the AD620's as the amplifiers. We don't need remotely adjustable gains, and the AD620s are a less noisy part.
I set the gain to be 30dB using a 1.65k resistor for R_G, which turns out to be too high. After I installed the board and realized that my counts were much higher than they used to be, I realized that what we had been calling +30dB was in fact +13.2dB. ( I am assuming that the ADC for the gain sliders were putting out a maximum of +10V. The AD620 used to have a 1/10 voltage divider at the input, and an overall gain of 1, so the output of the AD620 was 100mV. This goes into pin 16 of the AD602, which has gain of 32*V_set + 10. Which gives 32*0.1+10=13.2dB. Ooops. We've been lying to ourselves. )
Anyhow, before I made the gain realization, I was happily going along, setting the AD620s' gains all to 30dB. I also copied Koji's modification from April of this year, and permanently enabled the whitening filters.
Here is the schematic of what ended up happening. The red modifications were already in place, and the greens are what I did today.
You can see the "before" picture in my elog Wednesday, elog 10774. Here is an "after" photo:
Here is a spectrum comparing the dark noise of the Xend QPD after modification to the current Yend QPD (which is still using the AD602 as the main instrumentation amplifier). I have given the Yend data an extra 16.8dB to make things match.
And, here is a set of spectra comparing both ends, dark noise versus single arm lock. While I'll have to sacrifice a lot of it, there's oodles more SNR in the Xend now. The Yend data still has the "gain fixing" extra 16.8dB.
The Xend quadrant input counts (before the de-whitening filters) now go up to peak values of about 1,000 at single arm lock. If (optimistically) the we got full power recycling and the arms got to powers of 300, that would mean we would have 300,000 counts, which is obviously way more than we actually have ADC range for. Currently, the Yend quadrant input counts go as high as 50, which with arm powers of 300 would give 15,000 counts. I think I need to bring the Xend gain down to about the level of the Yend, so that we don't saturate at full arm powers. I can't remember right now - are the ends 14-bit or 16-bit ADCs? If they're 16-bit, then I can set the gain somewhere between the current X and Y values.
Finally, I added a section of the 40m's DCC document tree for the QPD whitening: E1400473, with a page for each end. Xend = D1400414, Yend = D1400415.
Details later - empty entry for a reply.
Short story - Yend is now same as Xend filters-wise and lack of gain sliders -wise. Both ends have 13.7k resistors around the AD620 to give them gains of ~4.5.
Xend seems fine.
Yend seems not fine. Even the dark noise spectrum sees giganto peaks. See Diego's elog 10801 for details on this investigation.
[Jenne, Rana, Diego]
We did some test on the modified QPD board for the Yend; we saw some weird oscillations at high frequencies, so we went and check more closely directly within the rack. The oscillations disappear when the cable from the QPD is disconnected, so it seems something is happening within the board itself; however, looking closely at the board with an oscilloscope in several locations, with the QPD cable connected or disconnected, there is nothing strange and definitely nothing changing if the cable is connected or not. In the plots there are the usual channels we monitor, and the 64kHz original channels before they are downsampled.
Overall it doesn't seem being a huge factor, as the RMS shows at high frequencies, maybe it could be some random noise coming up, but anyway this will be investigated further in the future.
[Jenne, Rana, Diego]
After deciding that the Yend QPD situation was not significant enough to prevent us from locking tonight, we got started. However, the PRMI would not acquire lock with the arms held off resonance.
This started some PRMI investigations.
With no arms, we can lock the PRMI with both REFL55 I&Q or REFL165 I&Q. We checked the demod phase for both Refl 55 and 165. REFL55 did not need changing, but REFL165 was off significantly (which probably contributed to the difficulty in using it to acquire lock). I didn't write down what REFL165 was, but it is now -3 degrees. To set the phase (this is also how Rana checked the 55 phase), I put in an oscillation using the sensing matrix oscillators. For both REFL165I and 165Q, I set the sensing matrix demod phases such that all of the signal was in the I phase (so I_I and Q_I, and basically zero in I_Q and Q_Q). Then, I set the main PD demod phase so that the REFL165Q phase (the Q_I phase) was about zero.
Here are the recipes for PRMI-only, REFL55 and REFL165:
Both cases, actuation was PRCL = 1*PRM and MICH = (0.5*BS - 0.2625*PRM). Trigger thresholds for DoFs and FMs were always POP22I, 10 up and 0.5 down.
REFL55, demod phase = 31deg.
MICH = 2*R55Q, gain = 2.4, trig FMs 2, 6, 8.
PRCL = 12*R55I, gain = -0.022, trig FMs 2,6,9.
REFL165, demod phase = -3deg.
MICH = -1*R165Q, gain = 2.4, trig FMs 2,6,8.
PRCL = 2.2*R165I, gain = -0.022, trig FMs 2,6,9.
These recipes assume Rana's new resonant gain filter for MICH's FM6, with only 2 resonant gains at 16 and 24 Hz instead of a whole mess of them: elog 10803. Also, we have turned down the waiting time between the MICH loop locking, and the filters coming on. It used to be a 5 second delay, but now is 2 sec. We have been using various delays for the PRCL filters, between 0.2s and 0.7s, with no particular preference in the end.
We compared the PRCL loop with both PDs, and note that the REFL 165 error signal has slightly more phase lag, although we do not yet know why. This means that if we only have a marginally stable PRCL loop for REFL55, we will not be stable with REFL165. Also, both loops have a non-1/f shape at a few hundred Hz. This bump is still there even if all filters except the acquisition ones (FM4,5 for both MICH and PRCL) are turned off, and all of the violin filters are turned off. I will try to model this to see where it comes from.
To Do list:
Go back to the QPDY situation during the daytime, to see if tapping various parts of the board makes the noise worse. Since it goes up to such high frequencies, it might not be just acoustic. Also, it's got to be in something common like the power or something, since we see the same spectra in all 4 quadrants.
The ASS needs to be re-tuned.
Rana was talking about perhaps opening up the ETMX chamber and wiggling the optic around in the wire. Apparently it's not too unusual for the wire to get a bit twisted underneath, which creates a set of places that the optic likes to go to.
Diego is going to give us some spectra of the MC error point at various levels of pockel's cell drive. Is it always the same frequencies that are popping up, or is it random?
EricQ's crazy people filter has been deleted. I'm trying to lock right now, to see if all is well in the world.
I swapped out one of the channels on Q's lockloss plotter - we don't need POP22Q, but I do want the PC drive.
So, we still need to look into why the PC drive goes crazy, and if it is related to the buildup in the arms or just something intrinsic in the current FSS setup, but it looks like that was the cause of the lockloss that Q and Diego had on Wednesday.
The EPICS freeze that we had noticed a few weeks ago (and several times since) has happened again, but this time it has not come back on its own. It has been down for almost an hour so far.
So far, we have reset the Martian network's switch that is in the rack by the printer. We have also power cycled the NAT router. We have moved the NAT router from the old GC network switch to the new faster switch, and reset the Martian network's switch again after that.
We have reset the network switch that is in 1X6.
We have reset what we think is the DAQ network switch at the very top of 1X7.
So far, nothing is working. EPICS is still frozen, we can't ping any computers from the control room, and new terminal windows won't give you the prompt (so perhaps we aren't able to mount the nfs, which is required for the bashrc).
We need help please!
Today Q moved the FSS slow servo over to some init thing on megatron, and some time ago he did the same thing to the MC auto locker script. It isn't working though.
Even though megatron was rebooted, neither script started up automatically. As Diego mentioned in elog 10823, we ran sudo initctl start MCautolocker and sudo initctl start FSSslow, and the blinky lights for both of the scripts started. However, that seems to be the only thing that the scripts are doing. The MC auto locker is not detecting lockloses, and is not resetting things to allow the MC to relock. The MC is happy to lock if I do it by hand though. Similarly, the blinky light for the FSS is on, but the PSL temperature is moving a lot faster than normal. I expect that it will hit one of the rails in under an hour or so.
The MC autolocker and the FSS loop were both running earlier today, so maybe Q had some magic that he used when he started them up, that he didn't include in the elog instructions?
Rana noted last week that TRX's value was stuck, not getting to the lsc from iscex. I tried restarting the individual models scx, lsc and even scy (since scy had an extra red rfm light), to no avail. I then did sudo shutdown -r now on iscex, and when it came back, the problem was gone. Also, I then did a diag reset which cleared all of the unusual red rfm lights.
Things seem fine now, ready to lock all the things.
We are working on trying out the UGF servos, and wanted to take loop measurements with and without the servo to prove that it is working as expected. However, it seems like new DTT is not following the envelopes that we are giving it.
If we uncheck the "user" box, then it uses the amplitude that is given on the excitation tab. But, if we check user and select envelope, the amplitude will always be whatever number is the first amplitude requested in the envelope. If we change the first amplitude in the envelope, DTT will use that number for the new amplitude, so it is reading that file, but not doing the whole envelope thing correctly.
Thoughts? Is this a bug in new DTT, or a pebkac issue?
One of the things that we had talked about last night was the totally tiny amount of phase margin that we have in the CARM and DARM loops. DARM seemed to be the most obnoxious loop last night, so I focused on that today, although the CARM and DARM loops are pretty much identical.
(Q tells me via email that the phase budget has the same ~14 degree discrepancy between what we expect and what we measure as his estimate last night. However, the Caltech network issues prevented his posting an elog.)
So, we definitely need to figure out where this 14 deg is going, but for now, I wanted to see if I could recover a couple of extra degrees just by modifying the filters.
The original filters do seem to eat a lot of phase:
The short version of the story is that I didn't leave the filters changed at all. I reverted back to the last version of the filter file from Monday night, so currently everything is as it was.
I tried increasing the Q of the zeros on the cyan and brown filters, which would sacrifice some gain at ~20 Hz, but hopefully win us 10+ degrees of phase. This gave me a dip of about a factor of 2 between the new and old filters (all servo filters combined added up to this factor of 2 in magnitude) between ~20Hz - 70Hz.
When we were locked using DARM for just the Yarm (for the UGF servo commissioning), I took a spectra of the error signal (which was POY) as a reference, then loaded in my new filters. For the most part, the spectra didn't change (which is good, since the magnitude of the filter didn't change much.). The spectra was bigger though between 50-70Hz, in kind of a sharp bandpass-looking shape that I wasn't expecting. I don't know exactly why that's happening.
Anyhow, we tried the new filters once or twice with the full IFO, but kept losing lock. Since I clearly haven't put in enough thought yet for these (particularly, how much suppression do we really need? what are our requirements???), I reverted back to the filter file from last night. We continued locking, and checking out the new UGF servo that Diego is elogging about.
[Jenne, Diego, Rana]
This is a note about work done last night.
We were starting to lock, and saw glitches in the Thorlabs TRY PD about once every 1/60th of a second. It is not a sine wave, so it is not 60Hz line noise directly. It looks like this:
Rana pointed out that this looks like it could be from a power supply that is converting AC to DC.
We went down to the Yend, and noticed some weird symptoms. So far, we do not know where the noise is coming from. Rather, we are just using the QPD for locking.
* The noise comes and goes, particularly if someone is moving around at the end station.
* Moving the Thorlabs power supply farther from the HeNe power supply didn't do much. Turning off and disconnecting the HeNe supply didn't make the noise go away, so we conclude that it is not the HeNe's fault.
* We suspected the loops of excess cable that were sitting on top of iscey, but moving the coils away from the computer did not make the noise go away.
* We removed a few disconnected BNC cables that were near or touching the end table, but that didn't fix things.
* We disconnected the PD's signal cable and pulled it out of the table enclosure, and then put it back. Noise was gone when cable was disconnected (good), but it was back after plugging the cable back in.
* The noise still comes and goes, but we don't have to use the Thorlabs PD for locking, so we leave it for another day.
RXA: also moved the Thorlabs power supply to a different power strip and tried putting it closer/farther to the Uniblitz shutter controller. Another suspect is that its some PWM type noise from the doubler crystal temperature driver. Need to try turning off the heater and the Raspberry PI to if it effects the noise.
As a warm-up after the holidays, before the real locking began, I installed 1064nm bandpass filters in front of the transmission QPDs to eliminate the stray green light that is there.
The Yend had threads epoxied to it, so that end should be good. Steve is going to repeat that for the Xend QPD at some point. Right now, the filter is just on a lens mount about 2cm away from the PD box aperture, since that's as close as I could get it.
Also, while I was at the Xend, I noticed that the transmission camera is gone. I assume that it was in the way of Manasa's fiber work, and that it'll get put back somehow, sometime. She elogged that she had removed it, but I mistakenly thought that it was already replaced. We don't use that camera much, so I'm not worried.
Now that both end transmission QPDs have the line filters, I aligned them.
I locked and aligned the IR using the ASS, then went to each end table and put the beam in the center of the QPD.
I have added another block to the LSC screen (and made the corresponding sub-screen) to expose the analog settings for the DC photodiodes.
Note that we have 2 open channels there, which are still called something like "PD2" and "PD3" from olden times.
If we ever chose to use those, we will probably want to change their names, in /cvs/cds/caltech/target/c1iscaux2/LSC_aux2.db and /cvs/cds/caltech/target/c1iscaux/LSC_aux.db
[Jenne, EricQ, Rana]
Tonight we started prepping for an attempt at variable finesse locking.
The idea is to put in a MICH offset and hold the lock with ASDC/POPDC (so that the offset can be larger than if we were just using RF signals). This reduces the PRC buildup, which reduces / removes the double cavity resonance problems while reducing the CARM offset.
MICH locked on ASDC normalized by POPDC, PRM and ETMs (and SRM) all misaligned.
MICH offset of -20
MICH input = -0.04*ASDC normalized by 0.1*POPDC.
MICH gain = +5
MICH always triggered on (no triggering for DoF), but FM8 (CLP400) triggered to come on after lock (didn't write down the values).
PRMI locked with MICH on ASDC normalized by POPDC, PRCL on REFL33I, ETMs and SRM misaligned.
MICH offset of -10
PRCL input = 1*REFL33I
PRCL gain = -0.4 (factor ten times the regular value)
MICH always on, PRCL triggered on POP22. MICH FM8 and PRCL FM1,2,6,9 triggered on.
Gives POPDC of about 20 counts, POP22 of about 12 counts, ASDC of about 500 counts.
Arms held at 3nm, MICH locked on ASDC/POPDC, PRM and SRM misaligned.
Arms held at 3nm, attempt at PRMI lock with MICH on ASDC/POPDC.
Failed. Tried mostly same MICH gains as arms+mich, and PRCL at 10* normal gain.
Arms held at 3nm, PRMI locked with REFL 33 I&Q, attempt at transition to MICH on ASDC/POPDC.
Failed. At first, I was putting in the TF line at ~375Hz, but we looked at the full transfer function between 100Hz and 1kHz, and there was a weird dip near 300Hz from PRCL-MICH loop coupling. Here we were seeing that the phase between REFL33Q and ASDC was ~90 degrees. What?
Tried putting the TF line at ~100 Hz (since MICH UGF is in the few tens of Hz anyway, so 100 is still above that), but still get weird relative phase. Here it seems to be about 45 degrees when I inject a single line, although it didn't seem like a weird phase when we did the full swept sine earlier. Maybe I was just not doing something right at that point??
Anyhow, no matter what values I tried to put into the input matrix (starting with REFL33I&Q, trying to get MICH to ASDC/POPDC), I kept losing lock. This included trying to ramp up the MICH offset simultaneously with the matrix changing, which was meant to help with the PRCL gain change. Q has since given us MICH and PRCL UGF servos.
A few hours ago I tweaked up the alignment to the PMC. It was really bad in pitch, and the transmission was down to about 0.711.
In order to know where we should try to make the transition from REFL##Q to ASDC for MICH, I did a quick Optickle simulation to see what the error signals will look like.
The idea is to try to lock the PRMI on a single REFL diode (ex. REFL33 I&Q) with some MICH offset, and then transition over to ASDC. As soon as we have completed the transition, we can engage the normalization matrix to normalize ASDC by POPDC, and also increase the MICH offset if we want. Unfortunately, we do not as yet have the ability in our model to independently normalize different error signals, and then blend them, so we have to turn on the normalization after we've transitioned.
Here is the situation for PRMI-only:
You can see that REFL33Q has a slightly wider range than REFL165Q. It seems like we can perhaps try to make the transition around -15nm or so. Note that the error signals are not quite symmetric about 0nm, so we can use that to help determine what + and - mean. We expect that we need to add about 1nm offset to REFL33Q to get a true minimum in ASDC, so the sign of the digital offset that we need will tell us if there is a sign flip or not between the digital offset and this x-axis.
After we get this to work (hopefully in the next hour or so....), we will want to try the same thing with the arms held off resonance.
Usually we lock the PRMI at an offset of about 3nm:
However we could do it lower, perhaps around 1nm (which is where we currently are doing our CARM/DARM ALS->IR signals transitions):
At some point, we will arrive at 0nm CARM offset, when we'll want to transition back to RF signals (although probably we could jump straight to a 1f signal, not plotted):
The moral of the story here is that I'm not sure how we were ever successfully locking MICH on REFL165Q, unless my phase-setting in Optickle is way off. Certainly it looks like we should be sticking with REFL33 for PRFPMI. Also, since we have an offset in REFL33Q anyway (which we have seen and have commented on before), at 3nm CARM offset it looks like we could try to just do the jump without any extra digital offset. Here's a zoom of the 3nm situation:
[Jenne, Diego, EricQ]
Hopefully there will be more later, but Chiara just went down (network? other? Q is in there right now looking at it), so this is a so-far-tonight elog.
We have successfully transitioned MICH over from REFL33Q to ASDC in both the PRMI and PRFPMI configurations. Next up is to start reducing the CARM offset.
Resetting the REFL demod phases
I have been unable to lock the PRMI for more than teeny blips since Thursday. So, tonight I finally got it to lock with MICH on AS55Q and PRCL on REFL33I, and used that to set the demod phases.
Setting the demod phases, I used an oscillation of 100 cts to PRM, at 400.123 Hz.
REFL 33 demod phase started at 148deg, now 133.2deg.
REFL165 phase started at -105.53, now -172.
No signal in REFL55???? Time series and spectra both look just like noise. Need to check alignment of beam on PD, or if cables unplugged!!
REFL11 phase started at 16.75, now 18.9deg.
Was then able to lock on REFL 33 I&Q, like normal.
Transitioning PRMI from REFL33Q to ASDC
With the PRMI locked on REFL33 I&Q, I found that a MICH offset of -5 counts gives a minimum in ASDC. From my earlier elog this evening (http://nodus.ligo.caltech.edu:8080/40m/10887), I expect the minimum to be at +1.4nm. This is only one point though, so I don't know the calibration of the MICH offset yet (we should get this calib during the day by looking at MICH-only). Anyhow, this informed which side was positive and negative relative to my Optickle plots, so I know that I wanted positive offset in the MICH servo.
I was able to comfortably hold lock at +20 counts. Looking at a calibration line at 143.125 Hz, I determined that I wanted the matrix element for ASDC to be -0.05. After I made that transition using ezcastep, I put the POPDC normalization in. At the time, POPDC was about 151counts, so I put 1/151 in the POPDC->Mich matrix element.
So, here were the final lock parameters. Note that in PRMI-only, you can acquire lock like this, and with a variety of MICH offsets:
Locking PRMI part of PRFPMI
Since the PRMI has been fussy, I'm including a brief note on the PRMI settings when the arms are held with ALS off by roughly 3nm. To get to this point, we just ran the usual carm_cm_up script, and didn't let it run anymore when it asked for confirmation that PRMI was locked.
With MICH offset of -30 counts, AS port is pretty bright. ASDC dark offset is set to -475.4 by the LSCoffsets script. with MICH offset = 0, ASDC_OUT is around 300counts. But, with MICH offset = -30, ASDC_OUT is about 525 counts. So, I put that 525 counts into the ASDC filterbank offset (so it is now the dark offset + this extra offset), so the ASDC offset is currently around -1,000. This makes the ASDC signal roughly zero when I am ready to transition MICH over to it. In principle I should probably set it so the average is the same as the MICH offset, but the noise is so high relative to that offset, that it doesn't matter.
After this, we engaged the CARM and DARM UGF servos. MICH was gain peaking, so I think we might want to turn that one on too, rather than my by-hand turning down the gain.
The transition has been successful 4 or 5 times with the arms held off resonance at 3nm. Once, we reduced the CARM offset as low as 1.7 (and had to lower the MICH gain to 1.5), but we were still hearing a woomp-woomp sound. Not sure what that was from. At this point, Chiara died, so we lost lock. After that, we re-acquired lock a few more times, but MC keeps losing it. We are still able to make the MICH to ASDC transition though, which is good.
The transition won't work if the PRCL UGF servo is not on. The gain multiplier goes from about 1.1 up to 2.4, so the PRCL gain is certainly changing through the transition.
Diego has written up scripts for the individual UGF servos (look for an elog from him separately), so now the carm_cm_up script goes as far as locking the PRMI on REFL33 I&Q, and then it starts to transition. PRCL UGF is engaged, MICH offset is set to -30 counts, MICH is transitioned to ASDC, POP normalization engaged, CARM UGF servo turned on, and DARM UGF servo turned on. There are "read"s in the script before each step, so you can stop whenever you like.
Here's the final configuration for the PRFPMI while the arms are held at 3nm, with MICH on ASDC (so after the transition):
The transition for MICH to ASDC has been successful with the arms held off resonance several times tonight. It's all part of the carm_cm_up script now. I think that if we hadn't lost about an hour of time and our momentum, we would have gotten farther. I have high hopes for tomorrow night!
I'm super excited about this new frequency readback, but I'm not sure that it's reliable yet. Without touching any settings, the readback is currently saying 78.6MHz, and is changing slightly (as is the FSS Slow Temp), so something is working. However, the beatnote as measured on the spectrum analyzer is 158.2MHz. So, either the calibration or the tracking or something isn't quite finished being tuned yet.
It's going to be super awesome when we have this though!!
We tried locking with the variable finesse MICH offset technique again today.
A daytime task tomorrow will be to figure out where we are in MICH and CARM offset spaces. This will require some thinking, and perhaps some modelling.
We were using the UGF servos and checking out their step resonses, and had the realization that we don't want the gain multiplication to happen before the offsets are applied, in the case of MICH and CARM. Otherwise, as the UGF servo adjusts the gain, the offset is changed. I think this is what ChrisW and I saw earlier on in the evening, when it seemed like the CARM offset spontaneously zoomed toward zero even though I didn't think I was touching any buttons or parameters. Anyhow, we no longer used the MICH and CARM UGF servos for the rest of the night. We need to think about where we want the offset to happen, and where we want the UGF servo multiplication to happen (maybe at the control point, with a very low bandwidth?) such that this is not an issue.
Also, I'm no longer sure that the sqrt(I^2 + Q^2) instead of the usual demodulation is going to work for the UGF servos (Q made this change the other day, after we had talked about it). When the numbers going into the I and Q servo banks are small (around 1e-5), the total UGF servo gets the answer wrong by a factor of 10 or so. If I made the "sin gain" and "cos gain" 1000 instead of the usual 1, the numbers were of the order 1e-2, and the servo worked like normal. So, I think we were perhaps running into some kind of numerical error somehow. We first noticed this when we lowered the DARM excitation by a factor of 10, and the servo no longer functioned. We should take out this non-linear math and go back to linear math tomorrow.
During the evening tomorrow, we should try locking the PRMI with a large MICH offset, and then leaving CARM and DARM on ALS, and seeing how far we can get. Is it possible to just jump over to RF signals, since we won't have to worry about the detuned cavity pole?
Tonight, the locking procedure was the same as usual, but stopping the carm_up script before it starts to lower the CARM offset at all. Only difference was that MICH triggered FMs were 2,3,7 rather than the usual 2,6,8.
So, assuming you have the IFO with CARM and DARM on ALS held at +3 CARM offset counts (which we think is about 3nm), and the PRMI is locked on REFL33I&Q with no offsets, here's what we did:
Something else to think about: Should we normalize our DC transmission signals by POPDC, so that the arm powers will change when we change the MICH offset (for a constant CARM offset)?
The best we got was holding for a few minutes at arm powers of 7.5, but since the MICH offset was large and the power recycling was low, this was perhaps pretty far. This is why we need some calibration action.
Also, earlier today I copied the CARM and DARM "slide" filter module screens so that we have the same thing for MICH. Now all 3 of these degrees of freedom have slider versions of the filter module screens, which are called from the ctrl_compact screen.
Life would be easier with the UGF servos working. As Diego already elogged, we aren't sure why the demod phases are changing, but that is certainly causing the I-signals to dip below zero, which the log function can't handle (there is a limiter before the log, so that the signal can't go below 1e-3). Anyhow, this is causing the UGF servos to freak out, so we have not been using them for tonight's locking.
Our goal tonight was to see if we could introduce a nice big MICH offset, and then lower the CARM offset while keeping the arms locked on ALS. We hope to see some kind of sign of a PDH signal in some RF PD.
In the end, the highest we got to was -460 MICH offset counts, which we think is about 29nm (if our rough calibration is accurate). The MICH half fringe should be 188nm. With this offset, we got down to 0.3 CARM offset counts while locked on ALS. We think that this is around 300pm, plus or minus a lot. Note that while yesterday I had a pretty easy time getting to -660 counts of MICH offset, tonight I struggled to get past -200. The only way we ended up getting farther was by lowering the CARM offset. Although, as I type this, I realized that last night's work already had a lower CARM offset, so maybe that's key to being able to increase the MICH offset.
We watched REFL11I and REFL11I/(TRX+TRY) on striptool, but we didn't see any evidence of a PDH signal. We lost lock when I tried to transition CARM over to REFLDC, but I wasn't careful about my offset-setting, so I am not convinced that REFLDC is hopeless.
So. Tonight, we didn't make any major locking progress (the MC started being fussy for about an hour, right after I ran the LSC offsets script, just before we started locking in earnest). However, we have some ideas from talking with Rana about directions to go:
* Can we transition CARM over to REFL11I, and then engage the AO path?
* Then, while the MICH offset is still large, can we transition DARM over to POX or POY, actuating on a single arm? If CARM is totally suppressed, this is DARM-y. If CARM doesn't have the AO path yet, this is halfsy-halfsy, but maybe we don't care.
* Then, can we lower the MICH offset and transition back to a REFLQ signal?
* Separately, it seemed like we kept losing PRC lock due to PRC motion. If the MICH offset is very large, are we sideband-limited at the POP port, such that we can use the POP DC QPD? Is it even worth it?
A single mirror (ITM) moving by lambda/2, in the MICH-only situation is the full range, from bright to dark fringe. So, half fringe should be lambda/4, or about 133nm. If we are thinking about pushing on the BS, there's an extra factor of sqrt(2), so I think the half fringe should be at 188nm of BS motion.
When we had MICH locked on ASDC/POPDC, we put in a line at 143.125Hz, at 20 counts to (0.5*BS-0.2625*PRM), so a total of 10 counts to the BS at 143Hz. Given the BS calibration in http://nodus.ligo.caltech.edu:8080/40m/8242, this is 10.1pm of actuation. We saw a line in the error signal of 0.1 counts, so we infer that the MICH error signal of ASDC/POPDC has a calibration of 94pm/count. This number was invariant over a few different MICH offsets, although the ones I measured at were all below about 100 counts of MICH offset, so maybe this number changes as we start to get farther from the MICH dark fringe.
IFO left flashing (all mirrors aligned except SRM) in case anyone wants fresh data for that.
Something that kind of drives me crazy with our current LSC model setup is that I can't make "finished" error signals before blending them. The blending happens before the normalization matrix, and there is no place to put an offset to help match a new error signal to the current offset. So. While I'm sure this is not going to be immediately popular, here's a cartoon of a proposed model change to the LSC.
The most important difference between this and the ramping matrix that is used at the sites is that you can put in offsets before the blend. Also useful is the fact that the normalization can happen before the blend. This proposal would make the LSC input matrix and the normalization matrix have twice as many rows, and add an extra "selector matrix" just before the triggering at the error point of the loops.
I've only drawn one degree of freedom in my cartoon, but assume that they all have the same capability (maybe we don't have to do XARM, YARM and MC this way). One row is currently being used for the error signal, while the other row is just used to prep a new singal. For a first transition (say, ALS to DC transmission), maybe the ALS signals are on row 1, and the DC trans is on row 2. Once the transition is complete, row 1 is available to prep for the next transition (such as AS55Q).
Thoughts? Is there a better way to achieve what I'm going for here?
I have installed kerberos on Rossa, so that I don't have to type my name and password every time I do an svn checkin, since I'm making some modifications and want to be sure that everything is checked in before and afterwards.
I ran sudo apt-get install krb5-user. I didn't put in a default_realm when it prompted me to during install, so I went into the /etc/krb5.conf file and changed the default_realm line to read default_realm = LIGO.ORG.
Now we can use kinit, but we must (as usual) remember to kdestroy our credentials when we're done.
As a reminder, to use:
> kinit albert.einstein
Password for albert.einstein@LIGO.ORG: (type your pw here)
When you're finished, run
WARNING: since the workstations are all shared user, if you forget to kdestroy the next user can commit under your user ID. It might be good to set the timeout to be something much shorter than 24 hours, like maybe 1, or 2.
Good call. I added a line ticket_lifetime = 3600, which should make it destroy the credentials after an hour.
Okay, it has taken me almost exactly 12 hours (with a dinner break), but I have implemented this change.
Everything was svn-ed before I did things, and then again afterward.
Here is the "before" screenshot of the LSC model:
And here is afterward:
If you look extra carefully, you will see that it matches my proposal from http://nodus.ligo.caltech.edu:8080/40m/10904 . I have made the change for DARM, MICH, PRCL, SRCL and CARM. I did not alter XARM, YARM or MC. Also, the CESAR stuff was taken out of the CARM area, since this is now a more generalized version of the same thing.
I have also checked and modified all of the scripts that I could think of, as well as all of the ifoconfig burt .req and .snap files that I could think of. I also ran the carm_cm_up.sh script once, and it seems to work fine. All of the transition scripts that are listed below (which are the only ones used currently in the sequence) now use the new error signal blending scheme.
Burts (listed are the .req files, but I also checked the .snap files, hand-editing the matrix element numbers where needed if I wasn't in the right config to do a save):
I also modified the screens for the input matrix and for the normalization matrix. I created a new screen for the final blending matrices (which are all 2x1's), and I also modified the LSC_OVERVIEW screen.
The input matrix and normalization matrix screens have colored bars that tell you whether a row is in use or not. If the background to the row is the blue of the whole screen, that row is not being used.
The LSC screen has new hand-modified Kissel Buttons. I wanted to show the total PD error signal that is being used, regardless of what row (A or B) it is on at that time. So, I have collapsed the rows so that DARM_A and DARM_B are overlapped, even though they are actually rows 1 and 2 of the matrix. The PD should only show up green on the LSC screen if that row is in use (so, if you are prepping a row, but aren't using it yet, you won't see those elements in the matrix). Anyhow, the point is that the LSC overview part of things shouldn't look any different than before.
Brain not working anymore now that it's ~4am, but I need to rethink and recheck to make sure that the PD whitening triggering is still okay and working. Or maybe we can remove it, and just include that in the scripts, as Rana has been suggesting for ages. Thoughts for tomorrow.
Have we been running the PMC autolocker lately? I can't remember, and I also can't find where it might be running. It's not on megatron, either in the crontab or Q's new /etc/init place. It's also not on op340m.
Anyhow, what prompted this was that the PMC transmission has been incredibly fuzzy today. On the StripTool it looks like it was fine until about -7 hours ago, when it lost lock. Then Diego relocked it around -3 hours ago, and it's been fuzzy ever since. It was unlocked again for about 15 minutes about 45 minutes ago, and when I relocked it, it was even more fuzzy.
The FSS slow is almost exactly zero, the PMC's PZT is not at the edge of the range, the FSS PC drive RMS has been both high and low, and the PMC fuzz level has just been consistently high. I was checking the parameters in the PMC phase shifter screen, and looked up the autolocker to see what the nominial values are supposed to be.
For the RFADJ value, the autolocker sets it to 2.0, and after it locks increases it up to 4.5. I found the value at 2.0, and the autolocker isn't running, which made me wonder if the autolocker died sometime after it set the value low, but before it could detect lock and reset the value to high. (Actually, after lock it sets the value to whatever is in the channel C1:PSL-STAT_PMC_NOM_RF_ADJ, which is 4.5).
Anyhow, I manually set the RFADJ value to 4.5, and the PMC transmission immediately improved.
EDIT, 8pm, JCD: Rana reminded me that he attached a screenshot back on 30Dec2014 (http://nodus.ligo.caltech.edu:8080/40m/10849), which I had ignored earlier because the parameters weren't written in text. My bad. Anyhow, after the New Year's tune-up, the RFADJ should be 6.0. I have set it so, and also changed the C1:PSL-STAT_PMC_NOM_RF_ADJ chan to be 6.0.
Nope, I used the script.
Yesterday's changes were mostly to the generateLSCscreen/C1LSC_OVERVIEW_INPUT_MATRIX.adl sub-screen. The UGF servos were added earlier in the week to the LSC screen in the generateLSCscreen/C1LSC_OVERVIEW_SERVOS.adl sub-screen.
I have been playing with the IFO tonight. Mostly, I wanted to make sure that all of the scripts for the carm_cm_up sequence were working, and they seem to all be fine.
I also turned on all 4 UGF servos. My big ah-ha moment for the night is that the excitation is multiplied by the gain multiplier. This means that if the UGF servo is multiplying by a small number (less than 1), the excitation will get smaller, and could get small enough that it is lost in the noise. Now the error signal for the UGF servo is very noisy, and can dip to zero. Since we can't take the log of zero, there are limiters in the model, but they end up giving -80dB to the error point of the UGF servo. This makes it all freak out, and often lose lock, although sometimes you just get a weird step in the UGF servo output.
Anyhow, we need to be mindful of this, and offload the UGF servos regularly. I think the better thing to do though will be to divide the excitation amplitude by the gain multiplier. This will undo the fact that it is multiplied by that number, so that the number of counts that we put into the excitation amplitude box is what we expect.
LSC whitening triggering was not working, because of the implementation of the double-rows for the input matrix. I have modified the c-code that looks at the input matrix and triggers, and decides when to turn on the PD whitening, so that it now works.
I made little scripts to go with the sus driftmon buttons, that will servo the alignment sliders until the susyaw and suspit values match the references on the driftmon screen.
The Xarm ALS has been a little funky today.
First, the green and the arm-axis would not stay co-aligned. I'm not sure which was moving (although neither ITMX nor ETMX seemed to be moving very much according to their oplevs and OSEMs). I went to the Xend table and jiggled the mounts for the steering optics, in case one was loose or something. None were. However, the transmission quit jumping around by a factor of 2 after that. The beatnote alignment on the PSL table was also bad, so I tweaked that alignment up for the Xarm. There were some not connected cables and fibers blocking the access to the X beatnote area, so those are up on top of the PSL table.
Anyhow, I haven't locked the individual arms, but I cannot hold the lock with CARM/DARM. The CARM output keeps hitting the threshold for the locking watchdog, which turns off the lock. Obviously I could just increase this threshold, but the right thing to do is figure out why the Xarm ALS is so noisy today, and why it wants to output such a large control signal to maintain the lock.
This problem with the CARM loop last night was the fault of a bug that I had put into the LSC model last week. When I gave the input matrix and normalization matrix double rows, I had put the goto tags for the CARM normalization matrix rows backwards. So, even though I thought I was not normalizing CARM, in fact I was normalizing by POPDC, which was near zero since the PRM was misaligned.
Anyhow, found, fixed, currently locking, and all seems well.
Tonight we worked on the acquisition sequence (including re-re-re-commissioning the UGF servos, hopefully for the last time...) for the PRFPMI with large MICH offsets.
The procedure is all in the carm_up script, as far as things work.
We had some locklosses, but they were mostly due to non-carefulness on my part during the transitions between error signals, or the UGF servos getting upset because the oscillator peaks had gotten lost in the noise. The one that I show here is our very last one of the night, where we are hitting the rails for the MICH signal, which is then causing the other loops to have to do weird things to try to compensate, and they lose lock.
Here also is a StripTool shot during that lock stretch. I was in the middle of increasing the MICH offset to 75% of the fringe. The yellow trace (called MICH_B_MON) is ASDC/POPDC normalized so that it always goes 0-1. I was pleased to see that perhaps REFL11I and AS55Q are turning over, although as Q will tell us in a more detailed elog tomorrow, having a large MICH offset does weird things and moves the DARM zero-point. So, maybe we aren't actually anywhere awesome yet.
After some MICH offset, the maximum arm power is always going to be about 50, so arm powers of 8 or 10 equates to 100 pm. We didn't get there tonight while on IR signals.
The locking sequence is now something like this:
After this, we tried a few times to lower the CARM offset, but kept losing lock, I think because the UGF servos went crazy. The final lock, shown above, we lost because the MICH output was hitting the rails.
The problem with the MICH servo right now is the low SNR of the POPDC being used to normalize ASDC. The control output is enormous, even if we have the 400Hz lowpass on. We need to rethink our MICH servo, starting with a lower UGF, so that we're not injecting all this sensing noise all over the place.
One of tonight's goals was to tweak the CARM filters, so that we could engage the lowpass filter, to avoid the detuned double cavity pole resonance disturbing the CARM loop.
I increased the Q of the zeros in the FM3 boost so that it eats fewer than the original 18 degrees of phase at 100 Hz. We kept losing lock though, so for each lock I backed off on the Q a little bit. In the end, the filter eats 9 degrees of phase at 100 Hz. I also moved the lowpass from 700 Hz to 1kHz, although that doesn't change the phase at 100 Hz very much.
We modified the carm_up script re: PRMI locking a little bit. The PRMI is not so enthusiastic about locking immediately at 25% MICH fringe, so I backed that off. It now acquires lock at a few percent, and then ramps up the offset. Also, the MICH FM6 bounce roll filter is now turned on after lock is acquired, effectively giving it an extra second or two of delay beyond the rest of the filters.
We were able several times to get to some MICH offset and turn on the lowpass filter, but starting to reduce the CARM offset makes us lose lock. I think the problem is that the UGF servo demod phase is changing as we are changing offsets, filters and error signals. We see that the I-phase is servoed successfully to 0dB, but that the Q-phase is starting to move around by 30 degrees or more. We either need to monitor this much more closely, and add the changing demod phases to the carm_up script, or we need to go back to the sum-of-squares situation that we had last week. Note that we saw failures with that method for a completely separate reason: we were getting too close to the limiters, which cause the UGF servos to glitch and the outputs jump by a significant amount. So, the issues that we were seeing last week when we had the sum-of-squares were a different thing, that we noticed and understood later.
Anyhow, nothing too exciting and glorious tonight, but progress has been made.
Also, from some Mist simulations that Q did, Diego made a sweet plot that is now posted in the control room, so we can translate arm power to CARM offset, at various MICH offsets.
We also took some CARM loop measurements with the new filters. We have a little more phase than we used to, which is nice. These traces don't have the lowpass engaged, since I was trying to see how far we could get without it. We lost lock right after the second measurement, but I think that was to do with the UGF servos.
So, I neglected to elog this yesterday, but yesterday we had one of those EPICS freezes that only affects slow channels that come from the fast computers. It lasted for about 5 minutes.
Right now, we're in the middle of another - it's been about 7 minutes so far.
Why are these happening again? I thought we had fixed whatever was the issue.
EDIT: And, it's over after a total of about 8 minutes.
A small change, but now the carm_up script supports both sides of the CARM offset. After the arms are locked with ALS it asks for a "+" or a "-", which indicates which sign of digital CARM offset will be added. In the past, we have been primarily using the "+" sign.
I have just put the seismometers back into their nominal positions, on the concreted slabs. The T-240 is in the vertex, and the 2 Guralps are at the end stations.
The vertex location doesn't have a spaghetti pot right now. There is an aluminum support for cable trays that is welded to the supports under the beam tube that is in the way. The pot looks like it will fit barely, if it were slid totally horizontally into place. However we can't do that with the seismometer in place. I'll chat with Steve this afternoon about our options.
Since I don't know that we are planning on ever putting a cable tray on the inside of the beamtube, perhaps we can cut ~6 inches of this piece away.
I had a look at the OAF model today.
Somehow, the screens that we had weren't matching up with the model. It was as if the screens were a few versions old. Anyhow, I found the correct screens in /userapps/oaf/common/medm, and copied them into the proper place for us, /userapps/isc/c1/medm/c1oaf. Now the screens seem all good.
I also added 2 PCIE links between the OAF and the SUS models. I want to be able to send signals to the PRM's pitch and yaw. I compiled and restarted both the oaf model and the sus model.
The OAF model isn't running right now (it's got the NO SYNC error), but since it's not something that we need for tonight, I'll fix it in the morning.
My thought for trying out the OAF is to look at the coherence between seismic motion and the POP DC QPD when the PRMI is locked (no arms). I assume that the PRM is already handled in terms of angular damping (local and oplev), so the motion will be primarily from the folding mirrors. Then, if I can feedforward the seismometer signal to the PRM to compensate for the folding mirrors' motion, I can use the DC QPD as a monitor to make sure it's working when we're PRMI-only locked, or at low recycling gain with the arms. But, since I'm not actually using the QPD signal, this will be independent of the arm power increase, so should just keep working.
Anyhow, that's what my game plan is tomorrow for FF. Right now the T-240 is settling out from its move today, and the auto-zero after the move.
We did a series of small things that may have helped with the locking, although we didn't actually get anywhere closer in CARM offset.