40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 61 of 341  Not logged in ELOG logo
ID Date Author Type Categoryup Subject
  16496   Thu Dec 9 18:22:36 2021 TegaUpdateCDSNew SUS medm screen update

Work on the medm screen for SUS RMS monitor is ongoing. The next step would be to incorporate this into the SUS medm screen, add the BLRMS model to the SUS controller model, recompile, check that the channels are being correctly addressed, then load the appropriate bandpass and lowpass filters.  

Attachment 1: Screen_Shot_2021-12-09_at_6.21.09_PM.png
Screen_Shot_2021-12-09_at_6.21.09_PM.png
  16500   Fri Dec 10 18:55:58 2021 TegaUpdateCDSNew SUS medm screen update

Turns out the BLRMS monitoring channels for MC1, MC2, MC3, ITMY and SRM already exist in c1pem. So I modified the new SUS screen to display the BLRMS info for the aforementioned optics. Next step is to add the BLRMS monitor for PRM, ITMX, ETMX and ETMY. This would require extending the number of inputs for the "SUS" block in c1pem to accomodate the additional inputs from the remaining optics.

Attachment 1: BLRMS_ITMY_screenshot.png
BLRMS_ITMY_screenshot.png
  16533   Wed Dec 22 17:40:22 2021 AnchalSummaryCDSc1su2 model updated with SUS damping blocks for 7 SOSs

[Anchal, Koji]

I've updated the c1su2 model today with model suspension blocks for the 7 new SOSs (LO1, LO2, AS1, AS4, SR2, PR2 and PR3). The model is running properly now but we had some difficulty in getting it to run.

Initially, we were getting 0x2000 error on the c1su2 model CDS screen. The issue probably was high data transmission required for all the 7 SOSs in this model. Koji dug up a script /opt/rtcds/caltech/c1/userapps/trunk/cds/c1/scripts/activateDQ.py that has been used historically for updating the data rate on some of theDQ channels in the suspension block. However, this script was not working properly for Koji, so he create a new script at /opt/rtcds/caltech/c1/chans/daq/activateSUS2DQ.py.

[Ed by KA: I could not make this modified script run so that I replaces the input file (i.e. C1SU2.ini). So the output file is named C1SU2.ini.NEW and need to manually replace the original file.]

With this, Koji was able to reduce acquisition rate of SUSPOS_IN1_DQ, SUSPIT_IN1_DQ, SUSYAW_IN1_DQ, SUSSIDE_IN1_DQ, SENSOR_UL, SENSOR_UR, SENSOR_LL,SENSOR_LR, SENSOR_SIDE, OPLEV_PERROR, OPLEV_YERROR, and OPLEV_SUM to 2048 Sa/s. The script modifies the /opt/rtcds/caltech/c1/chans/daq/C1SU2.ini file which would get re-written if c1su2 model is remade and reinstalled. After this modification, the 0x2000 error stopped appearing and the model is running fine.


Should we change the library model part for sus_single_control.mdl

We notice that all our suspension models need to go through this weird python script modifying auto-generated .ini files to reduce the data rate. Ideally, there is a simpler solution to this by simply adding the datarate 2048 in the '#DAQ Channels' block in the model library part /cvs/cds/rtcds/userapps/trunk/sus/c1/models/lib/sus_single_control.mdl which is the root model in all the suspensions. With this change, the .ini files will automatically be written with correct datarate and there will be no need for using the activateDQ script. But we couldn't find why this simple solution was not implemented in the past, so we want to know if there is more stuff going on here then we know. Changing the library model would obviously change every suspension model and we don't want a broken CDS system on our head at the begining of holidays, so we'll leave this delicate task for the near future.

  16537   Wed Dec 29 20:09:40 2021 ranaSummaryCDSc1su2 model updated with SUS damping blocks for 7 SOSs

We want to maintain the 16 kHz sample rate for the COIL DAQ channels, but nothing wrong with reducing the others.

I would suggest setting the DQ sample rates to 256 Hz for the SUS DAMP channels and 1024 Hz for the OPLEV channels (for noise diagnostics).

Maybe you can put these numbers into a new library part and we can have the best of all worlds?

Quote:
 

Should we change the library model part for sus_single_control.mdl

We notice that all our suspension models need to go through this weird python script modifying auto-generated .ini files to reduce the data rate. Ideally, there is a simpler solution to this by simply adding the datarate 2048 in the '#DAQ Channels' block in the model library part /cvs/cds/rtcds/userapps/trunk/sus/c1/models/lib/sus_single_control.mdl which is the root model in all the suspensions. With this change, the .ini files will automatically be written with correct datarate and there will be no need for using the activateDQ script. But we couldn't find why this simple solution was not implemented in the past, so we want to know if there is more stuff going on here then we know. Changing the library model would obviously change every suspension model and we don't want a broken CDS system on our head at the begining of holidays, so we'll leave this delicate task for the near future.

 

  16546   Thu Jan 6 12:52:49 2022 AnchalUpdateCDSYearly DAQD fix 2022!

Just as predicted, all realtime models reported "0x4000" error. Read the parent post for more details. I fixed this by following the instructions. I add folowing lines to the file /opt/rtcds/rtscore/release/src/include/drv/spectracomGPS.c in fb1:

/* 2020 had 366 days and no leap second */
       pHardware->gpsOffset += 31622400;
/* 2021 had no leap seconds or leap days, so adjust for that */
       pHardware->gpsOffset += 31536000;

Then is made the package and reloaded it after stoping the daqd services. This brought back all the fast models except C1SUS2 models which are in red due to some other reason that I'll investigate further.

 

  16547   Thu Jan 6 13:54:28 2022 KojiUpdateCDSYearly DAQD fix 2022!

Just restarting all the c1sus2 models fixed the issue. (Attachment 1)

SUS2 ADC1 CH21 is saturated. I'm not yet sure if this is the electronics issue or the ADC issue.
SUS2 ADC1 CH10 also has large offset. This should also be investiagted.

Attachment 1: Screenshot_2022-01-06_13-57-40.png
Screenshot_2022-01-06_13-57-40.png
  16548   Thu Jan 6 14:08:14 2022 KojiUpdateCDSMore BHD SUS screens added to sitemap

More BHD SUS screens added to sitemap (Attachment 1)

Attachment 1: Screenshot_2022-01-06_14-06-15.png
Screenshot_2022-01-06_14-06-15.png
  16553   Thu Jan 6 22:18:47 2022 KojiUpdateCDSSUS screen debugging

Indicated by the red arrow:
Even when the side damping servo is off, the number appears at the input of the output matrix

Indicated by the green arrows:
The face magnets and the side magnets use different ADCs. How about opening a custom ADC panel that accommodates all ADCs at once? Same for the DAC.

Indicated by the blue arrows:
This button opens a custom FM window. When the pitch gain was modified with a ramping time, the pitch and yaw gain grows at the same time even though only the pitch gain was modified.

Indicated by the orange circle:
The numbers are not indicated here, but they are input-related numbers (for watchdogging) rather than output-related numbers. It is confusing to place them here.

Attachment 1: Screen_Shot_2022-01-06_at_18.03.24.png
Screen_Shot_2022-01-06_at_18.03.24.png
  16570   Tue Jan 11 10:46:07 2022 TegaUpdateCDSSUS screen debugging

Seen. Thanks.

Red Arrow: The channel was labeled incorrectly as INMON instead of OUTPUT

Green Arrow: OK, I will create a custom medm screen for this.

Blue arrow: Hmm, OK I will look into this. Doing this work remotely is a pain as the medm response is quite slow for poking around.

Orange circle: OK, I'll move this to the left side of the line.

Note to self: I also noticed another error on the side (LPYS blue box just b4 the sum). The channel is pointing to YAW instead of the side, so needs to be fixed as well.

Quote:

Indicated by the red arrow:
Even when the side damping servo is off, the number appears at the input of the output matrix

Indicated by the green arrows:
The face magnets and the side magnets use different ADCs. How about opening a custom ADC panel that accommodates all ADCs at once? Same for the DAC.

Indicated by the blue arrows:
This button opens a custom FM window. When the pitch gain was modified with a ramping time, the pitch and yaw gain grows at the same time even though only the pitch gain was modified.

Indicated by the orange circle:
The numbers are not indicated here, but they are input-related numbers (for watchdogging) rather than output-related numbers. It is confusing to place them here.

 

  16611   Fri Jan 21 12:46:31 2022 TegaUpdateCDSSUS screen debugging

All done (almost)! I still have not sorted the issue of pitch and yaw gains growing together when modified using ramping time. Image of custom ADC and DAC panel is attached.

 

Quote:

Seen. Thanks.

 
Quote:

Indicated by the red arrow:
Even when the side damping servo is off, the number appears at the input of the output matrix

Indicated by the green arrows:
The face magnets and the side magnets use different ADCs. How about opening a custom ADC panel that accommodates all ADCs at once? Same for the DAC.

Indicated by the blue arrows:
This button opens a custom FM window. When the pitch gain was modified with a ramping time, the pitch and yaw gain grows at the same time even though only the pitch gain was modified.

Indicated by the orange circle:
The numbers are not indicated here, but they are input-related numbers (for watchdogging) rather than output-related numbers. It is confusing to place them here.

 

 

Attachment 1: Custom_ADC_DAC_monitors.png
Custom_ADC_DAC_monitors.png
  16662   Thu Feb 10 21:16:27 2022 KojiSummaryCDSchiara resolv.conf wierdo

During the videomux debug, I noticed that the host name resolving on chiara didn't behave well. Basically I could not login to anything from chiara using host names.

I found that there was no /etc/resolv.conf. Instead, there is /etc/resolvconf directory.

According to my research, live resolv.conf is placed in /run/resolveconf/resolv.conf .

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 192.168.113.20
nameserver 131.215.125.1
nameserver 8.8.8.8

This 113.20 is directing an old "linux1" machine. Too much obsolete. If I modify this file as

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 192.168.113.104
nameserver 131.215.125.1
nameserver 8.8.8.8
search martian

Then the name resolving became reasonable. However, during rebooting / service resetting / etc, resolvconf -u command is executed and /run/resolveconf/resolv.conf is overridden, as indicated in the file.

I have modified /etc/resolvconf/resolv.conf.d/base to include 192.168.113.104 and search martian . The latter was included but the former did not show up.

FInally I figured out that, after the resolv.conf is constructed from base and head files in /etc/resolvconf/resolv.conf.d/ , NetworkManager overrides the nameserver addresses.
The configuration was found in /etc/NetworkManager/system-connections/Wired\ connection\ 1 .

Here is the modified setting (dns entry was modified)

>sudo cat /etc/NetworkManager/system-connections/Wired\ connection\ 1
[sudo] password for controls:
[802-3-ethernet]
duplex=full
mac-address=68:05:CA:36:4E:B4

[connection]
id=Wired connection 1
uuid=ed177e70-d10e-42be-8165-3bf59f8f199d
type=802-3-ethernet
timestamp=1438810765

[ipv6]
method=auto

[ipv4]
method=manual
dns=192.168.113.104;131.215.125.1;8.8.8.8;
addresses1=192.168.113.104;24;192.168.113.2;

And

>cat /etc/resolvconf/resolv.conf.d/base
search martian
# See Also /etc/NetworkManager/system-connections/Wired\ connection\ 1

So complicated...

  16663   Thu Feb 10 21:51:02 2022 KojiUpdateCDS[Solved] Huge random numbers flowing into ETMX/ETMY ASC PIT/YAW

Huge random numbers are flowing into ETMX/ETMY ASC PIT/YAW. Because of this, I could not damp the ETMX/ETMY suspension at the beginning during the recovery from rebooting. (Attachment 1)
By turning off the output of the ASC filters, the mirrors were successfully damped.

Looking at the FE model view of the end RTSs, there were two possibilities: (Attachment 2)

- They are coming from RFM connection
- They are coming from ASXASY

ASX/ASY are not active and I could not see anything producing these numbers. Burtrestore didn't help.

The possibility was something at the other side of the RFM, or corruption of the RFM signal.

- Looking at the RFM model (Attachment 3), the ASC signals are coming from ASS and IOO. The ASS path has the filter module (C1:RFM-ETMX_PIT and etc). This FM is quiet and not guilty.

- Why do we have the RFM from IOO? I went to IOO and found the new ASC (WFS) model is there. I didn't realize the presence of this model. In fact ASC screen showed that these random numbers are flowing into the end SUSs.
So I did burtrestore of c1iooepics. Alas! they are gone.

Now I can go home.

Attachment 1: Screenshot_2022-02-10_21-46-02.png
Screenshot_2022-02-10_21-46-02.png
Attachment 2: Screen_Shot_2022-02-10_at_21.54.21.png
Screen_Shot_2022-02-10_at_21.54.21.png
Attachment 3: Screen_Shot_2022-02-10_at_22.14.23.png
Screen_Shot_2022-02-10_at_22.14.23.png
  16664   Fri Feb 11 10:56:38 2022 AnchalUpdateCDS[Solved] Huge random numbers flowing into ETMX/ETMY ASC PIT/YAW

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

 

  16666   Fri Feb 11 12:22:19 2022 ranaUpdateCDS[Solved] Huge random numbers flowing into ETMX/ETMY ASC PIT/YAW

you can hand edit the autoBurt file which the FE uses to set the values after boot up. Just make a python script that amends all of the OFF or ZERO that are needed to make things safe. This would be the autoBurt snap used on boot up only, and not the hourly snaps.

 

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

 

  16668   Fri Feb 11 17:07:19 2022 AnchalUpdateCDS[Solved] Huge random numbers flowing into ETMX/ETMY ASC PIT/YAW

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

Quote:

you can hand edit the autoBurt file which the FE uses to set the values after boot up. Just make a python script that amends all of the OFF or ZERO that are needed to make things safe. This would be the autoBurt snap used on boot up only, and not the hourly snaps.

 

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

 

 

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

  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
40mBHD_C1SUSAUX2_Acromag_Chassis.pdf
  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
PXL_20220305_035255834.jpg
Attachment 2: PXL_20220305_034649120.MP.jpg
PXL_20220305_034649120.MP.jpg
  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.

  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
BHD_WatchDogs.png
Attachment 2: 40mBHD_C1SUSAUX2_Acromag_Chassis.pdf
40mBHD_C1SUSAUX2_Acromag_Chassis.pdf
  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
c1su2.pdf
  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...
Done
Parsing the model c1su2...
Done
Building EPICS sequencers...
Done
Building front-end Linux kernel module c1su2...
Done
RCG source code directory:
/opt/rtcds/rtscore/branches/branch-3.4
The following files were used for this build:
/opt/rtcds/userapps/release/cds/common/models/lockin.mdl
/opt/rtcds/userapps/release/cds/common/models/rtbitget.mdl
/opt/rtcds/userapps/release/cds/common/models/rtdemod.mdl
/opt/rtcds/userapps/release/isc/common/models/QPD.mdl
/opt/rtcds/userapps/release/sus/c1/models/c1su2.mdl
/opt/rtcds/userapps/release/sus/c1/models/lib/sus_single_control.mdl

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
/opt/rtcds/caltech/c1/scripts/killc1su2
/opt/rtcds/caltech/c1/scripts/startc1su2
Performing install-daq
Updating testpoint.par config file
/opt/rtcds/caltech/c1/target/gds/param/testpoint.par
/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
/opt/rtcds/caltech/c1/target/gds/param/tpchn_c1su2.par
Installing auto-generated DAQ configuration file
/opt/rtcds/caltech/c1/chans/daq/C1SU2.ini
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 
/opt/rtcds/caltech/c1/chans/daq/C1SU2.ini
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
Trying 192.168.113.201...
Connected to fb.martian.
Escape character is '^]'.
daqd> shutdown
OK
Connection closed by foreign host.
daq>burtgooey
>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 <
daq>

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

  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.

  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.

  16737   Fri Mar 18 19:10:51 2022 AnchalSummaryCDSc1auxey1 slow controls issues

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

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

 

  16741   Mon Mar 21 18:42:06 2022 AnchalSummaryCDSc1auxey1 slow controls issues

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

  16756   Mon Apr 4 17:03:47 2022 AnchalSummaryCDSc1susaux2 slow controls acromag chassis fixed and installed

[Anchal, JC, Ian, Paco]

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

Attachment 1: Screenshot_2022-04-04_17-03-26.png
Screenshot_2022-04-04_17-03-26.png
  16793   Thu Apr 21 10:35:23 2022 KojiUpdateCDSDAQ seemed down

Yesterday, when I worked on the damping servo, I found that any of the daqvtools (ndscope, dtt, dataviewer,...) is not available.  We may need to restart the fb and rt machines.

  16811   Mon Apr 25 17:24:06 2022 AnchalUpdateCDSDAQ still down

I investigated this issue today. At first, it seemed that only new suspension testpoints are inaccessible. I was able to use diaggui for a measurement on MC2. The DAQ network cable between 1X4 and 1Y1 was tied and is very taught now (we should relieve this as soon as possible, best solution is to lay down a longer cable over the bridge). My hypothesis is that the DAQ network might have broken while tying this cable and it probably did not come back since then.

The simplest solution would have been to restart c1su2 models. As I restarted those models though, I found that c1lsc and c1sus models failed. This is very unusual as c1su2 models are independent and share nothing with the other vertex models. So I had to restart all the FE computers eventually. But this did not solve the issue. Worse, now the DAQ isn't working for the vertex machiens as well.

Next step was to try restarting fb1 itself. We switched off all the FE computers, restarted fb1, stopped daqd_* processes, reloaded gpstime module, restarted open-mx, mx, nds and daqd_* process. But the mx.service failed to load with following error message:

● mx.service - LSB: starts MX driver for Myrinet card
   Loaded: loaded (/etc/init.d/mx)
   Active: failed (Result: exit-code) since Mon 2022-04-25 17:18:02 PDT; 1s ago
  Process: 4261 ExecStart=/etc/init.d/mx start (code=exited, status=1/FAILURE)

Apr 25 17:18:02 fb1 mx[4261]: Loading mx driver
Apr 25 17:18:02 fb1 mx[4261]: insmod: ERROR: could not insert module /opt/mx/sbin/mx_mcp.ko: File exists
Apr 25 17:18:02 fb1 mx[4261]: insmod: ERROR: could not insert module /opt/mx/sbin/mx_driver.ko: File exists
Apr 25 17:18:02 fb1 systemd[1]: mx.service: control process exited, code=exited status=1
Apr 25 17:18:02 fb1 systemd[1]: Failed to start LSB: starts MX driver for Myrinet card.
Apr 25 17:18:02 fb1 systemd[1]: Unit mx.service entered failed state.

(Ignore the timestamp above, I ran the command again to capture the error message.)

However, I was able to start all the FE models without any errors and daqd processes are also all running without showing any errors. Everything is green in CDS screen with no error messages. But the only thing still wrong is mx.service which is not running.

From my limited knowledge and experience, mx.service is a one-time script that mounts mx devices in /dev and loads the mx driver. I tried running the script /opt/mx/sbin/mx_start_stop :

controls@fb1:/opt/mx/sbin 1$ sudo ./mx_start_stop start
Loading mx driver
insmod: ERROR: could not insert module /opt/mx/sbin/mx_mcp.ko: File exists
insmod: ERROR: could not insert module /opt/mx/sbin/mx_driver.ko: File exists

This gave the same error. On searching little bit online, "insmod: ERROR; cound not insert module" error comes up when the kernel version of the driver doesnot match the Linux kernel (whatever that means!). Such deep issues should not appear out of nowhere in a previosuly perfectly runnig system. I'll check around more what changed in fb1, network cables etc.

  16887   Fri Jun 3 12:13:58 2022 PacoConfigurationCDSFix RFM channels

[Paco, Yuta]

We tried fixing the issue of LSC_TRY and LSC_TRX channels not working. We first did some investigation, and just like previously reported by Chris, narrowed down the issue to the RFM channels coming from c1iscex/c1iscey.

First attempt : FAIL

In our first attempt, we

  1. Tripped ETMX/ETMY watchdogs, ssh to c1iscex/c1iscey and restart the rtcds models.
  2. Since the last step didn't fix things, we decided to do the same thing on c1lsc, c1sus, c1ioo.
  3. After hard rebooting c1ioo and c1lsc (because they died during the stopping of rtcds models), and not experiencing any timing issues (nice), we still don't fix the issue.

Second attempt: Success

A second attempt just followed Koji's previous fix explained here. Basic difference with our first attempt was a hard reboot of c1iscex/c1iscey in addition to the rtcds model restarting. RFM channels were then clear of errors and we recovered our IR transmission channels in the LSC model.

Attachment 1: SoGreen.png
SoGreen.png
  16976   Wed Jul 6 22:40:03 2022 TegaSummaryCDSUse osem variance to turn off SUS damping instead of coil outputs

I updated the database files for the 7 BHD optics to separate the OSEM variance trigger and the LATCH_OFF trigger operations so that an OSEM variance value exceeding the max of say 200 cnts turns off the damping loop whereas pressing the LATCH_OFF button cuts power to the coil. I restarted the modbusIOC service on c1susaux2 and checked that the new functionality is behaving as expected. So far so good.

 

TODO

Figure out the next layer of watchdogging needed for the BHD optics.  

 

Quote:

[Anchal, JC, Ian, Paco]

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

 

  16979   Thu Jul 7 21:25:48 2022 TegaSummaryCDSUse osem variance to turn off SUS damping instead of coil outputs

[Anchal, Tega]

Implemented ramp down of coil bias voltage when the BHD optics watchdog is tripped. Also added a watchdog reset button to the SUS medm screen that turns on damping and ramps up the coil PIT/YAW bias voltages to their nominal values. I believe this concludes the watchdog work.

Quote:

TODO

Figure out the next layer of watchdogging needed for the BHD optics.  

 

  17000   Wed Jul 13 17:30:19 2022 KojiUpdateCDSToo huge script_archive

I wanted to check the script archive to see some old settings. I found that the script archive inflated to huge volume (~1TB).
The size of the common NFS volume (/cvs/cds) is 3TB. So it is really significant.

- The scripts living in /opt/rtcds/caltech/c1/scripts are archived daily in /cvs/cds/caltech/scripts_archive as bz2 files. This is done by crontab of megatron (see https://wiki-40m.ligo.caltech.edu/Computers_and_Scripts/CRON)

- In fact, the script folder (say old script folder) /opt/rtcds/caltech/c1/scripts has the size of 10GB. And we have the compressed copy of thi s everyday.

- This large script folder is due to a couple of huge files/folders listed below

  • (scripts)/MEDMtab is 5.3GB / This is probably related to the web MEDM view (on nodus) but I don't think the web page is not updated. (i.e. the images are unused)
  • (scripts)/MC/logs/AutoLocker.log 2.9GB / This is just the accumulated MC autolocker log.
  • (scripts)/GigE 780M / This does not look like scripts but source and object files
  • (scripts)/Admin/n2Check.log 224M / This is important but increases every minute.
  • (scripts)/ZI 316MB / Zurich Instrument installation. This should not be here.

Here I propose some changes.
For the script archive

  • We can remove most of the scripts for the past (say ~2019). We leave an archive file per month.
  • For the scripts in 2020, we leave a weekly archive.
  • For 2021 and 2022, we leave all the archive files.

For the existing large files/folders

  • MEDMtab: the stored files are redundant with the burt snapshots. Remove the image files. Also, we want to move the image-saving location.
  • Autolocker.log: simply zap it
  • n2Check.log: we should move the saving location
  • GigE /ZI: they need a new home where the daily copy is not taken.
  17043   Thu Jul 28 15:11:59 2022 KojiUpdateCDSToo huge script_archive

As a result of the following work, the file volume of /cvs/cds was reduced from 3.2TB to 2.2TB, and /opt/rtcds/caltech/c1/scripts was reduced from 10GB to 1.5GB


/cvs/cds/caltech/scripts_archive was cleaned up. Now the archive files are reduced to have:

  • every month 1st day from 2005 to 2018/12
  • every ten days (1, 11, 21) for 2019 and 2020
  • everyday for 2021 and 2022

(scripts)/MEDMtab/image was deleted. I can be restore back from one of the script_archive files.

(scripts)/MC/logs/AutoLocker.log was just deleted and refreshed. For the past settings, we can refer autoburt snapshots or script_archive files.

(scripts)/Admin/n2Check.log

  • It turned out that the frequency of the check was reduced to once per 10min on Sep 9th, 2021 (unelogged activity).
  • The volume of the text since then was not much volume. So I deleted the lines before this date. And the file size is <7MB now.

(scripts)/ZI was moved to /cvs/cds/apps

/opt/rtcds/caltech/c1/burt/autoburt/snapshots

  • 2018, 2019, 2020 snapshots were archived in tar.gz.
  • These snapshots were then deleted

 

  17149   Wed Sep 21 10:10:22 2022 YehonathanUpdateCDSC1SU2 crashed

{Yehonathan, Anchal}

Came this morning to find that all the BHD optics watchdogs tripped. Watchdogs were restored but the all ADCs were stuck.

We realized that the C1SU2 model crashed.

We run /scripts/cds/restartAllModels.sh to reboot all machines. All the machines rebooted and burt restored to yesterday around 5 PM.

The optics seem to have returned to good alignment and are damped.

  470   Thu May 8 02:06:13 2008 ranaSummaryCOCThermal Lensing in the ITMs and BS may be a problem
The iLIGO interferometers start to see thermal lensing effects with ~2W into the MC, a recycling
gain of ~50, and a beam waist on the ITMs of ~3.5 cm.

At the 40m, the laser power into the MC is 1/2 as much, the recycling gain is 4-5x less, but the
beam on the ITM has a 3 mm waist. So the power in the ITM bulk is 10x less but the power density
is 100x more
. Seems like the induced lens in the ITM bulk might be larger and that if there's
significant absorption on the ITM face (remember our Finesse is 4-5x higher) the beam size in the
arm cavity may also change enough to measure.

Someone (like Andrey) should calculate how much the beam sizes change with absorbed power.
  885   Tue Aug 26 09:58:59 2008 steveOmnistructureCOCETMX is #03
This is the picture of ETMX from the upper south west viewport
Attachment 1: etmx-d40posg_012.jpg
etmx-d40posg_012.jpg
Attachment 2: etmx03.jpg
etmx03.jpg
  1649   Wed Jun 3 18:55:27 2009 ranaUpdateCOCsnapshot of upgrade layout
Attachment 1: layout.png
layout.png
  2094   Thu Oct 15 01:21:31 2009 ranaSummaryCOCThermal Lensing in the ITM

Thermal lensing formula:

Untitled.png

from (T090018 by A. Abramovici (which references another doc).

In the above equation:

w        1/e^2 beam radius

k        thermal conductivity (not the wave vector) = 1.3 W / m/ K

alpha    absorption coefficient (~10 ppm/cm for our glass)

NP       power in the glass (alpha*NP = absorbed power)

dn/dT    index of refraction change per deg  (12 ppm/K)

d        mirror thickness (25 mm for all of our SOS)

I'm attaching a plot showing the focal length as a function of recycling cavity power for both our current MOS and future SOS designs.

I've assumed a 10 ppm/cm absorption here. It may actually be less for our current ITMs which are made of Heraeus low absorption glass - our new ITMs are Corning 7980-A (measured to have an absorption of 13 ppm/cm ala the iLIGO COC FDD). I expect that our thermal lens focal length will always be longer than 1 km and so I guess this isn't an issue.

Attachment 2: aa.png
aa.png
  2096   Thu Oct 15 02:41:04 2009 ranaUpdateCOCChoice of folding mirrors in the RC cavities

In addition to the main mirrors (PRM, SRM) we will also have fold mirrors (called PR1, PR2, SR1, SR2). I am curious to see if we can get away with just using commercial optics; I think that the CVI Y1S coatings may do the trick.

Picture_9.png

The above plots show the reflectivities v. wavelength. I've asked the sales rep to give us specs on the reflectivity v. angle. I bet that we can guess what the answer will be from these plots.

  2157   Wed Oct 28 17:20:21 2009 ranaSummaryCOCETM HR reflectivity plot

This is a plot of the R and T of the existing ETM's HR coating. I have only used 1/4 wave layers (in addition to the standard 1/2 wave SiO2 cap on the top) to get the required T.

The spec is a T = 15 ppm +/- 5 ppm. The calculation gives 8 ppm which is close enough. The calculated reflectivity for 532 nm is 3%. If the ITM reflectivity is similar, the signal for the 532 nm locking of the arm would look like a Michelson using the existing optics.

etm_40_1998.png

  2361   Mon Dec 7 18:18:55 2009 JenneUpdateCOCETMX drag wiped

[Koji, Jenne, Alberto, Steve, Bob]

ETMX has been drag wiped. 

Around 2:45pm, after the main IFO volume had come up to atmospheric pressure, we removed both doors to the ETMX chamber.  Regular procedures (wiping of O-rings with a dry, lint-free cloth, covering them with the light O-ring covers, etc.) were followed.  Koji took several photos of the optic, and the rest of the ETMX chamber before anything was touched. These will be posted to the 40m Picasa page.  Steve and Koji then deionized the optic.

Koji removed the bottom front earthquake stop, and clamped the optic with the remaining earthquake stops.

The clean syringes were prepared: These are all glass and metal (nothing else) medical syringes.  The size used was 100microliters.  Earlier today, we had prepared our solvents in small little beakers which had been baked over the weekend.  Brand new glass bottles of Acetone and Isopropyl Alcohol were opened, and poured into the small beakers.  To make sure we have enough, we have 3 ~10ml beakers of each Acetone and Isopropyl.

We started with Acetone.  The syringe was filled completely with acetone, then squirted onto a kimwipe.  This was repeated ~twice, to ensure the syringe was well rinsed.  Then the syringe was filled a little past the 100 microliter mark.  Koji held a piece of lens cleaning paper to ETMX and used an allen wrench underneath the optic to help guide the paper, and keep it near the optic (of course, the only thing in actual contact with the optic was the lens paper).  In one smooth shot, the plunger of the syringe was pressed all the way down.   (This is a bit tricky, especially when the syringe is totally full.  You have to squeeze it so the plunger moves fairly quickly down the barrel of the syringe to get a good arc of liquid.  The goal is to shoot all of the solvent to the same place on the lens paper, so that it makes a little circle of wetness on the paper which covers the coated part of the optic.  The amount of solvent used should be balanced between having too little, so that the paper is dry by the time it has been wiped all the way down, and too much such that there is still a residue of liquid on the optic after the paper has been removed.)  The target was to hit the optic just above the center mark (the oplev was on, so I went for just above the red oplev dot).  Immediately after applying the liquid onto the paper, Koji slowly and smoothly pulled down on the lens paper until it came off of the bottom of the optic.  The acetone was repeated, for a total of 2 acetone wipes.  Because acetone evaporates very quickly, more acetone is used than isopropyl.  The optimal amount turned out to be ~115 microliters of acetone.  It is hard to say exactly how much I had on the second wipe, because the syringe is not marked past 100 microliters.  On the first wipe, with about 105 microliters, the lens paper was too dry at the bottom of the optic.

We then switched to Isopropyl.  A new syringe was used, and again we rinsed it by filling it completely with isopropyl, and emptying it onto a kimwipe.  This was repeated at least twice.  We followed the same procedure for applying liquid to the optic and wiping the optic with the lens paper.  On the first try with isopropyl, we used 100 microliters, since that was the preferred amount for acetone.  Since isopropyl evaporates much slower than acetone, this was determined to be too much liquid.  On the second isopropyl wipe, I filled the syringe to 50 microliters, which was just about perfect.  The isopropyl wiping was done a total of 2 times.

After wiping, we replaced the front bottom earthquake stop, and released the optic from the other earthquake stops' clamping.  The OSEM values were checked against the values from the screenshots taken yesterday afternoon, and were found to be consistent.  Koji took more photos, all of which will be placed on the 40m Picasa page.

We visually inspected the optic, and we couldn't see anything on the optical surface of the mirror.  Koji said that he saw a few particulates on some horizontal surfaces in the chamber.  Since the optic seemed (at least to the level of human vision without a strong, focused light) to be free of particulates on the optical surface to start with, the suspense will have to remain until we button down, pump down, and try to lock the IFO to determine our new finesse, to see if the wiping helped any substantial amount. 

We replaced the regular, heavy door on the inner side of the ETMX chamber (the side closer to the CES building), and put only a light door on the outer side of the chamber (the side closer to the regular walkway down the arm).  We will look at the spectra of the OSEMS tomorrow, to confirm that none of the magnets are stuck.

We commence at ~9am tomorrow with ETMY.

LESSONS LEARNED:

The LED lights are awesome.  It's easy to use several lights to get lots of brightness (more than we've had in the past), and the chamber doesn't get hot.

We should get larger syringes for the acetone for the large optics.  It's challenging to smoothly operate the plunger of the syringe while it's so far out.  We should get 200 microliter syringes, so that for the acetone we only fill them about half way.  It was noticeably easier to apply the isopropyl when the syringe only had 50 microliters.

* It may be helpful to have a strong, focused optical light to inspect the surface of the mirror.  Rana says that Garilynn might have such an optical fiber light that we could borrow.

  2366   Tue Dec 8 13:03:26 2009 KojiUpdateCOCETMY drag wiped

Jenne, Kiwamu, Alberto, Steve, Bob, Koji

We wiped ETMY after recovery of the computer system. We take the lunch and resume at 14:00 for ITMX.
Detailed reports will follow.

  2367   Tue Dec 8 16:27:13 2009 JenneUpdateCOCITMX wiped

Jenne, Kiwamu, Koji, Alberto, Steve, Bob

ITMX was wiped without having to move it. 
After 'practice' this morning on ETMY, Kiwamu and I successfully wiped ITMX by leaning into the chamber to get at the front face. 

Most notable (other than the not moving it) was that inspection with the fiber light before touching showed many very small particles on the coated part of the optic (this is versus ETMY, where we saw very few, but larger particles).  The after-wiping fiber light inspection showed many, many fewer particles on the optical surface.  I have high hopes for lower optical loss here!

  2373   Wed Dec 9 18:01:06 2009 KojiUpdateCOCWiping finished

[Kiwamu, Jenne, Alberto, Steve, Bob, Koji]

We finished wiping of four test masses without any trouble. ITMY looked little bit dusty, but not as much as ITMX did.
We confirmed the surface of the ITMX again as we worked at vertex a lot today. It still looked clean.

We closed the light doors. The suspensions are left free tonight in order to check their behavior.
Tomorrow morning from 9AM, we will replace the door to the heavy ones.

  2424   Wed Dec 16 20:29:08 2009 ranaUpdateCOCETM Coating study

This plot shows the Transmission for 532 and 1064 nm as a function of the thickness of the SiO2 layer.

i.e. the thickness is constrained so that the optical thickness of the SiO2 and Ta2O5 pair is always 1/2 of a wavelength.

The top layer of the mirror is also fixed in this plot to be 1/2 wave.

This plot shows the result for 17 pairs. For 16 pairs, we are unable to get as low as 15 ppm for the 1064 nm transmission.

Attachment 1: layerfrac.png
layerfrac.png
  2588   Wed Feb 10 23:44:56 2010 KojiSummaryCOCPhase Map Analysis

In the middle of the last month, Kiwamu and I went to Garilynn's lab to measure the phase maps of the new ITMs and SRMs.

Analysis of the phase map data were posted on the svn directory:
https://nodus.ligo.caltech.edu:30889/svn/trunk/docs/upgrade08/cocdocs/PhaseMaps/

The screen shots and the plots were summarized in a PDF file. You can find it here:
http://lhocds.ligo-wa.caltech.edu:8000/40m/Upgrade_09/Main_Optics_Phase_Maps

The RoCs for all of the PRMs are turned out to be ~155m. This is out of the spec (142m+/-5m) although the actual effect is not understand well yet..

These RoCs are almost independent from the radus of the assumed gaussian beam.
In deed, I have checked the dependence of the RoC on the beam spot position, and it turned out that the RoCs vary only little.
(In the SRMU01 case, for example, it varies from 153.5m to 154.9m.)
The beam radius of 3mm was assumed. The RoCs were calculated 20x20mm region around the center of the mirror with a 2mm mesh.
 

Attachment 1: SRM01_HR_RoC_rad_15mm.png
SRM01_HR_RoC_rad_15mm.png
Attachment 2: SRM01_HR_RoC_scan.png
SRM01_HR_RoC_scan.png
  2611   Wed Feb 17 19:36:05 2010 KojiUpdateCOCArm visibility

I have measured the arm visibilities.
I did not see any change since the last wiping. Our vacuum is not contaminating the cavity in the time scale of 2 months.

It is very good.


Arm visibility measurement ~ latest (Feb. 17, 2010)

X Arm: 0.898 +/- 0.003
Y Arm: 0.892 +/- 0.006

Arm visibility measurement after the vent (Dec. 14, 2009)

X Arm: 0.897 +/- 0.005
Y Arm: 0.893 +/- 0.004

Arm visibility measurement before the vent (Nov 10, 2009)

X Arm: 0.875 +/- 0.005
Y Arm:
0.869 +/- 0.006

  2614   Fri Feb 19 00:31:17 2010 JenneUpdateCOCNew ITMX guiderods glued

[Jenne, Kiwamu, with moral support from Koji, and loads of advice from Steve and Bob]

New upgrade ITMX (ITMU03) has it's guiderod & standoff glued on, as step 1 toward hanging the ITMs.

Procedure:

1. Make sure you have everything ready.  This is long and complicated, but not really worth detail here.  Follow instructions in E970037 (SOS Assembly Spec), and get all the stuff in there.

2. Set optic in a 'ring stand', of which Bob has many, of many different sizes. They are cleaned and baked, and in the cleanroom cupboard on the bottom just behind the door. We used the one for 3" optics.  This lets you sit the optic down, and it only rests on the bevel on the outside, so no coated surface touches anything.

3. Drag wipe the first surface of the optic, using Isopropyl Alcohol.  We used the little syringes that had been cleaned for the Drag Wipe Event which happened in December, and got fresh Iso out of the bottle which was opened in Dec, and put it into a baked glass jar.  The drag wipe procedure was the same as for the December event, except the optic was flat on the bench, in the ring holder.

4. Turn the optic over.

5. Drag wipe the other surface.

6. Align the optic in the guiderod gluing fixture (Step 3 in Section 3.2.1: Applying Guide Rod and Wire Standoff of E970037).

7. Set guiderod and standoff (1 guiderod on one side, 1 standoff on the other, per instructions) against the side of the optic.

8.a.  Use a microscope mounted on a 3-axis micrometer base to help align the guiderod and standoff to the correct places on the optic (Steps 4-5 of Section 3.2.1).  This will be much easier now that we've done it once, but it took a looooooong time. 

8.b.  We put the optic in 180deg from the way we should, based on the direction of the wedge angle in the upgrade table layout (wedge angle stuff used a "Call a Friend" lifeline.  We talked to Koji.) The instructions say to put the guiderod and standoff "above" the scribe lines in the picture on Page 5 of E970037 - the picture has the arms of the fixture crossing over the scribe lines.  However, to make the optic hang correctly, we needed to put the guiderod and standoff below the scribe lines.  This will be true as long as the arrow scribe line (which marks the skinniest part of the optic, and points to the HR side) is closest to you when the optic is in the fixture, the fixture is laying on the table (not standing up on end) with the micrometer parts to your right.  We should put the other ITM into the fixture the other way, so that the arrow is on the far side, and then we'll glue the guiderod and standoff "above" the scribe lines.  Mostly this will be helpful so that we can glue in exactly the places the instructions want us to.

8.c.  The biggest help was getting a flashlight to help illuminate the scribe lines in the optic while trying to site them in the microscope.  If you don't do this, you're pretty much destined to failure, since the lights in the cleanroom aren't all that bright. 

8.d.  The micrometer mount we were able to find for the microscope has a max travel of 0.5", but the optic is ~1" thick.  To find the center of the optic for Step 5 in the guiderod and standoff alignment we had to measure smaller steps, such as bevel-to-end-of-scribe-line, and length-of-scribe-line then end-of-scribe-line-to-other-bevel.  Thankfully once we found the total thickness and calculated the center, we were able to measure once bevel-to-center. 

9. Apply glue to the guiderod and standoff.  We made sure to put this on the "down" side, which once the optic is hung, will be the top of the little rods.  This matches the instructions as to which side of the rods to apply the glue on.  The instructions do want the glue in the center of the rod though, but since we put the optic in the fixture the wrong way, we couldn't reach the center, so we glued the ends of the rods.  We will probably apply another tiny dab of glue on the center of the rod once it's out of the fixture, perhaps while the magnet assemblies are being glued.

10.  We didn't know if the airbake oven which Bob showed us to speed up the curing of our practice epoxy last night was clean enough for the ITM (he was gone by the time we got to that part), so for safety, we're leaving the optic on the flow bench with a foil tent (the foil is secured so there's no way it can blow and touch the optic).  This means that we'll need the full curing time of the epoxy, not half the time.  Maybe tomorrow he'll let us know that the oven is in fact okay, and we can warm it up for the morning.

  2618   Fri Feb 19 15:29:14 2010 kiwamuUpdateCOCGluing dumbbells and magnets

Jenne and kiwamu

We have glued the dumbbells to the magnets that will be used for the ITMs

We made two sets of glued pair of the dumbbell and the magnet ( one set means 6 pairs of the dumbbell and the magnet. Therefore in total we got 12 pairs. )

You can see the detailed procedure we did on the LIGO document E990196.

Actually we performed one different thing from the documented procedure;

we made scratch lines on the surface of the both dumbbells and magnets by a razor blade.

According to Steve and Bod, these scratch make the strength of the glues stronger.

Now the dumbbell-magnet pairs are on the flow bench in the clean room, and supported by a fixture Betsy sent us.

 

- -  notes

On the bench the left set is composed by magnets of 244 +/- 3 Gauss and the right set is 255 +/- 3 Gauss.

 

ELOG V3.1.3-