I have further updated my calculation. Please find the results in the attached pdf.

Following is the description of calculations done:

Arm cavity reflection:

Reflection fro arm cavity is calculated as simple FP cavity reflection formula while absorbing all round trip cavity scattering losses (between 50 ppm to 200 ppm) into the ETM transmission loss.

So effective reflection of ETM is calculated as

The magnitude and phase of this reflection is plotted in page 1 with respect to different round trip loss and deviation of cavity length from resonance. Note that the arm round trip loss does not affect the sign of the reflection from cavity, at least in the range of values taken here.

PRC Gain

The Michelson in PRFPMI is assumed to be perfectly aligned so that one end of PRC cavity is taken as the arm cavity reflection calculated above at resonance. The other end of the cavity is calculated as a single mirror of effective transmission that of PRM, 2 times PR2 and 2 times PR3. Then effective reflectivity of PRM is calculated as:

Note, that field transmission of PRM is calculated with original PRM power transmission value, so that the PR2, PR3 transmission losses do not increase field transmission of PRM in our calculations. Then the field gain is calculated inside the PRC using the following:

From this, the power recycling cavity gain is calculated as:

The variation of PRC Gain is showed on page 2 wrt arm cavity round trip losses and PR2 transmission. Note that gain value of 40 is calculated for any PR2 transmission below 1000 ppm. The black verticle lines show the optics whose transmission was measured. If V6-704 is used, PRC Gain would vary between 15 and 10 depending on the arm cavity losses. With pre-2010 ITM, PRC Gain would vary between 30 and 15.

LO Power

LO power when PRFPMI is locked is calculated by assuming 1 W of input power to IMC. IMC is assumed to let pass 10% of the power (). This power is then multiplied by PRC Gain and transmitted through the PR2 to calculate the LO power.

Page 3 shows the result of this calculation. Note for V6-704, LO power would be between 35mW and 15 mW, for pre-2010 ITM, it would be between 15 mW and 5 mW depending on the arm cavity losses.

The power available during alignment is simply given by:

If we remove PRM from the input path, we would have sufficient light to work with for both relevant optics.

I have attached the notebook used to do these calculations. Please let me know if you find any mistake in this calculation.

The main issue with SR2 OSEMs, now that I think of it, was that the BS table was very inclined due to the multiple things we removed (including counterweights). Today the first I did was level the BS table by placing some counterweights in the correct positions. I placed the level in two directions right next to SR2 (clamped in its planned place), and made the bubble center.

While doing do, at one point, I was trying to reach the far South-West end of the table with the 3x heavy 6" cylindrical counterweight in my hand. The counterweight slipped off my hand and fell from the table. See the photo in attachment 1. It went to the bottommost place and is resting on its curved surface.

This counterweight needs to be removed but one can not reach it from over the table. So to remove it, we'll have to open one of the blank flanges on the South-west end of BS chamber and remove the counterweight from there. We'll ask Chub to help us on this. I'm sorry for the mistake, I'll be more careful with counterweights in the future.

Moving on, I tuned all the SR2 OSEMs. It was fairly simple today since the table was leveled. I closed the chamber with the optic free to move and damped in all degrees of freedom.

Photos: https://photos.app.goo.gl/CQ6VouSB1HX2DPqW6

SUSPENSION STATUS UPDATED HERE

AS4 is set to go through a free swinging test at 10 pm tonight. We have used this script (Git/40m/scripts/SUS/InMatCalc/freeSwing.py) reliably in the past so we expect no issues, it has a error catching block to restore all changes at the end of the test or if something goes wrong.

To access the test, on allegra, type:

Then you can kill the script if required by Ctrl-C, it will restore all changes while exiting.

SR2 is set to go through a free swinging test at 3 am tonight. We have used this script (Git/40m/scripts/SUS/InMatCalc/freeSwing.py) reliably in the past so we expect no issues, it has a error catching block to restore all changes at the end of the test or if something goes wrong.

To access the test, on allegra, type:

Then you can kill the script if required by Ctrl-C, it will restore all changes while exiting.

The free swinging test was successful. I ran the input matrix diagonalization code (/opt/rtcds/caltech/c1/Git/40m/scripts/SUS/InMAtCalc/sus_diagonalization.py) on theSR2 free-swinging data collected last night. The logfile and results are stored in /opt/rtcds/caltech/c1/Git/40m/scripts/SUS/InMAtCalc/SR2 directory. Attachment 1 shows the power spectral density of the DOF basis data (POS, PIT, YAW, SIDE) before and after the diagonalization. Attachment 2 shows the fitted peaks.

1.09

0.914

0.622

0.798

-0.977

1.249

0.143

-1.465

-0.359

0.378

0.552

-1.314

-0.605

1.261

0.118

0.72

0.403

0.217

0.534

3.871

The new matrix was loaded on SR2 input matrix and this resulted in no control loop oscillations at least. I'll compare the performance of the loops in future soon.

The free swinging test was successful. I ran the input matrix diagonalization code (/opt/rtcds/caltech/c1/Git/40m/scripts/SUS/InMAtCalc/sus_diagonalization.py) on the AS4 free-swinging data collected last night. The logfile and results are stored in /opt/rtcds/caltech/c1/Git/40m/scripts/SUS/InMAtCalc/AS4 directory. Attachment 1 shows the power spectral density of the DOF basis data (POS, PIT, YAW, SIDE) before and after the diagonalization. Attachment 2 shows the fitted peaks.

0.844

0.707

0.115

0.253

-1.646

0.122

0.262

-1.319

-1.459

0.214

1.087

-0.901

-0.874

1.114

0.016

0.622

0.934

0.357

0.045

3.822

The new matrix was loaded on AS4 input matrix and this resulted in no control loop oscillations at least. I'll compare the performance of the loops in future soon.

I placed LO2 in its planned position in BS chamber, inserted the OSEMs, and tuned their position to halfway brightness. At the end of the work, I was able to damp the optic successfully. The full open (full brightness) OSEM ADC counts are:

UL 25743.  -> 12876
UR 27384. -> 13692
LL 25550. -> 12775
LR 27395 -> 13697
SD 28947 -> 14473

Today's OSEM tuning was relatively unhappening. I have only following two remarks:

• BS table was 3 SOS near the East end and PRM is parked in the center, thus the table is very unevenly balanced. I had to use all available counter weights to make it flat near the LO2 suspension.
• The side OSEM for LO2 is not exactly centered (probably due to table imbalance). I was able to balance the table to a point though that the side OSEM was responsive to full range and I was able to damp the optic.

Free swinging test set to trigger

LO2 is set to go through a free swinging test at 10 pm tonight. We have used this script (Git/40m/scripts/SUS/InMatCalc/freeSwing.py) reliably in the past so we expect no issues, it has a error catching block to restore all changes at the end of the test or if something goes wrong.

To access the test, on allegra, type:

Then you can kill the script if required by Ctrl-C, it will restore all changes while exiting.

Photos: https://photos.app.goo.gl/Ff3yGBprj9xgPbnLA

SUSPENSION STATUS UPDATED HERE

I agree. That's an interesting idea. But does that mean that there is an always working inverse matrix solution or that any solution will be vulnerable to the alignment biases.

I think we can also calculate the matrix rotation required as a function of dc biases and do that rotation in the simulimk model.

The free swinging test was successful. I ran the input matrix diagonalization code (/opt/rtcds/caltech/c1/Git/40m/scripts/SUS/InMAtCalc/sus_diagonalization.py) on the LO2 free-swinging data collected last night. The logfile and results are stored in /opt/rtcds/caltech/c1/Git/40m/scripts/SUS/InMAtCalc/LO2 directory. Attachment 1 shows the power spectral density of the DOF basis data (POS, PIT, YAW, SIDE) before and after the diagonalization. Attachment 2 shows the fitted peaks.

0.46

1.237

1.094

0.318

0.98

1.091

0.252

-1.512

-0.672

-0.088

0.722

-1.014

-0.217

1.519

0.314

-0.747

1.523

1.737

-0.534

3.134

The new matrix was loaded on LO2 input matrix and this resulted in no control loop oscillations at least. I'll compare the performance of the loops in future soon.

For some reasonf the free swing test showed only one resonance peak (see attachment 1). This probably happened because one of the earthquake stops is touching the optic. Maybe after the table balancing, the table moved a little over its long relazation time and by the time the free swing test was performed at 3 am, one of the earthquake stops was touching the optic. We need to check this when we open the chamber next.

I noticed that our current suspension damping loops for the new SOS were railing the DAC outputs. The reason being that cts2um module has not been updated for most optics and thus teh OSEM signal (with the new Sat Amps) is about 30 times stronger. That means our usual intuition of damping gains is too high without applying correct conversion cts2um filter module. I reduced all these gains today and nothing is overflowing the c1su2 chassis now. I also added two options in the "!" (command running drop down menu) in the sus_single medm screens for opening ndscope for monitoring coil outputs or OSEM inputs of the optic whose sus screen is used.

[Anchal, Paco]

We removed the old PR3 housed in a tip-tilt style suspension and put it on the North flow bench in the cleanroom. I put PR3 in an accessible position near the North West edge of the BS chamber and balanced the table again with many weights. The OSEM tuning was very uneventful and easy. Following are the full brightness ADC counts for the OSEMs:
UL 25693. -> 12846
UR 24905. -> 12452
LL 23298. -> 11649
LR 24991. -> 12495
SD 26357. -> 13178

I was able to damp the optic easily after the OSEM installation with no issues.

Photos: https://photos.app.goo.gl/jcAqwFJoboeUuR7F9

AS1, PR2 and PR3 are set to o go through a free swinging test at 3 am. We have used this script (Git/40m/scripts/SUS/InMatCalc/freeSwing.py) reliably in the past so we expect no issues, it has a error catching block to restore all changes at the end of the test or if something goes wrong.

To access the test, on allegra, type:

Then you can kill the script if required by Ctrl-C, it will restore all changes while exiting.

The free swinging test was successful. I ran the input matrix diagonalization code (/opt/rtcds/caltech/c1/Git/40m/scripts/SUS/InMAtCalc/sus_diagonalization.py) on the PR2 free-swinging data collected last night. The logfile and results are stored in /opt/rtcds/caltech/c1/Git/40m/scripts/SUS/InMAtCalc/PR2 directory. Attachment 1 shows the power spectral density of the DOF basis data (POS, PIT, YAW, SIDE) before and after the diagonalization. Attachment 2 shows the fitted peaks. I chose to not type out the matrix values now. One can find them in teh repo links above.

The free swinging test was successful. I ran the input matrix diagonalization code (/opt/rtcds/caltech/c1/Git/40m/scripts/SUS/InMAtCalc/sus_diagonalization.py) on the PR3 free-swinging data collected last night. The logfile and results are stored in /opt/rtcds/caltech/c1/Git/40m/scripts/SUS/InMAtCalc/PR3 directory. Attachment 1 shows the power spectral density of the DOF basis data (POS, PIT, YAW, SIDE) before and after the diagonalization. Attachment 2 shows the fitted peaks. I chose to not type out the matrix values now. One can find them in teh repo links above.

We still did not get a good AS1 free swinging spectrum. It seems the Side OSEM is reporting coupling to too many DOFs and some extra resonances than we expect. So we did not upload the new input matrix calculated from this test. I'm attaching teh peak fitting (attachment 1) and the diagonalization attempt (attachment 2) to give some idea of what happened. Note how different this fre swinging spectrum looks from the other optics. Given that Yehonathan also felt that somthing might be off with this optic, we need to reevaluate if the suspension has wire not aligned in grove, or it is imbalanced or something else if touching it still.

Please edit this same entry throughout the day for the shutdown elogging.

I took a screenshot of C0VAC_MONITOR.adl to ensure that all pnematic valves are in closed positions:

The status message says "All pnematic valves closed" and the latest error message is about "V7 closed, N2 < 6.50e+01".

I found out that there was no autoburt happening for c1vac channels. I created an autoBurt.req file for the vac.db file and saved one snapshot. I also added the path of this file in autoburt/.requestfilelist . Let's see if autoburting starts by that for this file as well.

With this, I think we can safely shutdown acromag chassis. Hopefully, the relays are configured such that the valves are nominally closed in absence of a control signal. After the chassis is shut down, wwe can shutdown C1VAC by:

[Chub, Jordan]

At the 1x8 rack, the following were switched off on their respective front panels:

PTP2 & PTP3 Controller
MKS Gauge controller
PRP Gauge Controller
G2P316a & b Controllers
Sorenson
Serial Device Server
Both UPS's

Powered off from back of unit:

TP1 Controller
Acromag chassis

TP2 and 3 controllers were unplugged from respective power strips (labeled C2 and C3)

C1vac and the laptop at the workstation were shut down

Manual Gate valve was closed

[Anchal, Paco]

Bringing back CDS took a lot of work yesterday. I'm gonna try to summarize the main points here.

mx_start_stop

For some reason, fb1 was not able to mount mx devices automatically on system boot. This was an issue I earlier faced in fb1(clone) too. The fix to this problem is to run the script:

To make this persistent, I've configured a daemon (/etc/systemd/system/mx_start_stop.service) in fb1 to run once on system boot and mount the mx devices as mentioned above. We did not see this issue of later reboots yesterday.

gpstime

Next was the issue of gpstime module out of date on fb1. This issue is also known in the past and requires us to do the following:

Again, to make this persistent, I've configured a daemon (/etc/systemd/system/re-add-gpstime.service) in fb1 to run the above commands once on system boot. This corrected gpstime automatically and we did not face these problems again.

time synchornization

Later we found that fb1-FE computers, ntp time synchronization was not working and the main reason was that fb1 was unable to access internet. As a rule of thumb, it is always a good idea to try pinging www.google.com on fb1 to ensure that it is connected to internet. The issue had to do with fb1 not being able to find any namespace server. We fixed this issue by reloading bind9 service on chiara a couple of times. We're not really sure why it wasn't working.

After the above, we saw that fb1 ntp server is working fine. You see following output on fb1 when that is the case:

On the FE models, timedatectl should show that NTP synchronized feild is yes. That wasn't happening even after us restarting the systemd-timesyncd service. After this, I just tried restarting all FE computers and it started working.

CDS

We had removed all db9 enabling plugs on the new SOSs beforehand to keep coils off just in case CDS does not come back online properly.

Everything in CDS loaded properly except the c1oaf model which kepy showing 0x2bad status. This meant that some IPC flags are red on c1sus, c1mcs and c1lsc as well. But everything else is green. See attachment 1. I then burtrestroed everything in the /opt/rtcds/caltech/c1/burt/autoburt/snapshots/2022/Feb/4/12:19 directory. This includes the snapshot of c1vac as well that I added on autoburt that day. All burt restore statuses were green OK. I think we are in good state now to start watchdogs on the new SOSs and put back the db9 enabling plugs.

Future work:

When somebody gets time, we should make cutom service files in fb1:/etc/systemd/system/ symbolic links to a repo directory and version control these important services. We should also make sure that their dependencies and startup order is correctly configured. I might have done a half-assed job there since I recently learned how to make unit files. We should do the same on nodus and chiara too. Our hope is that on one glorious day, the lab can be restarted without spending more than 20 min on booting up the computers and network.

I found out that the ESP300 service needs to be run in root mode for it to be able to connect to the USB port of HWP motor controller. While doing this change, I noticed that the channels hosted by c1psl might have a duplication conflict with some other channel hosting computer, because a lot of them show the Warning: "Identical process variable names on multiple servers" which is not good. Someone should look into this conflict.

I added instructions on the power control MEDM screen as it was very non-trivial to use. I have set the power such that the C1:IOO-MC_RFPD_DCMON is 5.6 and this happened at C1:IOO-HWP_POS_SET 2.29.

Something is wrong with the Video MUX. The system did not turn back on with full functionality. Even though we see the screens as they were before the power shutdown, we have lost control on switching any of the videos. I went to check the wiki page about Video MUX which told be we should be able to see the configuration screen on this link, but the page wasn't opening. I went and removed the power cable and put it back in. That brought back the configuration page. Still, I could not change any of the video feeds however this time, I could see the EPICS channel values (like C1:VID-QUAD1_4) change. I tired to go to the configuration page and change the matrix values from the control tab there. I found out that the matrix was mislabeled and while making the changes, I started seeing blue screen on QUAD1_3 (where MC2T was set before). I set the QUAD1_3 (output 23) to MC2T (input 16), but no change. The EPICS values are also set properly, so I don't understand the reason behind blue screen. The same happened when I tried to use:

Weirdly, this caused the QUAD1_4 screen to go blue. Running following had no effect:

So, I'm not sure what to do. This really needs to be fixed! I wanted to see teh MC2F camera so that I can align IMC, that was the whole reason for this rabit hole. Help needed.

Yeah, this is a known issue actually. We go to ASC screen and manually swich off all the outputs after every reboot. We haven't been able to find a way to set default so that when the model comes online, these outputs remain switched off. We should find a way for this.

I found that two computers are not powering up in the control room, Ottavia and Allegra. Allegra was important for us as it had the current version of LIGO CDS workstation installed on, providing us with options to use latest packages written by LIGO CDS team. I think the power issue should be resolvable if someone opens it and knows what thye are doing. Do we have any way of getting fuse repairs on such computers? Both these computers are Dell XPS 420.

We increased the input power to IMC by replacing the 98% transmission BS by a 10% transmission BS on the detection table (reverse of what mentioned in 40m/16408 see attachment 8-9). We then realigned the BS so that MC RFPD is centered. Then we realigned two steering mirrors to get the beam centered on the WFS1 and WFS2 QPD. Then we increased the power of the input beam to get 5.307 reading on the C1:IOO-MC_RFPD_DCMON channel. We did this so that we can align the IMC. Once we have it aligned, we'll go back to low poer for doing chamber work.

Beware, there is about 1W beam on the detection table right now.

The autoBurt file for FE already has the C1:ASC-ETMX_PIT_SW2 (and other channels for ETMY, ITMX, ITMY, BS and for YAW) present, and I checked the last snapshot file from Feb 7th, 2022, which has 0 for these channels. So I'm not sure why when FE boots up, it does not follow the switch configuration. Fr safety, I changed all the gains of these filter modules, named like C1:ASC-XXXX_YYY_GAIN (where XXXX is ETMX, ETMY, ITMX, ITMY, or BS , and YYY is PIT or YAW) to 0.0. Now, even if the FE loads with switches in ON configuration, nothing should happen. In future, if we use this model for anything, we can change the gain values which won't be hard to track as the reason why no signal moves forward. Note, the BS connections from this model to BS suspension model do not work.

I reconfigured the MC reflection path for low power. This meant the following changes:

• Replaced the 10% reflection BS by 98% reflection beam splitter
• Realigned the BS angle to get maximum on C1:IOO-MC_RFPD_DCMON when cavity is unlocked.
• Then realigned the steering mirrors for WFS1 and WFS2.
• I tried to align the light for MC reflection CCD but then I realized that the pickoff for the camera is too low for it to be able to see anything.

Note, even the pick-off for WFS1 and WFS2 is too low I think. The IOO WFS alignment does not work properly for such low levels of light. I tried running the WFS loop for IMC and it just took the cavity out of the lock. So for low power scenario, we would keep the WFS loops OFF.

As discussed in the meeting, I removed the extra beam splitter that dumps most of the beam going towards WFS photodiodes. This beam splitter needs to be placed back in position before increasing the input power to IMC at nominal level. This is to get sufficient light on the WFS photodiodes so that we can keep IMC locked for more than 3 days. Currently IMC is unlocked and misaligned. I have marked the position of this beam splitter on the table, so putting it back in should be easy. Right now, I'm trying to align the mode cleaner back and start the WFS loops once we get it locked.

I found a peculiar issue today. The C1:IOO-MC_RFPD_DCMON remains constantly 0. I wonder if the RFPF output is being read properly. I opened the table and used an oscilloscope to confirm that the DC output from the MC REFL photodiode is coming consistently but our EPICs channel is not reading it. I tried restarting the modbusIOC service but that did not affect anything. I power cycled the acromag chassis while keeping the modbusIOC service off, and then restarted teh modbusIOC service. After this, I saw more channels got stuck and became unresponsive, including the PMC channels. So then I rebooted c1psl without doing anything to the acromaf chasis, and finally things came back online. Everything looks normal to me now but I'm not sure if one of the many channels is not in the right state. Anyways, problem is solved now.

I think I have aligned the cavity, including MC1 such that we are seeing flashing of fundamental mode and significant transmission sum value as well.However, I'm unable to catch lock following Koji's method in 40m/16673. Autolocker could not catch lock either. Maybe I am doing something wrong, I'll pickup again tomorrow, hopefully the cavity won't drift too much in this time.

c1teststand has been restructured. There is no port computer called 'c1teststand' anymore. When you ssh into the c1teststand network using ssh c1teststand from inside martian or from outside network using the method mentioned in this wiki page , you would land into chiara (clone) computer and you can navigate into any teststand network computer from there.

I'll be repurposing 1U c1teststand computer into the new c1susaux2 slow machine now. All files from home directory and from /etc directory of former c1teststand have been zipped and stored in /home/controls of chiara (clone). Just a aside, the network configuration of teststand can be done from inside the teststand network, by going to a browser on either fb1 (clone) or chair (clone) and going to address 10.0.1.1. The login and password are same as our usual workstation username and password.

I took the c1teststand computer from teststand and converted it into c1susaux2. To do so, I installed a fresh copy of debian 10 on it and followed the steps on this wiki page. I did some parts slightly differently though. The directory /cvs/cds/caltecg/c1susaux2 is a repository and contains the service unit file modbusIOC.service as well. A symbolic link is created at /etc/systemd/system to use this service file for creating the modbusIOC service. All db files are generated by parsing the acromag chassis wiring file using this python script.

The service file is running without any errors now and all channels are available. The leftmost bench on EEshop at 40m is now ready to do LO1 slow controls and monitor testing. If someone gets time today, they can hookup an unused coil driver to the chassis and verify ENABLE switching and monitoring through the optical isolators. We can also drive some voltage on the PD monitors and verify the functioning of our ADCs. Once this test passes, it is straight forward to finish the remaining 6 SOS wiring and we would be good to install the chassis.

Attaching wiring diagram of c1susuaux2 acromag chassis. Any comments/modification suggestions should come soon as we'll go ahead and wire it soon.

Note: While accessing channels using caget on c1susuaux2, you might get a warning "Identical process variable names on multiple servers". You can safely ignore it. It just means that channel is accessible on that particular computer via two different network interfaces (martian network eno1 and acromag subnetwork eno2) and it will just pick one of them.

I tried to perform a simple enabling test of coils using c1susaux2 modbus channels but failed. I'm able to do the enabling of coils using the windows GUI of acromag card but I can not do it when the cards are connected to the computer subnetwork. The issue is two-fold:

• The enable channels such as C1:SUS-LO1_UL_ENABLE are not changing values when their DOL changes a value. In this case, I created a calc channel C1:SUS-LO1_ALL_CALC which takes the AND of all coil's individual CALC channels which are normally used as DOL for the ENABLE channels. But even though the changes are reflected properly to C1:SUS-LO1_ALL_CALC, it does not affect C1:SUS-LO1_UL_ENABLE. See the db files here for more info.
• I tried to directly change the value of C1:SUS-LO1_UL_ENABLE using caput and even though in soft value the channel changes, it does not propagate a change at the output of Acromag card. So my suspicion is that something might be off with the setting of the Acromag card or c1susuaux2.cmd file. I followed this wiki page instructions, but if anyone can find an error, it would be useful.

There's also an issue in reading back the ENABLE_MON channels. Here we suspect that one of the optical isolator box that we have been using might have a short in one of it's output channel. I'll investigate this more tomorrow. Again, the issue is two-fold. The EPICS channel values do not really change. So there is clearly some issue of communicating with the acromag cards.

[Anchal, Yehonathan, Ian]

We installed c1susaux2 acromag chassis in 1Y0 with c1susaux2 computer. We connected PD monitors, Binary inputs, Binary outputs, and Run/Acquire RTS signals for 6 of the 7 suspensions. We ran out of DB9 cables to connect PR3. Of the ones that were connected, LO2, AS1, AS4, SR2, and PR2 are showing no issues in the functionality from the chassis. For LO1, everything is working except for UR EnableMon channel. The enable monitor does not show an ON state for the coil even though the coil driver chassis shows that it is ON via the LED lights. A possible reason could be that a wire got disconnected when we closed the chassis (there are a lot of wires pushing against each other. Another reason could be that the optical isolator ISO10 could have developed a bad channel on channel 2. The circuit was tested before closing the chassis, so not sure what went wrong after closing it.

PR2 is showing a non-acromag chassis related issue. As soon as we close the loop by enabling the coils, the watchdog triggers because the loop is unstable. Not sure what has changed for PR2, but someone should take a look at it.

For the issue with LO1, I suggest we keep a note that the C1:SUS-LO1_UR_ENABLEMon channel is faulty and don't take its value seriously. We should diagnose and fix this issue once we have more reasons to disconnect the chassis and open it.

I routed the XXX_COIL_DW signals from the 7 SOS blocks in c1su2.mdl (located at /cvs/cds/rtcds/userapps/trunk/sus/c1/models/c1su2.mdl) to the binary outputs from the FE model. The routing is done such that when these binary outputs are routed through the binary interface card mounted on 1Y0, they go to the acromag chassis just installed and from there they go to the binary inputs of the coil drivers together with the acromag controlled coil outputs.

I have not restarted the rtcds models yet. This needs more care and need to follow instructions from 40m/16533. Will do that sometime later or Koji can follow up this work.

I have restarted c1su2 model with the connections of Run Acquire switch to analog filters on coil drivers. Following steps were taken:

First ssh to c1sus2 and then:

Then on rossa, run activateSUS2DQ.py which creates a file C1SU2.ini.NEW. Remove old backup file C1SU2.ini.bak, rename C1SU2.ini to C1SU2.ini.bak and rename C1SU2.ini.NEW to C1SU2.ini:

Then ssh back to c1sus2 and restart the rtcds model:

Then restart daqd services from rossa and burtrestore to latest snap of c1su2epics.snap:

All suspensions are back online and everything is same as before now. Will test later the Run/Acquire switch functionality.

http://nodus.ligo.caltech.edu:8080/40m/16722

http://nodus.ligo.caltech.edu:8080/40m/16716

[Paco, Anchal]

BS Chamber work

• ASL was positioned in nominal place.
• PR3 was moved to its nominal place from temprorary position.
• BS Table was rebalanced
• Earthquake stops were removed from all SOS from BS table (LO2, SR2, BS, PR3)

ITMY Chamber work

• AS2, AS3, LO3, LO4, and BHDBS were positioned in the nominal place.
• AS1 was moved to its nominal place from temporary position.
• ITMY tbale was rebalanced
• Earthquake stops were removed from all SOS from ITMY table (AS1, AS4, ITMY)

[Anchal, Yehonathan] (on Y Arm)

We first checked if the PZT mirrors M1 and M2 can be controlled. They indeed show no motion even after being connected with a power supply. So green injection path can not be aligned using cds controls right now.

We also noticed that all ETMY slow controls and monitors are offline. That's because the electronics upgrade did not include acromag chassis. This means that the DC bias adjustment is not accessible for ETMY.

Alignment work:

• We first aligned the green injection beam to cross two irises in the injection path to ETMY chamber.
• Then I (Anchal) went inside the ITMY chamber to find the green light. Yehonathan controlled the injection path while I gave feedback from ITMY side. We aligned injection path to get the beam near center of ITMY.
• Then I aligned ITMY through sitemap>IFO>Align to get counter propagating reflection near the ITMY side.
• We were able to see reflection from ETMY hitting the beam tube.
• Since DC alignment controls of ETMY are not accessible, we used the Alignment offset in rtcds model which puts dc offset in the coil driver to get the reflected beam from ETMY to come to ITMY table, about 1 inch above the table and about 3 inch south of ITMY SOS.
• But we got limitted by the DAC overflow on ETMY at this point. Several back and forth attempts to relief ETMY were unsuccesful.

Possible issues:

• We think having the HV coil driver set up for ETMY is important for this alignment work if not essential. The coil drivers of ETMY are near saturation.
• We also think that addition of two new suspensions in ITMY table and then counter weights to balance the table, has depressed table height slightly. We need to work out how to change injection path height and angle accordingly.

[Paco, Ian] (on X Arm)

http://nodus.ligo.caltech.edu:8080/40m/16732

[Anchal, Tega]

We installed c1auxey1 computer and the acromag chassis in 1Y4. The computer has been configured properly for nfs mounts to happen and we have initialized a git repo for /cvs/cds/caltech/target/c1auxey1 directory which stores all files for running modbusIOC service on this computer. We connected 18V power source but have not connected the 24V power yet  as we need to make a new connector for it. Going on what Koji recommended, we'll connect the 24V power input to 18 V strip as well as the acromags can run on that voltage too.

I started the modbusIOC service on c1auxey1 and added PD variance channels for UR and SD as well.  There are unfortunately two issues here:

• The enable monitors are reading NOT of what they should read. The optical isolator circuit might need to be changed.
• ETMY is not damping now. This is strange and was seen in the use to other acromag chassis as well where AS4 and PR2 are unable to damp. This is weird since the acromag chassis are not part of the damping loop, maybe it is a coincidence. Next time we should check if we still have this issue when acromag chassis is disconnected from ETMY.

I'm not sure why but the PIT and YAW offset values of +2725 and -2341 were not sufficient for the reflected OPLEV beam to reach the OPLEV QPD. I had to change the C1:SUS-ETMY_PIT_OFFSET to 5641 and C1:SUS-ETMY_YAW_OFFSET to -4820 to come back to center of the OPLEV QPD. We aligned the Oplevs to center before venting, so hopefully this is our desired ETMY position.

On another note, the issue of ETMY unable to damp was simple. The alignment offsets were on to begin with with values above 1000. This meant that whenever we enabled coil output, ETMY would necessarily get a kick. All I had to do was keep alignment offsets off before starting the damping and slowly increase the alignment offsets to desired position.

[Anchal, Tega]

We did the following alignment steps on Yarm today:

• We aligned the green beam going into the ETMY chamber to the three irises on the path.
• We aligned ETMY to get counter-propagating prompt reflection from ETMY.
• We were able to see light in the reflection photodiode for the green PDH loop.
• Then we went to ITMY chamber and checked where the beam is coming to. It was coming very low in height.
• We walked the beam on the end to get it near the center of ITMY.
• Then we changed the ETMY alignment again to get back the reflection beam on the reflection photodiode.
• Then we went again to ITMY chamber and changed the ITMY alignment to get counter-propagating reflection from ITMY.

After this, we came back to the control room. One peculiar thing to note is that the C1:LS-Y_REFL_DC_OUT channel is inverted i.e. it is showing negative values for the reflection DC voltage. On this signal, we see a little bit higher-order mode flashing but it is not bright enough to be seen on the face camera of the suspension. We'll continue aligning the cavity using CDS now to get TEM00 mode.

After trying for a bit, we were able to get flash of about 2000 counts which is about 16% of the max value of 12200 counts. We adjusted the ITMY angular position using the IFO_ALIGN screen but used the OPTICAL_ALIGN offset screen to adjust the angular position of ETMY. The pitch and yaw values for ITMY are 1.0360 and -0.260 respectively whereas the pitch and yaw values for ETMY are 5664.0 and -4937.0 respectively. 

Another issue, Green Y Shutter can not be controlled with the EPICS controls right now. This needs to be investigated.

[Anchal, Paco]

Uneloged: yesterday, Paco and Ian tried locking the green laser on Yend to the Y-arm. Nothing noteworthy happened, no luck.

• Started with aligning the green injection to the Iris on table (it was misaligned) and getting it on the ITMY center.
• Then we realized that the beam is going through the focusing leans very offceter. This makes the beam warped and deflected inside that needs to be corrected by mirrors.
• So we decided to adjust the lens position first.
• We realized that lens position is hard to adjust along with keeping the beam hiting ITMY.
• So, we decided to remove the lens first and just align the green beam directly with the Iris on the table and the ITMY center. The beam became as big as ITMY when it reached there without the lens in path. We aligned it to fall on the mirror.
• Then we placed the lens back so that the beam goes through the center of the lens.
• Then we aligned ETMY to get the reflection back to the reflection PD.
• But then when we checked the beam at ITMY again, it was severely missing ITMY. The possible reason is that ETMY is a diverging lens for the beam as well and changing its position changed the beam direction in the beam tube.
• We decided to do another iteration of lens positioning with the new ETMY position. So same steps, removed lens, aligned beam with iris and ITMY, placed back the lens, aligned ETMY again to get reflection back on the PD.
• This time the beam was still reaching ITMY. So we were glad that our iterations converged in 2 repititions.
• Then we aligned ITMY to get counter propagating beam.
• At the end of this alignment:
  • We see dips in relfection photodiode counts from 12200 to 9500.
  • The ETMY oplev is partially out of range (only 1 of the quadrant seeing light) but that could be because we changed the lens position. So Oplev servo is off.
• We confirmed that the PDH servo is properly connected and loop is on. But we see no HOM catching lock for YARM even after us doing about 10 min search with ITMY-ETMY alignments.
• We are leaving things as it is. We'll continue trying to align the cavity tomorrow. Everyone is welcome to try as long as they restore the positions of the optics to a good state at the end.

After Ian updated the cts2um filters for OSEM, shouldn't the damping gains be increased back by factor of 10 to previos values? Was the damping gain for SIDE ever changed? we found it at 250.

Can you explain why gain_offset filter was required and why this wasn't done for the side coil?

[Anchal, Paco, Shruti]

• Today we found out that the laser controller at the Yend had it's inputs disconnected for the FAST PZT input and the Slow temperature control input. The cables were also not labeled that were lying nearby.
• I tracked the cables and connected the Fast input adn the slow input.
• We then adjusted the temperature slider to go to previously marked laser crystal temperature of 40.1 degrees celsius. But we could not find the the beatnote of Y end IR with teh Main laser IR.
• We scanned the laser crystal temeprature until we could see a beatntoe with the main IR laser and stopped in that region.
• Then we continued looking for flashing and HOM, but no luck.
• It was interesting that when the PDH loop was closed, we saw fluctuations in relfection photodiode DC value, but not so much when the loop was not closed.
• We tried flipping the sign of the loop with no luck and we tried changing the gain of the loop as well, but no luck.
• The behavior of this Yend laser and its controller is still suspicious to us. When the loop is closed, the PZT feedback signal should not cause a change in amplitude of the light so much as we see it.
• Also the fact that when loop is clsoed we do not see signs of flashing in the reflection photodiode is interesting. If anyone has any ideas, that would be good.

[Anchal, JC, Ian, Paco]

We have now fixed all issues with the PD mons of c1susaux2 chassis. The slow channels are now reading same values as the fast channels and there is no arbitrary offset. The binary channels are all working now except for LO2 UL which keeps showing ENABLE OFF. This was an issue earlier on LO1 UR and it magically disappeared and now is on LO2. I think the optical isolators aren't very robust. But anyways, now our watchdog system is fully functional for all BHD suspended optics.

[Paco, Anchal, Ian, JC]

We attempted the alignment of IR beam into the arm cavities. We used PR2 and PR3 (moved manually as well as using cdsutils) and got the YAW aligned pretty good on both X and Y directions. PIT alignment however turned out to be much harder to align. PR2 PR3 didn't have much range, so we zeroed there offset and tried to use TT1, TT2, MMT1, and MMT2 to align the PIT but it would get clipped before reaching BS table if we were to correct for PIT misalignment happening downstream. We concluded that the issue is that one of the PR2, PR3 mirrors have too much PIT offset in equilibrium position. We have requested Koji to change the output resistors in the coil drivers of PR2 and PR3 so that we can correct for the PIT offset in them directly using the coils and reduce load on upstream optics. We have tweaked TT1, TT2, MMT1, and MMT2 positions today, so we do not have the previous reference anymore.

[Anchal, Paco]

After Koji reduced the output resistors on PR2/PR3 coil drivers, we got much better actuation range. We aligned TT1 TT2 again to get beam centered on PR2 and PR3. Then we used only PR2 and PR3 to do the input beam alignment to Y arm cavity. Using access in ETMY chamber, we aligned the input beam parallel to cavity axis. Slight changes were required in ETMY alignment offsets to get first roundtrip in same spot on ITMY. remaining alignment is finer and needs to be done with a help of a reflection photodiode and cameras in the control room. Immediate next step is to setup POY path for locking the Yarm with IR.

Side note: Because of the large PIT correction required in PR3, we found that our upper OSEMs were hitting totally bright limit and lower OSEMs were hitting totally dark limit on PR3. This also destablized our damping loops. We pushed the upper OSEMs slighlty and pulled back the lower OSEMs slightly to get the PD signal in half shadow region again. This worked and our damping loops are stable again. However, we think we should repeat free swing test in future to diagonalize the input matrix for new OSEM positions.

[Anchal, Paco, JC, Tega]

Today we have aligned the Yarm cavity for IR, with verified 1.5 roundtrips. We also placed following optics in the BS table.

• POXM1 (installed earlier, not eloged)
• SRMOL2
• POYM1
• SRMOL1
• POYM2

We also cleared the in-air BS table of all previous optics. JC and Tega setup HeNe laser for Oplevs roughly for now. Tega also transported the POY RFPD from ITMY in-air table to the BS in-air table. We aligned the POY path to the table, but we had to move ITMY after that to get 2nd roundtrip in the arm cavity, which misaligned our POY path again. POY path would need to be modified tomorrow.

Nice. Please put this information on the DCC pages of the coil driver units. You'll find links to all the units in this document tree LIGO-E2100447. For each page, click on "Change Metadata" from the left panel and add the change made to the resistor (including the resistor name on PCB, previous and new value), and add a link to your previous elog post which has more details like photos, to "Notes and Changes", and upload an updated version of the circuit schematic by creating an annotation in the previous circuit schematic pdf. Every unit that has a serial number in the lab has a DCC page (if not, we should create one) where we should track all such hard changes.