40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 8 of 339  Not logged in ELOG logo
ID Date Author Type Category Subject
  16736   Fri Mar 18 18:39:13 2022 YehonathanSummaryCDSc1auxey1 slow controls acromag chassis installed, powered

{Yehonathan, Anchal}

We connected the c1auxey1 chassie to the different boxes (coil drivers, SAT amp, etc.) using DB9 cables and labeling them in the process. We ran out of 2.5 foot DB9 cables so we used 5 foot as a temporary solution.

The chassie was powered, but a two issues arised:

1. The Acromags didn't turn on.

2. When connecting the green laser shutter BNC cable, the power supply overloaded.

We took the chassie back to the bench. The wire that powers the Acromags was disconnected. We made a new longer wire and made sure it is not connected flimsily.

The issue with the BNC turned out to be a much deeper problem: The GND and EXC wires on the DIN rail connector were switched! Making the shield of the BNC to have high volatage compared to the shield of the green shutter causing current to overflow when the BNC was connected.

We switched back the EXC and GND wires. Not trusting the digital I/O tests that were done before due to this mistake we tested some of the I/Os using a spare coil driver. We tested both the inputs and the outputs and they all seemed to work.

Finally, we also noticed that the 2 RTS DB9s were wrongly female type so we switched them to males. We closed the lead on chassie and installed it back in the rack. We connected the cables and saw that the green shutter BNC cable was no longer shorting the power supply.

  16735   Fri Mar 18 17:15:19 2022 PacoUpdateBHDXARM AUX alignment cont.

[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.

Attachment 1: Screen_Shot_2022-03-18_at_4.09.38_PM.png
  16734   Thu Mar 17 19:12:44 2022 AnchalSummaryCDSc1auxey1 slow controls acromag chassis installed, not powered

[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.

  16733   Thu Mar 17 17:23:22 2022 AnchalSummaryBHDPart IIa of BHR upgrade - Green laser alignment

[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)


  16732   Thu Mar 17 16:50:53 2022 PacoUpdateBHDXARM AUX alignment

[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


  • 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.

  16731   Thu Mar 17 11:40:41 2022 PacoUpdateSUSETMY green PZT HV supply

[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.

burtwb -f /cvs/cds/rtcds/caltech/c1/burt/autoburt/today/05:19/c1scyepics.snap -l /tmp/controls_1220317_115006_0.write.log -o /tmp/controls_1220317_115006_0.nowrite.snap -v

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.

  16730   Tue Mar 15 18:45:12 2022 AnchalSummaryBHDPart X of BHR upgrade - BHDBS Path setup

[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)
  16729   Tue Mar 15 18:42:37 2022 AnchalSummaryBHDPart IX of BHR upgrade - AS1 resuspended and OSEMs tuned



  16728   Tue Mar 15 14:10:41 2022 AnchalSummaryCDSc1su2 model remade, reinstalled, restarted after the update

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:

controls@c1sus2:~ 0$ rtcds make c1su2
buildd: /opt/rtcds/caltech/c1/rtbuild/release
### building c1su2...
Cleaning c1su2...
Parsing the model c1su2...
Building EPICS sequencers...
Building front-end Linux kernel module c1su2...
RCG source code directory:
The following files were used for this build:

Successfully compiled c1su2
Compile Warnings, found in c1su2_warnings.log:
WARNING  *********** No connection to subsystem output named  SUS_DAC1_12  
WARNING  *********** No connection to subsystem output named  SUS_DAC1_13  
WARNING  *********** No connection to subsystem output named  SUS_DAC1_14  
WARNING  *********** No connection to subsystem output named  SUS_DAC1_15  
WARNING  *********** No connection to subsystem output named  SUS_DAC2_7  
WARNING  *********** No connection to subsystem output named  SUS_DAC2_8  
WARNING  *********** No connection to subsystem output named  SUS_DAC2_9  
WARNING  *********** No connection to subsystem output named  SUS_DAC2_10  
WARNING  *********** No connection to subsystem output named  SUS_DAC2_11  
WARNING  *********** No connection to subsystem output named  SUS_DAC2_12  
WARNING  *********** No connection to subsystem output named  SUS_DAC2_13  
WARNING  *********** No connection to subsystem output named  SUS_DAC2_14  
WARNING  *********** No connection to subsystem output named  SUS_DAC2_15  
controls@c1sus2:~ 0$ rtcds install c1su2
buildd: /opt/rtcds/caltech/c1/rtbuild/release
### installing c1su2...
Installing system=c1su2 site=caltech ifo=C1,c1
Installing /opt/rtcds/caltech/c1/chans/C1SU2.txt
Installing /opt/rtcds/caltech/c1/target/c1su2/c1su2epics
Installing /opt/rtcds/caltech/c1/target/c1su2
Installing start and stop scripts
Performing install-daq
Updating testpoint.par config file
/opt/rtcds/rtscore/branches/branch-3.4/src/epics/util/updateTestpointPar.pl -par_file=/opt/rtcds/caltech/c1/target/gds/param/archive/testpoint_220315_135808.par -gds_node=26 -site_letter=C -system=c1su2 -host=c1sus2
Installing GDS node 26 configuration file
Installing auto-generated DAQ configuration file
Installing Epics MEDM screens
Running post-build script

/opt/rtcds/userapps/release/cds/common/scripts/generate_KisselButton.py 4 5 C1:SUS-AS1_INMATRIX > /opt/rtcds/caltech/c1/medm/c1su2/C1SUS_AS1_INMATRIX_KB.adl
/opt/rtcds/userapps/release/cds/common/scripts/generate_KisselButton.py 2 4 C1:SUS-AS1_LOCKIN_INMTRX > /opt/rtcds/caltech/c1/medm/c1su2/C1SUS_AS1_LOCKIN_INMTRX_KB.adl
/opt/rtcds/userapps/release/cds/common/scripts/generate_KisselButton.py 5 6 C1:SUS-AS1_TO_COIL --fi > /opt/rtcds/caltech/c1/medm/c1su2/C1SUS_AS1_TO_COIL_KB.adl
/opt/rtcds/userapps/release/cds/common/scripts/generate_KisselButton.py 4 5 C1:SUS-AS4_INMATRIX > /opt/rtcds/caltech/c1/medm/c1su2/C1SUS_AS4_INMATRIX_KB.adl
/opt/rtcds/userapps/release/cds/common/scripts/generate_KisselButton.py 2 4 C1:SUS-AS4_LOCKIN_INMTRX > /opt/rtcds/caltech/c1/medm/c1su2/C1SUS_AS4_LOCKIN_INMTRX_KB.adl
/opt/rtcds/userapps/release/cds/common/scripts/generate_KisselButton.py 5 6 C1:SUS-AS4_TO_COIL --fi > /opt/rtcds/caltech/c1/medm/c1su2/C1SUS_AS4_TO_COIL_KB.adl
/opt/rtcds/userapps/release/cds/common/scripts/generate_KisselButton.py 4 5 C1:SUS-LO1_INMATRIX > /opt/rtcds/caltech/c1/medm/c1su2/C1SUS_LO1_INMATRIX_KB.adl
/opt/rtcds/userapps/release/cds/common/scripts/generate_KisselButton.py 2 4 C1:SUS-LO1_LOCKIN_INMTRX > /opt/rtcds/caltech/c1/medm/c1su2/C1SUS_LO1_LOCKIN_INMTRX_KB.adl
/opt/rtcds/userapps/release/cds/common/scripts/generate_KisselButton.py 5 6 C1:SUS-LO1_TO_COIL --fi > /opt/rtcds/caltech/c1/medm/c1su2/C1SUS_LO1_TO_COIL_KB.adl
/opt/rtcds/userapps/release/cds/common/scripts/generate_KisselButton.py 4 5 C1:SUS-LO2_INMATRIX > /opt/rtcds/caltech/c1/medm/c1su2/C1SUS_LO2_INMATRIX_KB.adl
/opt/rtcds/userapps/release/cds/common/scripts/generate_KisselButton.py 2 4 C1:SUS-LO2_LOCKIN_INMTRX > /opt/rtcds/caltech/c1/medm/c1su2/C1SUS_LO2_LOCKIN_INMTRX_KB.adl
/opt/rtcds/userapps/release/cds/common/scripts/generate_KisselButton.py 5 6 C1:SUS-LO2_TO_COIL --fi > /opt/rtcds/caltech/c1/medm/c1su2/C1SUS_LO2_TO_COIL_KB.adl
/opt/rtcds/userapps/release/cds/common/scripts/generate_KisselButton.py 4 5 C1:SUS-PR2_INMATRIX > /opt/rtcds/caltech/c1/medm/c1su2/C1SUS_PR2_INMATRIX_KB.adl
/opt/rtcds/userapps/release/cds/common/scripts/generate_KisselButton.py 2 4 C1:SUS-PR2_LOCKIN_INMTRX > /opt/rtcds/caltech/c1/medm/c1su2/C1SUS_PR2_LOCKIN_INMTRX_KB.adl
/opt/rtcds/userapps/release/cds/common/scripts/generate_KisselButton.py 5 6 C1:SUS-PR2_TO_COIL --fi > /opt/rtcds/caltech/c1/medm/c1su2/C1SUS_PR2_TO_COIL_KB.adl
/opt/rtcds/userapps/release/cds/common/scripts/generate_KisselButton.py 4 5 C1:SUS-PR3_INMATRIX > /opt/rtcds/caltech/c1/medm/c1su2/C1SUS_PR3_INMATRIX_KB.adl
/opt/rtcds/userapps/release/cds/common/scripts/generate_KisselButton.py 2 4 C1:SUS-PR3_LOCKIN_INMTRX > /opt/rtcds/caltech/c1/medm/c1su2/C1SUS_PR3_LOCKIN_INMTRX_KB.adl
/opt/rtcds/userapps/release/cds/common/scripts/generate_KisselButton.py 5 6 C1:SUS-PR3_TO_COIL --fi > /opt/rtcds/caltech/c1/medm/c1su2/C1SUS_PR3_TO_COIL_KB.adl
/opt/rtcds/userapps/release/cds/common/scripts/generate_KisselButton.py 4 5 C1:SUS-SR2_INMATRIX > /opt/rtcds/caltech/c1/medm/c1su2/C1SUS_SR2_INMATRIX_KB.adl
/opt/rtcds/userapps/release/cds/common/scripts/generate_KisselButton.py 2 4 C1:SUS-SR2_LOCKIN_INMTRX > /opt/rtcds/caltech/c1/medm/c1su2/C1SUS_SR2_LOCKIN_INMTRX_KB.adl
/opt/rtcds/userapps/release/cds/common/scripts/generate_KisselButton.py 5 6 C1:SUS-SR2_TO_COIL --fi > /opt/rtcds/caltech/c1/medm/c1su2/C1SUS_SR2_TO_COIL_KB.adl
safe.snap exists
controls@c1sus2:~ 0$

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:

~> cd /opt/rtcds/caltech/c1/chans/daq/
daq>python2 activateSUS2DQ.py 
daq>rm C1SU2.ini.bak
daq>mv C1SU2.ini C1SU2.ini.bak
daq>mv C1SU2.ini.NEW C1SU2.ini

Then ssh back to c1sus2 and restart the rtcds model:

controls@c1sus2:~ 0$ rtcds restart c1su2
### stopping c1su2...
### starting c1su2...
c1su2epics: no process found
Number of ADC cards on bus = 2
Number of DAC16 cards on bus = 3
Number of DAC18 cards on bus = 0
Number of DAC20 cards on bus = 0
Specified filename iocC1.log does not exist.
c1su2epics C1 IOC Server started
c1su2 RT ready in 4
awg_server Version $Id$
channel_client Version $Id$
testpoint_server Version $Id$
/opt/rtcds/caltech/c1/target/gds/bin/awgtpman -s c1su2 -l /opt/rtcds/caltech/c1/target/gds/awgtpman_logs/c1su2.log started on host c1sus2 hostid ffffffffa8c05771 
awgtpman Version $Id$
controls@c1sus2:~ 0$

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

daq>telnet fb 8083
Connected to fb.martian.
Escape character is '^]'.
daqd> shutdown
Connection closed by foreign host.
>burtwb -f /opt/rtcds/caltech/c1/burt/autoburt/latest/c1su2epics.snap -l /tmp/controls_1220315_140755_0.write.log -o /tmp/controls_1220315_140755_0.nowrite.snap -v <

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

  16727   Tue Mar 15 13:49:44 2022 Ian MacMillanBureaucracyTreasureNew Screwdriver Bits

I have received the new screwdriver bits that will work with the two electric screwdrivers we have. I have distributed them in the 40m. Some are in the electronics stations and some are in the toolbox in the lab. The new electric screwdriver (which looks like a drill but takes typical screwdriver bits) is in the room with the workshop. It is in the blue Makita box. For some reason, lots of the old bits were rounded because of incorrect use. I have thrown the unuseable ones out.

I also requested some screw extractors in case we need them. the one we have now is really big and may not work on smaller screws.

  16726   Tue Mar 15 11:52:34 2022 AnchalSummaryCDSc1su2 model updated for sending Run/Acquire Binary Output to Binary Interface card

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.

Attachment 1: c1su2.pdf
  16725   Tue Mar 15 10:45:31 2022 PacoUpdateGeneralAssembled small in-vac optics


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.

  16724   Mon Mar 14 12:20:05 2022 AnchalSummaryCDSc1susaux2 slow controls acromag chassis installed

[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.


Attachment 1: BHD_WatchDogs.png
Attachment 2: 40mBHD_C1SUSAUX2_Acromag_Chassis.pdf
  16723   Fri Mar 11 16:43:03 2022 Ian MacMillanUpdateSUSETMY SUS Electronics Replacement

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

  16722   Thu Mar 10 10:05:49 2022 PacoUpdateSUSAS1 free swing test

[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.

Attachment 1: SUS_Input_Matrix_Diagonalization.pdf
  16721   Thu Mar 10 09:39:59 2022 JordanUpdateVACLeak Testing of New Manual Gate Valve - Attempt #2

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.

Attachment 1: 3-09-2022.PNG
Attachment 2: 3-10-2022.PNG
  16719   Wed Mar 9 12:57:52 2022 KojiUpdateBHDSimplified BHD readout sketch on ITMY 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

  16718   Wed Mar 9 11:52:18 2022 YehonathanUpdateBHDSimplified BHD readout sketch on ITMY table

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.

Attachment 1: ITMY_Table_Sketch.drawio.pdf
  16717   Wed Mar 9 10:23:28 2022 JordanUpdateVACLeak Testing of New Manual Gate Valve - Attempt #1

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.


- 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

  16716   Wed Mar 9 09:35:26 2022 PacoUpdateBHDRe-balance of AS1


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

  16715   Tue Mar 8 19:29:36 2022 PacoUpdateBHDRe-balance of AS1


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. 

  16714   Tue Mar 8 12:24:13 2022 YehonathanUpdateBHDRe-susspension of AS1

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.


Attachment 1: AS1_Roll_Balance.png
Attachment 2: AS1_Height_Balance.png
Attachment 3: FreeSwingingSpectra_new.pdf
  16713   Tue Mar 8 12:08:47 2022 TegaUpdateVACOngoing work to get the FRG gauges readouts to EPICs channels

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.


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)


Attachment 1: XGS600_calibration.pdf
  16712   Mon Mar 7 19:38:47 2022 AnchalSummaryCDSc1susaux2 slow controls issues

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.

  16711   Mon Mar 7 18:53:16 2022 KojiUpdateBHDRe-susspension of AS1

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.


  16710   Mon Mar 7 16:56:08 2022 YehonathanUpdateBHDRe-susspension of AS1

{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

Attachment 1: signal-2022-03-07-171520_001.png
Attachment 2: signal-2022-03-07-172659_001.jpeg
Attachment 3: signal-2022-03-07-172659_003.jpeg
  16709   Mon Mar 7 16:44:15 2022 Ian MacMillanUpdateSUSETMY SUS Electronics Replacement

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)

  Before After Gain difference
UL -31 dB -5 dB 19.952
UR -36 dB -10 dB 19.952
LR -27 dB -2 dB 17.782
LL -37 dB -12 dB 17.782
SIDE -48 dB -45 dB 1.412

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

OSEM DC OFFSET Before DC OFFSET After Gain increase
UL 557 5120 9.19
UR 568 5111 8.99
LR 780 7041 9.02
LL 385 3430 8.91
SD 328 2922 8.91

In addition, the oplev position was:

  Before After
 OPLEV_PERROR -16.055 -16.715
 OPLEV_YERROR -6.667 -16.597

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.

Attachment 1: UR_TF_Graph.pdf
Attachment 2: UL_TF_Graph.pdf
Attachment 3: LR_TF_Graph.pdf
Attachment 4: LL_TF_Graph.pdf
Attachment 5: SD_TF_Graph.pdf
Attachment 6: 20220307_SUSElectronicsAfterTests.zip
  16708   Mon Mar 7 14:55:33 2022 KojiUpdateIOOIMC unlocked again, completely misaligned

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.


  16707   Mon Mar 7 14:52:34 2022 KojiUpdateVACOngoing work to get the FRG gauges readouts to EPICs channels

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)

  16706   Mon Mar 7 13:53:40 2022 TegaUpdateVACOngoing work to get the FRG gauges readouts to EPICs channels

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. 



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.  


Attachment 1: iolan_xgs_comm_live.pdf
  16705   Mon Mar 7 10:06:32 2022 YehonathanUpdateIOOIMC unlocked again, completely misaligned

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.

Attachment 1: Screenshot_2022-03-07_10-15-19.png
  16704   Sun Mar 6 18:14:45 2022 TegaUpdateVACOngoing work to get the FRG gauges readouts to EPICs channels

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.  

Attachment 1: iolan_xgs_comm_investigation.pdf
iolan_xgs_comm_investigation.pdf iolan_xgs_comm_investigation.pdf iolan_xgs_comm_investigation.pdf iolan_xgs_comm_investigation.pdf
  16703   Sat Mar 5 02:03:46 2022 KojiUpdateSUSETMY 1Y4 Electronics Replacement

Oplev saga


- 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.

Attachment 1: oplev_spot.jpg
Attachment 2: PXL_20220305_090003837.jpg
Attachment 3: PXL_20220305_090023436.jpg
Attachment 4: PXL_20220305_091232290.jpg
Attachment 5: PXL_20220305_091306604.MP.jpg
Attachment 6: Screenshot_2022-03-05_01-37-26.png
  16702   Sat Mar 5 01:58:49 2022 KojiSummaryCDSpaola rescue

ETMY end ThinkPad "paola" could not reboot due to "Fan Error". It seems that it is the failure of the CPU fan. I really needed a functional laptop at the end for the electronics work, I decided to open the chassis. By removing the marked screws at the bottom lid, the keyboard was lifted. I found that the CPU fan was stuck because of accumulated dust. Once the fan was cleaned, the laptop starts up as before.

Attachment 1: PXL_20220305_035255834.jpg
Attachment 2: PXL_20220305_034649120.MP.jpg
  16701   Fri Mar 4 18:12:44 2022 KojiUpdateVACRGA pumping down

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)

Attachment 1: Screenshot_2022-03-04_19-38-11.png
  16700   Fri Mar 4 11:04:34 2022 AnchalSummaryCDSc1susaux2 system setup and running

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.

Attachment 1: 40mBHD_C1SUSAUX2_Acromag_Chassis.pdf
  16699   Thu Mar 3 17:21:11 2022 Ian MacMillanUpdateSUSETMY 1Y4 Electronics Replacement

[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

  16698   Thu Mar 3 17:09:46 2022 PacoUpdateBHDRe-susspension of AS1

[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.


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.


  16697   Thu Mar 3 15:37:40 2022 AnchalSummaryCDSc1teststand restructured

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 The login and password are same as our usual workstation username and password.

  16696   Thu Mar 3 04:24:23 2022 KojiUpdateSUSETMY 1Y4 Electronics Replacement

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


Attachment 1: PXL_20220303_094421604.jpg
Attachment 2: PXL_20220303_094435127.jpg
  16695   Thu Mar 3 04:11:36 2022 KojiUpdateSUSETMY 1Y4 Electronics Replacement

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

Attachment 1: PXL_20220303_082726693.jpg
Attachment 2: PXL_20220303_082752494.jpg
Attachment 3: PXL_20220303_082744464.jpg
  16694   Wed Mar 2 14:02:43 2022 YehonathanUpdateBHDRe-susspension of AS1

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.

  16693   Wed Mar 2 12:40:08 2022 TegaUpdateVACOngoing work to get the FRG gauges readouts to EPICs channels

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 "" 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.

Attachment 1: IMG_20220302_123529382.jpg
Attachment 2: XGS600_Serial2Ethernet2Serial2USB_comm_test_result.txt
$ python3 XGS600_comm_test.py  

----- Multiple Sensor Read Commands -----

Sent to XGS-600 -> #0001\r : Read XGS contents
response : >FE4CFE4CFE4C

Sent to XGS-600 -> #0003\r : Read Setpoint States
response : >0000

... 73 more lines ...
Attachment 3: VID-20220302-WA0001.mp4
Attachment 4: comm_test_c1vac_to_laptop_via_iolansds.py
#!/usr/bin/env python

#Created 3/2/22 by Tega Edo
'''Script to emulate XGS-600 controller using laptop USBserial port'''

import serial
import sys,os,math,time

ser = serial.Serial('/dev/cu.usbserial-1410') # open serial port 

... 19 more lines ...
Attachment 5: laptop_terminal.txt
(base) tega.edo@Tegas-MBP serial % python3 comm_test_c1vac_to_laptop_via_iolansds.py

----- Listen for USBserial command and asynchronously send data in XGS600 format -----

Command received from c1vac [1] : 

Data sent to c1vac [1] : >1.000E+00,NOCBL    ,NOCBL    ,NOCBL    ,2.00E+00,NOCBL\r
Command received from c1vac [2] : 

Data sent to c1vac [2] : >2.000E+00,NOCBL    ,NOCBL    ,NOCBL    ,3.00E+00,NOCBL\r
... 54 more lines ...
Attachment 6: c1vac_terminal.txt
controls@c1vac:/opt/target/python/serial$ caget C1:Vac-FRG1_status && caget C1:Vac-FRG2_status && caget C1:Vac-FRG3_status && caget C1:Vac-FRG4_status && caget C1:Vac-FRG5_status
C1:Vac-FRG1_status             1.530E+02
C1:Vac-FRG2_status             OFF
C1:Vac-FRG3_status             OFF
C1:Vac-FRG4_status             NO COMM
C1:Vac-FRG5_status             1.55E+02
controls@c1vac:/opt/target/python/serial$ caget C1:Vac-FRG1_status && caget C1:Vac-FRG2_status && caget C1:Vac-FRG3_status && caget C1:Vac-FRG4_status && caget C1:Vac-FRG5_status
C1:Vac-FRG1_status             1.630E+02
C1:Vac-FRG2_status             OFF
C1:Vac-FRG3_status             OFF
... 70 more lines ...
  16692   Wed Mar 2 11:50:39 2022 TegaUpdateVACOngoing work to get the FRG gauges readouts to EPICs channels

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.

Attachment 1: XGS600_IOLAN_settings_1.png
Attachment 2: XGS600_IOLAN_settings_2.png
Attachment 3: XGS600_USBserial_settings.png
Attachment 4: XGS600_comm_test.py
#!/usr/bin/env python

#Created 2/24/22 by Tega Edo
'''Script to read/write to the XGS-600 Gauge Controller'''

import serial
import sys,os,math,time

ser = serial.Serial('/dev/cu.usbserial-1410') # open serial port 

... 74 more lines ...
Attachment 5: XGS600_comm_test_result.txt
----- Multiple Sensor Read Commands -----

Sent to XGS-600 -> #0001\r : Read XGS contents
response : >FE4CFE4CFE4C

Sent to XGS-600 -> #0003\r : Read Setpoint States
response : >0000

Sent to XGS-600 -> #0005\r : Read software revision
response : >0206,0200,0200,0200
... 69 more lines ...
  16691   Tue Mar 1 20:38:49 2022 TegaUpdateVACOngoing work to get the FRG gauges readouts to EPICs channels

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.

Attachment 1: Working_Serial_Port_List_1.png
Attachment 2: Working_Serial_Port_List_2.png
Attachment 3: Working_Config_Ports#1-5.png
Attachment 4: Working_Config_Ports#7-8.png
  16690   Tue Mar 1 19:26:24 2022 KojiUpdateSUSETMY SUS Electronics Replacement

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.

Attachment 1: PXL_20220302_025723651.jpg
Attachment 2: PXL_20220302_030102033.MP.jpg
  16689   Tue Mar 1 16:01:14 2022 PacoUpdateElectronicsRFSoC 2x2 board -- setup for remote work & BALUN saga

[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.

Attachment 1: balun_adc1.png
Attachment 2: PXL_20220302_001734121.jpg
  16688   Mon Feb 28 19:15:10 2022 TegaUpdateVACOngoing work to get the FRG gauges readouts to EPICs channels

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.

  16687   Mon Feb 28 15:51:07 2022 Ian MacMillanUpdateSUSETMY 1Y4 Electronics Replacement

[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 DB9 (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:

Number Used Type of Cable Length
8 DB9 to DB9 2.5 ft
2 DB9 to DB9 5 ft
2 DB9-DB15  
2 DB9 (called #1, aka D2100675-01) 30ft
9 Orange Power Cables ~ 3 ft

I attached pictures below.

Attachment 1: IMG_0865.jpg
Attachment 2: IMG_0867.jpg
Attachment 3: IMG_0868.jpg
Attachment 4: IMG_0866.jpg
  16686   Sun Feb 27 01:12:46 2022 KojiUpdateGeneralIMC manual alignment procedure

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.


Attachment 1: PXL_20220226_100859871.jpg
ELOG V3.1.3-