40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 47 of 339  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  696   Fri Jul 18 17:12:35 2008 JenneUpdateIOOChecking out the MC Servo Board
[Jenne, Max]

One of the things that Rana thinks that might be causing my MC_F calibration to be off is that the MC Servo Board's filters don't match those on the schematics. Max and I pulled the MC servo board today to check resistor and capacitor values. Alberto needed the Mode Cleaner, so we put the board back before finishing checking values. We will probably pull the board again next week to finish checking the values.

I haven't checked to ensure that the MC still locks, because Yoichi is doing stuff on the PSL table, but I didn't change anything on the board, and hooked all the cables back where they were, so hopefully it's all okay.
  697   Fri Jul 18 19:15:15 2008 JenneUpdateIOOChecking out the MC Servo Board

Quote:
[Jenne, Max]

I haven't checked to ensure that the MC still locks, because Yoichi is doing stuff on the PSL table, but I didn't change anything on the board, and hooked all the cables back where they were, so hopefully it's all okay.


I put the PMC back and the MC now locks.
  11603   Tue Sep 15 20:44:13 2015 gautamSummaryLSCChecking the delay line phase shifter DS050339
I checked out the delay line phase shifter D050339, (theory of operation here) this afternoon. I first checked that the power connection was functional, which it was, though the power connector is is not the usual chassis one (see image attached, do we need to change this?).

The box has two modes of operation - you can either change the delay by flipping switches on the front panel or via a 25pin D-sub connector on the back (the pin numberings for this connector on the datasheet are a little misleading, but I determined that pins 1-9 on the D-sub connector correspond to the 9 delays on the front panel in ascending order, pin 10 is the mode selector switch, should be high for remote operation, pins 11 and 13 are NC, pin 12 is VCC of 5V, and pins 14-25 are grounded). I first checked the front-panel mode of operation, using an oscilloscope to measure the delay between the direct signal from the Fluke 6061 and the output from the D050339. This corresponds to the first set of datapoints in the plot attached (signal was 100MHz sine wave).

I then used a 25 pin D sub breakout boards to check the remote operation mode as well, which corresponds to the second set of datapoints in the plot attached. For this measurement, I used the Agilent network analyzer to measure the phase lag between the direct signal (for all delays, I measured the phase lag at 100MHz, having first calibrated the "thru" path by connecting the R and A inputs of the network analyzer using a barrel BNC) and the delayed output from the box, and then converted it to a time delay.

Both sets of data are linear, with a slope nearly equal to 1 as expected. I conclude that the box is functioning as expected. Right now, Koji is checking a board which will be used to remotely control this box. On the hardware side it remains to make a cable going from the DS050339 Dsub input to the driver board output (also 25 pin Dsub).
Attachment 1: IMG_20150915_193100.jpg
IMG_20150915_193100.jpg
Attachment 2: Calibration.pdf
Calibration.pdf
  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

  2762   Sun Apr 4 00:21:42 2010 rana, kojiSummaryElectronicsCheckout of EG&G (PARC) preamp model #113, s/n 49135

We tested out the functionality of the EG&G 113 preamp that I found in one of the cabinets. This is one of the ancestors of the SR560 preamp that we are all used to.

It turns out that it works just fine (in fact, its better than the SR560). The noise is below 3nV/rHz everywhere above 30 Hz. The filter settings from the front panel all seem to work well. And the red knob on the front panel allows for continuous (i.e. not steps) gain adjustment. In the high-bandwidth mode (low pass filter at 300 kHz), there is ~35 deg of phase lag at 100 kHz. So the box is pretty fast.

IMG_0628.JPG

I would easily recommend this above the SR560 for use in all applications where you don't need to drive a 50 Ohm load. Also the battery is still working after 17 years!

There's several more of the this vintage in one of the last cabinets down the new Y-arm.

  15543   Wed Aug 26 22:49:47 2020 gautamUpdateElectronicsCheckout of Trek Model 603

I unboxed the Trek amplifier today, and performed some basic tests of the functionality. It seems to work as advertised. However, we may have not specified the correct specifications - the model seems to be configured to drive a bipolar output of +/- 125 V DC, whereas for PZT driving applications, we would typically want a unipolar drive signal. From reading the manual, it appears to me that we cannot configure the unit to output 0-250V DC, which is what we'd want for general PZT driving applications. I will contact them to find out more. 

The tests were done using the handheld precision voltage source for now. I drove the input between 0 to +5 V and saw an output voltage (at DC) of 0-250 V. This is consistent with the voltage gain being 50V/V as is stated in the manual, but how am I able to get 250 V DC output even though the bipolar configuration is supposed to be +/- 125 V? On the negative side, I am able to see 50V/V gain from 0 to -1 V DC. At which point making the input voltage more negative does nothing to the output. The unit is supposed to accept a bipolar input of +/- 10 V DC or AC, so I'm pretty sure I'm not doing anything crazy here...

Update:

Okay based on the markings on the rear panel, the unit is in fact configured for unipolar output. What this means is we will have to map the +/- 10 V DC output from the DAC to 0-5 V DC. Probably, I will stick to 0-2.5 V DC for a start, to not exceed 125 V DC to the PI PZT. I'm not sure what the damage spec is for that. The Noliac PZT I think can do 250 V DC no problem. Good thing I have the inverting summing amplifier coming in tomorrow...

Attachment 1: IMG_8951.JPG
IMG_8951.JPG
  11579   Fri Sep 4 20:42:14 2015 gautam, ranaUpdateCDSCheckout of the Wenzel dividers

Some years ago I bought some dividers from Wenzel. For each arm, we have x256 and a x64 divider. Wired in series, that means we can divide each IR beat by 2^14.

The highest frequency we can read in our digital system is ~8100 Hz. This corresponds to an RF frequency of ~132 MHz which as much as the BBPD could go, but less than the fiber PDs.

Today we checked them out:

  1. They run on +15V power.
  2. For low RF frequencies (< 40 MHz) the signal level can be as low as -25 dBm.
  3. For frequencies up to 130 MHz, the signal should be > 0 dBm.
  4. In all cases, we get a square wave going from 0 ~ 2.5 V, so the limiter inside keeps the output amplitude roughly fixed at a high level.
  5. When the RF amplitude goes below the minimum, the output gets shaky and eventually drops to 0 V.

Since this seems promising, we're going to make a box on Monday to package both of these. There will one SMA input and output per channel.

Each channel will have a an amplifier since this need not be a low noise channel. The ZKL-1R5 seems like a good choice to me. G=40 dB and +15 dBm output.

Then Gautam will make a frequency counter module in the RCG which can do counting with square waves and not care about the wiggles in the waveform.

I think this ought to do the trick for our Coarse frequency discriminator. Then our Delay Box ought to be able to have a few MHz range and do all of the Fast ALS Carm that we need.

Attachment 1: TEK00000.PNG
TEK00000.PNG
Attachment 2: TEK00001.PNG
TEK00001.PNG
Attachment 3: TEK00002.PNG
TEK00002.PNG
  11307   Tue May 19 11:15:09 2015 ericqUpdateComputer Scripts / ProgramsChiara Backup Hiccup

Starting on the 14th (five days ago) the local chiara rsync backup of /cvs/cds to an external HDD has been failing:

caltech/c1/scripts/backup/rsync_chiara.backup.log:

2015-05-13 07:00:01,614 INFO       Updating backup image of /cvs/cds
2015-05-13 07:49:46,266 INFO       Backup rsync job ran successfully, transferred 6504 files.
2015-05-14 07:00:01,826 INFO       Updating backup image of /cvs/cds
2015-05-14 07:50:18,709 ERROR      Backup rysnc job failed with exit code 24!
2015-05-15 07:00:01,385 INFO       Updating backup image of /cvs/cds
2015-05-15 08:09:18,527 ERROR      Backup rysnc job failed with exit code 24!
...
 

Code 24 apparently means "Partial transfer due to vanished source files."

Manually running the backup command on chiara worked fine, returning a code of 0 (success), so we are backed up. For completeness, the command is controls@chiara: sudo rsync -av --delete --stats /home/cds/ /media/40mBackup

Are the summary page jobs moving files around at this time of day? If so, one of the two should be rescheduled to not conflict. 

  11327   Wed May 27 15:20:54 2015 ericqUpdateComputer Scripts / ProgramsChiara Backup Hiccup

The local chiara backups are still failing due to vanished source files. I've emailed Max about the summary page jobs, since I think they're running remotely. 

  11336   Fri May 29 11:28:42 2015 ericqUpdateComputer Scripts / ProgramsChiara Backup Hiccup

I've changed the chiara local backup script to read a folder exclusion file, and excluded /users/public_html/detcharsummary, and things are working again. 

This was neccesary because the summary pages are being updated every half hour, which is faster than the time it takes for the backup script to run, so the file index that it builds at the start becomes invalid later on in the process. 


Thinking about chiara's disk, it strikes me that when we went from the linux1 RAID to a single HDD on chiara, we may have tightened a bottleneck on our NFS latency, i.e. we are limited to that single hard drive's IO rates. This of course isn't the culprit for the more recent dramatic slowdowns, but in addition to fixing whatever has happened more recently, we may want to consider some kind of setup with higher IO capability for the NFS filesystem. 

  11337   Fri May 29 12:49:53 2015 KojiUpdateComputer Scripts / ProgramsChiara Backup Hiccup

In fact, the file access is supposed to be WAY faster now than in the RAID case.

As noted in ELOG 9511, it was SCSI-2(or 3?) that had ~6MB/s thruput. Previously the backup took ~2hours.
This was improved to 30min by SATA HDD on llinux1.

I am looking at /opt/rtcds/caltech/c1/scripts/backup/rsync.backup.cumlog

In fact, this "30-min backup" was true until the end of March. After that the backup is taking 1h~1.5h.

This could be related to the recent NFS issue?

  11338   Fri May 29 15:12:39 2015 KojiUpdateComputer Scripts / ProgramsChiara Backup Hiccup

Actual data

Attachment 1: backup_hours.pdf
backup_hours.pdf
  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.

  13154   Mon Jul 31 20:35:42 2017 KojiSummaryComputersChiara backup situation summary

Summary
- CDS Shared files system: backed up
- Chiara system itself: not backed up


controls@chiara|~> df -m
Filesystem     1M-blocks    Used Available Use% Mounted on
/dev/sda1         450420   11039    416501   3% /
udev               15543       1     15543   1% /dev
tmpfs               3111       1      3110   1% /run
none                   5       0         5   0% /run/lock
none               15554       1     15554   1% /run/shm
/dev/sdb1        2064245 1718929    240459  88% /home/cds
/dev/sdd1        1877792 1426378    356028  81% /media/fb9bba0d-7024-41a6-9d29-b14e631a2628
/dev/sdc1        1877764 1686420     95960  95% /media/40mBackup

/dev/sda1 : System boot disk
/dev/sdb1 : main cds disk file system 2TB partition of 3TB disk (1TB vacant)
/dev/sdc1 : Daily backup of /dev/sdb1 via a cron job (/opt/rtcds/caltech/c1/scripts/backup/localbackup)

/dev/sdd1 : 2014 snap shot of cds. Not actively used. USB

https://nodus.ligo.caltech.edu:8081/40m/11640

 

  13159   Wed Aug 2 14:47:20 2017 KojiSummaryComputersChiara backup situation summary

I further made the burt snapshot directories compressed along with ELOG 11640. This freed up additional ~130GB. This will eventually help to give more space to the local backup (/dev/sdc1)

controls@chiara|~> df -m
Filesystem     1M-blocks    Used Available Use% Mounted on
/dev/sda1         450420   11039    416501   3% /
udev               15543       1     15543   1% /dev
tmpfs               3111       1      3110   1% /run
none                   5       0         5   0% /run/lock
none               15554       1     15554   1% /run/shm
/dev/sdb1        2064245 1581871    377517  81% /home/cds
/dev/sdd1        1877792 1426378    356028  81% /media/fb9bba0d-7024-41a6-9d29-b14e631a2628
/dev/sdc1        1877764 1698489     83891  96% /media/40mBackup

 

 

  14385   Fri Jan 4 15:18:15 2019 KojiUpdateGeneralChiara disk clean up and internally mounted

[Koji Gautam]

Took the opprtunity of the power glitch to take care of the disk situation of chiara.

- Unmounted /cvs/cds from nodus. This did not affect the services on nodus as they don't use /cvs/cds

- Go to chiara, shut it down, and physically checked the labels of the drives.

root = 0.5TB
/cvs/cds = 4TB HGST
backup of /cvs/cds= 6TB HGST

- These three disks are internally mounted and connected with SATA. Previously, 6TB was on USB.

- There were two other drives (2TB and 3TB) but they seemed logically or physically broken. These two disks were removed from chiara. (they came back online after reformatting on mac. So they seem still physically alive).

controls@chiara|~> df
df: `/var/lib/lightdm/.gvfs': Permission denied
Filesystem      1K-blocks       Used  Available Use% Mounted on
/dev/sda1       461229088   10690932  427109088   3% /
udev             15915020          4   15915016   1% /dev
tmpfs             3185412        848    3184564   1% /run
none                 5120          0       5120   0% /run/lock
none             15927044        144   15926900   1% /run/shm
/dev/sdb1      5814346836 1783407788 3737912972  33% /media/40mBackup
/dev/sdc1      3845709644 1884187232 1766171536  52% /home/cds
controls@chiara|~> lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 465.8G  0 disk
├─sda1   8:1    0 446.9G  0 part /
├─sda2   8:2    0     1K  0 part
└─sda5   8:5    0  18.9G  0 part [SWAP]
sdb      8:16   0   5.5T  0 disk
└─sdb1   8:17   0   5.5T  0 part /media/40mBackup
sdc      8:32   0   3.7T  0 disk
└─sdc1   8:33   0   3.7T  0 part /home/cds
sr0     11:0    1  1024M  0 rom

- Rebooted the machine and just came back without any error. This time the control room machines were not shutdown, but they just recovered the NFS once chiara got back.

Attachment 1: P_20190104_143336.jpg
P_20190104_143336.jpg
Attachment 2: P_20190104_143357.jpg
P_20190104_143357.jpg
  10837   Tue Dec 23 14:33:24 2014 SteveUpdateVACChiara gets UPS

Quote:

Quote:

We had an unexpected power shutdown for 5 sec at ~ 9:15 AM.

Chiara had to be powered up and am in the process of getting everything else back up again.

Steve checked the vacuum and everything looks fine with the vacuum system.

PSL Innolight laser and the 3 units of IFO air conditions turned on.

The vacuum system reaction to losing power: V1 closed and Maglev shut down. Maglev is running on 220VAC so it is not connected to VAC-UPS.  V1 interlock was triggered by Maglev "failure" message.

Maglev was reset and started. After Chiara was turned on manually I could bring up the vac control screen through Nodus and opened V1

"Vacuum Normal" valve configuration was recovered instantly.

 

Chiara needs UPS 

It is arriving Thursday

 EricQ and Steve,

Steve preset the vacuum for safe-reboot mode with C1vac1 and C1vac2 running normal: closed valves as shown, stopped Maglev & disconnected valves V1 plus valves with moving labels.

(The position indicator of the valves changes to " moving " when its cable disconnected )

Eric shut down Chiara, installed APC's UPS Pro 1000 and restarted it.

All went well. Nothing unexpected happened. So we can conclude that the vacuum system with running C1vac1 and C1vac2 is not effected by Chiara's losing AC power.

Attachment 1: prepUP.png
prepUP.png
  11481   Thu Aug 6 01:38:19 2015 ericqUpdateComputer Scripts / ProgramsChiara gets new Ethernet card

Since Chiara's onboard ethernet card has a reputation to be flaky in Linux, Koji suggested we could just buy a new ethernet card and throw it in there, since they're cheap. 

I've installed a Intel EXPI9301CT ethernet card in Chiara, which detected it without problems. I changed over the network settings in /etc/networking/interfaces to use eth1 instead of eth0, restarted nfs and bind9, and everything looked fine. 

Sadly, EPICS/network slowdowns are still happening. :(

  11483   Thu Aug 6 09:16:57 2015 SteveUpdateVACChiara gets new Ethernet card
  1. Yesterday we did put the vacuum system into safe to reboot mode  for the ethernet card swap.
  2. Atm1, IFO pressure
  3. Atm2, as prepared valve configuration where " moving " means closed and disconnected

 

Attachment 1: ChiaraNetCard.png
ChiaraNetCard.png
Attachment 2: 23.png
23.png
  10835   Tue Dec 23 14:27:16 2014 ericqUpdateCDSChiara moved to UPS

 Steve and I switched chiara over to the UPS we bought for it, after ensuring the vacuum system was in a safe state. Everything went without a hitch. 

Also, Diego and I have been working on getting some of the new computers up and running. Zita (the striptool projecting machine) has been replaced. One think pad laptop is missing an HD and battery, but the other one is fine. Diego has been working on a dell laptop, too. I was having problems editing the MAC address rules on the martian wifi router, but the working thinkpad's MAC was already listed. 

  10836   Tue Dec 23 14:30:11 2014 ericqUpdateCDSChiara moved to UPS

Quote:

 Steve and I switched chiara over to the UPS we bought for it, after ensuring the vacuum system was in a safe state. Everything went without a hitch. 

Also, Diego and I have been working on getting some of the new computers up and running. Zita (the striptool projecting machine) has been replaced. One think pad laptop is missing an HD and battery, but the other one is fine. Diego has been working on a dell laptop, too. I was having problems editing the MAC address rules on the martian wifi router, but the working thinkpad's MAC was already listed. 

 Turns out that, as the martian wifi router is quite old, it doesn't like Chrome; using Firefox worked like a charm and now also giada (the Dell laptop) is on 40MARS.

  13977   Sun Jun 17 14:20:35 2018 KojiUpdateGeneralChiara new USB 4TB DIsk

I have connected a 4TB disk to chiara via a USB-SATA adapter. This disk has been recognized as /dev/sde. A GUID Partition Table (GPT), not MBR was made with gdisk to make a partition with the size beyond 2TB.
I tried to use "dd" to copy /home/cds (/dev/sdb1) to /dev/sde1, but failed. The copy was done (taking ~12h) and the partition was not recognized as a complete filesystem.

So I decided to use rsync instead.

sudo mkfs -t ext4 /dev/sde1
sudo mkdir /media/usb4g
sudo mount -t ext4 -o rw /dev/sde1 /media/usb4g
sudo rsync -a --progress /home/cds/ /media/usb4g

Progress
14:33 Copied     33G/1831G
14:38 Copied     36G/1831G
17:02 Copied   365G/1831G (~2.2GB/min)
01:18 Copied 1449G/1831G (~2.2GB/min)
04:36 Completed
> sent 1907955222607 bytes  received 126124609 bytes  37010956.31 bytes/sec
> total size is 1907271994803  speedup is 1.00

  13980   Mon Jun 18 12:07:03 2018 KojiUpdateGeneralChiara new USB 4TB DIsk

The initial local backup with rsync was done. Now the new 4TB disk is (supposed to be) automatically mounted at boot as /media/40mBackup so that we can run the daily backup on this disk. (<- This was confirmed by "sudomount -a")

controls@chiara|~> sudo blkid
...
/dev/sde1: UUID="92dc7073-bf4d-4c58-8052-63129ff5755b" TYPE="ext4"

controls@chiara|~> cat /etc/fstab

...

UUID=92dc7073-bf4d-4c58-8052-63129ff5755b   /media/40mBackup    ext4    defaults    0   0

Here I've used UUID rather than the device name "/dev/sde1" because the device name can get altered depending on the order of the usb connection.

This new disk is just a bare HDD drive sitting on the top of the chassis. We eventually want to accommodate this disk in the chassis so that we can recover the function only with the modification of /etc/fstab.  We need to wait for a next chance to have chiara down. In fact, when we can isolate chiara, we want to use this disk as the main disk and install another 4TB disk as a backup.

  14360   Fri Dec 14 22:19:22 2018 KojiUpdateGeneralChiara new USB 4TB DIsk

Edit: It was not 4TB disk but 6TB disk in fact. (We actually ordered 4TB disk...)

I think the problem of the backup disk was the flaky power supply for the external drive.
I swapped the drive to a new HGST 4TB one, but it was neither recognized nor spun up with the external power supply we had. So I decided to put both the new and old drives in the PC chassis to power them up with the internal power supply. I tested the old disk via a USB-SATA cable. However, this disk was not recognized. I noticed that the disk was not HGST 4TB but Seagate 3TB. Is it possible? I thought it was 4TB... Did I miss something?

Once the new 4TB was connected to the USB-SATA, it was very smooth to get it mounted. Now the disk is mounted as /media/40mBackup as before. /etc/fstab was also modified with the new UUID. All the command logs are found here below.

Let's see how the morning backup goes. It would take a while to copy everything on the new disk. So it was actually very nice to set this disk up by Friday midnight.


controls@chiara|~> lsblk

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 465.8G  0 disk 
---- sda1   8:1    0 446.9G  0 part /
---- sda2   8:2    0     1K  0 part 
---- sda5   8:5    0  18.9G  0 part [SWAP]
sdb      8:16   0   1.8T  0 disk 
---- sdb1   8:17   0   1.8T  0 part 
sdc      8:32   0   3.7T  0 disk 
---- sdc1   8:33   0   3.7T  0 part /home/cds
sr0     11:0    1  1024M  0 rom  
sdd      8:64   0   5.5T  0 disk 

controls@chiara|~> sudo mkfs -t ext4 /dev/sdd1

mke2fs 1.42 (29-Nov-2011)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
183144448 inodes, 1465130385 blocks
73256519 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
44713 block groups
32768 blocks per group, 32768 fragments per group
4096 inodes per group
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
    102400000, 214990848, 512000000, 550731776, 644972544
Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done      

controls@chiara|~> blkid

/dev/sda1: UUID="972db769-4020-4b74-b943-9b868c26043a" TYPE="ext4" 
/dev/sda5: UUID="a3f5d977-72d7-47c9-a059-38633d16413e" TYPE="swap" 
/dev/sdc1: UUID="92dc7073-bf4d-4c58-8052-63129ff5755b" TYPE="ext4" 
/dev/sdd1: UUID="1843f813-872b-44ff-9a4e-38b77976e8dc" TYPE="ext4" 

controls@chiara|~> sudo emacs -nw /etc/fstab
controls@chiara|~> cat /etc/fstab

# /etc/fstab: static file system information.
#
# Use 'blkid -o value -s UUID' to print the universally unique identifier
# for a device; this may be used with UUID= as a more robust way to name
# devices that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    nodev,noexec,nosuid 0       0
# / was on /dev/sda1 during installation
UUID=972db769-4020-4b74-b943-9b868c26043a /               ext4    errors=remount-ro 0       1
# swap was on /dev/sda5 during installation
UUID=a3f5d977-72d7-47c9-a059-38633d16413e none            swap    sw              0       0
#UUID="90a5c98a-22fb-4685-9c17-77ed07a5e000"    /media/40mBackup       ext4      defaults,relatime,commit=60       0         0
UUID="1843f813-872b-44ff-9a4e-38b77976e8dc"    /media/40mBackup       ext4      defaults,relatime,commit=60       0         0

#fb:/frames      /frames nfs     ro,bg


UUID=92dc7073-bf4d-4c58-8052-63129ff5755b   /home/cds    ext4    defaults,relatime,commit=60    0   0

controls@chiara|~> sudo mount -a
controls@chiara|~> df

Filesystem      1K-blocks       Used  Available Use% Mounted on
/dev/sda1       461229088   10694700  427105320   3% /
udev             15915020         12   15915008   1% /dev
tmpfs             3185412        868    3184544   1% /run
none                 5120          0       5120   0% /run/lock
none             15927044        484   15926560   1% /run/shm
/dev/sdc1      3845709644 1809568856 1840789912  50% /home/cds
/dev/sdd1      5814346836     190408 5521130352   1% /media/40mBackup
  14361   Sat Dec 15 18:29:53 2018 KojiUpdateGeneralChiara new USB 4TB DIsk

The local backup was done at 18:18 after 11h18m of running.

2018-12-15 07:00:01,699 INFO       Updating backup image of /cvs/cds
2018-12-15 18:17:56,378 INFO       Backup rsync job ran successfully, transferred 5717707 files.

 

  10575   Tue Oct 7 10:09:07 2014 manasaUpdateGeneralChiara not responding

Chiara doesn't seem to be responding and I guess something happened 7 hrs ago.

I tried to hook up chiara to a monitor to reboot or atleast look for error messages; but it is not even detecting the external monitor (Tried changing monitors and vga cables; still see nothing).

I tried to ssh into it and only received errors :
NFS lookup failed for server XXX.XXX.XXX.XXX : error 5 (RPC: Timed out)
ssh: chiara: host/servname not known

Steve had the vacuum checked and everything seems fine with the status of the vacuum system atleast.

  10577   Tue Oct 7 16:19:50 2014 ericqUpdateGeneralChiara not responding

We're back! It was entirely my fault.

Some months ago I wrote a script that chiara calls every night, that rsyncs its hard drive to an external drive. With the power outage yesterday, the external drive didn't automatically mount, and thus chiara tried to rsync its disk to the mount point, which was at the time just a local folder, which made it go splat. 

I'm fixing the backup script to only run if the destination of the rsync job is not a local volume. 

  10578   Tue Oct 7 16:41:12 2014 JenneUpdateGeneralChiara not responding

I put a little script into ...../scripts/Admin that will check the fullness of Chiara's disk.  We only have the mailx program installed on Nodus, so for now it runs on Nodus and sends and email when the chiara disk that nodus mounts is more than 97% full.

  3438   Wed Aug 18 20:54:23 2010 rana, yoichiConfigurationEnvironmentChiller's chiller turned off

WE programmed the MOPA chiller's AC unit to turn off at 6PM each day and automatically turn on at 7 AM each morning. Its now very quiet in the control room at night.

Next, we'll leave it off during the day and see if it makes Steve go crazy or not.

  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.

  8966   Mon Aug 5 18:18:32 2013 gautamUpdateCDSChoosing LO Amplitudes and Frequencies

In order to decide what frequencies to dither the 4 degrees of freedom (M1-pitch&yaw, M2-pitch&yaw) at, I took the power spectrum of the X and Y-arm green transmission (C1:ALS-TRX_OUT, C1:ALS-TRY_OUT). Plots showing the power spectra are attached. Looking at the power spectra, I would think that for the X-arm, it would be okay to dither at 40, 50, 60 and 70 Hz. In order to check if the piezos could respond to these frequencies, I used my QPD setup and shook the PZTs with a 100Hz, 1Vpp sinusoid, and saw that the spot moved smoothly on the QPD.


 As for choosing the modulation amplitude, I did a simplistic approximation assuming that the misalignment only rotates the beam axis relative to the cavity axis, and determined what angle coupled 10% of the power into the next eigenmode. Assuming that this is small enough such that if we are already locked to TEM00, the dither won't kick it up to some higher-order mode, the LO amplitude should be in the range of 30-60 digital counts (determined using the PZT calibration constants determined here. This corresponds to a sine-wave of ~50mV amplitude reaching the PZTs (after HV amplification). I am not sure if this is too small, but according to the PZT datasheet, these platforms are supposed to have a resolution of 0.02 urad, which would correspond to the input signal changing by ~0.1 mV, so this signal should be capable of dithering the tip-tilt. 


 I have already added band-pass filters centered at these frequencies to the model (with a passband of 5Hz, 2Hz on either side), and low-pass filters to pull out the DC component of the output of the lock-in amplifiers. It remains to tune the gains of the filter stages. These parameters (frequency, amplitude of the LOs) may also have to be changed after tests). Hopefully the PZTs can be plugged in tomorrow, and I can try and make a measurement of the output matrix. 

Koji also suggested that it may be good to have a path in the model that feeds back to the PZTs by dithering the cavity mirrors as opposed to the PZT mounted mirrors. I will work on incorporating this into the SIMULINK model (c1asx.mdl) and also into the master medm screen.


 

Notes:

  1. The spot size of the X-arm green transmission on the PD was larger than the active surface. I moved the GTRX PD a little back and put in a lens (KPX085, 62.9mm FL, AR.14) in front of the PD, such that the spot is now occupying about 1/4th of the active surface area. The lens was mounted in a Thorlabs LMR1mount, and has been labelled.
  2. I made a slight change to the SIMULINK model, so as to calibrate the PZT sliders to (approximately) volts (I added a multiplier block that multiplies the slider value by constant value 3267.8). The idea is that we can approximately relate the slider value to tilt, knowing the calibration constant in mrad/V for the PZTs.

 

Power Spectra of Arm Green Transmission:

GTR_Power_Spectrum.pdf

  8968   Mon Aug 5 19:10:01 2013 KojiUpdateCDSChoosing LO Amplitudes and Frequencies

- I suppose the green transmission paths were thoroughly inspected and aligned in prior to the measurement

- Of course it is a BAD idea to use 60Hz as the LO frequency.

- Power spectra should be plotted as "RIN (relative intensity noise)" as the DC of 1 and 100 gives you 100 times different power spectra for the same beam.
  Don't forget to subtract the offset from your DC values.

  8972   Tue Aug 6 16:36:51 2013 gautamUpdateCDSChoosing LO Amplitudes and Frequencies-revised

I redid the power spectrum measurement for the X-arm green transmission after aligning the arm to green using the ITMX/ETMX Pitch and Yaw sliders on IFOalign.

The Y-axis now reflects the relative intensity noise (RIN), which I obtained by taking the average value of the X-arm green transmission using tdsavg. Based on this measurement, I have now picked four new frequencies at which to try and modulate the PZT mirrors: 10, 19, 34 and 39 Hz. Bandpass filters in the LIA stage have been appropriately modified. 

Power Spectrum:

powerSpec0806.pdf

  9229   Thu Oct 10 08:25:07 2013 SteveUpdatesafetyChris received safety training

Chris Couste, our new undergrad help received 40m specific, basic safety training yesterday.

  10329   Mon Aug 4 17:30:00 2014 ericqUpdateGeneralChronic Suspension Problems

TRX and TRY communication were recovered by doing a simultaneous reboot of all of the frontends.

Working with the interferometer has been extremely frustrating today. Having transmission values let us lock and ASS, but that has been less helpful than you would hope.

Saving the ASS offsets has repeatedly resulted in an overall bad change in alignment, moving the TTs and other things off randomly.

ITMX continues to be kicked. ITMY intermittently wanders away. It has not been possible to maintain IFO alignment for a reasonable length of time.

Also, the wall IOO striptool shows the MC2 Trans QPD Yaw having large step-function features. The MC is having an ok duty cycle, but this just may mean that the WFS are able to absorb what is happening to the MC suspensions.

The suspensions are really misbehaving. We need to get to the bottom of this, or else we are going to keep losing time to alignment.

  10330   Mon Aug 4 18:25:46 2014 JenneUpdateGeneralChronic Suspension Problems

Q is working on fixing the "save offsets" script for the ASS, because that has lost me my alignment two more times in the last few hours.  But, right now I have both arms locked with transmitted powers of about 0.9!  To get this, I ran the ASS scripts, and hand-tweaked the bias sliders of some of the optics to relieve the ASS outputs.  Then I turned the ASS gain to zero, and by-hand turned off the oscillators.  So, the ASS outputs are just frozen. 

I haven't seen IMTX suspension kicks, I think since Q did the front end reboot earlier. There has been ITMY activity, however. I think I'm going to be bold, and try locking ALS.

  14824   Fri Aug 2 16:46:09 2019 KruthiUpdateCamerasClean up

I've put the analog camera back and disconnected the 151 unit GigE. But I ran out of time and wasn't able to replace the beamsplitter. I've put all the equipments back to the place where I took them from. The chopper and beam dump mount, that Koji had got me for the scatterometer, are kept outside, on the table I was working on earlier, in the control room. The camera lenses, additional GigEs, wedge beamsplitter, 1050nm LED and all related equipments are kept in the GigE box. This box was put back into CCD cameras' cabinet near the X arm.

Note: To clean stuff up, I had entered the lab around 9.30pm on Monday. This might have affected Yehonathan's loss measurement readings (until then around 57 readings had been recorded).

Sorry for the late update.

  5451   Sun Sep 18 16:42:00 2011 KojiBureaucracyEnvironmentClean up your mess

Mess in the lab is increasing. Kiwamu and I had to clean up some stuffs to continue our work.
(i.e. some components were disturbing to open the lid of the tables.)

Basically the tools/equipments/component/cables/digital cameras/lens caps/IR viewers
you have used for the day should be cleaned up at the end of the day.

If one likes to leave a temporary stuff, leave a note to indicate by whom, for what, how long
it will be kept like that, and when one is going to back there with contact info like the cell phone #.

  3953   Fri Nov 19 04:23:12 2010 SureshUpdateSUSCleaned and stuck magnets to dumbbells

To clean the glue off the magnets and dumbbells I soaked them in Acetone for about an hour and then scrubbed the ends clean with a lint free tissue soaked in Acetone. 

I then examined the ends under a microscope and found that while the flat faces were clean some of the grooves were still filled with glue.

 

Top Bottom

dumbells_before_ultrasonic_bath_2.jpg

dumbells_before_Ultrasonic_wash_1.jpg
 magnets_after_scrub.jpg magnets_after_scrub.jpg


While examining the magnets I found some small magnetic fibers stuck to the magnets.  Rana had mentioned these before as potential trouble makers which could degrade the high frequency performance of the OSEMs.

 Magnetic_Hair.jpg

 

To try and get the glue out of the grooves I put the dumbells through an ultrasonic bath for ten mins.  Most of the glue has been removed from the grooves.  Pics below

 

dumbells_after_ultrasonic_wash_1.jpg

dumbells_after_ultrasonic_wash_2.jpg

 

I proceeded try and recover the lost time by sticking the magnets back to the dumbbells.  Increased the quantity of the glue to a slightly larger amount than usual.  It should definitely squish out a bit now.  We will know tomorrow when we open the gluing fixture.

 

 

 

  9833   Sun Apr 20 18:15:37 2014 ericqUpdateIOOCleaner Cleanup

Came in, and the PMC and MC needed aligning. 

PMC Trans .74->.83

I wasn't able to move the MC1&3 the right way in pitch without having a terrible MC2 position... using the move MC2 scripts to bring it back threw off the other spots.

  12089   Tue Apr 26 15:22:35 2016 SteveUpdateendtable upgradeCleaning ETMX vacuum dirty window

Gautom is progressing with the layout nicely. The X-arm transmission window have not seen cleaning for decades. This should be the time to do it. Here is picture of dirtiness.

It is not that simple... How much effort should we put in it? The hole table with 1W inno laser plus... set up now about ~500 lbs  We can pull it off carefully, but it is not risk free.

We should look at our other signal port windows! Gautom's long reach able him to do the first contact cleaning without moving anything. It is great!
 

Attachment 1: ETMX-Tvp.jpg
ETMX-Tvp.jpg
Attachment 2: ETMX-TvpDetail.jpg
ETMX-TvpDetail.jpg
  12094   Wed Apr 27 15:04:47 2016 SteveUpdateendtable upgradeCleaning ETMX vacuum dirty window

It looks very promising.

 

Attachment 1: 1cETMX-Tcmp.jpg
1cETMX-Tcmp.jpg
  12100   Fri Apr 29 16:05:23 2016 gautamUpdateendtable upgradeCleaning ETMX vacuum dirty window

After a second round of F.C. application, I think the window is clean enough and there are no residual F.C. pieces anywhere near the central parts of the window (indeed I think we got most of it off). So I am going to go ahead and install the Oplev. 

Quote:

It looks very promising.

 

 

Attachment 1: IMG_0755.JPG
IMG_0755.JPG
  3975   Tue Nov 23 11:20:30 2010 josephbUpdateCDSCleaning up old target directory

Winter Cleaning:

I cleaned up the /cvs/cds/caltech/target/ directory of all the random models we had built over the last year, in preparation for the move of the old /cvs/cds/caltech/target slow control machine code into the new /opt/rtcds/caltech/c1/target directories.

I basically deleted all the directories generated by the RCG code that were put there, including things like c1tst, c1tstepics, c1x00, c1x00epics, and so forth.  Pre-RCG era code was left untouched.

  8223   Mon Mar 4 18:11:10 2013 JamieUpdateSUSCleaning up suspension POS inputs

I did a little bit of cleanup of the suspension POS inputs today, both in model and MEDM land.

model

sus_single_control.mdl was simplified such that now there are just two position inputs:

  • POS: with LSC filter
  • ALTPOS: unfiltered

The regular LSC inputs go into POS, and any optic-specific extra pos inputs go into ALTPOS after being properly filtered and summed.

So for instance, MC2_MCL and MC2_ALS are filtered and summed then go into MC2 ALTPOS.  The ETM ALS inputs go into ALTPOS.

I modified the GLOBAL DAMPING outputs so that they are filtered in the GLOBAL block before being sent to be summed before going into ALTPOS for {I,E}TM{X,Y}.

All suspension models were rebuilt/installed/restarted.

MEDM

The SUS_SINGLE.adl template screen was modified such that the POS button now points to optic-specific POS filter screens at:

/opt/rtcds/caltech/c1/medm/master/sus/SUS_$(OPTIC)_POS.adl

For MC1, MC3, PRM, BS, SRM these are links to SUS_SINGLE_POS.adl.  The rest of the suspensions (MC2, {I,E}TM{X,Y}) now have custom screens that are variations of SUS_SINGLE_POS but with their extra filter screens added in.  For instance, here is the new SUS_ETMX_POS.adl:

SUS_ETMX_POS.png

This gets rid of all the white screen crap that was in here before.

All of this has been committed to the SVN.  NOTE: symlinks were heavily used when sorting this stuff out, so check for symlinks when modifying in the future.

  4443   Fri Mar 25 08:58:38 2011 AidanUpdateTreasureCleared stuff off SP table

I tidied up some of the stuff that was on the SP table. The ISS box that has been sitting on there for months is now underneath the X-arm on top of the spare Marconi which is stored there.

 

 

Attachment 1: ISS_box.JPG
ISS_box.JPG
  6968   Thu Jul 12 15:25:24 2012 JenneUpdateSUSClearing test points

Somehow we got an excitation going on BS OpLevs, and even though Yuta thought he might have accidentally started it, he couldn't find where, so we couldn't stop it.

Since we don't have anything written on the wiki, I ended up calling Joe to remind me how to clear test points:

controls@allegra:~ 0$ diag -l -z
diag> tp clear * *
test point cleared
diag> awg clear 21.*
reset succeeded

The tp clear clears all test points everywhere.  The awg clear wouldn't let me do a universal clear, so I just did #21, which is the SUS model.  So if you want to kill excitations on a specific model, you must find it's DCU ID (it's in the top right corner of the GDS status screens for each model). 

  12555   Wed Oct 12 22:51:26 2016 KojiUpdateGeneralClipping could not be improved by the PZTs - NEED ANOTHER VENT

[Gautam Koji]

We engaged the HV driver to the output port PZTs, hoping to mitigate the AS port clipping. Basically, the range of the PZT is not enough to make the beam look clean. Also, our observation suggested there are possible multiple clipping in the chamber. We need another vent to make the things clearly right. Eric came in the lab and preparing the IFO for it.


1. Before the test, the test masses have been aligned with the dither servo.

2. We looked at the beam shape on the AS camera with a single bounce beam. We confirmed that the beam is hard-clipped at the upper and left sides of the beam on the video display. This clipping is not happening outside of the chamber.

3. We brought an HV power supply to the short OMC rack. There is a power supply cable with two spades. The red and black wires are +150V and GND respectively.

4. The voltage of +/-10V was applied on each of the four PZT drive inputs. We found that the motion of the beam on the camera is tiny and in any case, we could not improve the beam shape.

5. We wondered that if we are observing ANY improvement of the clipping. For this purpose, we aligned AS110 sensor every time we gave the misalignment with the PZTs. Basically, we are at the alignment to have the best power we can get. We thought this was weird.

6. Then we moved the AS port spot with the ITMX. We could clearly make the spot more round. However, this reduced the power at the AS port reduced by ~15%. When the beam was further clipped, the power went down again. Basically, the initial alignment gave us the max power we could get. As the max power was given with the clipped beam, we get confused and feel safer to check the situation with the chambers open.

During this investigation, we moved the AS port opitcs and the AS camera. So they are not too precise reference of the alignment. The PZT HV setup has been removed.

  6690   Sat May 26 01:28:58 2012 KojiUpdateGeneralClipping improvement

The beam at the dark port was largely clipped.
The arm transmissions (TRX/TRY) were ~0.6 no matter how you try to align.

The PZT1/2 X was scanned and TRX/TRY are now both ~0.9.
This means that the beam was mostly clipped in or after the mode mathing optics.

FPMI contrast is (2.45-0.02)/(2.45+0.02) = 98%
Not so bad although it does not tell anything about clipping before the IFO.

In the next opportunity, we should try to "pin" the beam axis on the arm mirrors using A2L.

1. I am not sure exactly where the clipping was. It means that a small clipping might still be there.

2. I am afraid that the beam is still clipped in the faraday. The beam can be scanned using the steering on the PSL table.

 

Attachment 1: Untitled.png
Untitled.png
ELOG V3.1.3-