40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 311 of 344  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  12989   Fri May 12 18:45:04 2017 rebeccaUpdateCamerasMC2 Pics with Olympus

Raw and JPG formats of the pictures are saved on the Mac in the control room and at this link:

https://drive.google.com/open?id=0B9WDJpPRYby1c2xXRHhfOExXNFU 

The camera was mounted using the JOBE arm wrapped around a small heavy piece of metal. The lights were kept on, the camera was zoomed in as closely as possible (so the light would take up most of the frame), F number of 8 was used, and shutter speeds from 1/2 to 1/100 seconds were used. 

The pictures still look a bit blurry, probably because looking back at the details of the image, the focal length was 86.34m (as short of a focal length would be ideal, and Olympus is capable of going down to 1m).

Next steps include looking at the saturation in the pictures and setting up a more stable mount. 

  7854   Tue Dec 18 16:44:00 2012 rijuUpdate Photodiode transimpedance

Today I measured the dark current of the PDA10CF. The output of the PD was connected to the A channel of the network analyzer, when there was no light falling on it. The response is collected using GPIB.

I will upload the result shortly.

  14880   Mon Sep 16 11:55:58 2019 rikaUpdateIOOWFS loop measurements

[rika, aaron]

We aligned optics of WFS as it was. Now auto-locker is working to lock MC.

But it still doesn't lock. We notice that the c1lsc machine doesn't work. So we run rebootCILSC.sh.

 

Now we reset the hardware!

 

17:11

After reset, auto locking didn't work well. Gautum and Aaron reboot slow c1ioo. Then it works, and Gautam returned the MC to a good alignment.

We found the beam is not in the center of the QPD, we (turned off the MC autolocker and MC loop, then) realigned to make beam to get in to the QPD center. Afterwards we start auto locking.

With the WFS on, the maximum MC transmission we observe is 14,700 counts; after the transmission level stabilizes (MC_TRANS pit and yaw brought to 0), the MC transmission is only 14,200 counts. Perhaps the MC_TRANS QPD offsets need adjustment. We relieve the WFS servo of its DC offsets. This is the configuration we'll use for WFS loop measurements this week.

  14888   Tue Sep 17 10:47:44 2019 rikaUpdateIOOWFS loop measurements

[aaron, rika]

Once stop the auto-locker and realigned to make beam to get into QPD again.

After we lock MC, we took TFs from suspension MC1/2/3 PIT/YAW to WFS1/2 PIT/YAW. 

----- 

Diagnotics test tools

range: 7 Hz to 50 Hz

 avarage=61

Column 0: WFS2_PIT   1: WFS2_YAW   2:WFS1_PIT   3: WFS1_YAW   4: TRANCE_PIT   5:TRANCE_YAW 

-----

I'm wondering weather the MC1data I saved is correct, becouse I found the channel was changed when I exported MC2 data. So I took MC1 data again.

 

We got all data for TFs already.  Each data is devided to real part and imaginary part. Then we are arranging the datas to obtain TFs. 

TF of MC2 is attachiment 1. So tomorrow, I make other TF.

Quote:

[rika, aaron]

We aligned optics of WFS as it was. Now auto-locker is working to lock MC.

But it still doesn't lock. We notice that the c1lsc machine doesn't work. So we run rebootCILSC.sh.

 

Now we reset the hardware!

 

17:11

After reset, auto locking didn't work well. Gautum and Aaron reboot slow c1ioo. Then it works, and Gautam returned the MC to a good alignment.

We found the beam is not in the center of the QPD, we (turned off the MC autolocker and MC loop, then) realigned to make beam to get in to the QPD center. Afterwards we start auto locking.

With the WFS on, the maximum MC transmission we observe is 14,700 counts; after the transmission level stabilizes (MC_TRANS pit and yaw brought to 0), the MC transmission is only 14,200 counts. Perhaps the MC_TRANS QPD offsets need adjustment. We relieve the WFS servo of its DC offsets. This is the configuration we'll use for WFS loop measurements this week.

 

Attachment 1: MC2.pdf
MC2.pdf
  14896   Wed Sep 18 14:45:52 2019 rikaUpdateIOOWFS loop measurements

[aaron, rika]

Gettng TFs

In the data we got yesterday, we can see some filter's effect. 

But it is not good coherence above 10Hz, so we mesured again. And this time we save the data as xml file.

And also we chaned the frequency regions broader to watch corner frequency of suspension.

-----

 Diagnotics test tools

 range: 0.1 Hz to 100 Hz

 points: 120 

 Amplitude: 1000

----

but at low frequency, the mode maching cavity was unloked cause of too much shaking.

So, we saw single frequency TF, and searched the good amplitude.

 

First, I tried to get TF @0.1~1 Hz .

-----

0.1 to 1 Hz

points: 61 (I think it's too much becous it takes about an hour)

amplitude: 5

-----

The TFs and coherence of MC1/PIT to each QPD is below. [above window: coherence, below: TF]

During the mesurement, something happened @0.2-0.3Hz so I stopped it.

We found the coherence of WFS1P and WFS2Y is not good, but others are good.

we guess that it could come from alignment which made Q chainging to small.

 

Finaly, I also got the  .xml data of MC1P 1 Hz to 10 Hz. In this time,

-----

1 to 10 Hz

points: 41 

amplitude: 90

-----

 

Making matrics

Now we took single frequency 6 TFs (MC1/2/3 PIT/YAW) @7Hz (Because this frequency has good coherence in all channel).

Aaron wrote the script using dtt to making matrics. 

 

 

Quote:

[aaron, rika]

Once stop the auto-locker and realigned to make beam to get into QPD again.

After we lock MC, we took TFs from suspension MC1/2/3 PIT/YAW to WFS1/2 PIT/YAW. 

----- 

Diagnotics test tools

range: 7 Hz to 50 Hz

 avarage=61

Column 0: WFS2_PIT   1: WFS2_YAW   2:WFS1_PIT   3: WFS1_YAW   4: TRANCE_PIT   5:TRANCE_YAW 

-----

I'm wondering weather the MC1data I saved is correct, becouse I found the channel was changed when I exported MC2 data. So I took MC1 data again.

 

We got all data for TFs already.  Each data is devided to real part and imaginary part. Then we are arranging the datas to obtain TFs. 

TF of MC2 is attachiment 1. So tomorrow, I make other TF.

Quote:

[rika, aaron]

We aligned optics of WFS as it was. Now auto-locker is working to lock MC.

But it still doesn't lock. We notice that the c1lsc machine doesn't work. So we run rebootCILSC.sh.

 

Now we reset the hardware!

 

17:11

After reset, auto locking didn't work well. Gautum and Aaron reboot slow c1ioo. Then it works, and Gautam returned the MC to a good alignment.

We found the beam is not in the center of the QPD, we (turned off the MC autolocker and MC loop, then) realigned to make beam to get in to the QPD center. Afterwards we start auto locking.

With the WFS on, the maximum MC transmission we observe is 14,700 counts; after the transmission level stabilizes (MC_TRANS pit and yaw brought to 0), the MC transmission is only 14,200 counts. Perhaps the MC_TRANS QPD offsets need adjustment. We relieve the WFS servo of its DC offsets. This is the configuration we'll use for WFS loop measurements this week.

 

 

Attachment 1: Screenshot_from_2019-09-18_18-15-34.png
Screenshot_from_2019-09-18_18-15-34.png
  15   Thu Oct 25 22:02:58 2007 robRoutinePSLHEPAs maxed
In light of the SoCal fires, I turned the PSL HEPAs up to 100%.
  40   Wed Oct 31 15:22:59 2007 robConfigurationIOOMode Cleaner transfer function
I measured the transfer function of the input mode cleaner using a PDA255 and the ISS. First I put the PD in front of the ISS out-of-loop monitor diode and used an SR785 to measure the swept sine transfer function from the Analog IN port of the ISS to the intensity at the PD. Then I moved the PD to detect the light leaking out from behind MC2, using ND filters to get the same DC voltage, and measured the same transfer function. Dividing these two transfer functions should take out the response of the ISS and the PD, and leave just the transfer function of the MC. A plot of the data, along with a single-pole fit, are attached.

The fit is pretty good for a single pole at 3.79 kHz. There's a little wiggle around 9kHz due to ISS weirdness (as Tobin has not been giving it the attention it requires), but this shouldn't affect this result too much. Using the known MC length of 27.0955m, and assuming that MC1 and MC3 have a power transmissivity of 2000ppm and MC2 is perfectly reflecting, the total round trip loss should be about 300ppm. The fitted finesse is 1460.
Attachment 1: MCtf.pdf
MCtf.pdf
  67   Tue Nov 6 10:42:01 2007 robConfigurationIOOmode cleaner locked
Increased the power exiting the PSL by turning the half-wave plate after the MOPA, opened the PSL shutter, and aligned the mode cleaner to the input beam. It wasn't that hard to find the beam with the aperture open all the way on the MC2 camera. The transmitted power is now 2.9 arbitrary units, while the input power is 1.2 arbitrary units. Not sure yet if that's an increase or decrease in efficiency, since no one posted numbers before the vent. Also turned on the input-steering PZTs and saw a REFL beam on the camera.
  69   Tue Nov 6 15:36:03 2007 robUpdateLSCXARM locked
Easily, after resetting the PSL Uniblitz shutters. There's no entry from David or Andrey about the recovery from last week's power outage, in which they could have indicated where the procedure was lacking/obscure. Tsk, tsk.
  70   Tue Nov 6 15:37:34 2007 robConfigurationSUSrampdown script
/cvs/cds/caltech/scripts/SUS/rampdown.pl is now in the crontab for op340m, running every half-hour at 15&45. It checks the suspension watchdog trip levels, and reduces them by 20 if they are above 150.
  78   Wed Nov 7 13:54:44 2007 robConfigurationIOOMode Cleaner transfer function
I performed the same procedure described here, and re-measured the transfer function of the mode cleaner to see the effect of the drag-wiping. The results are attached in a pdf. We don't seem to have done any damage, but the improvements are barely measurable.

WhatThenNow
pole frequency3.789kHz3.765kHz
loss per optic99ppm91ppm
finesse14601470
trans86.7%87.7%
Attachment 1: mctf.pdf
mctf.pdf
  89   Fri Nov 9 17:33:33 2007 robConfigurationPSLISS

The 3.7 MHz is actually on the light. It's the beat between the 29.5 MHz sidebands and the 33.2 MHz sidebands. There are pads in the ISS PCB for a filter to notch this frequency--John is working on it.

I also found a 1.2 ND filter on the lens which focuses the beam on the ISS diodes. I replaced it with a 0.6 ND filter, which brought the ISS DC level (on the screen) up to ~4.2 (it saturates at 5). Once John finishes the filter we should be able to crank up the gain.
  90   Fri Nov 9 21:36:14 2007 robConfigurationPSLFSS
rob, rana

We looked at the FSS a bit today. The most we could get out of it with the gain sliders was a UGF of around 95kHz. After a bit of tweaking the waveplate after the AOM, this got up to ~115kHz. We should be able to get at least 500kHz. This system needs a fair amount of work.
  94   Mon Nov 12 14:09:19 2007 robDAQGeneraltpman dead on fb40m
The testpoint manager was dead on fb40m. I know I re-started it sometime after the power outage, so something must have killed it. If you get an error from DTT like
"diagnostic kernel does not support: testpoints", then log into fb40m as root, check for the tpman with a ps -ef | grep tpman. If it's not there, then run /usr/controls/tpman & and close the terminal window.
  95   Mon Nov 12 15:05:49 2007 robConfigurationPSLFSS

Spent a bit of time fiddling with the FSS again today. In a not-particularly-systematic manner, I raised the input-side of the 21.5MHz PC, adjusted the half-wave plate in front of it, touched up the RC alignment and the alignment onto the transmitted and reflected diodes. This got us a ~15% increase in
transmitted light, and I was able to push the UGF to 140kHz with the common gain slider at 30dB and the FAST gain slider at 22dB. The next options include adjusting the AOM setup, mode matching into the RC, and just increasing the pickoff fraction right from the getgo.
  96   Mon Nov 12 15:18:34 2007 robUpdatePSLISS

After John soldered a 3.7 MHz notch filter onto the ISS board, I took a quick TF and RIN measurement. The out-of-loop RIN is attached, including a dark noise trace, and with the gain slider at 10dB. The UGF is 35kHz with a phase margin of 30deg. John is currently doing a more thorough inspection, and will detail his findings in a subentry.
Attachment 1: ISS.png
ISS.png
  121   Wed Nov 21 14:31:41 2007 robUpdatePSLFSS twiddle

I `tweaked' the FSS path today. Here's what I did:

1) Shut down the FSS autolocker

2) Turn off FSS servo

3) Assume the beam coming back from the AOM is double-first-order, and don't make any changes large enough to lose it.

4) Tweak the alignment of these components to maximize the incident power on the RC reflected diode:

a) PBS before AOM
b) AOM
c) curved mirror after the AOM

5) Translate the AOM such that the beam moves away from the PZT, then when it levels off (no more power gains with movement),
move it back just a little bit so there's a teensy drop in power. This should but the beam as close to the edge as possible,
but whether or not it's the best place is still to be determined.

6) Lock the FSS, and align the mirrors into the frequency reference cavity.

After all this, the RC transmitted power went from .57 to .73 -- probably not a big enough change to account for the missing loop
gain, but we'll know more once the loop gets measured (after Alberto stops hogging the Agilent network analyzer).

Other possible routes include a systematic check of the upstream path (e.g., the Pockels cell) and just increasing the pickoff fraction for the FSS.
  124   Tue Nov 27 15:45:08 2007 robConfigurationPSLFSS loop

It's unclear (to me, at least) what was the end result of the FSS path tweaking before Thanksgiving. Today I measured the open loop gain, and it was still around 100kHz, even with the gain sliders maxed out, but it looked really crappy with a sharp cutoff around the UGF. Then, on a lark, I pushed around the "Input Offset Adjust" slider, which sums an offset into the signal coming out of the mixer. By moving this slider to 7V, I got the UGF to 500kHz with 45 deg of phase. That would be fine, and we could go offset hunting, but the same thing happens if one puts in a large negative value! I don't really understand what's going on, but it seems like weirdness in the electronics. Unfortunately the web interface to the conlog is not running (presumably because the `new' linux1 doesn't have its apache server running) and my command line conlog efforts have been stymied. So, I don't know what the historical settings of this offset are, but zero is definitely not a good setting right now. Here's a snapshot:

FSS
UGF: 500kHz
CG : 24dB
FG : 19dB
input offset: 7V
Phase Adjust: 1.09V
Phase Button: 0
RF Amp Adjust: 7.38V

margins:
phase: 45 deg
gain: 8dB
Attachment 1: FSSsmall.jpg
FSSsmall.jpg
  125   Tue Nov 27 15:47:17 2007 robConfigurationIOOMC loop
After the FSS running pretty quick, I checked the MC loop. I used TPA 1&2.

MC loop
UGF: 70kHz
Input Gain: 29dB
Boost Level: 2
phase: 40 deg
Attachment 1: MCsmall.jpg
MCsmall.jpg
  126   Tue Nov 27 16:18:58 2007 robConfigurationIOOMC loop
Reduced the common gain to 22dB in the mcup script, so that the WFS would not blow the lock. The above measure of the OLG was done without the mcWFS running, so may be a low estimate as compared to when the alignment is perfect.
  134   Wed Nov 28 17:41:34 2007 robUpdatePSLFSS again
I investigated the FSS a bit more today. I looked at the signals coming out of the FSS frequency reference, and saw that both the LO and PC drive were distorted, non-symmetric waveforms. In addition, the LO path had a 3dB attenuator, meaning the mixer was starved. I placed mini-circuits SLP-30 filters in both paths, and now both are nice sine waves. I also took out the 3dB att. With this work, and the CG slider maxed out at 30, the FSS open loop gain (for real this time) goes up to ~250kHz. Still needs more investigation.
  139   Thu Nov 29 11:10:54 2007 robOmnistructureVACRGAlogger sleeping
Without the RGA controller responding, the RGAlogger script just hangs. Rather than fix it, I just put it to sleep by commenting out the line in op440m crontab file. Once we get it running again, we'll move the cronjob to op340m.
  141   Thu Nov 29 15:17:53 2007 robConfigurationPSLISS

I put some ISS beam on the diode on the PSL table. In the previous layout, this was the monitor diode (and it's labeled monitor) but I plugged it into the sensor jack anyways so we can run with the loop closed for now; we can just switch the cables later. The reason the beam was unclear is because someone popped up a flipper mirror which redirects the beam from the ISS into an OSA.

With the ISS gain slider at 15 dB the UGF is around 40kHz.

Why do we have such short cables for the ISS diodes?
  145   Fri Nov 30 11:44:57 2007 robConfigurationElectronicsETMX oplev
In the interests of getting the Xarm alignment script working again, I reset the local damping gains for the test masses to their previous known working values (1), then I noticed that the ETMX oplev was dead. Since the scripts use the oplev motion as a readback for the optic motion, this means the script was basically blindly swinging the optics around. Some monkeying around with swapping HeNe power supplies eventually led to the conclusion that the power strip is funky, since the laser works when plugged into another power strip. Even weirder, the HeNe and the power supply indicator light have some sort of XOR relationship going on. When one works, the other doesn't. Steve will sort out this confusion later; we're good for now.
  146   Fri Nov 30 13:46:50 2007 robConfigurationElectronicsETMX oplev dead again

Quote:
In the interests of getting the Xarm alignment script working again, I reset the local damping gains for the test masses to their previous known working values (1), then I noticed that the ETMX oplev was dead. Since the scripts use the oplev motion as a readback for the optic motion, this means the script was basically blindly swinging the optics around. Some monkeying around with swapping HeNe power supplies eventually led to the conclusion that the power strip is funky, since the laser works when plugged into another power strip. Even weirder, the HeNe and the power supply indicator light have some sort of XOR relationship going on. When one works, the other doesn't. Steve will sort out this confusion later; we're good for now.


Ech. The HeNe quit again. Let's replace it and see what happens.
  175   Thu Dec 6 18:11:15 2007 robHowToComputer Scripts / ProgramsMaking DMF monitors

I was able to use the matlab compiler to compile a version of the linetracker written by Rana, and run the compiled version on mafalda.

I believe I made the necessary edits to our mDV config file so that it should be easy for others to follow these steps:

1) Write the DMF routine you want, as a matlab function (not a script).

2) If it runs correctly in matlab, then from the matlab command line compile
it using the -m flag (i.e., mcc -m myfun.m). You should run the
compiler from the directory where you want the executable to end up (don't use the mDV/extra
directory so it doesn't get all cluttered).

3) prior to running the resulting executable (which should be called simply myfun),
prepend the directories
/cvs/cds/caltech/apps/linux/matlab/bin/glnx86
/cvs/cds/caltech/apps/linux/matlab/sys/os/glnx86/

to the LD_LIBRARY_PATH enviroment variable. These directories must be prepended as the
versions that already exist in /usr/lib don't work; I'm loathe to do this in the cshrc.40m
for fear of later conflicts, so it will need to be done in some sort of shell script which
calls the matlab executable.
  180   Fri Dec 7 14:14:48 2007 robMetaphysicsComputer Scripts / Programstdsread problems on Solaris

tdsread has developed a strange new illness, whereby it cannot read EPICS values from two subsystems at once (e.g., getting an LSC and SUS value simultaneously). I thought this might have something to with the fact that both losepics and iscepics are running on the same box,
but the same thing happens with IOO EPICS records, so that's not the culprit.

This is new behaviour, and it's only happening on the solaris machines. I suspect some ENV/cshrc juju has caused it, as the tdsread executable is the same one from April, and I don't think our EPICS infrastructure has changed otherwise. In the near term we can either try running the scripts on linux, or modify the IFO scripts to not do these types of calls.
  184   Mon Dec 10 13:54:26 2007 robHowToComputer Scripts / ProgramsDon't blame the Matlab compiler

For human error. We should be careful to only run the compiler outside the mDV directory (thus placing the _mcr outside of the range the addpath command in the mdv_config files). Or maybe there's a smarter solution...
  224   Thu Jan 3 12:38:49 2008 robBureaucracyTMISore throat

Quote:

I did not feel anything wrong yesterday, but unfortunately I have a very much sore throat today. I need to drink warm milk with honey and rinse my throat often today. So far I do not have other illness symptomes (no fever), so I hope that this small disease will not last for a long time, but I feel that it is better for me to cure my sore throat today at home (and probably it is safer for others in 40-m).

I took yesterday the book "Digital Signal Processing", so I have it for reading at home.

Hope to see you tomorrow.


I've added a new category--TMI--for entries along these lines.
  240   Wed Jan 16 14:06:24 2008 robUpdateLSCmonday's locking
rob, tobin, johnnie

We did some locking work monday night, with decent progress. Working in the PRFPMI style, we managed to get through the part of the script that hands off the offset-CARM DOF to the MCL, but were not successful in engaging the AO path.

We also confirmed the problem with tdsread which prevent it from reading from multiple TLS (Three Lettered Subsystems) at the same time. Tobin traced this to a problem with the ezca library which tds uses, but it's not clear how to fix it. For now we just split the tdsread calls so that there are no multiple TLS calls. Tobin will report further on this.
  241   Wed Jan 16 14:09:45 2008 robUpdateLSCtuesday's locking

I got a little further with the locking (PRFPMI) last night, after discovering that the cable going from the CM board to the MC board was unplugged at the MC side. This explains why we weren't able to engage the AO path last night. Tonight, I got up to the point where DARM is handed off to OMC transmission, a step which repeatedly failed.
Eventually I realized that although all the lights are the green, the OMC Trans signal was not being updated in the LSC's memory. I suspect this is because the c1ass machine was powered down. Work continues.
  244   Thu Jan 17 14:13:20 2008 robUpdateLSCWednesday's locking
Incremental progress on locking yet again. This time the handoff of DARM to the OMC worked, and progress halted at handing off control of the common mode to REFL166.
  249   Fri Jan 18 15:31:47 2008 robUpdateLSCThursday's locking

rob, johnnie, andrey

On Thursday night we got the intereferometer fully locked in a power-recycled FPMI state. The obstacles included the REFL166 phase being wrong by 180 deg (because that's the correct phase for DRMI locking) and getting confused (again) by the "manual" mode dewhite switching at the ETMs. After turning on the dewhites and the MICH correction, we took the noise spectrum below.
Attachment 1: DARMnoise080118.png
DARMnoise080118.png
  252   Tue Jan 22 02:33:45 2008 robUpdateLSCDRMI work

0) The ETMY oplev needs work/centering

1) recentered DRMI oplevs

2) Did some light DRMI locking. Looked at the loops and the DD signals. The PODD signals look flaky; the beam may not be on the diode. MICH and PRC handoffs to DD signals were spotty, but not a total disaster. Changed the PD9 phase by 115 degs. Work continues on the DD_handoff subscript.

3) John says "There are ants everywhere."

4) Andrey is now versed in the arts of decimation.
  263   Fri Jan 25 08:55:26 2008 robConfigurationGeneralChanges to Dataviewer channels (XARM)

As a general rule,


Quote:
clicking random blue buttons chaotically


is not a good problem solving technique. It is thus now explicitly discouraged as an option in the LIGO 40m Lab.
  265   Fri Jan 25 10:14:35 2008 robConfigurationSUSChanges to Dataviewer channels (XARM)

Quote:

2) BAD NEWS. While "clicking the appropriate blue button" on the DAQ MEDM screen,
namely CODAQ_DETAIL,adl screen, I obviously clicked some blue button that I should not have clicked,
and as a result the signal in Dataviewer from the channel "C1:SUS-ITMX_POS" has disappeared (it is now a straight line).


Description of what has happened and of my wrong actions:
I had two channels opened in Dataviewer simultaneously (both "C1:SUS-ETMX_POS" and "C1:SUS-ITMX_POS"),
and after clicking some blue button on CODAQ_DETAIL,adl screen, the signal from "C1:SUS-ITMX_POS" became
a straight line,
while signal from "C1:SUS_ETMX_POS" continued to be a random noise.

I was scared that I made worse for the channels and for Dataviewer, and I started clicking random blue buttons chaotically hoping that it will restore the signal from "C1:SUS-ITMX_POS". Random clicking on arbitrary blue buttons did not return the signal.

As the channel "C1:SUS-ETMX_POS" works normally, I will be measuring Q-factors of ETMX tonight,
but it is obvious that someone else (Rana, Robert,Steve?) needs to restore the correct settings for "C1:SUS-ITMX_POS".

Moreover, as I was clicking chaotically all the blue buttons on CODAQ_DETAIL,adl screen, someone else (Rana, Robert, Steve?) will need to check somehow that I did not destroy signals from some other channels.

I apologize for the negative consequences of my channel adding,

but Rana asked me in the very beginning in September to let others know if I spoil something, so that others would be aware of it and could fix the problem.


I eventually resolved the situation by restarting the c1susvme1 processor, which had somehow got confused by the clicking random blue buttons chaotically. The data acquisition should be working again.
  280   Mon Jan 28 15:11:38 2008 robHowToDMFrunning compiled matlab DMF tools

I compiled Rana's seisBLRMS monitor, and it's now running on mafalda. To start your own DMF tools, here is a procedure:

1) build your tool in mDV, get it working the way you'd like.
2) Make a new directory /cvs/cds/caltech/apps/DMF/compiled_matlab/{your_new_directory} and copy the *.m file there.
3) Make the *.m in your new directory into a function with no args (just add a function line at the top)
4) compile it (from within a fully mDV-configured matlab) with mcc -m -R -nojvm {yourfile}.m at the matlab command line.
5) add a line corresponding to your new tool to the script /cvs/cds/caltech/apps/DMF/scripts/start_all
6) Run the start_all script referenced in part (5).

NB: Steps (4) and (6) must be carried out on mafalda.
  284   Tue Jan 29 14:56:39 2008 robUpdateDMFseisBLRMS 1.0

The seisBLRMS 1.0 program crashed at ~7:20 pm last night, so we didn't get data from overnight. It crashed when framecaching failed. I added
a try-catch-end statement around the call to dttfft2 to let the program survive this, then compiled it and started it on mafalda. After ~45 minutes, the compiled version encountered the same error, and while it didn't crash per se, after 20 minutes it still wasn't able to read data. We may have to dig deeper into the guts of mDV to make this stuff run more robustly.
  287   Wed Jan 30 20:39:31 2008 robUpdateDMFseisBLRMS


In order to reduce the probability of seisBLRMS crashing due to unavailability of data, I edited seisBLRMS.m so that it displays data from 6 minutes in the past, rather than 3. After compiling, this version ran for ~8 hours without crashing. I've killed the process now because it seems to interfere with alignment scripts that use ezcademod, causing "DATA RECEIVING ERROR 4608" messages. These don't cause ezcademod to crash, but so many of them are spit out that the scripts don't work very well. I guess running DMF constantly is just making the framebuilder work too hard with disk access. In the near term, we can maybe work around this by having DMF programs check the AutoDithering bit of the IFO state vector, and just not try to get data when we're running these sorts of scripts.
  291   Fri Feb 1 12:37:39 2008 robUpdateDMFseisBLRMS trends

Here are DV trends of the output of seisBLRMS over the last ~36 hours (which is how long it's been running), and another of the last 2 hours (which show the construction crew taking what appears to be a lunch break).
Attachment 1: seis36hours.png
seis36hours.png
Attachment 2: seis2hours.png
seis2hours.png
  307   Sun Feb 10 21:43:16 2008 robConfigurationIOOMC alignment tweaked

I adjusted the alignment of the free hanging mode cleaner to best transmit the PSL beam.
  309   Mon Feb 11 22:44:29 2008 robConfigurationDAQChange in channel trending on C1SUS2

I removed the MC2 optical lever related channels from trends, and the SRM POUT and YOUT (as these are redundant if we're also trending PERROR and YERROR). I did this because the c1susvme2 processor was having bursts of un-syncy lateness every ~15 seconds or so, and I suspected this might interfere with locking activities. This behaviour appears to have been happening for a month or so, and has been getting steadily worse. Rebooting did not fix the issue, but it appears that removing some trends has actually helped. Attached is a 50 day trend of the c1susvme2 sync-fe monitor.
Attachment 1: srm_sync.png
srm_sync.png
  310   Tue Feb 12 13:53:27 2008 robOmnistructureVACReturn of the RGA

The new RGA head was installed a few days ago. I just ran the RGAlogger script to see if it works, which it does. I also edited the crontab file on op340m to run the RGAlogger script every night at 1:25 AM. It should run tonight.
Attachment 1: RGA-080212.png
RGA-080212.png
  311   Tue Feb 12 16:18:29 2008 robConfigurationComputer Scripts / Programsautoburt cron moved to op340m

I moved the autoburt cron job from op440m to op340m. For some reason, burtrb requires gcc to run (I gather it uses the C-preprocessor to parse input files), so I had to install that on op340m to get it to work properly.

There are no more cron jobs running on op440m now.
  312   Tue Feb 12 16:34:07 2008 robDAQDMFseisBLRMS 1.1
The compiled version of seisBLRMS had been running ~2 weeks without crashing as of last night, when I killed it
so it wouldn't interfere with alignment scripts.  I added an EPICS channel C1:DMF-ENABLE, and updated the DMF
executables to check this channel while running.  So far it seems to work.  When you're running alignment acripts,
simply click the DISABLE button on the C1DMF_MASTER.adl screen, and then re-ENABLE when the scripts finish. 
It's not clear why this is necessary though.  Theories include the constant disk access is keeping the
framebuilder busy, reducing its ability to deal with ezcademod commands and DMF programs just flooding the
network with so much traffic that ezcademod-related packets run late and get ignored.

Also, for reasons of aesthetics, I changed the data delay from 6 minutes to 5 minutes.  We'll see if that's enough.
  313   Tue Feb 12 16:39:52 2008 robUpdateLockingreport

Did some locking work on DRFPMI on sunday and (with John) on monday nights. So far progress has not been terribly encouraging.

Problems include the DD_handoffs not working and the CARM->MCL handoff not working so well. To get around the DD signals trouble, I decided for now to just ignore 67% of the DD signals. We should be able to run with PRC & MICH on single demod signals, and SRC on a DD signal. This seems to work well in a DRMI state, and it also works well in a DRMI+2ARMs state.

The CARM->MCL handoff actually works, but it doesn't take kindly to the AO path and it doesn't work very stably. I guess this was always the most fragile part of the whole locking procedure, and it's fragility is really coming to light now. Investigation continues.
  316   Thu Feb 14 15:04:53 2008 robDAQDMFDMF delay

Sometime ago I edited seisBLRMS to keep of track of how long it was taking to write RMS data (that is, the delay between the accelerometer data and the write of the EPICS rms data). Here's a plot of that info, showing how the delay increases over time. I think this indicates a logical flaw in the timing of the seisBLRMS program, which sort of relies on everything running well consistently; this should not be difficult to fix. I'll maybe try increasing the delay to ~10 minutes, and making it relatively inflexible.
Attachment 1: DMFdelay.png
DMFdelay.png
  317   Thu Feb 14 15:05:18 2008 robDAQDMFseisBLRMS 1.1
> 
> Also, for reasons of aesthetics, I changed the data delay from 6 minutes to 5 minutes.  We'll see if that's enough.

5 minutes didn't work.  
  333   Fri Feb 22 11:11:00 2008 robUpdateElectronicsREFLDD problem found

I used a network analyzer that actually works to find a problem in the REFLDD electronics chain. There was loose (=bad) SMA-BNC adaptor on the output of channel one of the HP RF Amplifier. It worked intermittently, so going onto the ISCT and fiddling with cables could sometimes temporarily fix the problem. The bad adaptor has been given to Andrey to discard.
  334   Fri Feb 22 11:13:15 2008 robUpdateElectronicsRF Monitor (StocMon)

Quote:
It took some times because the written procedure to start the chiller is not very precise.


It is actually very precise. Precisely wrong.
ELOG V3.1.3-