40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 210 of 341  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  4038   Thu Dec 9 22:04:40 2010 kiwamuUpdateSUSRe:strange ETMX suspension

[Koji, Osamu and Kiwamu]

We checked the ETMX suspension and found the UR OSEM was close to the magnet.

So we rotated the UR OSEM so that it won't touch the magnet any more.

We will check the resonant frequencies again by taking the spectra.

--

  In fact the ETMX stacked when we applied a big angular offset to Yaw direction.

This was because that the magnet was actually touching the UR OSEM.

The earthquake stops were fine, they weren't touching the test mass.

Also we looked at the wire and the standoffs, they seemed fine.

Quote: #4036
We are going to inspect the suspension today.

  2606   Tue Feb 16 11:12:51 2010 kiwamuUpdateGreen LockingRe:take some optics away from the ETM end table

Quote:

Quote:

In the last two days Steve and I took some optics away from the both ETM end table.

This is because we need an enough space to set up the green locking stuff into the end table, and also need to know how much space is available.

Optics we took away are : Alberto's RF stuff, fiber stuff and some optics obviously not in used.

The picture taken after the removing is attached. Attachment1:ETMX, Attachment2:ETMY

And the pictures taken before the removing are on the wiki, so you can check how they are changed.

http://lhocds.ligo-wa.caltech.edu:8000/40m/Optical_Tables

The PD Kiwamu removed from the Y table was TRY, which we still need.

My bad if he took that. By mistake I told him that was the one I installed on the table for the length measurement and we didn't need it anymore.

I'm going to ask Kiwamu if he can kindly put it back.

 I am going to put the PD back to the Y end table in this afternoon.

  3457   Mon Aug 23 18:18:22 2010 kiwamuConfigurationSUSRe:watchdogs off

Now watchdogs are back.

The suspensions are well damped.

  2447   Tue Dec 22 18:42:40 2009 Sanjit, KojiConfigurationAdaptive FilteringReadded DAQ channels to active list

Sometimes back we modified /cvs/cds/caltech/chans/daq/C1ASS.ini to save some of the channels. The file was reverted to default after the recent changes in ASS.

We again uncommented and made acquire=1 to save the following three channels using daqconfig:

C1:ASS-TOP_ERR_MCL_IN1_2048

C1:ASS-TOP_PEM_15_IN1_2048

C1:ASS-TOP_PEM_18_IN1_2048

The script automatically created a back up in /cvs/cds/caltech/chans/daq/archive

 

  889   Tue Aug 26 19:07:37 2008 YoichiHowToComputersReading data from Agilent 4395A analyzer through GPIB from *Linux* machine
I succeeded in reading data from Agilent 4395A analyzer, who's floppy is crappy, through GPIB from a Linux machine using
agilent 82357B USB-GPIB interface.
I installed the linux GPIB driver to one of the lab. laptops (the silver DELL one currently sitting on the 4395A analyzer).
I wrote an initialization script for the USB-GPIB interface and a small python script for reading data from the analyzer.

[Usage]

1. Connect the USB-GPIB interface to the laptop and the analyzer.
2. Run /usr/local/bin/initGPIB command (it takes about 10sec to complete).
3. Run /usr/local/bin/getgpibdata.py > data.txt to save data from the analyzer to a text file.

The data format is explained in the comments of getgpibdata.py
This method is way faster than the unreliable floppy. The data is transfered in a few sec.

I'm now writing a wiki page on this
http://lhocds.ligo-wa.caltech.edu:8000/40m/GPIB

I will install the same thing into the other DELL laptop soon.
Let me know if you have trouble with this.
  9597   Tue Feb 4 17:40:19 2014 manasaUpdateGeneralReady for pump down??

Quote:

* PRM suspension has not been behaving well. PRM is being kicked around every 5-10 seconds when the PRC is aligned (as seen on REFL camera). We are not sure where this is coming from. The first time we saw this happening was when we were trying to lock PRC at low power even before we took the heavy doors off. So we are pretty sure this is not caused by the foil cover on the OSEMs. We tried turning ON/OFF the oplev servo, turning ON/OFF the damping loops and also checked the connections in the feedthrough and satellite box for the PRM. The OSEM sensor values for the suspension also seem to match the ones on the wiki.

 

This is solved.

The ASC for PRC for left turned ON. Turning it OFF solved the problem.

If there is no feedback regarding the POP alignment or anything to check with modified PRC length, we will close tomorrow morning.

  9598   Tue Feb 4 23:01:24 2014 JenneUpdateGeneralReady for pump down??

 

 This sounds great! The only suggestion that I have is for checking POP. If you have the beam on the camera, you can hold a card in front of each mirror, and find out where the edge of the beam is. Introduce the card from the side, and watch for the point where you just start to see the beam on the camera be obstructed. Repeat for the other side, and you have an idea of the centering of the beam. 

I think this is most important for the in-vac mirrors, since the beam is large-ish, and we have to hit both steering mirrors at ~45 degrees.

  9601   Wed Feb 5 15:26:57 2014 manasaUpdateGeneralReady for pump down??

Quote:

 

 This sounds great! The only suggestion that I have is for checking POP. If you have the beam on the camera, you can hold a card in front of each mirror, and find out where the edge of the beam is. Introduce the card from the side, and watch for the point where you just start to see the beam on the camera be obstructed. Repeat for the other side, and you have an idea of the centering of the beam. 

I think this is most important for the in-vac mirrors, since the beam is large-ish, and we have to hit both steering mirrors at ~45 degrees.

 [EricQ, Manasa]

This check was done and we had to move one of the steering mirrors in pitch. Else, everything was just fine.

In-vacuum pictures of PR2 and PR3 new positions were taken. MC spot positions measured to be < 1mm and oplevs were centered.

  14390   Tue Jan 8 19:13:39 2019 JonUpdateUpgradeReady for pumpdown tomorrow

Everything is set for a second pumpdown tomorrow. We'll plan to start pumping after the 1pm meeting. Since the main volume is already at 12 torr, the roughing phase won't take nearly as long this time.

I've added new channels for the TP1 analog readings (current and speed) and for the two N2 tank pressure readings. Chub finished installing the new regulator and has run the transducer signal cable to the vacuum rack. In the morning he will terminate the cable and make the final connection to the Acromag.

Gautam and I updated the framebuilder config file, adding the newly-added channels to the list of those to be logged. We also set up a git repo containing all of the Python interlock/interfacing code: https://git.ligo.org/40m/vacpython. The idea is to use the issue tracker to systematically document any changes to the interlock code.

  11488   Mon Aug 10 22:18:19 2015 IgnacioUpdateIOOReady to do some online mode cleaner subtraction

I'm attaching a SISO IIR Wiener filter here for reference purposes that will go online either tonight or tomorrow evening. This is a first test to convince myself that I can get this to work, MISO IIR filters are close to being ready and will soon be employed. 

This Wiener filter uses the STS-X channel as a witness and MCL as target. The bode plot for the filter is shown below,

The performance of the FIR and IIR Wiener filters and the ammount of subtraction achive for MCL is shown below,

 

Output from quack to be loaded with foton: filter.zip

K bye.

  8969   Tue Aug 6 07:52:58 2013 manasaUpdateGeneralReady to pump down

I did an alignment check of the IFO before we start pumping down.

Arms were locked. PRM and SRM were aligned. Green was aligned to the arms for reference during the pump down.

Steve! It's a GO!

MC spot positions:

MCspot_0806.png

OSEM:

OSEM_0806.png

Oplevs were all centered yesterday and haven't drifted much. So I left them as is.

OL_0806.png

QPDs (IPPOS aligned from yesterday.

QPD_0806.png

  6079   Wed Dec 7 00:48:58 2011 kiwamuUpdateRF SystemRealigned incindent pointing to MC
Actually it was already in a good place.
I just realigned the zig-zag mirrors on the PLS table to bring the entire beam axis a little bit upward.
The WFS servo still seems fine. The input pzt mirrors are still within their range.

Quote from #6077

Next step:  Kiwamu needs to find his happy mode cleaner place, and we'll realign the PSL beam to the MC.  The PSL-MC axes were mismatched pretty badly according to Suresh anyway, so this had to be done no matter what.

  5539   Sat Sep 24 17:12:54 2011 KojiUpdateLSCRealignment of REFL / Some 3f PRMI locking / Recycling Gain

[Koji Suresh]

Activity on Friday evening

- The REFL path has been thoroughly aligned
As I did not like the REFL spot misaligned on the REFL CCD, we went to the AP table.
Many optics had the spots not on the middle of the optic, including the PBS whose post was not fixed on the post holder.
We aligned the optical paths, the RF PDs, and the CCD. The alignment of the PD required the use of the IR viewer.
One should not trust the DC output as a reference of the PD alignment as it is not enough sensitive to the clipping.

We aligned the optical paths again after the reasonable alignment of PRM is established with the interferometer.
"Next time when you see REFL spot is not at the center of the camera, think what is moved!"

- The REFL165 PD is disconnected from the power supply
I found that the REFL165 PD is producing 7.5V output at the DC monitor no matter how the beam is blocked.
As I could not recover this issue by swapping the power connector at the LSC rack, I disconnected the cable
at the RFL165 PD side. I need to go through the PD power supply circuit next week.

- PRMI alignment policy of the night

Kiwamu has aligned Y-arm some time ago (Thursday evening?). I decided not to touch ITMY.
So the Michelson is aligned by ITMX, PRC is aligned by PRM.

- Michelson locking

The short Michelson was locked with AS55Q and the MICH filter. We could use the gain of +/-20 for locking,
and could increase it up to ~+/-250. At the max gain, the all three integrators and the two resonant gains
could be activated. The sign depends on which fringe you want at the AS port (bright or dark).

In this condition, the output of the POXDC channel (which is actually the POY DC out -- c.f. This entry
is used to determine the internal power. It was ~70cnt.

- PRMI locking

Then the PRMI was locked. There was some confusion of the gains because of the limitters at the servo filters
(which yielded the locking with 1bit outputs no matter how much the gains were....)

After all, I decided to use REFL33I for the PRCL for the test. The PRCL gain was -0.3~-1.0 for the carrier lock, but
was highly dependent on the alignment. i.e. if accidentally hit the high power recycling gain, it oscillated easily
and the lock was lost. Probably this was the first 3f locking at the 40m in the current optical config, if
Kiwamu did not do that secretly. The SB lock was also obtained by flipping the sign of the PRCL servo.

The difficulty we had was the instability when the recycling gain became big. We were monitoring the POXDC
(i.e.DCout of the POY PD). When this exceeds 5000, many glitches appears in the LSC signals and disturbs the lock.
This was not the fringes from neither the arms nor the SRC.

The observed POY DC with the carrier resonant PRMI was 5000~8000vcnt (momentary).

  5545   Mon Sep 26 15:15:45 2011 AnamariaUpdateLSCRealignment of REFL / Some 3f PRMI locking / Recycling Gain

A few comments on REFL table alignment and REFL165.

Last time we realigned the table was after the PZT work by Koji/Kiwamu; we made sure that the beam was going through optics satisfactorily and that we were reading reasonable numbers. I did use primarily a viewer to align onto PD, after which we used the voltage reading to center better around that spot. As desired, I could not see the beam once it was centered on the PD. I never touched the PBS unfortunately, so I never noticed it was not fixed. Sad.

I am very surprised to hear the reading from REFL165, since I was reading around 400mV from it a few days before. Something strange happened in the mean time. I hope not when I was plugging and unplugging at the power rack for the POY work. But I would not have needed to touch REFL165. Those cables should get some strain relief at the rack, by the way.

I thought about it, and I must admit that after we centered camera on REFL (paired with an alignment), we did not check the beam path later, even after we saw that the REFL beam had moved. We only did a quick by-viewer check that the beams were not off of the PDs.

Quote:

[Koji Suresh]

- The REFL path has been thoroughly aligned
Many optics had the spots not on the middle of the optic, including the PBS whose post was not fixed on the post holder.
We aligned the optical paths, the RF PDs, and the CCD. The alignment of the PD required the use of the IR viewer.
One should not trust the DC output as a reference of the PD alignment as it is not enough sensitive to the clipping.

We aligned the optical paths again after the reasonable alignment of PRM is established with the interferometer.
"Next time when you see REFL spot is not at the center of the camera, think what is moved!"

- The REFL165 PD is disconnected from the power supply
I found that the REFL165 PD is producing 7.5V output at the DC monitor no matter how the beam is blocked.
As I could not recover this issue by swapping the power connector at the LSC rack, I disconnected the cable
at the RFL165 PD side. I need to go through the PD power supply circuit next week.

 

  12169   Fri Jun 10 18:16:59 2016 varunUpdatePSLRealignment of pre mode cleaner

The mode cleaner was misaligned probably due to the earthquake (the drop in the MC transmitted value slightly after utc 7:38:52 as seen in the second plot). The plots show PMC transmitted and MC sum signals from 10th june 07:10:08 UTC over a duration of 17 hrs. The PMC was realigned at about 4-4:15 pm today by rana. This can be seen in the first plot.

  17137   Thu Sep 8 16:03:25 2022 YehonathanUpdateLSCRealignment, arm locking, gains adjustments

{Anchal, Yehonathan}

We came this morning and the IMC was misaligned. The IMC was realigned and locked. This of course changed the input beam and sent us down to a long alignment journey.

We first use TTs to find beam on BHD DCPD/Camera since it is only single bounce on all optics.

Then, PR2/3 were used to find POP beam while keeping the BHD beam.

Unfortunately, that was not enough. TTs and PRs have some degeneracy which caused us to lose the REFL beam.

Realizing this we went to AS table to find the REFL beam. We found a ghost beam that decieved us for a while. Realizing it was a ghost beam, we moved TT2 in pitch, while keeping the POP DCPD high with PRs, until we saw a new beam on the viewing card.

We kept aligning TT1/2, PR2/3 to maximize the REFL DCPD while keeping the POP DCPD high. We tried to look at the REFL camera but soon realized that the REFL beam is too weak for the camera to see.

At that point we already had some flashing in the arms (we centered the OpLevs in the beginning).

Arms were aligned and locked. We had some issue with the X-ARM not catching lock. We increased the gain and it locked almost immediately. To fix the arms gains correctly we took OLTFs (Attachment) and adjusted the XARM gain to 0.027 to make the UGF at 200Hz.


Both arms locked with 200 Hz UGF from:

From GPS: 1346713049
    To GPS: 1346713300

From GPS: 1346713380
    To GPS: 1346714166

HEPA turned off:
From GPS: 1346714298
    To GPS: 1346714716

 

  10367   Tue Aug 12 02:09:39 2014 ericqUpdateGeneralReasonable alignment restored

I took over the IFO, after Jenne's locking efforts, which included manual alignment, since the ASS was doing bad things. 

For whatever reason, the Yarm ASS TT gains needed to be flipped back to go in the right direction. I've restored the old BURT snap file, and the ASS seems to work for now.  

Furthermore, I added some FMs to the Yarm ASS to be able to ramp down gains, to be done as new offsets are ramped in, so that a smooth offset transition is possible. The new version of the script works reasonably, but could be smoother still... Once I iron this out, I'll do the same change to the Xarm, and update the buttons. 

In any case, I was able to run ASS on both arms; single arm lock maxed out at around 0.85, maybe because we're only getting 0.78 from the PMC and 16k from the MC? I then aligned and locked the PRM, then reentered the oplevs on all of the PRMI optics. Oddly, the ETMs were at single uRads on their oplevs.

With this arm alignment, I was able to get the green TRX to ~0.55, and thus the beatnote to around -25dBm, which is still lower than we'd like. I didn't touch the Y green alignment, though it is pretty bad, at transmission of below 0.2 when "locked" on the 00 mode. 

When I try to lock things, the initial ALS CARM and DARM locking seems to go fine, actuating on the ETMs for both DoFs, but ETMX is getting kicked during the resonance search every time. Maybe improving green alignment / increasing beatnote amplitudes will hopefully help some.

I'm leaving the interferometer with the PRM aligned, so that all optics (except SRM) are near the center of their oplev range. I'm curious as to what their variance will be over the next day; this can inform whether we need to improve the ETMY oplev's angular range or not. 

  10369   Tue Aug 12 14:29:01 2014 ericqUpdateGeneralReasonable alignment restored

I'm leaving the interferometer with the PRM aligned, so that all optics (except SRM) are near the center of their oplev range. I'm curious as to what their variance will be over the next day; this can inform whether we need to improve the ETMY oplev's angular range or not. 

 Here's an 12 hour minute-trend of all of the oplevs. The worst offenders are ITMY pitch and yaw, and ITMX pitch. 

Additionally, ETMY's yaw range is +-30urad, and here we see it wandering by 10 urad in a half day. We probably need more range.  

OLtrend.png

  10744   Mon Dec 1 20:12:52 2014 ericqUpdateModern ControlRebirth of CESAR / ESCOBAR

 I've uploaded a note at T1400735 about a new implementation of CESAR ESCOBAR ideas I've been working on. Please send me any and all feedback, comments, criticisms!

Using the things I talk about in there, I was able to have a time domain simulation of a 40m arm cavity transition through three error signals, without hardcoding the gains, offsets, or thresholds for using the signals. Some results look like this:

gssimSweep.pdf

I'm going to be trying this out on the real IFO soon...

  2068   Thu Oct 8 11:37:59 2009 josephbUpdateComputersReboot of dcuepics helped, c1susvme1 having problems

Power cycling c1dcuepics seems to have fixed the EPICs channel problems, and c1lsc, c1asc, and c1iovme are talking again.

I burt restored c1iscepics and c1Iosepics from the snapshot at 6 am this morning.

However, c1susvme1 never came back after the last power cycle of its crate that it shared with c1susvme2.  I connected a monitor and keyboard per the reboot instructions.  I hit ctrl-x, and it proceeded to boot, however, it displays that there's a media error, PXE-E61, suggests testing the cable, and only offers an option to reboot.  From a cursory inspection of the front, the cables seem to look okay.  Also, this machine had eventually come back after the first power cycle and I'm pretty sure no cables were moved in between.

 

  742   Sat Jul 26 15:09:57 2008 AidanUpdateComputersReboot of op440m

I was reviewing the PSL Overview screen this afternoon and op440m completely froze when I center-clicked on the REF CAVITY TRANSMISSION indicator. It was unresponsive to any keyboard or mouse control. The moon button had no effect to shut the machine down.

Called Alberto in and we logged into op440m from rosalba. From there we logged in as 'root' and run a shutdown script '/usr/sbin/shutdown -i S -g 1'. The medm screens started disappearing from the op440m display and we were eventually asked to enter System Maintenance Mode. From here we selected RUN LEVEL 5: "state 5: Shut the machine down so that it is safe to remove the power". Following this the machine turned itself off.

We powered it back on, logged back in as controls and restarted the medm screens. Everything seems to be running fine now.
Aidan.
  13935   Fri Jun 8 20:15:08 2018 gautamUpdateCDSReboot script

Unfortunately, this has happened (and seems like it will happen) enough times that I set up a script for rebooting the machine in a controlled way, hopefully it will negate the need to repeatedly go into the VEA and hard-reboot the machines. Script lives at /opt/rtcds/caltech/c1/scripts/cds/rebootC1LSC.sh. SVN committed. It worked well for me today. All applicable CDS indicator lights are now green again. Be aware that c1oaf will probably need to be restarted manually in order to make the DC light green. Also, this script won't help you if you try to unload a model on c1lsc and the FE crashes. It relies on c1lsc being ssh-able. The basic logic is:

  1. Ask for confirmation.
  2. Shutdown all vertex optic watchdogs, PSL shutter.
  3. ssh into c1sus and c1ioo, shutdown all models on these machines, soft reboot them.
  4. ssh into c1lsc, soft reboot the machine. No attempt is made to unload the models.
  5. Wait 2 minutes for all machines to come back online.
  6. Restart models on all 3 vertex FEs (IOPs first, then rest).
  7. Prompt user for confirmation to re-enable watchdog status and open PSL shutter.
  15071   Wed Dec 4 09:11:42 2019 YehonathanUpdateCDSReboot script

After the CDSs crashed we run the rebootC1LSC.sh script.

The script is a bit annoying in that it requires entering the CDSs' passwords multiple times over the time it runs which is long.

The resulting CDS screen is a bit different than what was reported before (attached). Also, not all watchdogs were restored.

We restore the remaining watchdogs and do XARM locking. Everything seems to be fine.

  15072   Wed Dec 4 12:13:10 2019 gautamUpdateCDSReboot script

It was way more annoying without a script and took longer than the 4 minutes it does now.

You can fix the requirement to enter password by changing the sshd settings on the FEs like I did for pianosa.

After running the script, you should verify that there are no red flags in the output to console. Yesterday, some of the settings the script was supposed to reset weren't correctly reset, possibly due to python/EPICS problems on donatella, and this cost me an hour of searching last night because the locking wasn't working. Anyway, best practise is to not crash the FEs.

Quote:

The script is a bit annoying in that it requires entering the CDSs' passwords multiple times over the time it runs which is long.

  1967   Fri Sep 4 16:09:26 2009 josephbSummaryVACRebooted RGA computer and reset RGA settings

Steve noticed the RGA was not working today.  It was powered on but no other lights were lit.

Turns out the c0rga machine had not been rebooted when the file system on linux1 was moved to the raid array, and thus no longer had a valid mount to /cvs/cds/.  Thus, the scripts that were run as a cron could not be called.

We rebooted c0rga, and then ran ./RGAset.py to reset all the RGA settings, which had been reset when the RGA had lost power (and thus was the reason for only the power light being lit).

 

Everything seems to be working now.  I'll be adding c0rga to the list of computers to reboot in the wiki.

  9562   Tue Jan 21 17:26:59 2014 JenneSummaryVACRebooted RGA computer and reset RGA settings

[Jenne, Steve]

Steve noticed that the RGA was not logging data and that not all the correct connection lights were on, and he wasn't able to run the "RGAset.py" script (in ...../scripts/RGA/) that sets up the proper parameters. 

I looked, and the computer was not mounting the file system.  I did a remote shutdown, then Steve went in and pushed the power button to turn the machine back on.  After it booted up, it was able to talk to the file system, so I started ..../scripts/RGA/RGAset.py .  The first 2 times I ran the script, it reported errors, but the 3rd time, it reported no communication errors.  So, now that the computer can again talk to the file system, it should be able to run the cronjob, which is set to take data at 4am every day.  Steve will check in the morning to confirm that the data is there.  (The last data that's logged is 22Dec2013, 4am, which is right around when Koji reported and then fixed the file system).

 

 

  14171   Mon Aug 20 15:16:39 2018 JonUpdateCDSRebooted c1lsc, slow machines

When I came in this morning no light was reaching the MC. One fast machine was dead, c1lsc, and a number of the slow machines: c1susaux, c1iool0, c1auxex, c1auxey, c1iscaux. Gautam walked me through reseting the slow machines manually and the fast machines via the reboot script. The computers are all back online and the MC is again able to lock.

  3931   Tue Nov 16 10:47:45 2010 AidanUpdateGreen LockingRebooted c1psl - added new GRNBEAT_FREQ channel

I restored C1:PSL-126MOPA_126MON to its original settings (EGUF = -410, EGUL = 410) and added a new calc channel called C1:LSC-EX_GRNBEAT_FREQ that is derived from C1:PSL-126MOPA_126MON. The calibration in the new channel converts the input to MHz.

grecord(calc, "C1:LSC-EX_GRNBEAT_FREQ")
{
        field(DESC,"EX-PSL Green Beat Note Frequency")
        field(SCAN, ".1 second")
        field(INPA,"C1:PSL-126MOPA_126MON")
        field(PREC,"4")
        field(CALC,"0.4878*A")
        }

I rebooted c1psl and burtrestored.

  7495   Sun Oct 7 12:11:00 2012 AidanUpdateComputersRebooted cymac0

I rebooted cymac0 a couple of times. When I first got here it was just frozen. I rebooted it and then ran a model (x1ios). The machine froze the second time I ran ./killx1ios. I've rebooted it again.

  7498   Mon Oct 8 09:45:28 2012 jamieUpdateComputersRebooted cymac0

Quote:

I rebooted cymac0 a couple of times. When I first got here it was just frozen. I rebooted it and then ran a model (x1ios). The machine froze the second time I ran ./killx1ios. I've rebooted it again.

For context, there's a is stand-alone cymac test system running at the 40m.  It's not hooked up to anything, except for just being on the martian network (it's not currently mounting any 40m CDS filesystems, for instance).  The machine is temporarily between the 1Y4 and 1Y5 racks.

  3446   Fri Aug 20 13:09:53 2010 josephbUpdateelogRebooted elog

I had to restart the elog again.

At this point, I'm going to try to get one of the GC guys to install gdb on nodus, and run the elog in the debugger, that way when it crashes the next time, I have some error output I can send back to the developer and ask why its crashing there.

  589   Sat Jun 28 23:23:50 2008 JohnUpdateComputersRebooting
All of the computers are now showing green lights.

Remaining problems:

Alignment scripts are failing with "ERROR: LDS - NDS server error #13"
I think this is a server transmission error.

Dataviwer shows all channels as zero.
  592   Sun Jun 29 14:53:02 2008 robUpdateComputersRebooting

Quote:
All of the computers are now showing green lights.

Remaining problems:

Alignment scripts are failing with "ERROR: LDS - NDS server error #13"
I think this is a server transmission error.

Dataviwer shows all channels as zero.


Fixed. Just started the testpoint manager on fb40m.


su
/usr/controls/tpman &
  4003   Wed Dec 1 12:02:49 2010 josephb, alexUpdateCDSRebuilding frame builder with latest code

Problem:

The front ends seem to have different gps timestamps on the data than the frame builder has when receiving them.

One theory is we have fairly been doing SVN checkouts of the code for the front ends once a week or every two weeks, but the frame builder has not been rebuilt for about a month. 

Current Action:

Alex is currently rebuilding the frame builder with the latest code changes.

It also suggests I should try rebuilding the frame builder on a semi-regular basis as updates come in.

 

 

  17079   Mon Aug 15 10:27:56 2022 KojiUpdateGeneralRecap of the additional measures for the outage prep

[Yuta Koji]

(Report on Aug 12, 2022)

We went around the lab for the final check. Here are the additional notes.

  • 1X9: The x-end frontend machine still had the AC power. The power strip to which the machine is connected was disconnected from the AC at the side of the rack. (Attachment 1)
  • 1X8: The vacuum rack still supplied the AC to c1vac. This was turned off at the UPS. (Attachment 2)
  • 1X6: VMI RFM hub still had the power. This was turned off at the rear switch. (Attachment 3)
  • PSL: The PSL door was open (reported above). Closed. (Attachment 4)
  • 1Y2: The LSC rack still had the DC power. The supplies were turned off at the KEPCO rack (the short rack). (Attachment 5)
    Note that the top-right supply for the +15V is not used. (The one in the empty slot got busted). We may need some attention to the left-most one in the second row. It indicated a negative current. Is this just the current meter problem or is the supply broken?
  • Control room: The CAD WS was turned off.

I declare that now we are ready for the power outage.

  2668   Thu Mar 11 17:51:04 2010 KojiUpdateSUSRecent status of SOSs

Jenne, Koji

Recent status of SOSs:

We completed one of the suspension (ITMY).

ITMX: 6 Magnets, standoffs, and guide rod glued / balance to be confirmed / needs to be baked
ITMY: 6 Magnets, standoffs, and guide rod glued / balance confirmed / needs to be baked
SRM: 6 Magnets, one standoff, and guide rod glued,  / waiting for the release from the gluing fixture.
PRM: one standoff, and guide rod glued / waiting for the magnet gluing. 

We think we solved all the problems for hanging the suspensions.

--- Magnet gluing fixture ---

  • There is the two kinds of fixtures. Neither does work propery in the original form!
  • The height of the side magnets should be finely adjusted by changing the teflon sheets beneath the optics in the fixture.
  • Be aware of the polarity of the fixture in terms of the side magnets
  • Wrongly glued magnets (and others) can be removed by a razor blade with some amount of acetone.
  • The pickle picker frequently knocks the magnets down during the release. Don't s be down in the dumps too much.

--- Suspending the mirror ---

  • The wire winches must be carefully attached to the suspension tower such that the wires are not streached during fastening the clamps.
  • There are a couple variations of the drawings for SOS. The one we have has #4-40 for the earthquake stops at the bottom.
    Zach and Mott made the EQ stops with the right size.
  16266   Thu Jul 29 14:51:39 2021 PacoUpdateOptical LeversRecenter OpLevs

[yehonathan, anchal, paco]

Yesterday around 9:30 pm, we centered the BS, ITMY, ETMY, ITMX and ETMX oplevs (in that order) in their respective QPDs by turning the last mirror before the QPDs. We did this after running the ASS dither for the XARM/YARM configurations to use as the alignment reference. We did this in preparation for PRFPMI lock acquisition which we had to stop due to an earthquake around midnight

  16268   Tue Aug 3 20:20:08 2021 AnchalUpdateOptical LeversRecentered ETMX, ITMX and ETMY oplevs at good state

Late elog. Original time 08/02/2021 21:00.

I locked both arms and ran ASS to reach to optimum alignment. ETMY PIT > 10urad, ITMX P > 10urad and ETMX P < -10urad. Everything else was ok absolute value less than 10urad. I recentered these three.

Than I locked PRMI, ran ASS on PRCL and MICH and checked BS and PRM alignment. They were also less than absolute value 10urad.

  1150   Fri Nov 21 16:03:50 2008 ranaHowToGeneralRecharging Batteries
I found some black & red "Ninja" alkaline AA batteries in the battery charger. This is dangerous. Please
do not put alkaline batteries in there, only Nimh. If you need help with the battery charger you can
come and talk to me or Rob and we can help you out getting started.
  14091   Fri Jul 20 18:30:47 2018 JonConfigurationAUXRecommend to install AUX PZT driver

I recently realized that the PLL is only using about 20% of the available actuation range of the AUX PZT. The +/-10 V control signal from the LB1005 is being directly inputted into the fast AUX PZT channel, which has an input range of +/-50 V.

I recommend to install a PZT driver (amplifier) between the controller and laser to use the full available actuator range. For cavity scans, this will increase the available sweep range from +/-50 MHz to +/-250MHz. This has a unique advantage even if slow temperature feedback is also implemented. To sample faster than the timescale of most of the angular noise,  scans generally need to be made with a total sweep time <1 sec. This is faster than the PLL offset can be offloaded via the slow temperature control, so the only way to scan more than 100 MHz in one measurement is with a larger dynamic range.

  16674   Wed Feb 16 15:19:41 2022 AnchalUpdateGeneralReconfigured MC reflection path for low power

I reconfigured the MC reflection path for low power. This meant the following changes:

  • Replaced the 10% reflection BS by 98% reflection beam splitter
  • Realigned the BS angle to get maximum on C1:IOO-MC_RFPD_DCMON when cavity is unlocked.
  • Then realigned the steering mirrors for WFS1 and WFS2.
  • I tried to align the light for MC reflection CCD but then I realized that the pickoff for the camera is too low for it to be able to see anything.

Note, even the pick-off for WFS1 and WFS2 is too low I think. The IOO WFS alignment does not work properly for such low levels of light. I tried running the WFS loop for IMC and it just took the cavity out of the lock. So for low power scenario, we would keep the WFS loops OFF.

 

  7690   Thu Nov 8 20:54:08 2012 Manasa, AyakaUpdateAlignmentReconfirming on IPPOS, IPANG and oplevs centering

Quote:

" We found that IPANG was not on its photodiode, but determined that it was centered on all of the in-vac mirrors, and that it was just a little bit of steering on the ETMY end out-of-vac table that needed to be done."

Manasa took photos of all test mass chambers and the BS chamber, so we can keep up-to-date CAD drawings. 

Oplevs and IPPOS/IPANG are being centered as I type.  Manasa and Ayaka are moving the lens in front of IPANG such that we have a slightly larger beam on the QPD.

 

The lens in front of IPANG on the out-of-vac table was moved to get a larger beam giving reasonable signals at the QPD.

IPPOS did not need much adjustment and was happy at the center of the QPD.

All oplevs but the ETMY were close to the center. I had to move the first steering mirror about half an inch on the out-of-vac table to catch the returning oplev beam from ETMY and direct it to the oplev PD.

* We have taken reasonable amount of in-vac pictures of ETM, ITM and BS chambers to update the CAD drawing.

 

  1907   Fri Aug 14 18:33:02 2009 ClaraUpdate Record of Accelerometer and Seismometer Movements

Rather than make a new elog post every time I move something, I'm going to just keep updating this Google spreadsheet, which ought to republish every time I change it. It's already got everything I've done for the past week-ish. The spreadsheet can be accessed here, as a website, or here, as a pdf. I will still post something nightly so that you don't have to search for this post, but I wanted to be able to provide more-or-less real-time information on where things are without carpet-bombing the elog.

  4123   Fri Jan 7 00:49:16 2011 JenneUpdateGreen LockingRecovered Xarm Green Lock, Preparation for Beat Note Measurement

[Kiwamu, Jenne]

We went this evening in search of a beat note signal between the Xarm transmitted green light and the PSL doubled green light. 

First, we removed our new ETMX camera (we left the mount so it should be easy to put back) from the other day.   We left the test masses exactly where they had been while flashing for IR, so even though we can no longer confirm, we expect that the IR beam axis hasn't changed.  We used the steering mirror on the end table to align the green beam to the cavity.  We turned on the loop to lock the end laser to the cavity, and achieved green lock of the arm.

Then we went to the PSL table to overlap the arm transmitted light with the PSL doubled light.  We made a few changes to the optics that take the arm transmitted light over to the PD.  We found that the arm transmitted light was very high, so we changed from having one steering mirror to having 3 (for table space / geometry reasons we needed 3, not just 2) in order to lower the beam axis.  We also found that the spot size of the arm transmitted beam was ~2x too small, so we changed the mode matching telescope from a 4x reducer to a 2x reducer by changing the 2nd lens from f=50mm to f=100mm (the first lens is f=200mm).  We made the arm transmitted beam and the PSL green beam overlap, but we saw no peak on the spectrum analyzer. 

We checked the temperature of the PSL and end lasers, and determined that we needed to adjust the set temp of the end laser.  However, we still didn't find any beat note.

We then tweaked the temperature of the doubling oven at the end station, to maximize the power transmitted, since Kiwamu said that that had worked in the past.  Alas, no success tonight.

We're stopping for the evening, with the success of reacquiring green lock of the Xarm.

  12611   Sat Nov 12 01:09:56 2016 gautamUpdateLSCRecovering DRMI locking

Now that we have all Satellite boxes working again, I've been working on trying to recover the DRMI 1f locking over the last couple of days, in preparation for getting back to DRFPMI locking. Given that the AS light levels have changed, I had to change the whitening gains on the AS55 and AS110 channels to take this into account. I found that I also had to tune a number of demod phases to get the lock going. I had some success with the locks tonight, but noticed that the lock would be lost when the MICH/SRCL boosts were triggered ON - when I turned off the triggering for these, the lock would hold for ~1min, but I couldn't get a loop shape measurement in tonight.


As an aside, we have noticed in the last couple of months glitchy behaviour in the ITMY UL shadow sensor PD output - qualitatively, these were similar to what was seen in the PRM sat. box, and since I was able to get that working again, I did a similar analysis on the ITMY sat. box today with the help of Ben's tester box. However, I found nothing obviously wrong, as I did for the PRM sat. box. Looking back at the trend, the glitchy behaviour seems to have stopped some days ago, the UL channel has been well behaved over the last week. Not sure what has changed, but we should keep an eye on this...

  16924   Thu Jun 16 18:23:15 2022 PacoConfigurationBHDRecovering LO beam in BHD DCPDs

[Paco, Yuta]

We recovered the LO beam on the BHD port. To do this, we first tried reverting to a previously "good" alignment but couldn't see LO beam hit the sensor. Then we checked the ITMY table and couldn't see LO beam either, even though the AS beam was coming out fine. The misalignment is likely due to recent changes in both injection alignment on TT1, TT2, PR2, PR3, as well as ITMX, ITMY. We remembered that LO path is quite constrained in the YAW direction, so we started a random search by steering LO1 YAW around by ~ 1000 counts in the negative direction at which point we saw the beam come out of the ITMY chamber yes


We proceeded to walk the LO1-LO2 in PIT mostly to try and offload the huge alignment offset from LO2 to LO1 but this resulted in the LO beam disappearing or become dimmer (from some clipping somewhere). This is WiP and we shall continue this alignment offload task at least tomorrow, but if we can't offload significantly we will have to move forward with this alignment. Attachment #1 shows the end result of today's alignment.

  9755   Wed Mar 26 22:22:43 2014 ManasaUpdateGeneralRecovery

The following that went unnoticed from yesterday were recovered today:

1. ETMX and ETMY 'misalign' scripts weren't running. Troubleshooting showed slow machines c1auxex and c1auxey weren't responding. The machines were reset.

2. PRM oplev gains were zero. Gain values were set looking back at the burt files.

3. X end PZT power supplies were turned ON and set to 100V.

4. X end doubler temperature was reset to the last optimal value on elog (36.35 deg).

 

Some hitches that should be looked into:

1. Check: ASS for X arm seems not quite doing its job. ETMX has to be moved using sliders to obtain maximum TRX and the arm alignment was seen to be drifting.

2. Check: Status of other slow machines and burt restore whichever needs one.

  9756   Thu Mar 27 10:34:39 2014 ericqUpdateGeneralRecovery

Quote:

1. Check: ASS for X arm seems not quite doing its job. ETMX has to be moved using sliders to obtain maximum TRX and the arm alignment was seen to be drifting.

ETMX ASC output was turned off for whatever reason. Switched it on, ASS is fine.

  10326   Sun Aug 3 17:19:32 2014 ericqUpdateGeneralRecovery efforts

[ericq, Jenne]

We both happened to come by today to fix things up.

When I arrived, the PMC was locked to a 01 mode, which I fixed. The PMC transmission is still worryingly low. MC locked happily. 

ETMX was getting odd kicks, the kind where a DC shift would occur suddenly, and then go away a few moments later. I turned off all dynamic coil outputs, and looked at the MON output of the SOS driver with a scope to try and see if the DAC or dewhitening was glitching, but didn't see anything... Meanwhile, Jenne fiddled with the TTs until we got beams on POP and REFL. (EDIT, JCD:  Useful strategies were to put an excitation onto TT2, and move TT1 until the scattered beam in the chamber was moving at the excitation frequency,  Find the edges of TT2 by finding where the scattered light stops seeing the excitation, and center the beam on TT2.  By then, I think I saw the beam on the PRM face camera.  Then, put a temporary camera looking at the face of PR2.  Using TT2 to center here got us the beam on the POP camera.)

We then walked PRM and the TTs around to keep those two camera beams and get the PRM oplev beam back on its QPD. At this point, ITMX was misaligned (by us), and ITMY aligned to get some recycled flashes into the Y-arm. Y-arm was locked to green, and we poked TTs to get better IR flashes. Misaligning PRM, we had Y-Arm flashes of ~0.7. From there, the michelson and then X-arm were roughly aligned. Both arms were seeing flashes of about 0.7, and the MICH fringes on the AS port look nice.

Frustratingly, the SUS->LSC communication for TRY and TRX isn't working, and could not be fixed by any combination of model or front-end restarting... Thus we haven't been able to actually lock the arms and run ASS. THIS IS VERY FRUSTRATING. 

Additionally, at the point where we were getting light back into the Yarm, the ITMX that were seen on Friday were happening again, tripping the watchdog. Also, something in the Yarm cavity is getting intermittently pushed around, as can be seen by the green lock suddenly wandering off. All of these suspension shenanigans seem to be independent of oplev damping. 

It troubles me that this whole situation is fairly similar to the last time we lost the input pointing (ELOG 10088)

In any case, we feel that we have gotten the IFO alignment to a lockable state.

  10327   Sun Aug 3 23:47:56 2014 KojiUpdateGeneralRecovery efforts

It's great that you guys found the beam.
Yes, ITMX kick and lost communication for TRY were the motivation of my CDS rebooting.

ELOG V3.1.3-