[ChrisW, Stefan, Sheila, Kiwamu]
Alignment pf PR2 and PR3:
As advertised yesterday, indeed we were close to a good alignment. Although we got confused by the BS camera, we managed to find the fringe by steering PR2 with PR3 continuousely scaning in yaw by AWG at 0.3 Hz. The vertical alignment looked OK from the beggning and we had to mainly tweak yaw. Afte we found it, we simply maximized the amplitude of the REFLAIR_A_RF9 signals. Note that the spot motion looked quiet today as all the ISIs were on.
Locking settings:
sensor = REFLAIR_A_RF9_I (whose phase was adjusted to be 10.0 deg)
actuator = PR2
details = see the screenshot below
Mysteries and issues to be solved:
Just prior to this evening's DAQ restart at 21:04, h1fw1 froze up again with disk issues at 21:01. Similar to this morning's problem, the file system appears to exist but files cannot be fully formed.
I tried at remote reset of h1ldasgw1, but that did not proceed. Chris went into the MSR and looked at h1ldasgw1's console, it had gotten stuck in the shutdown sequence with disk issues (not surprisingly). He power cycled the Sun box using the front panel button and it did reboot. I was able to log in remotely but could not get the QFS/SAMFS file system to mount. I got the error
root@h1ldasgw1:~# mount /cds-h1-frames
mount_samfs: Configuring file system
mount_samfs: Enabling the sam-fsd service.
mount_samfs: Adding service tags.
mount_samfs: Filesystem "cds-h1-frames" not found.: No such file or directory
so unfortunately we will have to limp along with just h1fw0 for this evening. Since h1nds1 is the default NDS, for archived data the control room will have to use h1nds0 instead.
later remount attempt gave more information
root@h1ldasgw1:~# mount /cds-h1-frames
mount_samfs: Configuring file system
Device /dev/dsk/c0t6000402003F466D66444B7EB00000000d0s0 not found.
Device /dev/dsk/c0t6000402003F466D66140BDCD00000000d0s0 not found.
Device /dev/dsk/c0t6000402003F466D66140BDDB00000000d0s0 not found.
Problem in mcf file /etc/opt/SUNWsamfs/mcf for filesystem cds-h1-frames
sam-fsd: Problem with file system devices.
Powering the illuminator on BS (LVEA ) – Richland End Y transitioned to LASER HAZARD (Fiber welding work) – Doug Guardian IMC autolocker now running (see alog # 8942) - Jameson Restart of h1fw1 – Dave DNS Server work - James
I have changed the default nds server back to h1nds1. This will be effective with new shells or processes.
(Alexa, Daniel)
With the gain setting at 0dB for the external PD:
Transimpedance = 2kOhm
Ext PD Monitor = 1.28V
Beckhoff readback = 5.17V (there is a 4x gain between the monitor and controls output)
If the external PD is a silicon diode (responsitivty = .25A/W), this implies that we have 2.6mW on the diode. Alternatively, if we believe that we have ~1mW on the diode as referenced in alog, then the responsitivty of the diode is closer to .64A/W, which resembles that of an in-gas diode. The former is more likely. **** Next time someone is in the PSL, can you please measure the power into the diode?
Meanwhile, I also confirmed that the gain setting on the ALS fiber distribution chassis is as expected. At the ext. PD input, I read -5.0V. Placing 100kOhm resistor at the input provides 50uA of current. Thus, one expects to read V=(50uA)(2kOhm) = 100mW at the ext PD monitor, which I verified. This is consistent with the test report for this chassis, which confirmed 3.13V at 30dB with 50uA. The factor for 30dB gives a factor of 31.26 in V.
Conclusion: ALS fiber distribution is okay. Diode is different than expected or we have more power ...
Starting at around noon, the QPD servos at end Y are running, we will leave this alone for about a day, then turn off a cleanroom to see if we have a repeat of the alingment drifts seen in end Y.
Before starting I moved the TMS with the QPD servos locked, here are the responses in the PZT sensors and outputs:
Moving the TMS in yaw moves the PZT pit, and vice versa
sensor mV/ urad TMS yaw | output counts/urad TMS motion yaw | sensor mV/urad TMS pit | output counts /urad TMS pit | |
PZT1 pit | -2 | -6.8 | 0.2 | 1.3 |
PZT2 pit | 0.1 | 4.12 | 0.56 | 2.07 |
PZT1 yaw | -22.9 | 7.26 | 0.594 | 1.39 |
PZT2 yaw | -1.59 | 5.43 | -.79 | -2.1 |
for reference the times are:
nominal TMS positions PIT -3urad, Yaw -297urad UTC 18:45:35
PIT -3 urad YAW -197 urad UTC 18:50
PIT -103 urad YAW -297 UTC 18:54:51
transissioning to level 2 I get
Isolating 4 dofs: X Y RZ HP
Using filter module(s): H1:HPI-BS_ISO_X H1:HPI-BS_ISO_Y H1:HPI-BS_ISO_RZ H1:HPI-BS_ISO_HP
Isolation level: 2
Starting gain ramp...
Time::HiRes::sleep(-0.451209): negative time not invented yet at /opt/rtcds/userapps/release//hpi/common/scripts/HPItool2.pl line 516.
And then the script stops, without runing on X, Y, RZ and HP.
Additionally, I noticed that a lot of these HPI turn-on scripts don't actually move to the set target position, but instead just throw a warning, asking for a manual move. This seems like an alignment time bomb that will get us sooner or later.
Initial restarts of daqd on h1fw1 did not fix the problem. The framewriter ran for about 10 mins and then its uptime counter stopped incrementing.
I power cycled h1ldasgw1, and had to manually remount the QFS file system and NFS export it. I then restarted h1fw1 and it has been running for about 20 mins now.
(Keiko, Chris)
The h1asc front end is now running with the latest version of the model. The previous version had been copied from L1 by Kiwamu back in May. Since then an Initial ALignment (IAL) system for the arm cavities (a dither scheme using the ALS green light) was added to h1asc by Stefan, but no other significant changes were made. Meanwhile the ASC model has been actively developed at LLO. Our goals were to update this model to track all the LLO changes, to merge in the IAL subsystem, and to start using library parts (which make it easier to verify that the LLO and LHO models are in fact the same).
Here's what's new:
The IMC is now fully under guardian control. The guardian components are (given by their full guardian identifier):
The paths listed are the fulls paths to the guardian system description modules that are being executed for each guardian process. Given a system identifier
The IFO_IMC manager is the top level control. It instructs SUS_MC2 and ISC_IMC to go to their ACQUIRE states if the IMC is not locked, and then transitions SUS_MC2 to turn on boost filters after ISC_IMC guardian reports that the IMC lock has been achieved. If ISC_IMC looses lock, IFO_IMC sees this and moves SUS_MC2 and ISC_IMC back to their ACQUIRE states.
The primary interface for controlling the processes is their medm screens, which are accessible from the "GRD" menu in the sitemap:
The REQUEST button selects the requested state of the system. The MODE button selects the operational mode of the guardian process. EXEC indicates that it is executing guardian code. The STATUS reflects the guardian process status. In this case, the IFO_IMC guardian is executing the RUN method of the LOCKED state.
The buttons at the upper right allow for displaying the log of the daemon, displaying the current system graph, and editing the underlying system module code.
All three guardian processes are running under the new guardian control infrastructure on h1guardian0:
controls@operator1:~ 0$ guardctrl list IFO_IMC * run: IFO_IMC: (pid 8739) 7805s, want down; run: log: (pid 13060) 78412s ISC_IMC * run: ISC_IMC: (pid 6400) 9332s, want down; run: log: (pid 1346) 66758s SUS_MC2 * run: SUS_MC2: (pid 2208) 66732s, want down; run: log: (pid 2050) 66737s SUS_SR2 * run: SUS_SR2: (pid 32679) 96154s, want down; run: log: (pid 23722) 230173s controls@operator1:~ 0$
The guardctrl
command line interface can be used to start/stop/restart the daemon process, as well as create new ones as needed.
Some immediate todo task for the next week:
There are also an ever-growing list of guardian bugs (not a bad thing at this point, since it means the system is actually being used now) that I will start filling in in the new guardian bugzilla (thanks Jonathan).
All the locking code guardian modules has been committed to the userapps repo at:
/opt/rtcds/userapps/release/ioo/common/guardian/ISC_IMC.py /opt/rtcds/userapps/release/sus/common/guardian/SUS_MC2.py /opt/rtcds/userapps/release/sus/common/guardian/SUS.py /opt/rtcds/userapps/release/sys/common/guardian/IFO_IMC.py
The guardian and cdsutils versions are:
cdsutils and guardian are installed in their proper places in /ligo/apps/linux-x86_64/
I calculated the spot centering on the IMC mirrors, with help from Kiwamu and Jax (alog #6676).
All beam spots are with 2.3mm on center on all 3 mirrors, which is slightly better than what Jax measured in June.
Beam Centering Measurements: 12/12 | P2L/Y2L gain | smallest peak amplitude | EL/EP | alpha | alpha in % | distance from center of mirror, in mm |
0.25/5.2382 | (EL/EP)*P2L/Y2L gain | % * 0.375 | ||||
MC1 | ||||||
P | -0.90 | 0.05 | 0.048 | -0.043 | -4.3 | -1.6 |
Y | 0.60 | 0.30 | 0.048 | 0.029 | 2.9 | 1.1 |
MC2 | ||||||
P | -1.30 | 0.05 | 0.048 | -0.062 | -6.2 | -2.3 |
Y | -1.00 | 0.50 | 0.048 | -0.048 | -4.8 | -1.8 |
MC3 | ||||||
P | 0.85 | 0.12 | 0.048 | 0.041 | 4.1 | 1.5 |
Y | -1.10 | 0.05 | 0.048 | -0.052 | -5.2 | -2.0 |
I'm revisiting beam centering measurements, and have recalculated the beam centering logged here, based on my enhanced knowledge, and with both the procedure used in 2013 and in 2017.
My sign conventions in this 2013 alog are incorrect, and I'm now correcting them, and posting values using both the 2013 and 2017 procedure.
In 2013, though it's not stated, I used the Eul2OSEM values that match the UR OSEM, which matches the procedure I used in 2017, alog 34973
Updated Results (details in attached pdf):
I have changed the default nds server to h1nds0 until we can sort out what is wrong with h1fw1. Note that this only affects newly opened shells and newly started programs. Also note that h1nds0 does not offer the same set of channels, it is set up to write science frames instead of commissioning frames. I will change the default back to h1nds1 as soon as h1fw1 is functional.
[Filiberto, Keita, ChrisW, Arnaud, Kiwamu]
We steered PR2 to get the beam on the center of PR3. Now we can see a beam hitting somewhere in the BS chamber. This beam spot appears to be the dark port beam.
Then one time, we were able to make the PR-Y cavity flash, but after some time of damping works, we lost it and never found it again. Tomorrow we are going to try a more systematic alignment. The attached is the alignment from the time when we saw fringes.
HAM3 spool Camera:
We first tried GigE cameras to look at the front surface of PR3 from the HAM3 spool position. This didn't work. The cameras were not so sensitive enough to resolve weak light. Then we removed a GigE and installed an analog camera on the 0 o'clock position on the spool. This then allowed us to see a spot on the PR3 cage as well as the swiss cheese baffle. We locally hooked up a monitor on the floor.
Later, Keita told me that it could be much more sensitive if we changed a gain in medm.
PR2 steering:
In the process of steering PR2, I found that PR2 kept tripping its watchdogs. It was due to the OSEMS hitting the open light threshold. I had to offload the alignment biases to IM3 and IM4 to mitigate this issue. The offloading worked well -- I was able to steer the beam onto PR3 while keeping the beam on both IM4 trans and POP_A. Unfortunately POP_B lost the beam but the recovery should be easy as we still have the beam on POP_A. The centering on PR3 was good in yaw and OK in pitch. I used scattered light from the lower part of the cage for aligning yaw and used the baffle to align the beam height. Also, PRM was aligned to obtain the retro-refletion back to PSL.
We got PR-Y flashing, but the spot seemed moving a lot:
Then we started steering PR3 by looking at the BS camera. The idea is to align the PR-Y cavity without wildly touching BS and ITMY which are thought to be a reference. Since I couldn't find a power cable for the illuminator on BS, the BS camera view has been simply dark. At some point, we found a moving spot out of this dark monitor. Because this spot responds to the angle of ITMY and BS, we believe this was the dark port beam which is now hitting somewhere in the BS chamber. By a yaw scan in PR3, we started seeing fringes in POP_A_SUM and REDL_A_LF. POP_A_SUM could go up to 10 counts when flashing while it is 5 counts nominally. However, the fringes didn't look stable -- sometime it didn't flash at all and sometime it flashed a lot. We suspected that something was moving and indeed PR3 was moving the spot position a lot. This was visible in the BS camera when we introduced an intentional offset in PR3 in yaw. The spot was moving vertically at about 1 Hz with an amplitude of approximately three beam sizes. Chris investigated why PR3 wobbled so much and eventually found that turning the HAM2 ISI on at level 3 made it quitter. After the investigating, we restored PR3 back. However we became unable to find the fringe any more. It is unclear what happened.
We also fully turned back on ISI and HEPI of ITMY and BS, which notably reduced the beam motion seen on the BS camera . The configuration of both systems was set to the one described by Hugo in his alog 8860. We increased the threshold of the T240 watchdogs for ITMY ISI to avoid the system to trip on the T240 when starting the loops. For the BeamSplitter ISI, we had to exclude the T240 out of the loop to turn it on. We then lowered the blends and included the T240. The isolation was turned on independentely for both stages of each ISI.
This is a picture of the HAM3 spool camera that looks at the front surface of PR3 through the swiss cheese baffle.
The green circle in the picture indicates the scattered light off of the upper side of the PR3 cage. This is the original position before we started aligning anything.
- Corey to EY - Gerardo to BSC2 for camera work - Keita/Filiberto input spool camera - Justin, card access changed - doors now lock - Richard to EX for fiber - Dale tour at 11AM - praxair delivery - Mounts Lock here to work on doors - Townsend Elect. on site - EY - alignment then welding - Jamie - guardian work on IMC locking
Card access not changed; door closing mechanisms adjusted.
As noted in alog6341, the gain on the Dual PD Amp board was set to 30dB (photo 1). I have reduced the gain to 10dB (photo 2). However, I still see saturation at 10V in the external PD monitor. Tomorrow I will try reducing the gain to 0dB.
I have reset the internal PD gain to 30dB (since we were never saturating there), and set the external PD gain to 0dB.
For the external PD:
Transimpedance = 20kOhm
Responsivity = .268A/W
Power @ ext PD = 0.93mW (w/ a drift of 7% of the ref cav alignment)
Gain = 0dB
Volts = (resp) x (power) x (trans) x (gain) = 5V
...Ignore above calculation for external PD...