40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 248 of 341  Not logged in ELOG logo
ID Date Authordown Type Category Subject
  16278   Thu Aug 12 14:59:25 2021 KojiUpdateGeneralPSL shutter was closed this morning

What I was afraid of was the vacuum interlock. And indeed there was a pressure surge this morning. Is this real? Why didn't we receive the alert?

Attachment 1: Screen_Shot_2021-08-12_at_14.58.59.png
Screen_Shot_2021-08-12_at_14.58.59.png
  16279   Thu Aug 12 20:52:04 2021 KojiUpdateGeneralPSL shutter was closed this morning

I did a bit more investigation on this.

- I checked P1~P4, PTP2/3, N2, TP2, TP3. But found only P1a and P2 were affected.

- Looking at the min/mean/max of P1a and P2 (Attachment 1), the signal had a large fluctuation. It is impossible to have P1a from 0.004 to 0 instantaneously.

- Looking at the raw data of P1a and P2 (Attachment 2), the value was not steadily large. Instead it looks like fluctuating noise.

So my conclusion is that because of an unknown reason, an unknown noise coupled only into P1a and P2 and tripped the PSL shutter. I still don't know the status of the mail alert.

Attachment 1: Screen_Shot_2021-08-12_at_20.51.19.png
Screen_Shot_2021-08-12_at_20.51.19.png
Attachment 2: Screen_Shot_2021-08-12_at_20.51.34.png
Screen_Shot_2021-08-12_at_20.51.34.png
  16281   Tue Aug 17 04:30:35 2021 KojiUpdateSUSNew electronics

Received:

Aug 17, 2021 2x ISC Whitening

Delivered 2x Sat Amp board to Todd

 

Attachment 1: P_20210816_234136.jpg
P_20210816_234136.jpg
Attachment 2: P_20210816_235106.jpg
P_20210816_235106.jpg
Attachment 3: P_20210816_234220.jpg
P_20210816_234220.jpg
  16284   Thu Aug 19 14:14:49 2021 KojiUpdateCDSTime synchornization not running

131.215.239.14 looks like Caltech's NTP server (ntp-02.caltech.edu)
https://webmagellan.com/explore/caltech.edu/28415b58-837f-4b46-a134-54f4b81bee53

I can't say it is correct or not as I did not make the survey at your level. I think you need a few tests of reconfiguring and restarting the NTP clients to see if time synchronization starts. Because the local time is not regulated right now anyway, this operation is safe I think.

 

  16288   Mon Aug 23 11:51:26 2021 KojiUpdateGeneralCampus Wide Power Glitch Reported: Monday, 8/23/21 at 9:30am

Campus Wide Power Glitch Reported: Monday, 8/23/21 at 9:30am (more like 9:34am according to nodus log)

nodus: rebooted. ELOG/apache/svn is running. (looks like Anchal worked on it)

chiara: survived the glitch thanks to UPS

fb1: not responding -> @1pm open to login / seemed rebooted only at 9:34am (network path recovered???)

megatron: not responding

optimus: no route to host

c1aux: ping ok, ssh not responding -> needed to use telnet (vme / vxworks)
c1auxex: ssh ok
c1auxey: ping ok, ssh not respoding -> needed to use telnet (vme / vxworks)
c1psl: ping NG, power cycled the switch on 1X2 -> ssh OK now
c1iscaux: ping NG -> rebooted the machine -> ssh recovered

c1iscaux2: does not exist any more
c1susaux: ping NG -> responds after 1X2 switch reboot

c1pem1: telnet ok (vme / vxworks)
c1iool0: does not exist any more

c1vac1: ethernet service restarted locally -> responding
ottavia: doesnot exist?
c1teststand: ping ok, ssh not respoding

3:20PM we started restarting the RTS

  16290   Mon Aug 23 19:00:05 2021 KojiUpdateGeneralCampus Wide Power Glitch Reported: Monday, 8/23/21 at 9:30am

Restarting the RTS was unsuccessful because of the timing discrepancy error between the RT machines and the FB. This time no matter how we try to set the time, the IOPs do not run with "DC status" green. (We kept having 0x4000)

We then decided to work on the recovery without the data recorded. After some burtrestores, the IMC was locked and the spot appeared on the AS port. However, IPC seemed down and no WFS could run.

  16294   Tue Aug 24 18:44:03 2021 KojiUpdateCDSFB is writing the frames with a year old date

Dan Kozak pointed out that the new frame files of the 40m has not been written in 2021 GPS time but 2020 GPS time.

Current GPS time is 1313890914 (or something like that), but the new files are written as C-R-1282268576-16.gwf

I don't know how this can happen but this may explain why we can't have the agreement between the FB gps time and the RTS gps time.

(dataviewer seems dependent on the FB GPS time and it indicates 2020 date. DTT/diaggui does not.)


This is the way to check the gpstime on fb1. It's apparently a year off.

controls@fb1:~ 0$ cat /proc/gps
1282269402.89

Attachment 1: Screen_Shot_2021-08-24_at_18.46.24.png
Screen_Shot_2021-08-24_at_18.46.24.png
  16306   Wed Sep 1 21:55:14 2021 KojiSummaryGeneralTowards the end upgrade

- Sat amp mod and test: on going (Tega)
- Coil driver mod and test: on going (Tega)

- Acromag: almost ready (Yehonathan)

- IDC10-DB9 cable / D2100641 / IDC10F for ribbon in hand / Dsub9M ribbon brought from Downs / QTY 2 for two ends -> Made 2 (stored in the DSUB connector plastic box)
- IDC40-DB9 cable / D2100640 / IDC40F for ribbon in hand / DB9F solder brought from Downs  / QTY 4 for two ends -> Made 4 0.5m cables (stored in the DSUB connector plastic box)

- DB15-DB9 reducer cable / ETMX2+ETMY2+VERTEX16+NewSOS14 = 34 / to be ordered

- End DAC signal adapter with Dewhitening (with DIFF/SE converter) / to be designed & built
- End ADC adapter (with SE/DIFF converter) / to be designed & built


MISC Ordering

  • 3.5 x Sat Amp Adapter made (order more DSUB25 conns)
    • -> Gave 2 to Tega, 1.5 in the DSUB box
    • 5747842-4 A32100-ND -> ‎5747842-3‎ A32099-ND‎ Qty40
    • 5747846-3 A32125-ND -> ‎747846-3‎ A23311-ND‎ Qty40
  • Tega's sat amp components
    • 499Ω P499BCCT-ND 78 -> Backorder -> ‎RG32P499BCT-ND‎ Qty 100
    • 4.99KΩ TNPW12064K99BEEA 56 -> Qty 100
    • 75Ω YAG5096CT-ND 180 -> Qty 200
    • 1.82KΩ P18391CT-ND 103 -> Qty 120
    • 68 nF P10965-ND 209
  • Order more DB9s for Tega's sat amp adapter 4 units (look at the AA IO BOM) 
    • 4x 8x 5747840-4 DB9M PCB A32092-ND -> 6-747840-9‎ A123182-ND‎ Qty 35
    • 4x 5x 5747844-4 A32117-ND -> Qty 25
    • 4x 5x DB9M ribbon MMR09K-ND -> 8209-8000‎ 8209-8000-ND‎ Qty 25
    • 4x 5x 5746861-4 DB9F ribbon 5746861-4-ND -> 400F0-09-1-00 ‎LFR09H-ND‎ Qty 35
  • Order 18bit DAC AI -> 16bit DAC AI components 4 units
    • 4x 4x 5747150-8 DSUB9F PCB A34072-ND -> ‎D09S24A4PX00LF‎609-6357-ND‎ Qty 20
    • 4x 1x 787082-7 CONN D-TYPE RCPT 68POS R/A SLDR (SCSI Female) A3321-ND -> ‎5787082-7‎ A31814-ND‎ Qty 5
    • 4x 1x 22-23-2021 Connector Header Through Hole 2 position 0.100" (2.54mm)    WM4200-ND -> Qty5

 

 

  16308   Thu Sep 2 19:28:02 2021 KojiUpdate This week's FB1 GPS Timing Issue Solved

After the disk system trouble, we could not make the RTS running at the nominal state. A part of the troubleshoot FB1 was rebooted. But the we found that the GPS time was a year off from the current time

controls@fb1:/diskless/root/etc 0$ cat /proc/gps 
1283046156.91
controls@fb1:/diskless/root/etc 0$ date
Thu Sep  2 18:43:02 PDT 2021
controls@fb1:/diskless/root/etc 0$ timedatectl 
      Local time: Thu 2021-09-02 18:43:08 PDT
  Universal time: Fri 2021-09-03 01:43:08 UTC
        RTC time: Fri 2021-09-03 01:43:08
       Time zone: America/Los_Angeles (PDT, -0700)
     NTP enabled: no
NTP synchronized: yes
 RTC in local TZ: no
      DST active: yes
 Last DST change: DST began at
                  Sun 2021-03-14 01:59:59 PST
                  Sun 2021-03-14 03:00:00 PDT
 Next DST change: DST ends (the clock jumps one hour backwards) at
                  Sun 2021-11-07 01:59:59 PDT
                  Sun 2021-11-07 01:00:00 PST


Paco went through the process described in Jamie's elog [40m ELOG 16299] (except for the installation part) and it actually made the GPS time even strange

controls@fb1:~ 0$ cat /proc/gps
967861610.89

I decided to remove the gpstime module and then load it again. This made the gps time back to normal again.

controls@fb1:~ 0$ sudo modprobe -r gpstime
controls@fb1:~ 0$ cat /proc/gps
cat: /proc/gps: No such file or directory
controls@fb1:~ 1$ sudo modprobe gpstime
controls@fb1:~ 0$ cat /proc/gps
1314671254.11

 

  16309   Thu Sep 2 19:47:38 2021 KojiUpdateCDSThis week's FB1 GPS Timing Issue Solved

After the reboot daqd_dc was not working, but manual starting of open-mx / mx services solved the issue.

sudo systemctl start open-mx.service
sudo systemctl start mx.service
sudo systemctl start daqd_*

 

  16310   Thu Sep 2 20:44:18 2021 KojiUpdateCDSChiara DHCP restarted

We had the issue of the RT machines rebooting. Once we hooked up the display on c1iscex, it turned out that the IP was not given at it's booting-up.

I went to chiara and confirmed that the DHCP service was not running

~>sudo service isc-dhcp-server status
[sudo] password for controls:
isc-dhcp-server stop/waiting

So the DHCP service was manually restarted

~>sudo service isc-dhcp-server start
isc-dhcp-server start/running, process 24502
~>sudo service isc-dhcp-server status
isc-dhcp-server start/running, process 24502

 

 

  16311   Thu Sep 2 20:47:19 2021 KojiUpdateCDSChiara DHCP restarted

[Paco, Tega, Koji]

Once chiara's DHCP is back, things got much more straight forward.
c1iscex and c1iscey were rebooted and the IOPs were launched without any hesitation.

Paco ran rebootC1LSC.sh and for the first time in this year we had the launch of the processes without any issue.

  16312   Thu Sep 2 21:21:14 2021 KojiSummaryComputersVacuum recovery 2

Attachment 1:
We are pumping the main volume with TP2. Once P1a reached the pressure ~2.2mtorr, we could open the PSL shutter. The TP2 voltage went up once but came down to ~20V. It's close to nominal now.
We wondered if we should use TP3 or not. I checked the vacuum pressure trends and found that the annulus pressures were going up. So we decided to open the annulus valves.

Attachment 2:
The current vacuum status is as shown in the MEDM screenshot.

There is no trend data of the valve status (sad)

Attachment 1: Screenshot_2021-09-02_21-20-24.png
Screenshot_2021-09-02_21-20-24.png
Attachment 2: Screenshot_2021-09-02_21-20-48.png
Screenshot_2021-09-02_21-20-48.png
  16316   Wed Sep 8 18:00:01 2021 KojiUpdateVACcronjobs & N2 pressure alert

In the weekly meeting, Jordan pointed out that we didn't receive the alert for the low N2 pressure.

To check the situation, I went around the machines and summarized the cronjob situation.
[40m wiki: cronjob summary]
Note that this list does not include the vacuum watchdog and mailer as it is not on cronjob.

Now, I found that there are two N2 scripts running:

1. /opt/rtcds/caltech/c1/scripts/Admin/n2Check.sh on megatron and is running every minute (!)
2. /opt/rtcds/caltech/c1/scripts/Admin/N2check/pyN2check.sh on c1vac and is running every 3 hours.

Then, the N2 log file was checked: /opt/rtcds/caltech/c1/scripts/Admin/n2Check.log

Wed Sep 1 12:38:01 PDT 2021 : N2 Pressure: 76.3621
Wed Sep 1 12:38:01 PDT 2021 : T1 Pressure: 112.4
Wed Sep 1 12:38:01 PDT 2021 : T2 Pressure: 349.2
Wed Sep 1 12:39:02 PDT 2021 : N2 Pressure: 76.0241
Wed Sep 1 12:39:02 PDT 2021 : N2 pressure has fallen to 76.0241 PSI !

Tank pressures are 94.6 and 98.6 PSI!

This email was sent from Nodus.  The script is at /opt/rtcds/caltech/c1/scripts/Admin/n2Check.sh

Wed Sep 1 12:40:02 PDT 2021 : N2 Pressure: 75.5322
Wed Sep 1 12:40:02 PDT 2021 : N2 pressure has fallen to 75.5322 PSI !

Tank pressures are 93.6 and 97.6 PSI!

This email was sent from Nodus.  The script is at /opt/rtcds/caltech/c1/scripts/Admin/n2Check.sh

...

The error started at 11:39 and lasted until 13:01 every minute. So this was coming from the script on megatron. We were supposed to have ~20 alerting emails (but did none).
So what's happened to the mails? I tested the script with my mail address and the test mail came to me. Then I sent the test mail to 40m mailing list. It did not reach.
-> Decided to put the mail address (specified in /etc/mailname , I believe) to the whitelist so that the mailing list can accept it.
I did run the test again and it was successful. So I suppose the system can now send us the alert again.
And alerting every minute is excessive. I changed the check frequency to every ten minutes.

What's happened to the python version running on c1vac?
1) The script is running, spitting out some error in the cron report (email on c1vac). But it seems working.
2) This script checks the pressures of the bottles rather than the N2 pressure downstream. So it's complementary.
3) During the incident on Sept 1, the checker did not trip as the pressure drop happened between the cronjob runs and the script didn't notice it.
4) On top of them, the alert was set to send the mails only to an our former grad student. I changed it to deliver to the 40m mailing list. As the "From" address is set to be some ligox...@gmail.com, which is a member of the mailing list (why?), we are supposed to receive the alert. (And we do for other vacuum alert from this address).

 

 

 

 

  16317   Wed Sep 8 19:06:14 2021 KojiUpdateGeneralBackup situation

Tega mentioned in the meeting that it could be safer to separate some of nodus's functions from the martian file system.
That's an interesting thought. The summary pages and other web services are linked to the user dir. This has high traffic and can cause the issure of the internal network once we crash the disk.
Or if the internal system is crashed, we still want to use elogs as the source of the recovery info. Also currently we have no backup of the elog. This is dangerous.

We can save some of the risks by adding two identical 2TB disks to nodus to accomodate svn/elog/web and their daily backup.

host file system or contents condition note
nodus root none or unknown  
nodus home (svn, elog) none  
nodus web (incl summary pages) backed up linked to /cvs/cds
chiara root maybe need to check with Jon/Anchal
chiara /home/cds local copy The backup disk is smaller than the main disk.
chiara /home/cds remote copy - stalled we used to have, but stalled since 2017/11/17
fb1 root maybe need to check with Jon/Anchal
fb1 frame rsync pulled from LDAS according to Tega
       

 

  16328   Tue Sep 14 17:14:46 2021 KojiUpdateSUSSOS Tower Hardware

Yup this is OK. No problem.

 

  16331   Tue Sep 14 19:12:03 2021 KojiSummaryPEMExcess seismic noise in 0.1 - 0.3 Hz band

Looks like this increase is correlated for BS/EX/EY. So it is likely to be real.

Comparison between 9/15 (UTC) (Attachment 1) and 9/10 (UTC) (Attachment 2)

Attachment 1: C1-ALL_393F21_SPECTRUM-1315699218-86400.png
C1-ALL_393F21_SPECTRUM-1315699218-86400.png
Attachment 2: C1-ALL_393F21_SPECTRUM-1315267218-86400.png
C1-ALL_393F21_SPECTRUM-1315267218-86400.png
  16333   Wed Sep 15 23:38:32 2021 KojiUpdateALSALS ASX PZT HV was off -> restored

It was known that the Y end ALS PZTs are not working. But Anchal reported in the meeting that the X end PZTs are not working too.

We went down to the X arm in the afternoon and checked the status. The HV (KEPCO) was off from the mechanical switch. I don't know this KEPCO has the function to shutdown the switch at the power glitch or not.
But anyway the power switch was engaged. We also saw a large amount of misalignment of the X end green. The alignment was manually adjusted. Anchal was able to reach ~0.4 Green TRX, but no more. He claimed that it was ~0.8.

We tried to tweak the SHG temp from 36.4. We found that the TRX had the (local) maximum of ~0.48 at 37.1 degC. This is the new setpoint right now.

Attachment 1: P_20210915_151333.jpg
P_20210915_151333.jpg
  16334   Wed Sep 15 23:53:54 2021 KojiSummaryGeneralTowards the end upgrade

Ordered compoenents are in.

- Made 36 more Sat Amp internal boards (Attachment 1). Now we can install the adapters to all the 19 sat amp units.

- Gave Tega the components for the sat amp adapter units. (Attachment 2)

- Gave Tega the componennts for the sat amp / coil driver modifications.

- Made 5 PCBs for the 16bit DAC AI rear panel interface (Attachment 3)

Attachment 1: P_20210915_231308.jpg
P_20210915_231308.jpg
Attachment 2: P_20210915_225039.jpg
P_20210915_225039.jpg
Attachment 3: P_20210915_224341.jpg
P_20210915_224341.jpg
  16335   Thu Sep 16 00:00:20 2021 KojiUpdateGeneralRIO Planex 1064 Lasers in the south cabinet

RIO Planex 1064 Lasers in the south cabinet

Property Number C30684/C30685/C30686/C30687

Attachment 1: P_20210915_232426.jpg
P_20210915_232426.jpg
  16336   Thu Sep 16 01:16:48 2021 KojiUpdateGeneralFrozen 2

It happened again. Defrosting required.

Attachment 1: P_20210916_003406_1.jpg
P_20210916_003406_1.jpg
  16341   Fri Sep 17 00:56:49 2021 KojiUpdateGeneralAwesome

The Incredible Melting Man!

 

  16342   Fri Sep 17 20:22:55 2021 KojiUpdateSUSEQ M4.3 Long beach

EQ  M4.3 @longbeach
2021-09-18 02:58:34 (UTC) / 07:58:34 (PDT)
https://earthquake.usgs.gov/earthquakes/eventpage/ci39812319/executive

  • All SUS Watchdogs tripped, but the SUSs looked OK except for the stuck ITMX.
  • Damped the SUSs (except ITMX)
  • IMC automatically locked
  • Turned off the damping of ITMX and shook it only with the pitch bias -> Easily unstuck -> damping recovered -> realignment of the ITMX probably necessary.
  • Done.
  16344   Mon Sep 20 14:11:40 2021 KojiUpdateBHDEnd DAC Adapter Unit D2100647

I've uploaded the schematic and PCB PDF for End DAC Adapter Unit D2100647.

Please review the design.

  • CH1-8 SUS actuation channels.
    • 5CHs out of 8CHs are going to be used, but for future extensions, all the 8CHs are going to be filled.
    • It involves diff-SE conversion / dewhitening / SE-diff conversion. Does this make sense?
  • CH9-12 PZT actuation channels. It is designed to send out 4x SE channels for compatibility. The channels have the jumpers to convert it to pass through the diff signals.
  • CH13-16 are general purpose DIFF/SE channels. CH13 is going to be used for ALS Laser Slow control. The other 3CHs are spares.

The internal assembly drawing & BOM are still coming.

Attachment 1: D2100647_End_DAC_Adapter.pdf
D2100647_End_DAC_Adapter.pdf D2100647_End_DAC_Adapter.pdf D2100647_End_DAC_Adapter.pdf D2100647_End_DAC_Adapter.pdf D2100647_End_DAC_Adapter.pdf D2100647_End_DAC_Adapter.pdf D2100647_End_DAC_Adapter.pdf D2100647_End_DAC_Adapter.pdf
  16350   Mon Sep 20 21:56:07 2021 KojiUpdateComputersWifi internet fixed

Ug, factory resets... Caltech IMSS announced that there was an intermittent network service due to maintenance between Sept 19 and 20. And there seemed some aftermath of it. Check out "Caltech IMSS"

 

  16376   Mon Oct 4 18:00:16 2021 KojiSummaryCDSc1teststand problems summary

I don't know anything about mx/open-mx, but you also need open-mx,don't you?


controls@c1ioo:~ 0$ systemctl status *mx*
● open-mx.service - LSB: starts Open-MX driver
   Loaded: loaded (/etc/init.d/open-mx)
   Active: active (running) since Wed 2021-09-22 11:54:39 PDT; 1 weeks 5 days ago
  Process: 470 ExecStart=/etc/init.d/open-mx start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/open-mx.service
           └─620 /opt/3.2.88-csp/open-mx-1.5.4/bin/fma -d

● mx_stream.service - Advanced LIGO RTS front end mx stream
   Loaded: loaded (/etc/systemd/system/mx_stream.service; enabled)
   Active: active (running) since Wed 2021-09-22 12:08:00 PDT; 1 weeks 5 days ago
 Main PID: 5785 (mx_stream)
   CGroup: /system.slice/mx_stream.service
           └─5785 /usr/bin/mx_stream -e 0 -r 0 -w 0 -W 0 -s c1x03 c1ioo c1als c1omc -d fb1:0

 

  16378   Mon Oct 4 20:46:08 2021 KojiUpdateElectronicsSatellite amp box adapters

Thanks. You should be able to find the chassis-related hardware on the left side of the benchtop drawers at the middle workbench.

Hardware: The special low profile 4-40 standoff screw / 1U handles / screws and washers for the chassis / flat-top screws for chassis panels and lids

  16380   Tue Oct 5 17:01:20 2021 KojiUpdateElectronicsSat Amp modifications

Make sure the inputs for the PD amps are open. This is the current amplifier and we want to leave the input pins open for the test of this circuit.

TP6 is the first stage of the amps (TIA). So this stage has the issue. Usual check if the power is properly supplied / if the pins are properly connected/isolated / If the opamp is alive or not.

For TP8, if TP8 get railed. TP5 and TP7 are going to be railed too. Is that the case, if so, check this whitening stage in the same way as above.
If the problem is only in the TP5 and/or TP7 it is the differential driver issue. Check the final stage as above. Replacing the opamp could help.

 

  16387   Thu Oct 7 02:04:19 2021 KojiUpdateElectronicsSatellite amp adapter chassis

The 4 units of Satellite Amp Adapter were done:
- The ears were fixed with the screws
- The handles were attached (The stock of the handles is low)
- The boards are now supported by plastic stand-offs. (The chassis were drilled)
- The front and rear panels were fixed to the chassis
- The front and rear connectors were fixed with the low profile 4-40 stand-off screws (3M 3341-1S)
 

Attachment 1: P_20211006_205044.jpg
P_20211006_205044.jpg
  16397   Tue Oct 12 23:42:56 2021 KojiSummaryCDSConnected c1sus2 to martian network

Don't you need to add the new hosts to /diskless/root/etc/rtsystab at fb1? --> There looks many elogs talking about editing "rtsystab".

controls@fb1:/diskless/root/etc 0$ cat rtsystab
#
# host    list of control systems to run, starting with IOP
#
c1iscex  c1x01  c1scx c1asx
c1sus     c1x02  c1sus c1mcs c1rfm c1pem
c1ioo     c1x03  c1ioo c1als c1omc
c1lsc    c1x04  c1lsc c1ass c1oaf c1cal c1dnn c1daf
c1iscey  c1x05 c1scy c1asy
#c1test   c1x10  c1tst2

 

  16404   Thu Oct 14 18:30:23 2021 KojiSummaryVACFlange/Cable Stand Configuration

Flange Configuration for BHD

We will need total 5 new cable stands. So Qty.6 is the number to be ordered.


Looking at the accuglass drawing, the in-vaccum cables are standard dsub 25pin cables only with two standard fixing threads.

https://www.accuglassproducts.com/sites/default/files/PDF/Partpdf/110070_3.pdf

For SOSs, the standard 40m style cable bracket works fine. https://dcc.ligo.org/D010194-x0

However, for the OMCs, we need to make the thread holes available so that we can mate DB25 male cables to these cables.
One possibility is to improvise this cable bracket to suspend the cables using clean Cu wires or something. I think we can deal with this issue in situ.


Ha! The male side has the 4-40 standoff (jack) screws. So we can hold the male side on the bracket using the standoff (jack) screws and plug the female cables. OK! The issue solved!

https://www.accuglassproducts.com/sites/default/files/PDF/Partpdf/110029_3.pdf

Attachment 1: 40m_flange_layout_20211014.pdf
40m_flange_layout_20211014.pdf
  16408   Fri Oct 15 17:17:51 2021 KojiSummaryGeneralVent Prep

I took over the vent prep: I'm going through the list in [ELOG 15649] and [ELOG 15651]. I will also look at [ELOG 15652] at the day of venting.

  1. IFO alignment: Two arms are already locking. The dark port beam is well overlapped. We will move PRM/SRM etc. So we don't need to worry about them. [Attachment 1]
    scripts>z read C1:SUS-BS_PIT_BIAS C1:SUS-BS_YAW_BIAS
    -304.7661529521767
    -109.23924626857811
    scripts>z read C1:SUS-ITMX_PIT_BIAS C1:SUS-ITMX_YAW_BIAS
    15.534616817500943
    -503.4536332290159
    scripts>z read C1:SUS-ITMY_PIT_BIAS C1:SUS-ITMY_YAW_BIAS
    653.0100945988496
    -478.16260735781225
    scripts>z read C1:SUS-ETMX_PIT_BIAS C1:SUS-ETMX_YAW_BIAS
    -136.17863332517527
    181.09285307121306
    scripts>z read C1:SUS-ETMY_PIT_BIAS C1:SUS-ETMY_YAW_BIAS
    -196.6200333695437
    -85.40819256078339

     
  2. IMC alignment: Locking nicely. I ran WFS relief to move the WFS output on to the alignment sliders. All the WFS feedback values are now <10. Here is the slider snapshots. [Attachment 2]
     
  3. PMC alignmnet: The PMC looked like it was quite misaligned -> aligned. IMC/PMC locking snapshot [Attachment 3]
    Arm transmissions:
    scripts>z avg 10  C1:LSC-TRX_OUT C1:LSC-TRY_OUT
    C1:LSC-TRX_OUT 0.9825591325759888
    C1:LSC-TRY_OUT 0.9488834202289581

     
  4. Suspension Status Snapshot [Attachment 4]
     
  5. Anchal aligned the OPLEV beams [ELOG 16407]
    I also checked the 100 days trend of the OPLEV sum power. The trend of the max values look flat and fine. [Attachment 5] For this purpose, the PRM and SRM was aligned and the SRM oplev was also aligned. The SRM sum was 23580 when aligned and it was just fine (this is not so visible in the trend plot).
     
  6. The X and Y green beams were aligned for the cavity TEM00s. Y end green PZT values were nulled. The transmission I could reach was as follows.
    >z read C1:ALS-TRX_OUTPUT C1:ALS-TRY_OUTPUT
    0.42343354488901286
    0.24739624058377277

    It seems that these GTRX and GTRY seemed to have crosstalk. When each green shutters were closed the transmissino and the dark offset were measured to be
    >z read C1:ALS-TRX_OUTPUT C1:ALS-TRY_OUTPUT
    0.41822833190834546
    0.025039383697636856
    >z read C1:ALS-TRX_OUTPUT C1:ALS-TRY_OUTPUT
    0.00021112720155274818
    0.2249448773499293

    Note that Y green seemed to have significant (~0.1) of 1st order HOM. I don't know why I could not transfer this power into TEM00. I could not find any significant clipping of the TR beams on the PSL table PDs.
     
  7. IMC Power reduction
    Now we have nice motorized HWP. sitemap -> PSL -> Power control
    == Initial condition == [Attachment 6]
    C1:IOO-HWP_POS 38.83
    Measured input power = 0.99W
    C1:IOO-MC_RFPD_DCMON = 5.38
    == Power reduction == [Attachment 7]
    - The motor was enabled upon rotation on the screen

    C1:IOO-HWP_POS 74.23
    Measured input power = 98mW
    C1:IOO-MC_RFPD_DCMON = 0.537
    - Then, the motor was disabled
     
  8. Went to the detection table and swapped the 10% reflector with the 98% reflector stored on the same table. [Attachments 8/9]
    After the beam alignment the MC REFL PD received about the same amount of the light as before.
    C1:IOO-MC_RFPD_DCMON = 5.6
    There is no beam delivered to the WFS paths.
    CAUTION: IF THE POWER IS INCREASED TO THE NOMINAL WITH THIS CONFIGURATION, MC REFL PD WILL BE DESTROYED.
  9. The IMC can already be locked with this configuration. But for the MC Autolocker, the MCTRANS threshold for the autolocker needs to be reduced as well.
    This was done by swapping a line in  /opt/rtcds/caltech/c1/scripts/MC/AutoLockMC.init
    # BEFORE
    /bin/csh ./AutoLockMC.csh >> $LOGFILE
    #/bin/csh ./AutoLockMC_LowPower.csh >> $LOGFILE
    --->
    # AFTER
    #/bin/csh ./AutoLockMC.csh >> $LOGFILE
    /bin/csh ./AutoLockMC_LowPower.csh >> $LOGFILE

    Confirmed that the autolocker works a few times by toggling the PSL shutter. The PSL shutter was closed upon the completion of the test
     
  10. Walked around the lab and checked all the bellows - the jam nuts are all tight, and I couldn't move them with my hands. So this is okay according to the ancient tale by Steve.
Attachment 1: Screenshot_2021-10-15_17-36-00.png
Screenshot_2021-10-15_17-36-00.png
Attachment 2: Screenshot_2021-10-15_17-39-58.png
Screenshot_2021-10-15_17-39-58.png
Attachment 3: Screenshot_2021-10-15_17-42-20.png
Screenshot_2021-10-15_17-42-20.png
Attachment 4: Screenshot_2021-10-15_17-46-13.png
Screenshot_2021-10-15_17-46-13.png
Attachment 5: Screenshot_2021-10-15_18-05-54.png
Screenshot_2021-10-15_18-05-54.png
Attachment 6: Screen_Shot_2021-10-15_at_19.45.05.png
Screen_Shot_2021-10-15_at_19.45.05.png
Attachment 7: Screen_Shot_2021-10-15_at_19.47.10.png
Screen_Shot_2021-10-15_at_19.47.10.png
  16409   Fri Oct 15 20:53:49 2021 KojiSummaryGeneralVent Prep

From the IFO point of view, all look good and we are ready for venting from Mon Oct 18 9AM

  16410   Mon Oct 18 10:02:17 2021 KojiUpdateVACVent Started / Completed

[Chub, Jordan, Anchal, Koji]

- Checked the main volume is isolated.
- TP1 and TP2 were made isolated from other volumes. Stopped TP1. Closed V4 to isolate TP1 from TP2.
- TP3 was made isolated. TP3 was stopped.
- We wanted to vent annuli, but it was not allowed as VA6 was open. We closed VA6 and vented the annuli with VAVEE.
- We wanted to vent the volume between VA6, V5, VM3, V7 together with TP1. So V7 was opened. This did not change the TP1 pressure (P2 = 1.7mmTorr) .
- We wanted to connect the TP1 volume with the main volume. But this was not allowed as TP1 was not rotating. We will vent TP1 through TP2 once the vent of the main volume is done.

- Satrted venting the main volume@Oct 18, 2021 9:45AM PDT

- We started from 10mTorr/min, and increased the vent speed to 200mTorr/min, 700mTorr/min, and now it is 1Torr/min @ 20Torr
- 280Torr @11:50AM
- 1atm  @~2PM


We wanted to vent TP1. We rerun the TP2 and tried to slowly introduce the air via TP2. But the interlock prevents the action.

Right now the magenta volume in the attachment is still ~1mTorr. Do we want to open the gate valves manually? Or stop the interlock process so that we can bypass it?

Attachment 1: Screen_Shot_2021-10-18_at_14.52.34.png
Screen_Shot_2021-10-18_at_14.52.34.png
Attachment 2: Screenshot_2021-10-18_15-08-59.png
Screenshot_2021-10-18_15-08-59.png
  16412   Tue Oct 19 10:59:09 2021 KojiUpdateVACVent Started / Completed

[Chub, Jordan, Yehonathan, Anchal, Koji]

North door of the BS chamber opened

 

  16413   Tue Oct 19 11:30:39 2021 KojiUpdateVACHow to vent TP1

I learned that TP1 was vented through the RGA room in the past. This can be done by opening VM2 and a manual valve ("needle valve")
I checked the setup and realized that this will vent RGA. But it is OK as long as we turns of the RGA during vent and bake it once TP1 is back.

Additional note:

- It'd be nice to take a scan for the current background level before the work.
- Turn RGA EM and filament off, let it cool down overnight. 
- Vent with clean N2 or clean air. (Normal operating temp ~80C is to minimize accumulation of H-C contaminations.)
- There is a manual switch and indicators on the top of the RGA amp. It has auto protection to turn filament off if the pressure increase over ~1e-5.

Attachment 1: Screen_Shot_2021-10-18_at_14.52.34.png
Screen_Shot_2021-10-18_at_14.52.34.png
  16415   Tue Oct 19 23:43:09 2021 KojiSummaryCDSc1sus2 DAC to ADC test

(Because of a totally unrelated reason) I was checking the electronics units for the upgrade. And I realized that the electronics units at the test stand have not been properly powered.

I found that the AA/AI stack at the test stand (Attachment 1) has an unusual powering configuration (Attachment 2).
- Only the positive power supply was used / - The supply voltage is only +15V / - The GND reference is not connected to anywhere.

For confirmation, I checked the voltage across the DC power strip (Attachments 3/4). The positive was +5.3V and the negative was -9.4V. This is subject to change depending on the earth potential.

This is not a good condition at all. The asymmetric powering of the circuit may cause damages to the opamps. So I turned off the switches of the units.

The power configuration should be immediately corrected.

  1. Use both positive and negative supply (2 power supply channels) to produce the positive and the negative voltage potentials. Connect the reference potential to the earth post of the power supply.
    https://www.youtube.com/watch?v=9_6ecyf6K40   [Dual Power Supply Connection / Serial plus minus electronics laboratory PS with center tap]
  2. These units have DC power regulator which produces +/-15V out of +/-18V. So the DC power supplies are supposed to be set at +18V.

 

Attachment 1: P_20211019_224433.jpg
P_20211019_224433.jpg
Attachment 2: P_20211019_224122.jpg
P_20211019_224122.jpg
Attachment 3: P_20211019_224400.jpg
P_20211019_224400.jpg
Attachment 4: P_20211019_224411.jpg
P_20211019_224411.jpg
  16418   Wed Oct 20 15:58:27 2021 KojiUpdateVACHow to vent TP1

Probably the hard disk of c0rga is dead. I'll follow up in this elog later today.

Looking at the log in /opt/rtcds/caltech/c1/scripts/RGA/logs , it seemed that the last RGA scan was Sept 2, 2021, the day when we had the disk full issue of chiara.
I could not login to c0rga from control machines.
I was not aware of the presence for c0rga until today, but I could locate it in the X arm.
The machine was not responding and it was rebooted, but could not restart. It made some knocking sound. I am afraid that the HDD failed.

I think we can
- prepare a replacement linux machine for the python scripts
or
- integrate it with c1vac

  16428   Tue Oct 26 14:53:24 2021 KojiUpdateElectronicsRack

1. We have a rack at the 40m storage. We are free to take it to the lab. If there is a tag, tell the info to Liz. Let's move it to the lab tomorrow right after the meeting.

2. We have a few racks in WB B1 (Attachment 1). Liz and I checked a rack which looks suitable for us. 46U height. Caltech transport will move it to the lab.

Attachment 1: P_20211026_143814.jpg
P_20211026_143814.jpg
  16434   Wed Oct 27 18:11:37 2021 KojiSummaryBHDPart II of BHR upgrade - Relocation of TT2 and MMT1/2 alignment

Closed the PSL shutter @18:11
During the vent, we want to keep the cavity unlocked if not necessary.

 

  16435   Wed Oct 27 18:16:45 2021 KojiSummaryBHDPart II of BHR upgrade - Relocation of TT2 and MMT1/2 alignment

- Moving the MMT2 south by a cm is fine. This will give you ~0.5cm at TT1 without changing the other alignment much.
- IMC mode is moving because of your presence + HEPA blow.
- 2cm at Faraday is plenty for the beam diameter of a few mm.

 

  16436   Wed Oct 27 19:34:52 2021 KojiSummaryElectronicsNew electronics racks

1. The rack we cleaned today (came from West Bridge) will be placed between 1X3 and 1X4, right next to 1X4 (after removing the plastic boxes). (Attachment 1)
For easier work at the side of the 1X4, the side panel of the 1X4 should be removed before placing the new rack. Note that this rack is imperial and has 10-32 threads

2. In terms of the other rack for the Y arm, we found the rack in the storage is quite dirty. Anchal pointed out that we have a few racks standing along the Y arm (as the storage of the old VME/Euro card electronics) (Attachments 2/3)
They are not too dirty and also doing nothing there. Let's vacate one of them (the one right next to the optics preparation table). Use this space as a new storage area placing a wire shelving rack for something.

BTW, I thought it is good to have the rack at the vertex side of 1Y1 (as 1Y0?), but the floor has "KEEP OUT" marking. I have no idea why we have this marking. Is this for crane operation??? Does any one know?

Attachment 1: P_20211027_180737.jpg
P_20211027_180737.jpg
Attachment 2: P_20211027_180443.jpg
P_20211027_180443.jpg
Attachment 3: P_20211027_180408.jpg
P_20211027_180408.jpg
Attachment 4: P_20211027_180139.jpg
P_20211027_180139.jpg
  16442   Mon Nov 1 14:51:34 2021 KojiUpdateGeneralChecking the vent plan

The vent team described a detailed vent plan (and reports where the actions have been performed)

https://wiki-40m.ligo.caltech.edu/vent/Fall2021

- [Sec.4] We should decide the final PR2 mirror through table-top measurements.

- [Sec 6] BS alignment is probably "unknown" now. So it'd be better to use the ITMY spot as the reference, then align BS for ITMX. For temporary alignment, it's OK though.

- [Sec 9-11] RIght now there is no mounts to place LO3/LO4/AS2/AS3/BHDBS. But we probably want to test something before the installation of the BHD? Just place the BHDBS on a optics mount so that we get an interfered beam on ITMY?

At this point we are supposed to have all the electronics all the CDS necessary for the new SOS control. Otherwise, they are just swinging and the alignment work will just be impossible.

- [Sec 15] The OPLEV mirrors can be freely moved as long as it does not block the main IR beams. Moving ITMXOL1 makes the reflection blocked by ITMXOL2. And moving ITMXOL2 would make the IR beams clipped. Consider replacing the mounts with a fixed mount. (The OPLEV mirrors are 1.5" in dia. It is not common vacuum compatible 1.5inch mounts. If 1" Al mirror is sufficient, we can use it.

https://wiki-40m.ligo.caltech.edu/vent/Fall2021/FinalAlignment

- The arms are the most strict alignment requirement. Everything else will follow the arm alignment. So start from the arms and propagate the alignment to Michelson / PRMI / SRMI.

- We reestablish arm alignment using the end green beams.

- Then recover IR arm alignment. Consider using ASS if possible

  16446   Tue Nov 2 22:50:30 2021 KojiUpdateBHDSOS assembly

2.5Hz is surprising. Can you move it down to sub 1Hz by adding a socket cap screw at the top instead of the set screw for the Teflon piece? How much mass do you need to add?

  16448   Thu Nov 4 15:03:43 2021 KojiSummaryBHD1Y1 rack work

I have visited the binder file for the 40m wiring file in the control room.
The 12V power supply on 1Y1 is for the CCD cameras. So we still want to keep the 12V 0.8A power and the side connections for these. It is not necessary to be Sorensen. Can we replace it with an AC-DC adapter with +12V/1A for example? BTW, the video matrix and quads are AC-powered.

The mysterious thick cables and cross-connects (green wires) on the side panel (labeled AP1/AP2/SP/IMCREFL) are for "EO shutters". It was meant for the protection of the PDs from bright beams.
I don't think they have been used. And we don't need them.

  16452   Fri Nov 5 20:35:10 2021 KojiUpdateBHDFeedthru / Optical Mounts

- New feedthrus [4xDB25 Qty 4 / 8xDB25 Qty 1] are placed on the wire shelf at the entrance -> Jordan, please clean them.

- There are plenty of 2" DLC mounts. There are also many 1.5" mounts but they are less useful.
  We need at least 3 1" moounts and 1 1" or 2" lens mount (and the lens). Let's purchase them on Thorlabs. I'll work on the order.

Attachment 1: P_20211105_200817.jpg
P_20211105_200817.jpg
  16454   Mon Nov 8 13:13:00 2021 KojiSummaryBHD1Y1 rack work; Sorensens removed

Updated the rack layout. Now there is an issue.
We were supposed to have 1U space at the top, but it was occupied by the 12V.
We need to either lower the c1sus2 and IO chassis 1U or move the Sorensen at the bottom.

Attachment 1: 40m_BHD.png
40m_BHD.png
  16458   Mon Nov 8 18:42:38 2021 KojiSummaryBHDRack Layout / Power Strips
Rack # of units that
requires +18V
Power Source
1X3 (new rack) 15 1X3 U1/2
1X4 13 1X3 U1/2
1X5 8 or 9 (OL AA) 1X5 U40/41
1Y0 17 1Y0 U1/2
1Y1 15 1Y0 U1/2
1Y3 12 1Y3 U39/40
1X9 9 1X9 U38/39
1Y4 9

1Y4 U39/40

Notes:

  • There are 8 racks and there is only 7x 18V power strips. 1X5 could be the one without the power strip and to parasite with 1X3/4. Otherwise we need to modify some of the 24V power strips (no plan to use) into 18V by replacing the connectors.
  • We need total ~100 18V cables / We ordered 60x 3ft / 60x 3ft / 30x 10ft. Hopefully these are enough for our depand... I haven't checked the delivered number.
  • All the acromags are supposed to be powered with one voltage. I think they are supposed to run with +18V.
  • I didn't check the distribution of Sorensens through the lab. (i.e. how many we have / how many we need / ...)
Attachment 1: rack_plan.pdf
rack_plan.pdf
  16464   Thu Nov 11 00:11:39 2021 KojiSummarySUS2" to 3" sleeve issue

Yehonathan and Tega found that the new PR3 and SR3 delivered in 2020 is in fact 3/4" in thickness (!). Digging the past email threads, it seems that the spec was 10mm but the thickness was increased for better relieving the residual stress by the coatings.

There are a few issues.

1. Simply the mirror is too thick for the ring. It sticks out from the hole. And the mirror retainers (four plastic plates) are too far from the designed surface, which will make the plates tilted.

2. The front side of the mirror assembly is too heavy and the pitch adjustment is not possible with the balance mass.

Some possible solutions:

- How about making the recess deeper?
In principle this is possible, but the machining is tricky because the recess is not a simple round hole but has "pads" where the mirror sits. And the distance of the retainer to the thread is still far.
And the lead time might become long.

- How about making new holes on the ring to shift the clamp?
Yes it is possible. This will shift the mirror assembly by a few mm. Let's consider this.

- How about modifying the wire blocks?
Yes it is equivalent to shift the holes on the ring. Let's consider this too.

1. How to hold the mirror with the retainer plates

[Attachment 1] The expected distance between the retainer plate and the threaded hole is 13.4mm. We can insert a #4-40 x L0.5" stand off (McMaster-Carr 91197A150, SUS316) there. This will make the gap down to 0.7mm. With a washer, we can handle this gap with the plate. Note that we need to use vented & silver plated #4-40 screws to hold the plates.

[Attachment 2] How does this look like when the CoM is aligned with the wire plane? Oh, no... the lower two plates will interfere with the EQ stops and the EQ stop holders. We have to remove them. [Attachment 3]
We need to check with the suspension if the EQ stop screws may hit the protruded optics and can cause chipping/cracking.

2. Modifying the wire block

[Attachment 4] The 4x thru holes of the wire block were extended to be +/-0.1" slots. The slots are too long to form ovals and produce thin areas. With the nominal position of the balance mass, the clamp coordinates are y=1.016 (vertical) and z=-2.54mm (longitudinal).
==> The CoM is 0.19mm backside (magnet side) and 0.9134 mm lower from the wire clamping points. This looks mathematically doable, but the feasibility of the manufacturing is questionable.

[Attachment 5] Because the 0.1" shift of the CoM is large, we are able to make new #2-56 thread holes right next to the original ones. The clamp coordinates are y=1.016 (vertical) and z=-2.54mm (longitudinal).
==> The CoM is 0.188mm backside (magnet side) and 0.9136 mm lower from the wire clamping points. With the given parameters, the expected pitch resonant frequency is 0.756Hz

My Recommendation

- Modify the metal ring to shift the #2-56 threads by 0.1"

- The upper two retainer plates will have #4-40 x 0.5" stand off. Use vented Ag-coated #4-40 screws.

- The lower two are to be removed.

- Take care of the EQ stops.

- Of course, the best solution is to redesign the holder for 3/4" optics. Can we ask Protolab for rapid manufacturing???


Why did we need to place the mass forward to align the 1/4" thick optic?

We were supposed to adjust the CoM not to have too much adjustment. But we had to move the balance mass way too front for the proper alignment with a 1/4" thick optic. Why...?
This is because the ring was designed for a 3/8" thick optic... It does not make sense because the depth of the thread holes for the retainer plate was designed for 1/4" optics...

When the balance mass is located at the neutral position, the CoM coordinate is

x 0.0351mm (x+: left side at the front view)
y 0.0254mm (y+: vertical up)
z 0.4493mm (z+: towards back)

So, the CoM is way too behind. When the balance mass was stacked and the moved forward (center of the axis was moved forward by 0.27"), the CoM coordinate is (Attachment 6)

x 0.0351mm
y 0.0254mm
z 0.0011mm

This makes sens why we had to move the balance mass a lot for the adjustment.

Attachment 1: Screenshot_2021-11-11_001050.png
Screenshot_2021-11-11_001050.png
Attachment 2: Screenshot_2021-11-11_010405.png
Screenshot_2021-11-11_010405.png
Attachment 3: Screenshot_2021-11-11_010453.png
Screenshot_2021-11-11_010453.png
Attachment 4: Screenshot_2021-11-11_012213.png
Screenshot_2021-11-11_012213.png
Attachment 5: Screenshot_2021-11-11_011336.png
Screenshot_2021-11-11_011336.png
Attachment 6: Screenshot_2021-11-10_235100.png
Screenshot_2021-11-10_235100.png
  16471   Tue Nov 16 18:28:53 2021 KojiUpdateBHDSOS assembly

Yehonathan told me that the wires are touching between the clamps! I went back to the CAD and confirmed it is really happening. Sad.

The distance of the wires at the upper clamp is 17.018mm.
The distance of the lower clamps is 74.168mm
The vertical drop of the wire is 251mm
--> The wire angle from the vertical line is 0.114 rad

The lower wire block has a step of 1.016mm with the vertical extension of the piece by 11.684mm
--> The angle clearance of the lower clamp is 0.087 rad

So the clearance was not enough.

If we cut the top center of the wire block more than 2.77mm, we can make the wires free.
For safety, we can cut 0.25" = 6.35mm. This will give 0.4mm clearance between the block and the wire at the closest point.

I did this modification on the 3D model and modified the 2D drawing too, so that we can find the machine shop to do it quickly.

Attachment 1: D2100546_Wire_Block.pdf
D2100546_Wire_Block.pdf
Attachment 2: D2100546_Wire_Block.png
D2100546_Wire_Block.png
ELOG V3.1.3-