40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 322 of 326 Not logged in
ID Date Author Type Category Subject
16086   Mon Apr 26 18:55:39 2021 Anchal, PacoUpdateSUSMC2 F2A Filters Tested

Today we tested the F2A filters created from the DC gain values listed in 16066.

Filters:

• For a DC gain $G_{DC}$ required for balancing the coil at DC and $f_0$ being the resonance frequency of the mode (POS in this case), we calculate the filter using:
$\frac{1 + i \frac{f_z}{f Q} - \frac{f_z^2}{f^2}}{1 + \frac{f_0}{f} - \frac{f_0^2}{f^2}}$where $f_z = f_0 \sqrt{G_{DC}}$.
• Attachment 1 shows the motivation for choosing the resonant frequency in the formula above. It makes gain at DC as $G_{DC}$ while keeping AC gain as 1.
• Attachment 2 shows the transfer functions of the filters uploaded.
• Filters are named Eg2CtQ3, Eg2CtQ7 and Eg2CtQ10 for Q=3,7,10 filters respectively. (Named for Eigenmode Basis to Cartesian Basis conversion filters, aka F2A filters).

Testing procedure:

• We uploaded the new input matrix listed in 16066.
• We then uploaded the coil output gains (AC gains) that are also listed in 16066.
• Then we reduced the C1:IOO-WFS_GAIN to 0.05 (by a factor of 20).
• Rana asked us to test the WFS sensors' impulse response to observe a minimum 10s decay to ensure that the UGF of WFS control loops is at or below 0.1 Hz.
• We were unable to have any effect on this decay actually. We tried setting offsets without tramps in multiple places but whenever we were able to excite this loop, it will always damp down in about 5-6s regardless of the value of C1:IOO-WFS_GAIN.
• So we moved on.
• Then, with MC locked we took reference data with no excitation or filters uploaded. (dotted curves)
• We took cross spectral density from C1:IOO-MC_F to C1:IOO-MC_TRANS_PIT_IN1, C1:IOO-MC_TRANS_YAW_IN1, C1:IOO-WFS1_PIT_IN1, C1:IOO-WFS1_PIT_IN1, C1:IOO-WFS2_PIT_IN1, and C1:IOO-WFS2_PIT_IN1.
• We were also looking at the power spectral density of these channels.
• Then using awggui (after the fix we did as in 16085), we added noise in C1:SUS-MC2_LSC_EXC as uniform noise between 0.05 Hz to 3.5 Hz with amplitude of 100 and gain of 100.
• We took a set of data without switching on the filters to have a comparison later. (Dash-dort curves)
• We then took data after switching on the filters. (Solid curves)

Next:

• Tomorrow we'll repeat this for MC1 and MC3 if we get a favourable grade in our work here.
• Even if not, we'll jsut conclude the suspension optimization work tomorrow morning and get into main interferometer.
Attachment 1: f2a.pdf
Attachment 2: IMC_F2A_Params_MC2.pdf
Attachment 3: MC2_F2A_FilterChar_POS2Ang.pdf
16087   Tue Apr 27 10:05:28 2021 Anchal, PacoUpdateSUSMC1 and MC3 F2A Filters Tested

We extended the f2a filter implementation and diagnostics as summarized in 16086 to MC1 and MC3.

MC1

Attachment 1 shows the filters with Q=3, 7, 10. We diagnosed using Q=3.

Attachment 2 shows the test summary, exciting with broadband noise on the LSC_EXC and measuring the CSD to estimate the transfer functions.

MC3

Attachment 3 shows the filters with Q=3, 7, 10. We diagnosed using Q=3.

Attachment 4 shows the test summary, exciting with broadband noise on the LSC_EXC and measuring the CSD to estimate the transfer functions.

Our main observation (and difference) with respect to MC2 is the filters have relative success for the PIT cross-coupling and not so much for YAW. We already observed this when we tuned the DC output gains to compute the filters.

Attachment 1: IMC_F2A_Params_MC1.pdf
Attachment 2: MC1_POStoAng_CrossCoupling.pdf
Attachment 3: IMC_F2A_Params_MC3.pdf
Attachment 4: MC3_POStoAng_CrossCoupling.pdf
16088   Tue Apr 27 15:15:17 2021 Ian MacMillanUpdateCDSSUS simPlant model

The first version of the single filter plant is below. Jon and I went through compiling a model and running it on the docker (see this post)

We activated an early version of the plant model (from about 10 years ago) but this model was not designed to run on its own so we had to ground lots of unconnected pieces. the model compiled and ran so we moved on to the x1sus_single_plant model that I prepared.

This model is shown in the first attachment wasn't made to be run alone because it is technically a locked library (see the lock in the bottom left). It is supposed to be referenced by another file: x1sup.mdl (see the second attachment). This works great in the Simulink framework. I add the x1sus_single_plant model to the path and Matlab automatically attaches the two. but the docker does not seem to be able to combine the two. Starting the cymac it gives these errors:

cymac    | Can't find sus_single_plant.mdl; RCG_LIB_PATH=/opt/rtcds/userapps:/opt/rtcds/userapps/lib:/usr/share/advligorts/src/src/epics/simLink/:/usr/share/advligorts/src/src/epics/simLink/lib:/usr/share/advligorts/src/src/epics/simLink cymac    | make[1]: *** [Makefile:30: x1sup] Error 2 cymac    | make: *** [Makefile:35: x1sup] Error 1

I have tried putting the x1sus_single_plant.mdl file everywhere as well as physically dragging the blocks that I need into the x1sup.mdl file but it always seems to throw an error. Basically, I want to combine them into one file that is not referencing anything other than the CDS library but I cant figure out how to combine them.

Okay but the next problem is the medm screen generation. When we had the original 2010 model running the sitemap did not include it. It included models that weren't even running before but not the model Jon and I had added. I think this is because the other models that were not running had medm screens made for them. I need to figure out how to generate those screens. I need to figure out how to use the tool Chris made to auto-generate medm screens from Simulink but I can't seem to figure it out. And honestly, it won't be much use to me until I can actually connect the plant block to its framework. One option is to just copy each piece over one by one. this will take forever but at this point, I am frustrated enough to try it. I'll try to give another update later tonight.

Attachment 1: x1sus_single_plant.pdf
Attachment 2: x1sup.pdf
16089   Wed Apr 28 10:56:10 2021 Anchal, PacoUpdateSUSIMC Filters diagnosed

Good morning!

We ran the f2a filter test for MC1, MC2, and MC3.

Filters

The new filters differ from previous versions by a adding non-unity Q factor for the pole pairs as well.

$\frac{f^2 - i \frac{f_z}{Q}f + f_z^2}{f^2 - i \frac{f_0}{Q}f + f_0^2}$
This in terms of zpk is: [ [zr + i zi, zr - i zi], [pr + i pi, pr - i pi], 1] where
$z_r = -\frac{f_z}{2Q}, \quad z_i = f_z \sqrt{1 - \frac{1}{4Q^2}}, \quad p_r = -\frac{f_0}{2Q}, \quad p_i = f_0 \sqrt{1 - \frac{1}{4Q^2}}$$, \quad f_z = f_0 \sqrt{G_{DC}}$

• Attachment #1 shows the filters for MC1 evaluated for Q=3, 7,and 10.
• Attachment #2 shows the filters for MC2 evaluated for Q=3, 7, and 10.
• Attachment #3 shows the filters for MC3 evaluated for Q=3, 7, and 10.
• Attachment #4 shows the bode plots generated by foton after uploading for Q=3 case.

We uploaded all these filters using foton, into the three last FM slots on the POS output gain coil.

Tests

We ran tests on all suspended optics using the following (nominal) procedure:

2. Lower the C1:IOO-WFS_GAIN to 0.05.
3. Upload AC coil balancing gains.
4. Take ASD for the following channels:
• C1:IOO-MC_TRANS_PIT_IN1
• C1:IOO-MC_TRANS_YAW_IN1
• C1:IOO-MC_WFS1_PIT_IN1
• C1:IOO-MC_WFS1_YAW_IN1
• C1:IOO-MC_WFS2_PIT_IN1
• C1:IOO-MC_WFS2_YAW_IN1
5. For the following combinations:
• No excitation** + no filter
• No excitation + filter
• Excitation + no filter
• Excitation + filter

** Excitation = 0.05 - 3.5 Hz uniform noise, 100 amplitude, 100 gain

Plots

• Attachment 5-7 give the test results for MC1, MC2 and MC3.
• In each pdf, the three pages show ASD of TRANS QPD, WFS1 and WFS2 channels' PIT and YAW, respectively.
• Red/blue correspond to data taken while F2A filters were on. Pink/Cyan correspond to data taken with filters off.
• Solid curves were taken with excitation ON and dashed curves were taken with excitation off.
• We see good suppression of POS-> PIT coupling in MC2 and MC3. POS->YAw is minimally affected in all cases.
• MC1 is clearly not doing good with the filters and probably needs readjustement. Something to do later in the future.
Attachment 1: IMC_F2A_Params_MC1.pdf
Attachment 2: IMC_F2A_Params_MC2.pdf
Attachment 3: IMC_F2A_Params_MC3.pdf
Attachment 4: IMC_F2A_Foton.pdf
Attachment 5: MC1_POS2ANG_Filter_Test.pdf
Attachment 6: MC2_POS2ANG_Filter_Test.pdf
Attachment 7: MC3_POS2ANG_Filter_Test.pdf
16090   Wed Apr 28 11:31:40 2021 JonUpdateVACEmpty N2 Tanks

I checked out what happened on c1vac. There are actually two independent monitoring codes running:

1. The interlock service, which monitors the line directly connected to the valves.
2. A seaparate convenience mailer, running as a cronjob, that monitors the tanks.

The interlocks did not trip because the low-pressure delivery line, downstream of the dual-tank regulator, never fell below the minimum pressure to operate the valves (65 PSI). This would have eventually occurred, had Jordan been slower to replace the tanks. So I see no problem with the interlocks.

On the other hand, the N2 mailer should have sent an email at 2021-04-18 15:00, which was the first time C1:Vac-N2T1_pressure dropped below the 600 PSI threshold. N2check.log shows these pressures were recorded at this time, but does not log that an email was sent. Why did this fail? Not sure, but I found two problems which I did fix:

• One was that the code was checking the sensor on the low-pressure side (C1:Vac-N2_pressure; nominally 75 PSI) against the same 600 PSI threshold as the tanks. This channel should either be removed or a separate threshold (65 PSI) defined just for it. I just removed it from the list because monitoring of this channel is redundant with the interlock service. This does not explain the failure to send an email.
• The second issue was that the pyN2check.sh script appeared to be calling Python 3 to run a Python 2 script. At least that was the situation when I tested it, and this was causing it to fail partway through. This might well explain the problem with no email. I explicitly set python --> python2 in the shell script.

The code then ran fine for me when I retested it. I don't see any further issues.

Quote:

Installed T2 today, and leaked checked the entire line. No issues found. It could have been a bad valve on the tank itself. Monitored T2 pressure for ~2 hours to see if there was any change. All seems ok.

 Quote: When I came into the lab this morning, I noticed that both N2 tanks were empty. I had swapped one on Friday (4-16-21) before I left the lab. Looking at the logs, the right tank (T2) sprung a leak shortly shortly after install. I leak checked the tank coupling after install but did not see a leak. There could a leak further down the line, possibly at the pressure transducer. The left tank (T1) emptied normally over the weekend, and I quickly swapped the left tank for a full one, and is curently at ~2700 psi. It was my understanding that if both tanks emptied, V1 would close automatically and a mailer would be sent out to the 40m group. I did not receive an email over the weekend, and I checked the Vac status just now and V1 was still open. I will keep an eye on the tank pressure throughout the day, and will try to leak check the T2 line this afternoon, but someone should check the vacuum interlocks and verify.

16091   Wed Apr 28 17:09:11 2021 AnchalUpdateSUSTuned Suspension Parameters uploaded for long term behavior monitoring

I have uploaded all the new settings mentioned in 16066 and 16072. The settings were uploaded through a single script present at anchal/20210428_IMC_Tuned_Suspension/uploadNewConfigIMC.py. The settings can be reverted back to old settings through anchal/20210428_IMC_Tuned_Suspension/restoreOldConfigIMC.py. Both these scripts can be run only through python3 in donatella or allegra.

GPSTIME of new settings: 1303690144

New settings include:

• New input matrices for MC1 and MC2.
• New Output coil gains for AC balancing on all three optics.
• Switching ON the FM8 filter modulae (Q=3 F2A filter) in POS column on output matrix of all optics.

We'll wait and watch the performance through summary pages and check back the performance on Monday.

16092   Wed Apr 28 18:56:57 2021 Yehonathan, JonUpdateCDSUpdated c1auxey wiring plan

We took a Supermicro from the lab (along with a keyboard, a mouse, and a screen taken from a table on the Y arm) and placed it near the Acromag chassis.

We installed Debian 10 on the machine. I followed the steps on the slow machine wiki for setting up the host machine. Some steps had to be updated. Most importantly, in the new Debian, the network interfaces are given random names like enp3s0 and enp4s0 instead of eth0 and eth1. I updated the wiki accordingly.

To operate the chassis using one 15V source I disconnected the +24V cable from the Acromag units and jumpered the +15V wire into the power input instead. I started up the Acromags. They draw 0.7A. I connected an Ethernet cable to the front interface. I checked that all the Acromags are connected to the local network of the host machine by pinging them one by one.

16093   Thu Apr 29 10:51:35 2021 JonUpdateCDSI/O Chassis Assembly

Summary

Yesterday I unpacked and installed the three 18-bit DAC cards received from Hanford. I then repeated the low-level PCIe testing outlined in T1900700, which is expanded upon below. I did not make it to DAC-ADC loopback testing because these tests in fact revealed a problem with the new hardware. After a combinatorial investigation that involved swapping cards around between known-to-be-working PCIe slots, I determined that one of the three 18-bit DAC cards is bad. Although its "voltage present" LED illuminates, the card is not detected by the host in either I/O chassis.

I installed one of the two working DACs in the c1bhd chassis. This now 100% completes this system. I installed the other DAC in the c1sus2 chassis, which still requires four more 18-bit DACs. Lastly, I reran the PCIe tests for the final configurations of both chassis.

PCIe Card Detection Tests

For future reference, below is the set of command line tests to verify proper detection and initialization of ADC/DAC/BIO cards in I/O chassis. This summarizes the procedure described in T1900700 and also adds the tests for 18-bit DAC and 32-channel BO cards, which are not included in the original document.

Each command should be executed on the host machine with the I/O chassis powered on:

$sudo lspci -v | grep -B 1 xxxx where xxxx is a four-digit device code given in the following table. Device Device Code General Standards 16-bit ADC 3101 General Standards 16-bit DAC 3120 General Standards 18-bit DAC 3357 Contec 16-channel BIO 8632 Contec 32-channel BO 86e2 Dolphin IPC host adapter 0101 The command will return a two-line entry for each PCIe device of the specified type that is detected. For example, on a system with a single ADC this command should return: 10:04.0 Bridge: PLX Technology, Inc. PCI9056 32-bit 66MHz PCI IOBus Bridge (rev ac) Subsystem: PLX Technology, Inc. Device 3101 16094 Thu Apr 29 10:52:56 2021 AnchalUpdateSUSIMC Trans QPD and WFS loops step response test In 16087 we mentioned that we were unable to do a step response test for WFS loop to get an estimate of their UGF. The primary issue there was that we were not putting the step at the right place. It should go into the actuator directly, in this case, on C1:SUS-MC2_PIT_COMM and C1:SUS-MC2_YAW_COMM. These channels directly set an offset in the control loop and we can see how the error signals first jump up and then decay back to zero. The 'half-time' of this decay would be the inverse of the estimated UGF of the loop. For this test, the overall WFS loops gain, C1:IOO-WFS_GAIN was set to full value 1. This test is performed in the changed settings uploaded in 16091. I did this test twice, once giving a step in PIT and once in YAW. Attachment 1 is the striptool screenshot for when PIT was given a step up and then step down by 0.01. • Here we can see that the half-time is roughly 10s for TRANS_PIT and WFS1_PIT corresponding to roughly 0.1 Hz UGF. • Note that WFS2 channels were not disturbed significantly. • You can also notice that third most significant disturbance was to TRANS_YAW actually followed by WF1 YAW. Attachment 2 is the striptool screenshot when YAW was given a step up and down by 0.01. Note the difference in x-scale in this plot. • Here, TRANS YAW got there greatest hit and it took it around 2 minutes to decay to half value. This gives UGF estimate of about 10 mHz! • Then, weirdly, TRANS PIT first went slowly up for about a minutes and then slowly came dome in a half time of 2 minutes again. Why was PIT signal so much disturbed by the YAW offset in the first place? • Next, WFS1 YAW can be seen decaying relatively fast with half-life of about 20s or so. • Nothing else was disturbed much. • So maybe we never needed to reduce WFS gain in our measurement in 16089 as the UGF everywhere were already very low. • What other interesting things can we infer from this? • Should I sometime repeat this test with steps given to MC1 or MC3 optics? Attachment 1: PIT_OFFSET_ON_MC2.png Attachment 2: YAW_STEP_ON_MC2_complete.png 16096 Thu Apr 29 13:41:40 2021 Ian MacMillanUpdateCDSSUS simPlant model To add the required library: put the .mdl file that contains the library into the userapps/lib folder. That will allow it to compile correctly I got these errors: Module ‘mbuf’ symvers file could not be found. Module ‘gpstime’ symvers file could not be found. ***ERROR: IPCx parameter file /opt/rtcds/zzz/c1/chans/ipc/c1.ipc not found make[1]: *** [Makefile:30: c1sup] Error 2 make: *** [Makefile:35: c1sup] Error 1 I removed all IPC parts (as seen in Attachment 1) and that did the trick. IPC parts (Inter-Process Communication) were how this model was linked to the controller so I don't know how exactly how I can link them now. I also went through the model and grounded all un-attached inputs and outputs. Now the model compiles Also, The computer seems to be running very slowly in the past 24 hours. I know Jon was working on it so I'm wondering if that had any impact. I think it has to do with the connection speed because I am connected through X2goclient. And one thing that has probably been said before but I want to note again is that you don't need a campus VPN to access the docker. Attachment 1: Non-IPC_Plant.pdf 16097 Thu Apr 29 15:11:33 2021 gautamUpdateCDSRFM The problem here was that the RFM errors cropped up again - seems like it started ~4am today morning judging by TRX trends. Of course without the triggering signal the arm cavity couldn't lock. I rebooted everything (since just restarting the rfm senders/receivers did not do the trick), now arm locking works fine again. It's a bit disappointing that the Rogue Master setting did not eliminate this problem completely, but oh well... It's kind of cool that in this trend view of the TRX signal, you can see the drift of the ETMX suspension. The days are getting hot again and the temp at EX can fluctuate by >12C between day and night (so the "air-conditioning" doesn't condition that much I guess 😂 ), and I think that's what drives the drift (idk what the transfer function to the inside of the vacuum chamber is but such a large swing isn't great in any case). Not plotted here but i hypothesize TRY levels will be more constant over the day (modulo TT drift which affects both arms). The IMC suspension team should double check their filters are on again. I am not familiar with the settings and I don't think they've been added to the SDF. Attachment 1: RFM_errs.png Attachment 2: Screenshot_2021-04-29_15-12-56.png 16098 Thu Apr 29 16:35:51 2021 YehonathanUpdateCDSUpdated c1auxey wiring plan I installed the EPICs base, asyn and modbus modules according to Jon's instructions. Since the modbus configurations files were already writtten for c1auxey1 (see elog 15292) the only thing I did was to change the IP addresses in ETMYaux.cmd to match the actual assigned IPs. I followed the rest of the instructions as written. The modbus service was activated succesfully. The only thing left to do is to change ETMYaux.db to reflect to new channels that were added. I believe these are BI channels named C1:SUS-ETMY_xx_ENABLEMon. 16099 Thu Apr 29 17:43:16 2021 KojiUpdateCDSRFM The other day I felt hot at the X end. I wondered if the Xend A/C was off, but the switch right next to the SP table was ON (green light). I could not confirm if the A/C was actually blowing or not. 16100 Thu Apr 29 17:43:48 2021 AnchalUpdateCDSF2A Filters double check I double checked today and the F2A filters in the output matrices of MC1, MC2 and MC3 in the POS column are ON. I do not get what SDF means? Did we need to add these filters elsewhere?  Quote: The IMC suspension team should double check their filters are on again. I am not familiar with the settings and I don't think they've been added to the SDF. Attachment 1: F2AFiltersON.png 16102 Thu Apr 29 18:53:33 2021 AnchalUpdateSUSIMC Suspension Damping Gains Test With the input matrix, coil ouput gains and F2A filters loaded as in 16091, I tested the suspension loops' step response to offsets in LSC, ASCPIT and ASCYAW channels, before and after applying the "new damping gains" mentioned in 16066 and 16072. If these look better, we should upload the new (higher) damping gains as well. This was not done in 16091. Note that in the plots, I have added offsets in the different channels to plot them together, hence the units are "au". Attachment 1: MC1_SUSDampGainTest.pdf Attachment 2: MC2_SUSDampGainTest.pdf Attachment 3: MC3_SUSDampGainTest.pdf 16103 Thu Apr 29 19:55:45 2021 YehonathanUpdateCDSUpdated c1auxey wiring plan We received a stock of DB9 male feed-through connectors. That allowed me to complete the remaining wiring on the c1auxey Acromag chassis. The only thing left to be done is the splicing to the RTS. 16105 Fri Apr 30 00:20:30 2021 gautamUpdateCDSF2A Filters double check The SDF system is supposed to help with restoring the correct settings, complementary to burt. My personal opinion is that there is no need to commit these filters to SDF until we're convinced that they help with the locking / noise performance.  Quote: I double checked today and the F2A filters in the output matrices of MC1, MC2 and MC3 in the POS column are ON. I do not get what SDF means? Did we need to add these filters elsewhere 16106 Fri Apr 30 12:52:14 2021 Ian MacMillanUpdateCDSSUS simPlant model Now that the model is finally compiled I need to make an medm screen for it and put it in the c1sim:/home/controls/docker-cymac/userapps/medm/ directory. But before doing that I really want to test it using the autogenerated medm screens which are in the virtual cymac in the folder /opt/rtcds/tst/x1/medm/x1sup. In Jon's post he said that I can use the virtual path for sitemap after running$ eval $(./env_cymac) 16107 Fri Apr 30 19:18:51 2021 Yehonathan, JonUpdateCDSUpdated c1auxey wiring plan We finished the installation procedure on the c1auxey1 host machine. There were some adjustments that had to be made for Debian 10. The slow machine wiki page has been updated. A test database file was made were all the channel names were changed from C1 to C2 in order to not interfere with the existing channels. We starting testing the channels one by one to check the wiring and the EPICs software. We found some misswirings and fixed them.  Channel Name Type EPICs Test Acromag windows software test C2:SUS-ETMY_ULPDMon AI Pass Pass C2:SUS-ETMY_URPDMon AI Pass Pass C2:SUS-ETMY_LLPDMon AI Pass Pass C2:SUS-ETMY_SPDMon AI Pass Pass C2:SUS-ETMY_LRPDMon AI Pass Pass C2:SUS-ETMY_ULVMon AI Pass Pass C2:SUS-ETMY_URVMon AI Pass Pass C2:SUS-ETMY_LLVMon AI Pass Pass C2:SUS-ETMY_SideVMon AI Pass Pass C2:SUS-ETMY_LRVMon AI Pass Pass Its getting late. I'll continue with the rest of the channels on Monday. Notice that for all the AI channels the RTN was disconnected while testing. 16108 Mon May 3 09:14:01 2021 Anchal, PacoUpdateLSCIMC WFS noise contribution in arm cavity length noise Lock ARMs • Try IFO Configure ! Restore Y Arm (POY) and saw XARM lock, not YARM. Looks like YARM biases on ITMY and ETMY are not optimal, so we slide C1:SUS-ETMY_OFF from 3.0 --> -14.0 and watch Y catch its lock. • Run ASS scripts for both arms and get TRY/TRX ~ 0.95 • We ran X, then Y and noted that TRX dropped to ~0.8 so we ran it again and it was well after that. From now on, we will do Y, then X. WFS1 noise injection • Turn WFS limits off by running switchOffWFSlims.sh  • Inject broadband noise (80-90 Hz band) of varying amplitudes from 100 - 100000 counts on C1:IOO-WFS1_PIT_EXC • After this we try to track its propagation through various channels, starting with • C1:LSC-XARM_IN1_DQ / C1:LSC-YARM_IN1_DQ • C1:SUS-ETMX_LSC_OUT_DQ / C1:SUS-ETMY_LSC_OUT_DQ • C1:IOO-MC_F_DQ • C1:SUS-MC1_**COIL_OUT / C1:SUS-MC2_**COIL_OUT / C1:SUS-MC3_**COIL_OUT  • C1:IOO-WFS1_PIT_ERR / C1:IOO-WFS1_YAW_ERR • C1:IOO-WFS1_PIT_IN2 ** denotes [UL, UR, LL, LR]; the output coils. • Attachment 1 shows the power spectra with IMC unlocked • Attachment 2 shows the power spectra with the ARMs (and IMC) locked Attachment 1: WFS1_PIT_Noise_Inj_Test_IMC_unlocked.pdf Attachment 2: WFS1_PIT_Noise_Inj_Test_ARM_locked.pdf 16109 Mon May 3 13:35:12 2021 Ian MacMillanUpdateCDSSUS simPlant model When the cymac is started it gives me a list of channels shown below. $  Initialized TP interface node=8, host=98e93ecffcca  $Creating X1:DAQ-DC0_X1IOP_STATUS$  Creating X1:DAQ-DC0_X1IOP_CRC_CPS  $Creating X1:DAQ-DC0_X1IOP_CRC_SUM$  Creating X1:DAQ-DC0_X1SUP_STATUS  $Creating X1:DAQ-DC0_X1SUP_CRC_CPS$  Creating X1:DAQ-DC0_X1SUP_CRC_SUM

But when I enter it into the Diaggui I get an error:

The following channel could not be found: X1:DAQ-DC0_X1SUP_CRC_CPS

My guess is that need to connect to the Diaggui to something that can access those channels. I also need to figure out what those channels are.

16110   Mon May 3 16:24:14 2021 AnchalUpdateSUSIMC Suspension Damping Gains Test Repeated with IMC unlocked

We repeated the same test with IMC unlocked. We had found these gains when IMC was unlocked and their characterization needs to be done with no light in the cavity. attached are the results. Everything else is same as before.

 Quote: With the input matrix, coil ouput gains and F2A filters loaded as in 16091, I tested the suspension loops' step response to offsets in LSC, ASCPIT and ASCYAW channels, before and after applying the "new damping gains" mentioned in 16066 and 16072. If these look better, we should upload the new (higher) damping gains as well. This was not done in 16091. Note that in the plots, I have added offsets in the different channels to plot them together, hence the units are "au".

Edit Tue May 4 14:43:48 2021 :

• Adding zoomed in plots to show first 25s after the step.
• MC1:
• Our improvements by new gains are only modest.
• This optic needs a more careful coil balancing first.
• Still the ring time is reduced to about 5s for all step responses as opposed to 10s at old gains.
• MC2:
• The first page of MC2 might be bit misleading. We have not changed the damping gain for SUSPOS channel, so the longer ringing is probably just an artifact of somthing else. We didn't retake data.
• In PIT and YAW where we increased the gain by a factor of 3, we see a reduction in ringing lifetime by about half.
• MC3:
• We saw the most optimistic improvement on this optic.
• The gains were unusually low in this optic, not sure why.
• By increasing SUSPOS gain from 200 to 500, we saw a reduction of ringing halftime from 7-8s to about 2s. Improvements are seen in other DOFs as well.
• You can notice rightaway that YAW of MC3 keeps oscillating near resonance (about 1 Hz). Maybe more careful feedback shaping is required here.
• In SUSPIT, we increased gain from 12 to 35 and saw a good reduction in both ringing time and initial amplitude of ringing.
• In SUSYAW, we only increased the gain to 12 from 8, which still helped a lot in reducing big ringing step response to below 5s from about 12s.

Overall, I would recommend setting the new gains in the suspension loops as well to observe long term effects too.

Attachment 1: MC1_SusDampGainTest.pdf
Attachment 2: MC2_SusDampGainTest.pdf
Attachment 3: MC3_SusDampGainTest.pdf
16111   Mon May 3 16:49:04 2021 YehonathanUpdateBHDSOS assembly

I found a "vice" in the cleanroom (attachment 1). I used it to push dowel pins into the last suspension block using some alcohol as a lubricant.

I then assembled the 7th and last suspension tower (attachment 2).

Things that need to be done:

1. Push Viton tips into vented screws and assemble the earthquake stops.

2. Glue magnets to dumbells.

Attachment 1: 20210503_161422.png
Attachment 2: 20210503_161456.jpg
16112   Mon May 3 17:28:58 2021 Anchal, Paco, RanaUpdateLSCIMC WFS noise contribution in arm cavity length noise

Rana came and helped us figure us where to inject the noise. Following are the characteristics of the test we did:

• Inject normal noise at C1:IOO-MC1_PIT_EXC using AWGGUI.
• Excitation amplitude of 54321 in band 12-37Hz with Cheby1 8th order bandpass filter with same limits.
• Look at power spectrum of C1:IOO-MC_F_DQ, C1:IOO-WFS1-PIT_OUT_DQ and the C1:IOO-MC1_PIT_EXC itself.
• Increased the gain of the noise excitation until we see some effect in MC_F.
• Diaggui also showed coherence plot in the bottom, which let's us have an estimate of how much we need to go further.

Attachment 1 shows a screenshot with awggui and diaggui screens displaying the signal in both angular and longitudinal channels.

Attachment 2 shows the analogous screenshot for MC2.

Attachment 1: excitationoftheMCanglessothatwecanseesomethingdotpng.png
Attachment 2: excitationoftheMCanglessothatwecanseesomethingdotpngbutthistimeitsMC2.png
16114   Mon May 3 20:36:46 2021 Yehonathan, JonUpdateCDSUpdated c1auxey wiring plan

It seemed like the BIO channels were not working, both the inputs and the outputs. The inputs were working on the windows machine though. That is, when we shorted the BIO channel to the return, or put 0V on it, we could see the LED turn on on the I/O testing screen and when we ramped up the voltage above 3 the LED turned off. This is the expected behavior from a sinking digital input. However, the EPICs caget didn't show any change. All the channels were stuck on Disabled.

We checked the digital outputs by connecting the channels to a fluke. Initially, the fluke showed 13V. We tried to toggle the digital output channels with caput and that didn't work. We checked the outputs with the windows software. For that, we needed to stop the Modbus. To our surprise, the windows software was not able to flip the channels either. We realized that this BIO Acromag unit is probably defective. We replaced it with a different unit and put a warning sticker on the defective unit. Now, the digital outputs were working as expected. When we turned them on the voltage output dropped to 0V. We checked the channels with the EPICs software. We realized that these channels were locked with the closed loop definition. We turned on the channels tied to these output channels (watchdog and toggles) and it worked. The output channels can be flipped with the EPICs software. We checked all the digital output channels and fixed some wiring issues along the way.

The digital input channels were still not working. This is a software issue that we will have to deal with later.

(Yehonathan) Rana noticed that the BNC leads on the chassis front panel didn't have isolation on them so I redid them with shrinking tubes.

16116   Tue May 4 07:38:36 2021 JonUpdateCDSI/O Chassis Assembly

IOP models created

With all the PCIe issues now resolved, yesterday I proceeded to build an IOP model for each of new FEs. I assigned them names and DCUIDs consist with the 40m convention, listed below. These models currently exist on only the cloned copy of /opt/rtcds running on the test stand. They will be copied to the main network disk later, once the new systems are fully tested.

Model Host CPU DCUID
c1x06 c1bhd 1 23
c1x07 c1sus2 1 24

The models compile and install successfully. The RCG runtime diagnostics indicate that all is working except for the timing synchronization and DAQD data transmission. This is as expected because neither of these have been set up yet.

Timing system set-up

The next step is to provide the 65 kHz clock signals from the timing fanout via LC optical fiber. I overlooked the fact that an SPX optical transceiver is required to interface the fiber to the timing slave board. These were not provided with the timing slaves we received. The timing slaves require a particular type of transceiver, 100base-FX/OC-3, which we did not have on hand. (For future reference, there is a handy list of compatible transceivers in E080541, p. 14.) I placed a Digikey order for two Finisar FTLF1217P2BTL, which should arrive within two days.

Attachment 1: Screen_Shot_2021-05-03_at_4.16.06_PM.png
16117   Tue May 4 11:43:09 2021 Anchal, PacoUpdateLSCIMC WFS noise contribution in arm cavity length noise

We redid the WFS noise injection test and have compiled some results on noise contribution in arm cavity noise and IMC frequency noise due to angular noise of IMC.

Attachment 1: Shows the calibrated noise contribution from MC1 ASCPIT OUT to ARM cavity length noise and IMC frequency noise.

• For calibrating the cavity length noise signals, we sent 100 cts 100Hz sine excitation to ITMX/Y_LSC_EXC, used actuator calibration for them as 2.44 nm/cts from 13984, and measured the peak at 100 hz in time series data. We got calibration factors: ETMX-LSC_OUT: 60.93 pm/cts , and ETMY-LSC_OUT: 205.0 pm/cts.
• For converting IMC frequency noise to length noise, we used conversion factor given by $\lambda L / c$ where L is 37.79m and lambda is wavelength of light.
• For converting MC1 ASCPIT OUT cts data to frequency noise contributed to IMC, we sent 100,000 amplitude bandlimited noise (see attachment 3 for awggui config) from 25 Hz to 30 Hz at C1:IOO-MC1_PIT_EXC. This noise was seen at both MC_F and ETMX/Y_LSC_OUT channels. We used the noise level at 29 Hz to get a calibration for MC1_ASCPIT_OUT to IMC Frequency in Hz/cts. See Attachment 2 for the diaggui plots.
• Once we got the calibration above, we measured MC1_ASCPIT_OUT power spectrum without any excitaiton and multiplied it with the calibration factor.
• However, something must be wrong because the MC_F noise in length units is coming to be higher than cavity length noise in most of the frequency band.
• It can be due to the fact that control signal power spectrum is not exactly cavity length noise at all frequencies.  That should be only above the UGF of the control loop (we plan to measure that in afternoon).
• Our calibration for ETMX/Y_LSC_OUT might be wrong.
Attachment 1: ArmCavNoiseContributions.pdf
Attachment 2: IOO-MC1_PIT_NoiseInjTest2.pdf
Attachment 3: IOO-MC1_PIT_NoiseInjTest_AWGGUI_Config.png
16118   Tue May 4 14:55:38 2021 Ian MacMillanUpdateCDSSUS simPlant model

After a helpful meeting with Jon, we realized that I have somehow corrupted the sitemap file. So I am going to use the code Chris wrote to regenerate it.

Also, I am going to connect the controller using the IPC parts. The error that I was having before had to do with the IPC parts not being connected properly.

16119   Tue May 4 19:14:43 2021 YehonathanUpdateGeneralOSEMs from KAGRA

I put the box containing the untested OSEMs from KAGRA near the south flow bench on the floor.

16120   Wed May 5 09:04:47 2021 AnchalUpdateSUSNew IMC Suspension Damping Gains uploaded for long term testing

We have uploaded the new damping gains on all the suspensions of IMC. This completes changing all the configuration to as mentioned in 16066 and 16072. The old setting can be restored by running python3 /users/anchal/20210505_IMC_Tuned_SUS_with_Gains/restoreOldConfigIMC.py from allegra or donatella.

GPSTIME: 1304265872

 UTC May 05, 2021 16:04:14 UTC Central May 05, 2021 11:04:14 CDT Pacific May 05, 2021 09:04:14 PDT

16121   Wed May 5 13:05:07 2021 ChubUpdateGeneralchassis delivery from De Leone

Assembled chassis from De Leone placed in the 40 Meter Lab, along the west wall and under the display pedestal table.  The leftover parts are in smaller Really Useful boxes, also on the parts pile along the west wall.

Attachment 1: de_leone_del_5-5-21.jpg
16122   Wed May 5 15:11:54 2021 Ian MacMillanUpdateCDSSUS simPlant model

I added the IPC parts back to the plant model so that should be done now. It looks like this again here.

I can't seem to find the control model which should look like this. When I open sus_single_control.mdl, it just shows the C1_SUS_SINGLE_PLANT.mdl model. Which should not be the case.

16124   Thu May 6 16:13:24 2021 Ian MacMillanUpdateCDSSUS simPlant model

When using mdl2adl I was getting the error:

$cd /home/controls/mdl2adl$  ./mdl2adl x1sup.mdl error: set $site and$ifo environment variables

to set these in the terminal use the following commands:

$export site=tst$  export ifo=x1

On most of the systems, there is a script that automatically runs when a terminal is opened that sets these but that hasn't been added here so you must run these commands every time you open the terminal when you are using mdl2adl.

16126   Fri May 7 11:19:29 2021 Ian MacMillanUpdateCDSSUS simPlant model

I copied c1scx.mdl to the docker to attach to the plant using the commands:

$ssh nodus.ligo.caltech.edu [Enter Password]$  cd opt/rtcds/userapps/release/isc/c1/models/simPlant $scp c1scx.mdl controls@c1sim:/home/controls/docker-cymac/userapps 16127 Fri May 7 11:54:02 2021 Anchal, PacoUpdateLSCIMC WFS noise contribution in arm cavity length noise We today measured the calibration factors for XARM_OUT and YARM_OUT in nm/cts and replotted our results from 16117 with the correct frequency dependence. Calibration of XARM_OUT and YARM_OUT • We took transfer function measurement between ITMX/Y_LSC_OUT and X/YARM_OUT. See attachment 1 and 2 • For ITMX/Y_LSC_OUT we took calibration factor of 3*2.44/f2 nm/cts from 13984. Note that we used the factor of 3 here as Gautum has explicitly written that the calibration cts are DAC cts at COIL outputs and there is a digital gain of 3 applied at all coil output gains in ITMX and ITMY that we confirmed. • This gave us callibration factors of XARM_OUT: 1.724/f2 nm/cts , and YARM_OUT: 4.901/f2 nm/cts. Note the frrequency dependence here. • We used the region from 70-80 Hz for calculating the calibration factor as it showed the most coherence in measurement. Inferring noise contributions to arm cavities: • For converting IMC frequency noise to length noise, we used conversion factor given by $\lambda L / c$ where L is 37.79m and lambda is wavelength of light. • For converting MC1 ASCPIT OUT cts data to frequency noise contributed to IMC, we sent 100,000 amplitude bandlimited noise from 25 Hz to 30 Hz at C1:IOO-MC1_PIT_EXC. This noise was seen at both MC_F and ETMX/Y_LSC_OUT channels. We used the noise level at 29 Hz to get a calibration for MC1_ASCPIT_OUT to IMC Frequency in Hz/cts. This measurement was done in 16117. • Once we got the calibration above, we measured MC1_ASCPIT_OUT power spectrum without any excitaiton and multiplied it with the calibration factor. • Attachment 3 is our main result. • Page 1 shows the calculation of Angle to Length coupling by reading off noise injects in MC1_ASCPIT_OUT in MC_F. This came out to 10.906/f2 kHz/cts. • Page 2-3 show the injected noise in X arm cavity length units. Page 3 is the zoomed version to show the matching of the 2 different routes of calibration. • BUT, we needed to remove that factor of 3 we incorporated earlier to make them match. • Page 4 shows the noise contribution of IMC angular noise in XARM cavity. • Page 5-6 is similar to 2-3 but for YARM. The red note above applied here too! So the factor of 3 needed to be removed in both places. • Page 7 shows the noise contribution of IMC angular noise in XARM cavity. Conclusions: • IMC Angular noise contribution to arm cavities is atleast 3 orders of magnitude lower then total armc cavity noise measured. Edit Mon May 10 18:31:52 2021 See corrections in 16129. Attachment 1: ITMX-XARM_TF.pdf Attachment 2: ITMY-YARM_TF.pdf Attachment 3: ArmCavNoiseContributions.pdf 16129 Mon May 10 18:19:12 2021 Anchal, PacoUpdateLSCIMC WFS noise contribution in arm cavity length noise, Corrections A few corrections to last analysis: • The first plot was not IMC frequency noise but actually MC_F noise budget. • MC_F is frequency noise in the IMC FSS loop just before the error point where IMC length and laser frequency is compared. • So, MC_F (in high loop gain frequency region upto 10kHz) is simply the quadrature noise sum of free running laser noise and IMC length noise. • Between 1Hz to 100 Hz, normally MC_F is dominated by free running laser noise but when we injected enough angular noise in WFS loops, due to Angle to length coupling, it made IMC length noise large enough in 25-30 Hz band that we started seeing a bump in MC_F. • So this bump in MC_F is mostly the noise due to Angle to length coupling and hence can be used to calculate how much Angular noise normally goes into length noise. • In the remaining plots, MC_F was plotted with conversion into arm length units but this was wrong. MC_F gets suppressed by IMC FSS open loop gain before reaching to arm cavities and hence is hardly present there. • The IMC length noise however is not suppresed until after the error point in the loop. So the length noise (in units of Hz calculated in the first step above) travels through the arm cavity loop. • We already measured the transfer function from ITMX length actuation to XARM OUT, so we know how this length noise shows up at XARM OUT. • So in the remaining plots, we plot contribution of IMC angular noise in the arm cavities. Note that the factor of 3 business still needed to be done to match the appearance of noise in XARM_OUT and YARM_OUT signal from the IMC angular noise injection. • I'll post a clean loop diagram soon to make this loopology clearer. Attachment 1: ArmCavNoiseContributions.pdf 16130 Tue May 11 16:29:55 2021 JonUpdateCDSI/O Chassis Assembly Quote: Timing system set-up The next step is to provide the 65 kHz clock signals from the timing fanout via LC optical fiber. I overlooked the fact that an SPX optical transceiver is required to interface the fiber to the timing slave board. These were not provided with the timing slaves we received. The timing slaves require a particular type of transceiver, 100base-FX/OC-3, which we did not have on hand. (For future reference, there is a handy list of compatible transceivers in E080541, p. 14.) I placed a Digikey order for two Finisar FTLF1217P2BTL, which should arrive within two days. Today I brought and installed the new optical transceivers (Finisar FTLF1217P2BTL) for the two timing slaves. The timing slaves appear to phase-lock to the clocking signal from the master fanout. A few seconds after each timing slave is powered on, its status LED begins steadily blinking at 1 Hz, just as in the existing 40m systems. However, some other timing issue remains unresolved. When the IOP model is started (on either FE), the DACKILL watchdog appears to start in a tripped state. Then after a few minutes of running, the TIM and ADC indicators go down as well. This makes me suspect the sample clocks are not really phase-locked. However, the models do start up with no error messages. Will continue to debug... Attachment 1: Screen_Shot_2021-05-11_at_3.03.42_PM.png 16131 Tue May 11 17:43:09 2021 KojiUpdateCDSI/O Chassis Assembly Did you match the local PC time with the GPS time? 16132 Wed May 12 10:53:20 2021 Anchal, PacoUpdateLSCPSL-IMC PDH Loop and XARM PDH Loop diagram Attached is the control loop diagram when main laser is locked to IMC and a single arm (XARM) is locked to the transmitted light from IMC.  Quote: I'll post a clean loop diagram soon to make this loopology clearer. Attachment 1: IMC_SingleArm.pdf 16134 Wed May 12 13:06:15 2021 Ian MacMillanUpdateCDSSUS simPlant model Working with Chris, we decided that it is probably better to use a simple filter module as a controller before we make the model more complicated. I will use the plant model that I have already made (see attachment 1 of this). then attach a single control filter module to that: as seen in attachment 1. because I only want to work with one degree of freedom (position) I will average the four outputs which should give me the position. Then by feeding the same signal to all four inputs I should isolate one degree of freedom while still using the premade plant model. The model I made that is shown in attachment 2 is the model I made from the plan. And it complies! yay! I think there is a better way to do the average than the way I showed. And since the model is feeding back on itself I think I need to add a delay which Rana noted a while ago. I think it was a UnitDelay (see page 41 of RTS Developer’s Guide). So I will add that if we run into problems but I think there is enough going on that it might already be delayed. Since our model (x1sup_isolated.mdl) has compiled we can open the medm screens for it. I provide a procedure below which is based on Jon's post [First start the cymac and have the model running] $  cd docker-cymac $eval$(./env_cymac)
$medm -x /opt/rtcds/tst/x1/medm/x1sup_isolated/X1SUP_ISOLATED_GDS_TP.adl To see a list of all medm screens use: $  cd docker-cymac \$  ./login_cymac  #  cd /opt/rtcds/tst/x1/medm/x1sup_isolated  #  ls

Some of the other useful ones are:

 adl screen Description X1SUP_ISOLATED_Control_Module.adl This is the control filter module shown in attachment 2 at the top in the center. This module will represent the control system. X1SUP_ISOLATED_C1_SUS_SINGLE_PLANT_Plant_POS_Mod.adl See attachment 4. This screen shows the POS plant filter module that will be filled by the filter representing the transfer function of a damped harmonic oscillator:        $\frac{x}{F}=\frac{\omega_0^2}{\omega_0^2+i\frac{\omega_0 \omega}{Q}-\omega^2}$ THIS TF HAS BEEN UPDATED SEE NEXT POST

The first one of these screens that are of interest to us (shown in attachment 3) is the X1SUP_ISOLATED_GDS_TP.adl screen, which is the CDS runtime diagnostics screen. This screen tells us "the success/fail state of the model and all its dependencies." I am still figuring out these screens and the best guide is T1100625.

The next step is taking some data and seeing if I can see the position damp over time. To do this I need to:

1. Edit the plant filter for the model and add the correct filter.
2. Figure out a filter for the control system and add it to that. (I can leave it as is to see what the plant is doing)
3. Take some position data to show that the plant is a harmonic oscillator and is damping away.
Attachment 1: SimplePlant_SingleContr.pdf
Attachment 2: x1sup_isolated.pdf
Attachment 3: X1SUP_ISOLATED_GDS_TP.png
Attachment 4: X1SUP_ISOLATED_C1_SUS_SINGLE_PLANT_Plant_POS_Mod.png
16135   Wed May 12 14:23:20 2021 JordanUpdateSUSMass Properties of SOS Assembly with 3"->2" Optic sleeve, in SI units
Attachment 1: Moments_of_Inertia_SI.PNG
16136   Wed May 12 16:53:59 2021 KojiUpdateSUSMass Properties of SOS Assembly with 3"->2" Optic sleeve, in SI units

No, this is the property of the suspension assembly. The mass says 10kg

Could you do the same for the testmass assembly (only the suspended part)? The units are good, but I expect that the values will be small. I want to keep at least three significant digits.

16137   Wed May 12 17:06:52 2021 JordanUpdateSUSMass Properties of SOS Assembly with 3"->2" Optic sleeve, in SI units

Here are the mass properties for the only the test mass assembly (optic, 3" ring, and wire block). (Updated with g*mm^2)

 Quote: No, this is the property of the suspension assembly. The mass says 10kg Could you do the same for the testmass assembly (only the suspended part)? The units are good, but I expect that the values will be small. I want to keep at least three significant digits.

Attachment 1: Moments_of_Inertia_SI.PNG
16138   Thu May 13 11:55:04 2021 Anchal, PacoUpdateSUSMC1 suspension misbehaving

We came in the morning with the following scene on the zita monitor:

The MC1 watchdog was tripped and seemed like IMC struggled all night with misconfigured WFS offsets. After restoring the MC1 WD, clearing the WFS offsets, and seeing the suspension damp, the MC caught lock. It wasn't long before the MC unlocked, and the MC1 WD tripped again.

We tried few things, not sure what order we tried them in:

• Letting suspension loops damp without the WFS switched on.
• Letting suspension loops damp with PSL shutter closed.
• Restoring old settings of MC suspension.
• Doing burt restore with command:
burtwb -f /opt/rtcds/caltech/c1/burt/autoburt/snapshots/2021/May/12/08:19/c1mcsepics.snap -l /tmp/controls_1210513_083437_0.write.log -o /tmp/controls_1210513_083437_0.nowrite.snap -v <

Nothing worked. We kept seeing that ULPD var on MC1 keeps showing kicks every few minutes which jolts the suspension loops. So we decided to record some data with PSL shutter closed and just suspension loops on. Then we switched off the loops and recorded some data with freely swinging optic. Even when optic was freely swinging, we could see impulses in the MC1 OSEM UL PD var which were completely uncorrelated with any seismic activity. Infact, last night was one fo teh calmer nights seismically speaking. See attachment 2 for the time series of OSEM PD variance. Red region is when the coil outputs were disabled.

Inference:

• We think something is wrong with the UL OSEM of MC1.
• It seems to show false spikes of motion when there is no such spike present in any other OSEM PD or the seismic data itself.
• Currently, this is still the case. We sometimes get 10-20 min of "Good behavior" when everything works.
• But then the impulses start occuring again and overwhelmes the suspension loops and WFS loops.
• Note, that other optic in IMC behaved perfectly normally throughout this time.
• In the past, it seems like satellite box has been the culprit for such glitches.
• We should look into debugging this as ifo is at standstill because of this issue.
• Earlier, Gautum would post Vmon signals of coil outputs only to show the glitches. We wanted to see if switching off the loops help, so we recorded OSEM PD this time.
• In hindsight, we should probably look at the OSEM sensor outputs directly too rather than looking at the variance data only. I can do this if people are interested in looking at that too.
• We've disabled the coil ouputs in MC1 and PSL shutter is off.

Edit Thu May 13 14:47:25 2021 :

Added OSEM Sensor timeseries data on the plots as well. The UL OSEM sensor data is the only channel which is jumping hapazardly (even during free swinging time) and varying by +/- 30. Other sensors only show some noise around a stable position as should be the case for a freely suspended optic.

Attachment 2: MC1_Glitches_Invest2.pdf
16139   Thu May 13 19:38:54 2021 AnchalUpdateSUSMC1 Satellite Amplifier Debugged

[Anchal Koji]

Koji and I did a few tests with an OSEM emulator on the satellite amplifier box used for MC1 which is housed on 1X4. This sat box unit is S2100029 D1002812 that was recently characterized by me 15803. We found that the differential output driver chip AD8672ARZ U2A section for the UL PD was not working properly and had a fluctuating offset at no input current from the PD. This was the cause of the ordeal of the morning. The chip was replaced with a new one from our stock. The preliminary test with the OSEM emulator showed that the channel has the correct DC value.

In further testing of the board, we found that the channel 8 LED driver was not working properly. Although this channel is never used in our current cable convention, it might be used later in the future. In the quest of debugging the issue there, we replaced AD8672ARZ at U1 on channel 8. This did not solve the issue. So we opened the front panel and as we flipped the board, we found that the solder blob shorted the legs of the transistor Q1 2N3904. This was replaced and the test with the LED out and GND shorted indicated that the channel is now properly providing a constant current of 35mA (5V at the monitor out).

After the debugging, the UL channel became the least noisy among the OSEM channels! Mode cleaner was able to lock and maintain it.

We should redo the MC1 input matrix optimization and the coil balancing afterward as we did everything based on the noisy UL OSEM values.

Attachment 1: MC1_UL_Channel_Fixed.png
16140   Fri May 14 03:29:50 2021 KojiUpdateElectronicsHV Driver noise test with the new HV power supply from Matsusada

I believe I did the identical test with the one in [40m ELOG 15786]. The + input of PA95 was shorted to the ground to exclude the noise from the bias input. The voltage noise at TP6 was measured with +/-300V supply by two HP6209 and two Matsusada R4G360.

With R4G360, the floor level was identical and 60Hz line peaks were less. It looks like R4G360 is cheap, easier and precise to handle, and sufficiently low noise.

Attachment 1: HV_Driver_PSD.pdf
16141   Fri May 14 17:45:05 2021 ranaUpdatePSLHEPA speed raised

The PSL was too hot, so I turned on the south HEPA on the PSL. The north one was on and the south one was off (or so slow as to be inaudible and no vibration, unlike the north one). Lets watch the trend over the weekend and see if the temperature comes down and if the PMC / WFS variations get less. Fri May 14 17:46:26 2021

16142   Sat May 15 12:39:54 2021 gautamUpdatePSLNPRO tripped/switched off

The NPRO has been off since ~1AM this morning it looks like. Is this intentional? Can I turn it back on (or at least try to)? The interlock signal we are recording doesn't report getting tripped but I think this has been the case in the past too.

After getting the go ahead from Koji, I turned the NPRO back on, following the usual procedure of diode current ramping. PMC and IMC locked. Let's see if this was a one-off or something chronic.

Attachment 1: NPRO.png
16143   Sat May 15 14:54:24 2021 gautamUpdateSUSIMC settings reverted

I want to work on the IFO this weekend, so I reverted the IMC suspension settings just now to what I know work (until the new settings are shown quantitatively to be superior). There isn't any instruction here on how to upload the new settings, so after my work, I will just restore from a burt-snapshot from before I changed settings.

In the process, I found something odd in the MC2 coil output filter banks. Attachment #1 shows what it it is today. This weird undetermined state of FM9 isn't great - I guess this flew under the radar because there isn't really any POS actuation on MC2. Where did the gain1 filter I installed go? Some foton filter file corruption? Eventually, we should migrate FM7,FM8-->FM9,FM10 but this isn't on my scope of things to do for today so I am just putting the gain1 filter back so as to have a clean FM9 switched on.

 Quote: The old setting can be restored by running python3 /users/anchal/20210505_IMC_Tuned_SUS_with_Gains/restoreOldConfigIMC.py from allegra or donatella.

I wrote the values from the c1mcs burt snapshot from ~1400 Saturday May 15, at ~1600 Sunday May 16. I believe this undoes all my changes to the IMC suspension settings.

Attachment 1: MC2coilOut.png
16144   Tue May 18 00:52:38 2021 ranaUpdatePSLHEPA speed raised

Looks like the fan lowered the temperature as expected. Need to get a few more days of data to see if its stabilized, or if that's just a fluke.

The vertical line at 00:00 UTC May 18 is about when I turned the fans up/on.

Attachment 1: Untitled.png
ELOG V3.1.3-