thomas.vo@LIGO.ORG - posted 08:54, Wednesday 22 January 2014 - last comment - 10:30, Wednesday 22 January 2014(9424)
Justin in LVEA @ 8:54 AM PT
Transitioning to laser safe.
Transitioning to laser safe.
Electronics testing.
TMS Cabling
Done at 3:55 PM PT
Turns out the 6dBm readback from the FIBR_A broadband PD was due to an oscillation of the noise eater at ~1MHz. Toggling the noise eater servo fixed the problem. Since the normal PLL beat note is at the -7dBm level, we should be able to use this as a noise eater oscillation monitor.
Did an SVN clean up of the slow Controls directory, and an update. (apparently this happens when svn update fails) Made new bootprojects for all three PLCs. Restarted the computer, PLCs seem to be running the current version of the code, but I couldn't caget anything on the beckhoff machine (channel not found). Restarted the EPICS database twice, and now I can caget locally, but I get zero when I can see in the PLC that the channel is not zero.
Problem solved by renaming the target directory (same effect as deleting it) and starting from scratch with the install scripts)
Now the PFD says it is getting 6 dBm input, this doesn't make any sense so we are headed down the X end.
I did the coil gain balancing on the M2 and M3 stages of PRM. Here are the results:
%% M2 stage
H1:SUS-PRM_M2_COILOUTF_UL_GAIN -0.961
H1:SUS-PRM_M2_COILOUTF_LL_GAIN 1.012
H1:SUS-PRM_M2_COILOUTF_UR_GAIN 0.987
H1:SUS-PRM_M2_COILOUTF_LR_GAIN -1.039
%% M3 stage
H1:SUS-PRM_M3_COILOUTF_UL_GAIN -0.999
H1:SUS-PRM_M3_COILOUTF_LL_GAIN 0.985
H1:SUS-PRM_M3_COILOUTF_UR_GAIN 1.015
H1:SUS-PRM_M3_COILOUTF_LR_GAIN -1.001
I used the same technique as Keita did for BS (see alog 9080), although WFS_REFL_B_LF was used in stead of an oplev because PRM doesn't have its own oplev.. In addition to it, because the WFS signals are not connected to the suspension LOCKINs, I simply used diaggui to check the amplitude of the excitation line. The excitation was introduced by the LOCKIN OSC with an amplitude of 500000 and 200000 counts for the M3 and M2 stages respectively. The frequency was at 4.1 Hz for both cases.
I've captured and committed a new safe.snap for h1susprm, such that these values remain for all time. (Note, I'd paused the excitation that is on-going with PRM to turn off all LOCK filters, alignment offsets, and master switch as per the standard configuration, but things were only off for a few minutes during one, many minute, average of the TF so it should not affect the results significantly.)
I launched a L2P(Y) transfer function measurement on PRM and BS.
The coil gains for the M2 stage of BS were set back to the ones Keita set on 24th of December (see alog 9079):
Before I changed these numbers they had been:
Therefore all the BS actuators on the M2 stage has now different sign. We should remember this, especially when locking the Michelson. I have no idea of why we kept using these funny +/-1 things instead of the balanced coil gains.
PR2 is intentionally misaligned to avoid a fringe showing up in REFL_WFSs. PRM is slightly misaligned on purpose to have the reflected light centered on REFL_WFS_B.
Currently PRM is at:
Its good aligment to get PRMI fringe is
Both TF measurements are running on opsws1.
I've captured new safe.snap for the BS such that these values are stored permanently.
S. Ballmer, J. Kissel The setup for the beam splitter transfer function was invalid, because the off-diagonal elements of the DRIVEALIGN matrix (i.e. filters for we're trying to re-measure the design data) were still on. We've also noticed that the coherence below 0.5 [Hz] is still poor. I'm going to re-tune the low frequency drive with higher amplitude drive for a bit, and then re-launch the measurement in the appropriate configuration.
oops!
NOTE:
The short was actually between pin 1 & 23.
Kiwamu, Stefan We locked the PRMI on the sidebands today. The locks lasted for about 1min at a time. Lock acquisition is still slow, so more work is needed. The first lock started at UTC 2014 Jan 22, 01:59:42, and lasted until 02:00:25. There were several additional locks after that. Attached is a large screen shot with all relevant screens. We managed to get a preliminary OLG measurement for PRCL, the UGF seems to be around 55Hz (plot attached.) We were not successful with a MICH OLG measurement yet. Finally, attached is also a plot of error and control signals for the two loops.
It seems that the pitch motion in PRM and PR2 is excited a lot during the acquisition and this prevents us from a smooth and quick lock.
In fact, when I enabled the LSC output after the pitch motion of PRM and PR2 settled down, it often locked within 5 sec. However, when their pitch rang up to more than 1 urad in RMS, locking became extremely difficult -- it catches a fringe approximately once per 5-10 minutes. Also, it seems to me that the unlock events were more or less initiated by the pitch fluctuation. See an example in the attached.
I restarted the end X beckhoff machine a few minutes ago (first it had the run time error not found error, then I tried to do an SVN update and was unable to connect to the repository, even though I could see the repository using firefox. Dave was able to check the snv status, and everything seems to be locked.) After restarting none of the variables were being exported, even on the beckhoff machine I could not caget them although the PLCs seemed to be running as well as the IoC. After using the install script to restart EPICS database, the variables seem to be exported, but they are not correct (for example, in the PLC, I can see that H1:ALS-X_FIBR_LOCK_FIBER_POLARIZATIONPERCENT is 17, but if I caget on the beckhoff machine it is zero. Also, values that I enter on medm screens do not make it into the beckhoff machine.
I think that I have found the beat note between the single shot beam and the PSL doubled light on ISCT1, right now it is at -49dBm, (nothing has been optimized) I wanted to confirm this is it by unlocking the X end PLL and seeing it move in frequency, but that is not possible without the end TwinCAT.
In order to ensure that the ODC bits are sending valid reports, I've visually confirmed the status of each subsystem module mentioned below. The ODC is currently reporting a happily locked mode cleaner and I confirm this is true. The goodness has been going on for a while now (as Stefan and Kiwamu are trying to lock the PRMI), but officially, we can say the goodness has been on-going since Jan 21 2014 6:00pm PST (Jan 22 2014 02:00:00 UTC, GPS 1074391216).
DetChar bonus tasks:
- Post performance ASDs of all the components mentioned below as a comment. I wanna see what "good" looks like for these systems.
- We should also be able to use tonight as an average reference ASD for recoloring the IMC_F / IMC_L data in to fake DARM.
- Show me spectra of the coil driver noise monitor channels. Show me what a "normal" coil output voltage ASD is for each of the driver stages. Let me know if there are any DAC saturations.
- For the IMC ODC, trend the H1:IMC-MC2_TRANS_SUM_OUTPUT, H1:IMC-IM4_TRANS_SUM_OUTPUT channels (which feed into ODC bits 10-13). Tell me where they average, and what the peak value is on the ~minute time-scale. Find out from the IO group what the expected power budget is from POWER IN to MC2 TRANS SUM, and from POWER IN to IM4 TRANS SUM, so we can stick that into the [W/W] gain and have these bits' thresholds be calibrated.
During this time there was no excitation on anything mentioned below.
IMC: IMC Locked, IMC WFS control ON, spitting out clean 00 mode light.
ODC bits all green (0-13), bits 2-9 masked out (see LHO aLOG 9373), summary bit (bit 0) and bit 10 are masked out (why?)
HAM2:
HPI: well-performing, well-aligned to target values. Level 1 isolation filters, position-sensor-only ("Pos") blend filters.
ODC bits all green (0-3), but summary bit (bit 0) is masked out (why?).
ISI: well-performing [BLRMS lights are mostly green, with some yellow in upper-left corner], well-aligned to target values. Level 3 isolation filters, with "01_28" blend filters.
ODC bits all green (0-4), but summary bit (bit 0) is masked out (why?).
MC1: IMC locked, IMC WFS control ON, locally damped and aligned
ODC bits all green (0-7) are green, but summary bit (bit 0) is masked out (why?).
MC3: IMC locked, IMC WFS control ON, locally damped and aligned
ODC bits all green (0-7) are green, but summary bit (bit 0) is masked out (why?).
HAM3:
HPI: well-performing, well-aligned to target values. Level 1 isolation filters, position-sensor-only ("Pos") blend filters.
ODC bits all green (0-3), but summary bit (bit 0) is masked out (why?).
ISI: well-performing [BLRMS lights are mostly green, with some yellow in upper-left corner], well-aligned to target values. Level 3 isolation filters, with "01_28" blend filters.
ODC bits all green (0-4), but summary bit (bit 0) is masked out (why?).
MC2: IMC locked, IMC WFS control ON, locally damped and aligned
ODC bits all green (0-7) are green, but summary bit (bit 0) is masked out (why?).
I don't imagine I'll get the chance tonight, but if possible I may put these components in various *bad* states tomorrow, to check that the ODC properly reports as such.
Q: "summary bit (bit 0) is masked out (why?)" A: The summary bit will always appear grey in the 'Mask' portion of the ODC MEDM screens because it is not used in the summary bitmask. The bitmask defines which bits are checked in order to determine whether the summary bit should be turned on, if you were to include the summary bit itself in that check then the bit would never be activated. If this is a cause of confusion, we can remove the summary bit from the bitmask identifier on the MEDM screens.
ASD of IMC-F at this time (psd.png) ASD of HAM2 ground sensor at this time (psd_ground.png)
I've played with the ISI-ETMX to reduce the excess motion seen in pitch and longitudinal at the suspension point by the ISC group (see Sheila's log).
I've tried different configurations (see plot attached). In all these configurations, HEPI is controlled in position.
I was able to get some improvement, especially in longitudinal. The key was to blend with the T240s to avoid the extra sensor noise coming from the L4Cs at low frequency. We could blend lower, using Ryan's blends (blend frequency at 40mHz). I've been having some troubles with them, but I'll try that again tomorrow.
Even if HEPI-ITMX is not controlled, I've tried the same thing and ended up with the same kind of results. I'll do a more complete post about that later.
To finally to begin putting non-CDS, useful interferometer diagnostics (band-limited RMS of seismic motion, glitch-grams, inspiral range [when we have one]) onto the wall monitors in the control room, I had to first learn how. Here's how you do it:
From a machine running OSX (e.g. the operator2 station on the right-hand side of the operator's workstation):
- Click on a blank space on the desktop, to switch to the "Finder" toolbar along the top.
- Either
- Select the "Go" drop-down menu
- Select "Connect to Server"
Or
- Use the "Command + K" keystroke
- enter in the server
vnc://video#
where # is a number from 0 to 6, representing each vertical pair of monitors around the room.
This opens up a screen sharing desktop akin to what you see on the wall.
It should have all the same functionality as the OSX workstation from which you've started.
I was also climbing around on top of HAM2 and the IMC Spool for a brief period.