[Koji, Ian]

We looked at a few power supplies and we found one that was marked "CHECK IF THIS WORKS" in yellow. We found that the power supply worked but the indicator light didn't work. I tried a two other lights from other power supplies that did not work but they did not work. Koji ordered a new one.

I moved the network-enabled power strip from above the power supplies on rack 1y4 to below. Nothing was powered through the strip when I unplugged everything and I connected everything to the same port after.

I will make a detailed elog later today giving a detailed outline of the connection from the Agilent gauge controller to the vacuum subnet and the work I have been doing over the past two days to get data from the unit to EPICs channels. I just want to mention that I have plugged the XGS-600 gauge controller into the serial server on the vacuum subnet. I check the vacuum medm screen and I can confirm that the other sensors did not experience and issues are a result of this. I also currently have two of the FRG-700 connected to the controller but I have powered the unit down after the checks.

I have attached a flow diagram of my understanding of how the gauges are connected to the network.

Earlier today, I connected the XGS-600 gauge controller to the IOLAN Serial Device Server on port 192.168.114.22 .

The plan is a follows:

1. Update the serial device yaml file to include this new ip entry for the XGS-600 gauge controller

2. Create a serial gauge class "serial_gauge_xgs.py" for the XGS-600 gauge controller that inherits from the serial gauge parent class for EPICS communication with a serial device via TCP sockets.

• Might be better to use the current channels of the devices that are being replaced initially, i.e.

• C1:Vac-FRG1_pressure	C1:Vac-CC1_pressure
  C1:Vac-FRG2_pressure	C1:Vac-CCMC_pressure
  C1:Vac-FRG3_pressure	C1:Vac-PTP1_pressure
  C1:Vac-FRG4_pressure	C1:Vac-CC4_pressure
  C1:Vac-FRG5_pressure	C1:Vac-IG1_pressure

3. Modify the launcher file to include the XGS gauge controller. Following the same pattern used  to start the service for the other serial gauges, we can start the communication between the XGS-600 gauge controller and the IOLAN serial server and write data to EPICS channels using

If we are able to establish communication between the XGS-600 gauge controller and write it gause data to EPICS channels, go on to steps 4.

4. Create a serial service file "serial_XGS600.service" and place it in the service folder

5. Add the new EPICS channels to the database file

6. Add the "serial_XGS600.service" to line 10 and 11 of modbusIOC.service

7. Later on, when we are ready, we can restart the updated modbusIOC service

For vacuum signal flow and Acromag channel assignments see [1]  and [2] respectively. For the 16 port IOLAN SDS (Serial Device Server) ethernet connections, see [3]. 

[1] https://wiki-40m.ligo.caltech.edu/Vacuum-Upgrade-2018?action=AttachFile&do=view&target=40m_Vacuum_System_Signal_Flow.pdf

[2] https://wiki-40m.ligo.caltech.edu/Vacuum-Upgrade-2018?action=AttachFile&do=view&target=AcromagChannelAssignment.pdf

[3] https://git.ligo.org/40m/vac/-/blob/master/python/serial/serial_devices.yaml

[Ian, Koji] - Activity on 25th (Fri)

We continued working on the ETMY electronics replacement.

- The units were fixed on the rack along with the rack plan.

- Unnecessary Eurocard modules were removed from the crate.

- Unnecessary IDC cables and the sat amp were removed from the wiring chain. The side cross-connects became obsolete and they also were removed.

- A 18V DC power strip was attached to one of the side DIN rails.

Warning:

- Right now the ETMY suspension is free and not damped. We are relying on the EQ stops.

Next things to do:

- Layout the coil driving cables from the vacuum feedthru to the sat amp (2x D2100675-01 30ft ) [40m wiki]

- Layout DB cables between the units

- Layout the DC power cables from the power strip to the units

- Reassign ADC/DAC channels in the iscey model.

- Recover the optic damping

- Measure the change of the PD gains and the actuator gains.

Summary:

- IMC was locked.
- Some alignment change in the output optics.
- The WFS servos working fine now.
- You need to follow the proper alignment procedure to recover the good alignment condition.

Locking:
- Basically followed the previous procedure 40m/16673.
- The autolocker was turned off. Used MC2 and MC3 for the alignment.
- Once I hit the low order modes, increased the IN1 gain to acquire the lock. This helped me to bring the alignment to TEM00
- Found the MC2 spot was way too off in pitch and yaw.
- Moved MC1/2/3 to bring the MC2 spot around the center of the mirror.
- Found a reasonably good visibility (<90%) at a MC2 spot. Decided this to be the reference (at least for now)

SP Table Alignment Work
- Went to the SP table and aligned the WFS1/2 spots.
- I saw no spot on the camera. Found that the beam for the camera was way too weak and a PO mirror was useless to bring the spot on the CCD.
- So, instead, I decided to catch an AR reflection of the 90% mirror. (See Attachment 1)
- This made the CCD vulnerable to the stronger incident beam to the IMC. Work on the CCD path before increasing the incident power.

MC2 end table alignment work
- I knew that the focusing lens there and the end QPD had inconsistent alignment.
- The true MC2 spot needs to be optimized with A2L (and noise analysis / transmitted beam power analysis / etc)
- So, just aligned the QPD spot using today's beam as the temporary target of the MC alignment. (See Attachment 2)

Resulting CCD image on the quad display (Attachment 3)

WFS Servo
- To activate the WFS with the low transmitted power, the trigger threshold was reduced from 5000 to 500. (See Attachment 4)
- WFS offset was reset with /opt/rtcds/caltech/c1/scripts/MC/WFS/WFS_RF_offsets
- Resulting working state looks like Attachment 5

We expect that the MC sus are susceptible to the temperature change and the alignment drifts away with time.

Here is the proper alignment procedure.

0) Assume there is no TEM00 flash or locking, but the IMC is still flashing with higher-order modes.

1) Use the CCD camera and WFS DC spots to bring the beam to the nominal position.

2) Use only MC2 and MC3 to align the cavity to have low-order modes (TEM00,01,02 etc)

3) You should be able to lock the cavity on one of these modes. Minimize the reflection (maximize the transmission) for that mode.

4) This should allow you to jump to a better lower-order mode. Continue alignment optimization only with MC2/3 until you get TEM00.

5) Optimize the TEM00 alignment only with MC2/3

6) Look at the MC end QPD. use one of the scripts in scripts/MC/moveMC2 . Note that the spot moves opposite to the name of the scripts. i.e. MC2_spot_down moves the spot up, MC2_spot_right moved the spot left, etc...
These scripts move MC1/2/3 and try to keep the good MC transmission.

7) moveMC2 scripts are not perfect. As you use them, it makes the MC alignment gradually degraded. Use MC2 and MC3 to recover good transmission.

8) If MC2 spot is satisfactory, you are done.

-------------

Step 6-8 can be done with the WFS on. This way, you can skip step 7 as the WFS servo takes care of it. But if the spot move is too fast, the servo can't keep up with the change. If so, you have to wait for the settling of the servo. Once the spot position is satisfactory, MC servo relief should be run so that the servo offset (in actuation) can be offloaded to the bias slider.

[Paco, Ian]

paco helped me wire the ETMY 1Y4 rack. We wired the following (copied from Koji's email):

1. Use DB9-DB9 to complete the wiring between
   1. 16bit DAC AI Chassis - End DAC Adapter (4 cables)
   2. End DAC Adapter - HAM-A Coil Driver (2 cables)
   3. AA Chassis - End ADC Adapter (2 cables)
2. Koji already brought two special DB9-DB15 cables (in plastic bags) to the end. They connect the HAM-A coil drivers to the satellite amp. At this time, we skip Low Noise HV Bias Driver.
3. Bring two 30ft DB25 (called #1, aka D2100675-01) cables from the office area to the end. I collected one end and left them there.
4. All the new units have +/-18V DC supply in the back. Find the orange cables behind the 40m vacuum duct around Y-end and connect the units and the DC power strip. Use short cables if possible to save the longer ones.

the cables we used:

I attached pictures below.

I decided to create an independent service for the XGS data readout so we can get this to work first before trying to integrate into current system. After starting the service, I noticed that the EPICS channel were not updating as expected. So I started to debug the problem and managed to track it down to an ip socket connect() error, i.e. we get a connection error for the ip address assigned to the LAN port to which the XGS box was connected. After trying a few things and searching the internet, I think the error indicates that this particular LAN port is not yet configured. I reached this conclusion after noting that only a select number of LAN ports connected without issues and these are the ports that already had devices connected. So it must be the case that the LAN ports were somehow configured. The next step is to look at the IOLAN manual to figure out how to configure the ip port for the XGS controller. Fingers crossed.

[Tommy, Paco]

Since last week I've worked with tommy on getting the RFSoC 2x2 board to get some TFs from simple minicircuits type filters. The first thing I did was set up the board (which is in the office area) for remote access. I hooked up the TCP/IP port to a wall ethernet socket (LIGO-04) and the caltech network assiggned some IP address to our box. I guess eventually we can put this behind the lab network for internal use only.

After fiddling around with the tone-generators and spectrum analyzer tools in loopback configuration (DAC --> ADC direct connection), we noticed that lower frequency (~ 1 MHz) signals were hardly making it out/back into the board... so we looked at some of the schematics found here and saw that both RF data converters (ADC & DAC) interfaces are AC coupled through a BALUN network in the 10 - 8000 MHz band (see Attachment #1). This is in principle not great news if we want to get this board ready for audio-band DSP.

We decided that while Tommy works on measuring TFs for SHP-200 all the way up to ~ 2 GHz (which is possible with the board as is) I will design and put together an analog modulation/demodulation frontend so we can upconvert all our "slow" signals < 1MHz for fast, wideband DSP. and demodulate them back into the audio band. The BALUN network is pictured in Attachment #2 on the board, I'm afraid it's not very simple to bypass without damaging the PCB or causing some other unwanted effect on the high-speed DSP.

The replacement key switches and Ne Indicators came in. They were replaced and work fine now.

The power supply units were tested with the X end HeNe display. It turned out that one unit has the supply module for 1350V 4.9mA while the other two do 1700V 4.9mA.
In any case, these two ignited the HeNe Laser (1103P spec 1700V 4.9mA).

The 1350V one is left at the HeNe display and the others were stored in the cabinet together with spare key SWs and Ne lamps.

During my investigation, I inadvertently overwrote the serial port configuration for the connected devices. So I am now working to get it all back. I have attached screenshots of the config settings that brought back communication that is not garbled. There is no physical connection to port 6, which I guess was initially used for the UPS serial communication but not anymore. Also, ports 9 and 10 are connected to Hornet and SuperBee, both of which have not been communicating for a while and are to be replaced, so there is no way to confirm communication with them. Otherwise, the remaining devices seem to be communicating as before.

I still could not establish communication with the XGS-600 controller using the serial port settings given in the manual, which also happen to work via Serial to USB adapter, so I will revisit the problem later. My immediate plan is to do a Serial Ethernet, then Ethernet to Serial, and then Serial to USB connection to see if the USB code still works. If it does then at least I know the problem is not coming from the Serial to Ethernet adapters. Then I guess I will replace the controller with my laptop and see what signal comes through when I send a message to the controller via the IOLAN serial device server. Hopefully, I can discover what's wrong by this point.

Note to self: Before doing anything, do a sanity check by comparing the settings on the IOLAN SDS and the config settings that worked for the Serial to USB communication and post an elog for this for reference.

Here is the IOLAN SDS TCP socket setting and the USBserial setting for comparison.

I have also included the python script and output from the USBserial test from earlier.

Connector Test:

A quick test to rule out any issue with the Ethernet to Serial adapter was done using the setup shown in Attachment 1. The results rule out any connector problem.

IOLAN COMM test (as per Koji's suggestion):

The next step is to swap the controller with a laptop set up to receive serial commands using the same settings as the XGS600 controller. Basically, run a slightly modified version of python script where we go into listening mode. Then send commands to the TCP socket on the IOLAN SDS unit using c1vac and check what data makes its way to the laptop USBserial terminal. After working on this for a bit, I realized that we do not need to do anything on the c1vac machine. We only need to start the service as it would work normally. So I wrote a small python code for a basic XGS-600 controller emulator, see Attachment 4. The outputs from the laptop and c1vac terminals are Attachments 5 and 6 respectively. 

These results show that we can communicate via the assigned IP address "192.168.114.22" and the commands that are sent from c1vac reaches the laptop in the correct format. Furthermore, the serial_XSG service, a part modbusIOC_XGS service, which usually exits with an error seems fine now after successfully communicating with the laptop. I don't know why it did not die after the tests. I also found a bug in my code as a result of the test, where the status field for the fourth gauge didn't get written to. 

Pressure reading issue:

I noticed that the pressure reading was not giving the atmospheric value of ~760 Torrs as expected. Looking through my previous readouts, it seems the unit showed this atm value of ~761 Torrs when the first gauge was attached. However, a closer look at the issue revealed a transient behavior, i.e. when the unit is turned on the reading dips to atm value but eventually rises up to 1000 Torrs. I don't think this is a calibration problem bcos the value of 1000 Torrs is the maximum value for the gauge range. I also found out that when the XGS-controller has been running for a while, a power cycle does not have this transient behavior. So maybe a faulty capacitor somewhere? I have attached a short video clip that shows what happens when the XGS-controller unit is turned on.

Yesterday, I rebuilt the OpLev setup in the cleanroom in order to suspend AS1. It took me a while to find all the necessary parts but I found them in the end.

The HeNe laser was placed on the optical table and turned on. The beam was aimed to bounce off a folding mirror to the SOS tower.

The beam's height was controlled by the HeNe laser stage and made to be 5+14/32". The beam from the folding mirror was made parallel to the table, first with an iris and then with the QPD connected to a scope.

Preparing the SOS tower for the suspension I noticed that the wire clamp is scratched on both sides from previous suspensions. I discarded that wire clamp but couldn't find the spares. Time ran out and I had to stop.

For the Y-end electronics replacement, we want to remove unused power supplies. In fact, we already removed the +/-5V supplies from the stack. I was checking what supply voltages are used by the Eurocard modules. I found that D990399 QPD whitening board had the possible use of +/-5V.

The 40m Y-end version can be found here D1400415. The +/-5V supply voltages are used at the input stage AD620 and the QPD bias voltage of -5V.

AD620 can work with +/-15V. Also the bias voltage can easily be -15V. So I decided to cut the connector legs and connected +5V line to +15V, and -5V line to -15V.

With this modification, I can say that the eurocards only use the +/-15V voltages and nothing else.

The updated schematics can be found as D1400415-v6

The DC power strip at Y-end was connected to the bottom two Sorensen power supplies. They are configured to provide +/-18V.

[Anchal, Paco]

Wire clamp spare was installed, furthermore AS1 was reinstalled on adapter, attached wire clamps, and cleaned using ionized air gun. Finally, we suspended it on the SOS tower and left it resting on the bottom earthquake stops; ready for balancing.

[Koji, Ian]

1) We attached the 30 coil driving cables to the vacuum feed through to the sat amp  [40m wiki] they run along the cable tray then up and down into the rack.

2) we checked all DB and power cables. We found that the anti-imaging filter had a short and got very hot when plugged in. the back power indicator lights turned on fine but the front panel stayed off. We removed it and replaced it with the one that was on the test stand marked for the BHD. This means we need to fix the broken one and Koji mentioned getting another one.

3) we reassigned the ADC and DAC channels in the iscey model and the asy model. we committed a version before we made any changes.

4) Finally we tested the setup to make sure the ETM was being damped.

Next step:

1) Measure the change of the PD gains and the actuator gains. See pervious elog

1. Jordan reported that the newly installed Pirani gauge for P2 shows 850Torr while PTP2 show 680 Torr. Because of this, the vacuum interlock fails when we try to open V4.

2. Went to c1vac. Copied the interlock setting file interlock_conditions.yaml to interlock_conditions_220304.yaml
3. Deleted diffpressure line and pump_underspeed line for V4
4. Restarted the interlock service

controls@c1vac:/opt/target/python/interlocks$ sudo systemctl status interlock.service  
controls@c1vac:/opt/target/python/interlocks$ sudo systemctl restart interlock.service
controls@c1vac:/opt/target/python/interlocks$ sudo systemctl status interlock.service

5. The above 2~4 was unnecessary. Start over.

Let RP1/3 pump down TP1 section through the pump spool. Then let TP2 pump down TP1 and RGA.

1. Open V7. This made P2 a bit lower (P2 is alive) and P3.
2. Connected the main RP tube to the RP port.
2. Started RP1/3. PRP quickly reaches 0.4Torr.
3. Opened V6 this made P3 and O2 below 1Torr.
4. Close V6. Shutdown RP1/3. Disconnect the RP tube.
5. Turn on auxRP at the wall powe
6. Turn on TP2. Wait for the starting up.
7. Open V4. Once the pressure is below Pirani range, open VM3.
8. Keep it running over the weekend.

9. Once TP2 reached the nominal speed, the "StandBy" button was clicked to lower the rotation speed (for longer life of TP2)

Oplev saga

Summary

- The new coil driver had not enough alignment range to bring the oplev beam back to the QPD center
- The coil driver output R was reduced from 1.2k to 1.2k//100 = 92.3 +/- 0.4 Ohm
- Now the oplev spot could be moved to the center of the QPD

- The damping gains (POS/PIT/YAW) and the oplev gains were reduced by a factor of 1/10.
- The damping and the oplev servos work now. Fine gain tuning is necessary.

To Do:
- DC value / TF measurements
- Adjust damping gains
- RFM issue
- Connection check
- Cable labeling

== Alignment Range ==

- Since c1auxey was removed, we no longer have C1:SUS-ETMY_PIT_COMM and C1:SUS-ETMY_YAW_COMM. At this moment, all the alignment is taken with the offset input from the fast real-time system via C1:SUS-ETMY_PIT_OFFSET and C1:SUS-ETMY_YAW_OFFSET.

- The oplev spot could not be moved on the center of the QPD without exceeding the DAC output range (~+ or -32000) for the coils. (Attachment 1)

- This is because the old system had a slow but large current range (Rout = 100) and a small current range for the fast control. Until we commission the new HV BIAS Driver, we have to deal with the large DC current with the HAM-A coil driver.

== Modification to the output resistances ==

The following units and the channels were modified. Each channel had a differential current driver and two output resistances of 1.2K. 100Ohm (OHMITE 43F100, 3W) wire wound resistors were added to them in parallel, making the resulting output R of ~92Ohm.

- ETMY HAM A Coil Driver 1: S2100622 (Attachments 2/3) CH1/2/3
- ETMY HAM A Coil Driver 2: S2100621 (Attachments 4/5) CH3

- This modification allowed me to align the oplev spot to the center of the QPD. C1:SUS-ETMY_PIT_OFFSET and C1:SUS-ETMY_YAW_OFFSE are +2725 (8%FS) and -2341 (7%FS), respectively.
- The previous alignment slider values were -0.9392 and 0.7615 (out of 10). These are the reasonable numbers, considering the change of the Rout from 100 to 92Ohm, and the sign flip.
(By the way, autoBurt files for c1auxex and c1auxey were not properly configured and the history of C1:SUS-ETM*_*_COMM was not recorded.)

== Damping Servos ==

- Now, the POS/PIT/YAW servos experience ~x10 gains. So temporarily these gains were reduced (POS 20->2, PIT 6->0.6, YAW 4->0.4) and the loops are stable when engaged.
- Also the gains of the OPLEV servos were reduced from -4.5 to -0.45. The loops are stable when engaged.

== Snapshot of the working condition ==

Attachent 6 shows the screenshot for the snapshot of the working condition.

To Do

- The damping servos were tested without proper PD whitening compensation.
  -> It turned out this is not necessary as our modified PD whitening has the pole and zero at the same freqs as before.

- Compare the DC values of the OSEM outputs and compensate for the gain increase by the "cts2um" filter.

- The end RTS suffers from the RFM issue. There is no data transmitted from the vertex to the end. I suspect we need to restart the c1rfm process. But this will likely suspend all the vertex real-time machines. Careful execution is necessary.

- c1iscey has all the necessary analog connections. But they are not tested. When we lock the green/IR cavity, we'll need them.

- The cable labeling is only half done.

Following repeated failure to establish communication between c1vac and the XGS600 controller via Perle IOLAN serial device server, I decided to monitor the signal voltage of the communication channels (pin#2, pin#3 and pin#5) using an oscilloscope. The result of this investigation is presented in the attached pdf document. In summary, it seems I have used a crossed wired RS232 serial cable instead of a normal RS232 serial cable, so the c1vac read request command is being relayed on the wrong comm channel (pin#2 instead of pin#3). I will swap out the cable to see if this resolves the problem.  

Came this morning and saw that the IMC is unlocked.

Went into MC Lock screen and see that the watchdog is down and the PSL shutter is closed. I tried to open the shutter but nothing happened - no REFL signal or beam on the MC REFL camera .

Thinking this has something to do with the watchdog I upped the watchdog:

ezcawrite C1:SUS-MC2_LATCH_OFF 1

The watchdog on the MEDM screen became green but the shutter still seemed unresponsive. I went to the PSL table and made sure that the shutter is working. I opened the AS table and saw there no MC REFL beam anywhere.

Thinking that MC1 must be completely misaligned I opened the MC align screen to find that indeed all the alignment values has been zeroed! (attachment).

I burt restore c1iooepics from Mar 4th 00:19. Didn't help.

I try to burt restore c1susepics from Mar 1st 13:19. Still zero.

I try to burt restore c1susaux from Mar 1st 00:19 -> seems like alignment values have been restored.

I open the shutter. Beam is flying! MC Watchdogs tripped! I close the shutter. OK, I need to wait until the MCs are dampped enough. MC2 and MC3 have relaxed so I enable their watchdogs. MC1 is still swinging a bit. I turn on damping for MC1 as well.

MC locked immediately but the REFL is still high like 1.2. Is it normal?

I turn on the WFSs and the REFL went down to 0.3 nice. I run the MC WFS relief script.

So it appears that my deduction from the pictures of needing a cable swap was correct, however, it turns out that the installed cable was actually the normal RS232 and what we need instead is the RS232 null cable. After the swap was done, the communication between c1vac and the XGS600 controller became active. Although, the data makes it all to the to c1vac without any issues, the scope view of it shows that it is mainly utilizing the upper half of the voltage range which is just over 50% of the available range. I don't know what to make of this.

I guess, the only remaining issue now is the incorrect atmospheric pressure reading of 1000 Torrs. 

Great trouble shoot!

> I guess, the only remaining issue now is the incorrect atmospheric pressure reading of 1000 Torrs. 

This is just a calibration issue. The controller should have the calibration function.
(The other Pirani showing 850Torr was also a calibration issue although I didn't bother to correct it. I think the pirani's typically has large distribution of the calibration values and requires individual calibration)

Hmm, the bias values were reset at 2022-03-03-20:01UTC which is 2022-03-03-12:01 PST with no apparent disruption of the data acquisition (= no resetting of the RTS). Not sure how this could happen.

Now that the ETMSUS is back up and running I reran my measurements from the beginning of the process. The results below show a change in gain between the before and after measurements. I have given values of the low-frequency section below.

Average Gain difference from the TFs: 18.867  (excluding thee side change)

I also am noting the new values for the OSEM DC output: average gain increase: 9.004

In addition, the oplev position was:

All data and settings have been included in the zip file

From the average gain increase of the TFs which indicates the increase of the whole system and the increase in gain from the OSEM we can calculate the gain from the actuators.

18.867/9.004 = 2.09

thus the increase in gain on the actuator is about 2.09

EDIT: I updated the side TF with one with better SNR. I increased the excitation amplitude.

{Paco, Yehonathan}

We tried to roughly balance the adapter with two counterweights at the front, like with the other thin optics using an iris. As before, we couldn't get the beam above the iris hole no matter how much we inserted the counterweights into the adapter. We noticed that one of the side blocks is actually the one where the clearance for the wire was made on the wrong side. So there was clearance on both the up and bottom sides of the side block (see attachment 1).

Could this be the cause of the balancing issue? Running out of ideas on how to fix it we gave it a try and replaced it with a spare side block. We also found that the wire on the other side block was kinked so we replaced the wire on this one as well.

After inserting new wires into the side blocks, we hung the adapter on the winches and the beam was above the iris aperture! How could this tiny amount of missing mass make this much difference?

We were able to roughly balance the adapter.

We then tried to balance the roll of the adapter but accidentally knocked off the side magnet 😫.

We usually glue several side magnets together and they all together support the metallic plate on which the magnets are magnetically attached to. This time we had only one side magnet to glue so instead of trying to glue the magnet vertically we are trying to glue it horizontally using a flat surface and a stage to clamp it (attachments 2,3).

BTW, the HeNe was not working when we came into the cleanroom. We realized it was the old HeNe that we already determined to be broken but there was no sign on it. I attached a "BAD" sign on it and replaced it with the new HeNe. The OpLeve beam was realigned. All of this happened before all the things described above

Not sure if that small difference can cause the alignment inability. Particularly, the removed metal was just below the wire. This means that there is no misalignment effect at the first order.

Here is my idea:
You may be able to assist the alignment by adding washers on one side of the four holes to this "H" shaped parts. The holes are away from the center line, adding some weight definitely do some misalignment.

OMG, it worked! It was indeed a calibration issue and all I had to do was press the "OK" button after selecting the "CAL" tab beside the pressure reading. Wow.

The gluing seemed to be successful. I assembled the side block with the magnet on the adapter. Paco helped me hang the adapter on the SOS tower.

The height and roll of the adapters were balanced (attachment 1,2).

The QPD was placed at the beam reflection. The beam was centered horizontally on the QPD and then measured vertically. The pitch DOF was balanced using the counterweights. The counterweight was locked. Balance was retained.

I tried to assemble the upper mirror clamp on the tower but for some reason, one of its tap holes was not able to accept screws. I gave it to Jordan for retapping. I measured the motion spectrum using the QPD connected to a scope (attachment 3).

Major peaks are at 668mHz, 942mHz, and 1029mHz.

[Paco]

Installed AS1 in vacuum, near the center of the table, and installed the OSEMs. All OSEMS are "balanced" nominally, i.e. their shadow is at the halfway point optimum, but fine tuning is required, which I will attempt tomorrow after restoring the AS1 suspension screen settings. Today, I tried damping the SIDE DOF, but didn't succeed, although there was definitely some oscillating behaviour with high (> 5) gains on the damping, so I believe this is a matter of patience. For now, all OSEMs are looking ok, the SOS is in place, and hopefully it will soon be damped. 

[Paco]

AS1 is installed, OSEMs balanced, and the optic damped successfully. We should run the free swinging test overnight to validate this re-installation.

Jordan, Chub, Paco

Chub and I went into the lab this morning to leak check the new gate valve after pumping over the weekend. This would be done through the RGA and spraying helium around the newly installed flanges. The RGA is set to monitor the partial pressure of helium versus time and we visually watch for any spikes in pressure to indicate an air leak.

So, I mistakenly thought the gate valve was opened and both sides were being pumped on, this was not the case. The vavle was closed so there was a pressure differential whenI turned the handle it tripped the interlocks and closed V4. I closed VM3 to the RGA volume to prevent the filament from being damaged.

Then the medm screen for the vac controls started flashing rapidly, I closed the window and reopened the controls to find all the panels were white, but we could still see the read only vac screen. So Paco restarted c1vac and the controls were restored. V7 closed, but was then reopened.

We now need to restart pumping with the odd pressure differentials between V4 and VM3.

Plan

- TP2 turned off along with the AUX pump

- VM3 opened to vent RGA volume (RGA turned off, filament cooled)

- Open the manual vent screw on TP1 to bring the RGA+TP1 volume back to atmosphere, now no pressure diff. on V4

- Open V4, restart AUX pump to rough out the volume

- Connect RP1/3 line to the pump scroll, turn on RP1/3 RGA+TP1 volume went to mtorr

- Slowly open the manual gate valve

- Connect AUX pump to TP2 and rough out

- Restart TP2, once at speed open V4, close V6 and turn off RP1/3

Now we are pumping on the RGA/TP1 volume with TP2, leak check attempt #2 will happen tomorrow morning

I have made an editable draw.io diagram of the planned simplified BHD setup on the ITMY table (see attached).  10 pts = 1 inch.

This is very sketchy but easily adjustable since we are removing everything but the ITMY Oplev from that table.

- BHD beams were already mixed in the chamber. So we don't need a BS on the table. (Probably there is no BS already)

- We don't need to split each BHD beam. One PD per BHD beam is OK for now.

- Check if the BHD paths have reasonable angles from the windows so that the beams do not hit the chamber wall.

- We need the POY path. POY indeed goes to the BS table

This morning Chub and I leak checked the manual gate valve with the RGA and helium. There was no change in the helium partial pressure while spraying helium around the flanges, all looks good.

I also took a 100 AMU analog scan, after the filament had warmed up overnight and the plot was quite noisy even with the lowest scan speed. I recommend this unit go back to SRS for a filament replacement/recalibration. I am worried yesterday's "vent" of the RGA volume may have burned the filament. See the comparison of yesterday's analog scan to today's below.

[Paco, Ian]

• Begin free swinging test for AS1 at 10:05 AM, set for ~ 2.04 hours.
  • Test failed because damping failed to disable.
• Restart free swinging test for AS1 at 15:06, set for 2.04 hours.
  • Success (Attachment #1 shows the DOF input matrix diagonalization effect)

Of slight concern is the side to other degrees of freedom coupling, but this is definitely an improvement from last time.

I updated the gain of the ct2um filter on the OSEMS for ETMY and decreased their gain by a factor of 9 from 0.36 to 0.04.

I added a filter called "gain_offset" to all the coils except for side and added a gain of 0.48.

together these should negate the added gain from the electronics replacement of the ETMY

[Paco]

This morning I assembled LO3, LO4 and AS3 (all mirrors) onto polaris K1 mounts. The mounts stand as per this elog, on 4.5" posts with 0.5" Al spacers to match the beam heigth of 5.5". I also assembled ASL by adding a 0.14" Al spacer, and finally, recycled two DLC mounts (from the XEND flowbench) and posts to mount the 2 inch diameter beamsplitters BHDBS and AS2 (T=10%). I stored the previous 2" optics in the CVI and lambda optic cases and labeled appropriately.

[Anchal, Paco]

We installed a HV kepco power supply for the green PZT steering the YAUX beam. We did this in anticipation of the YARM alignment to take place this afternoon. We borrowed an unused DC power supply labeled "OMC Power spply" and made an appropriate SMA connection (Attachment #1), Then we set the Vset to 100.0 Volts and the current limit to 10 mA. Once we enabled the output we saw the 5.6 mA of current drawn by the eurocard in accordance with the wiki log (Attachment #2). 

It may not be possible to use the PZT as per this so this work may not have a direct impact on our upcoming alignment task.

We probably bumped the ethernet cable (martian network) on c1iscey, so the FE models stopped showing up on the medm screens. When we connected it back, it seemed like the FE kept running the model and only IPC showed error. We restarted the rtcds models on c1iscey and burtrestored to today morning 5:19 am.

ETMY is properly damping now and the oplev is roughly centered as well but the OPLEV Servos are off. We did not turn them on.
We should be able to carry out our cavity arm alignment today afternoon on both arms now.

[Ian, Paco]

We opened the ITMX chamber and

• Inspected PR2 and LO1 and didn't see anything suspicious.
• Took the EQ stops off ITMX in preparation for alignment

Alignment:

• Ian started at the ETMX station, slightly tweaking the M1 M2 XAUX mirrors by hand and Paco on the ITMX chamber looking at the beam. The beam was visibly making it to the ITMX optic and reflecting back though at a negative pitch angle. No small motion on the M1-M2 knobs caused visible correction on this.
• We decided to try adding an alignment offset to ITMX, and quickly saturated to 25000 (on the SUS screen) but fell short of fully correcting this PIT offset.
• We scanned further the M1 M2 input alignment, and briefly lost the first reflection.
  • We recovered the first reflection, but the beam spot is now incident near the LL OSEM position.
• We kept scanning M1 - M2 with Ian on the ITMX chamber this time, providing feedback through facetime.
• Leaning on the ITMX chamber table, we noticed the magnitude of PIT correction left to be done and verified that M1-M2 two axis alignment + ITMX offsets should be enough for it.

We stopped our effort here, the XAUX beam spot is near the lower half of the ITMX face. Tomorrow, we will resume, but we will use airpods and a clean go-pro for real-time audiovisual feedback. Furthermore, ITMX OSEMs should be rebalanced as they haven't been touched after the table was balanced for PR2 and LO1.

[Paco, Ian]

First, we re-balanced the ITMX OSEMs so that they would damp at around half-a-shadow.

Then, we set up a clean camera inside ITMX chamber looking at the ITMX optic. Then, using the live feed we aligned the AUX beam from the ETMX station using M1 and M2. The camera was great to help us align the beam properly close to the ITMX center. It wasn't very long until we could see a green beam on the IR card, but we didn't really see any flashing, so this may just be the bare transmission away from XARM resonance (Attachment #1).

Ian checked the reflection from ITMX using the IR card with holes, and he pretty much only saw one beam spot, so we turned to look for a beam scattering on the vacuum tube but didn't really see anything. This could mean that we were hitting the ETMX again, or missing slightly, or missing completely. We tried scanning the ITMX pitch and yaw using the bias (alignment) sliders, and with the illuminators off, try seeing some scattered green beam on the ETMX. We can't really see anything yet, but we will keep trying. If there are any tips on our method, it would be great to know them.

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.

[Ian, Paco]

Continuing with the previous alignment that we stoped on friday, we re set up my heavily cleaned iPhone on FaceTime. The Phone alowed us to see the laser on the ITMX and center it on that optic.

• We increased the trigger level for the watchdog on the optics.
• Green beam was centered on th ITMX.
• aligned the green laser: prompt reflection off of the ETMX to maximize the signal on the reflection PD
• Went back to ITMX chamber, looked for the beam in the tube to see if the laser was hitting the beam tube off of the ITMX. From there we comunicated how to adjust the beam to move the beam towards the ETMX.
• On the ETMX the reflection PD signal was measured and the ITMX was adjusted using CDS until ripples/"flashes" were seen in the reflection PD channel (C1:ALS-X_REFL_DC_OUT_DQ).
• Once we saw flashing we tried to minimize the reflection pd signal using only ITMX alignment slider so that all the light was being held in the cavity.
• Once we had this going the PDH lock engaged the higher order mode that we were seeing.
• We removed the phone setup and closed up the ITMX chamber.
• From here we moved to the control room and continude to adjust the ITMX and ETMX to see if we could lock to a lower order mode.
  • This proved unsuccessful so we will resume by trying to replicate the ASS action manually (with M1 - M2 PZT sliders and the REFL PD)

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?

The point of changing the gains was to return the system to its origional state. ie I wanted the over all gain of the physical components to be the same as when we started. From the CDS side of things nothing else should be changed. The damping filters should remain at their origional values. The cts2um filter was changed to counteract a change in the electronics (replacing them). These changes should cancel eachother out. As for the side control, on 3/4/22 koji reduced the output resistors for the 4 face OSEMs but did not change the the SD one. there fore the SD did not need the same adjustment as the others.

[Ian, Paco]

• We removed the "cheby" filters from AS4, PR2 and PR3 which had been misplaced after copying from the old SUS models. After removing them, the new SOS damped fine. Note that because of the Input matrices, the filters have to be enabled all at once for the MIMO loop to make sense.
• We also disabled the "Cheby" filter on BS and saw it damp better. We don't understand this yet, but perhaps it's just a consequence of the many changes in the BSC that have rendered this filter obsolete.
• we also reduced the damping gains on PR2, PR3 and AS4 to prevent overflow values. After the adjustments the optics were damping fine.

Here is an early sketch of the MC table. 

We are supposed to have BS Oplev Beams. We don't like the shallow angle reflections (i.e. AOI>45deg).

The laser is too big but I suspect the other components are too small. So it'd be check the actual size of the components including the optical mounts that are missing on the figure so far.