40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 260 of 337  Not logged in ELOG logo
ID Date Author Type Category Subject
  3884   Wed Nov 10 02:51:35 2010 yutaSummaryIOOlimitation of current MC aligning

(Suresh, Yuta)

Summary:
  We need MC to be locked and aligned well to align other in-vac optics.
  We continued to align the incident beam so that the beam passes the actuation nodes of MC1 and MC3.
  From the previous measurement, we found that beam height at IM1 has to be increased by ~3cm.
  Today, we increased it by ~1cm and achieved about 1/3 of the required correction.
  But we cannot proceed doing this because the beam is hitting IM1 at the edge already.

What is the goal of this alignment?:
  If the beam doesn't hit MC optics in the center, we see angle to length coupling, which is not good for the whole interferometer.
 
  Also, if the beam is tilted so much, transmitted beam though MC3 cannot go into FI at right after MC3.
  Say, FI has an aparture of 3mm and MC3-FT distance is 300mm. The beam tilt should be smaller than 3/300 rad. MC1-MC3 distance is 200mm, so the displacement at each mirror should be smaller than ~1mm.
  1mm is about 7% (see Koji's elog #2863) TO_COIL gain imbalance in A2L measurement.
 
  We are currently assuming that each coils are identical. If they have 5% variance, it is meaningless to try to reduce the beam displacement less than ~5%.

  So, we set the goal to 7%.

What we did:

  1. Leveled the MC table.

  2. Measured the table height using DISTO D3 laser gauge.
    PSL table 0.83m (+-0.01m)
    OMC table 0.82m
    MC table  0.81m

  3. Using the last steering mirror(SM@PSL) and IM1, tilted the beam vertically

Result:

MCalignNov9.png

  At t=0 (this morning), the beam tilt was ~40%/(MC1-MC3 distance). Now, it is ~30%/(MC1-MC3 distance).
  30%/(MC1-MC3 distance) is ~5/200 rad.

Plan:

 We have to somehow come up with the next story. Too much vertical tilt. What is wrong? Table leveling seems OK.
 - measure in-vac beam height
 - maybe OSEMs are badly aligned. we have to check that.

  3883   Tue Nov 9 05:40:12 2010 yutaSummaryIOOMC aligning going on

(Suresh, Yuta)

Background:
  Last week, we reduced the common mode displacement of the beam through MC1 to MC3. 
  Next work is to tilt the beam and center it.

What we did:
  1. Changed the offset going into 1201 Low Noise Amplifier(1201 is for adding +5V offset so that the feedback signal will be in the range of 0-10V)
  2. Using the last steering mirror(SM@PSL) and IM1, tilted the beam
  3. As the beam height changed alot(~0.5cm higher at IM1), MC1 reflection could not reach MCREFL PD. So, we tilted the mirror just after MC1, too.

Result:
MCalignNov9.png

Plan:

  - continue to tilt IM1 in small increments in order to reduce PIT/YAW to length coupling
      If large increments, it takes so much time re-aligning MC to get flashing!

By the way:

    The signal we kept saying "MCL" was not the error signal itself. It was a feed back signal(output of the mode cleaner servo board). The cable labeled "MC REFL" is the error signal. Compare MEDM screen C1IOO_MC_SERVO.adl and the mode cleaner servo board at 1X2. You will be enlightened.

Quote (from elog #3857):

4. Disconnected the cable labeled "MC OUT1" at 1X2 (which is MCL signal to ADC) and put MC2_ULCOIL output directly using long BNC cable.

 

  3882   Mon Nov 8 18:30:33 2010 SureshUpdateIOOMC Trans Mon QPD gain increased by 50x

Increased the transimpedance gain of the MC-Trans-Mon QPD ckt

The gain of this QPD was insufficient to see the light transmitted through the MC2.  The resulting voltage output was about  10 steps of the 16-bit ADC card.  As the input power, which is currently held at about 40mW may be increased to the vicinity of 2W (total output of the NPRO) we would have 500 ADC steps.  But the dynamic range of the ADC is 64k and  increasing the gain of this QPD ckt by a factor of 50 would enable us to utilise this dynamic range effectively.  However as we do not need a response faster than 10Hz from this ckt its response time has been limited by increasing the feedback capacitance value.

The ckt diagram for the QPD ckt is D980325-Rev-C1  .  The particular unit we are dealing with has the Serial No. 110.  The resistors R1, R2, R3, R4 are now 499 kOhm.  As per the guidelines in the ckt diagram, we increased the capacitance values C3,C4,C5,C6 to 2.2 nFThe current cut off frequency for the MC-Trans-Mon is 145 Hz (computed).

Initially, while reassembling the QPD unit, the IDC 16 connector to the ckt board was reversed by mistake and resulted in the OP497 chip over-heating.  Consequently one of the opamps on the chip was damaged and showed monotonously increasing ouput voltage.  Todd Etzel gave us a spare OP497 and I replaced the damaged chip with this new one. The chips are also available from  Newark Stock No. 19M8991 . The connector has been marked to indicate the correct orientation. The ckt was checked by temporarily connecting it in the place of the PRM Optical lever QPD.  It worked fine and has been put back in its place at the MC2 Transmission.  The QPD was wiped with a lens tissue+Methanol  to remove dust and finger prints from its surface.

It may need to be repositioned since the beam would have shifted under the MC realignment procedure.

 

 

 

  3881   Mon Nov 8 16:03:46 2010 kiwamuUpdateGreen Locking80MHz VCO : PLL open loop looks good

Quote:

I measured the open loop transfer function of the 80MHz VCO's PLL while locking it to Marconi.

 

Bad; there should be a passive ~1 MHz LP filter between the mixer and anything that comes after. The SR560 + mixer does not equal a demodulator.

  3880   Mon Nov 8 14:30:15 2010 josephb, yutaUpdateCDSAdded LIGONDSIP setting to cshrc.40m

We added the following line to the cshrc.40m file in the 64-bit linux and 32-bit linux sections:

setenv LIGONDSIP fb

This allows codes like tdsdmd to work properly on the linux machines (seemed to already work fine on the solaris op440m without this change).

  3879   Mon Nov 8 10:48:58 2010 kiwamuUpdateGreen Locking80MHz VCO : PLL open loop looks good

I measured the open loop transfer function of the 80MHz VCO's PLL while locking it to Marconi.

 This measurement is for a health check and a characterization of the PLL

The transfer function looks good, it agrees with the designed filter shape.

 


(measurement setup) 

vco_pll.png

 The frequency of Marconi is set to 79.5MHz which is the center frequency of the VCO.

The signal from Marconi is mixed down with the VCO signal at a mixer ZLW-3SH.

Then the demodulated signal goes to a 80MHz LPF to cut off high frequency components.

And it goes through a control filter which has 1Hz pole and 40Hz zero (see this entry).

The 80MHz LPF, the controls filter, the VCO and the RF amplifier are all built in the box.

 

 In order to measure the open loop transfer function I inserted SR560 before the 80MHz LPF.

Using T-splitters the input and the output of SR560 are connected to a spectrum analyzer SR785.

 

(results)

 VCO_PLL.png

 Exciting the system using a source channel of SR785, I measured the open loop transfer function.

The unity gain frequency was measured to about 20 kHz.

It agrees with the designed filter shape (though the gain factor is a little bit underestimated).

Apparently there is a phase delay at high frequency above 10kHz, but it is okay because the phase margin is quite acceptable up to 100kHz.

 

However I found that the control range was quite narrow.

The PLL was able to be kept in only +/- 1MHz range, this fact was confirmed by shifting the frequency of Marconi during it's locked.

I will post another elog entry about this issue.

 


 (notes)

 Marconi power = 6dBm

 VCO power after RF amp. = -0.6 dBm

 Marconi frequency = 79.5 MHz

 Phase detection coefficient = 0.4 V/rad (measured by using an oscillo scope)

 

  3878   Mon Nov 8 10:37:14 2010 KojiUpdateIOOThe 10% pick-off for MCREFL was replaced to a HR mirror

As MC2 Trans mon QPD is temporary removed for fixing, we needed a reference for the MC alignment.

I replaced the 10% pick-off in the MCREFL path to the HR mirror.
Now the MCREFL DC with MC unlock is ~2.2, while it is ~0.29 in lock.
i.e. The visibility is 87%.

This means that the MCWFS were disabled for the moment.

  3877   Sat Nov 6 16:13:14 2010 ranaSummaryCDS40m computer slow down solved

As part of the effort to debug what was happening with the slow computers, I disabled the auto MEDM snapshots process that Yoichi/Kakeru setup some long time ago:

https://nodus.ligo.caltech.edu:30889/medm/screenshot.html

We have to re-activate it now that the MEDM screen locations have been changed. To do this, we have to modify the crontab on nodus and also the scripts that the cron is calling. I would prefer to run this cron on some linux machine since nodus starts to crawl whenever we run ImageMagick stuff.

Also, we should remember to start moving the old target/ directories into the new area. All of the slow VME controls are still not in opt/rtcds/.

  3876   Sat Nov 6 07:26:54 2010 yutaSummaryIOOreduced common mode displacement of the beam through MC1 to MC3

(Koji, Suresh, Yuta)

Summary:

  We need MC to be locked and aligned well to align other in-vac optics.
  By using a new python script A2L.py(see elog #3863), we are measuring A2L coupling and centering the beam.
  Tonight's goal was to reduce common mode displacement of the beam through MC1 to MC3, and we succeeded.

Strategy of beam centering:

  We first ignore the beam position at MC2 and focus on MC1,MC3. If MC1,MC3 alignments are given, MC2 alignment is determined.

  For MC1 and MC3, we first reduce the common mode displacement using the last steering mirror at PSL table.
  The last steering mirror makes translation of the incident beam because it is far (~m) from the MC.
  So,
    1. Rotate the steering mirror nob a little
    2. Lock MC so that MC beam axis will be the same as the incident beam axis
    3. A2L measurement
    4. To 1-3 over until the beam crosses MC1 center to MC3 center axis
        The amount of vertical/horizontal displacements of the beam spot at MC1 and MC3 should be the same.
        From our convention, for vertical, MC1 and MC3 should have opposite sign. For horizontal, same sign. (see picture below)

Result:
A2LMCalign.png
 
  From the A2L measurement, now the beam spot is lower right at MC1 and upper right at MC3.
 

  The directions of the beam spot motion agree with the steering mirror tilts.
  Also, the amount of the motion seems reasonable.
    1 tooth rotation of the steering mirror nob makes ~1e-3 inch push which equals to ~0.5mrad rotation.
    The steering mirror to MC is like ~2m and 0.5mrad mirror tilt makes ~2mm displacement at the MC optics.
    2mm displacement is ~15% at the mirror (see Koji's elog #2863;note that coil-coil distance is 1/sqrt(2) of the mirror diameter).
    The measured vertical spot motion is ~15%/1tooth. Horizontal is sqrt(2) times bigger because of the angle of the MC1, MC3 and they are about that much, too.

Plan:
 - Use IM1 to make beam tilt and finally center the beam
 - Improve the script so that it features weighting in fitting
 - Write a script that balances actuation efficiency of the 4 coils.
     We are currently assuming that 4 coils are well balanced.
     In order to do the balancing, we need to balance OSEMs too.

  3875   Sat Nov 6 01:54:15 2010 FrankSummaryComputersvirus definition file update on laptop for dinocam

i took some pictures with the dinocam this afternoon. I used the laptop computer next to it using wireless lan connection to the caltech network to send the pictures to me.

The installed anti virus software was bitching about the old database and wanted to update that. As the installed virus definition database was from mid last year i agreed and started downloading the update. As the file was huge (~100MB) it wasn't finished when i left. computer is still running and probably waiting for instructions.

Will come back on the weekend to finalize the new virus definition file database installation.

  3874   Sat Nov 6 00:49:04 2010 KojiUpdateIOOIMC table work

[Suresh, Koji]

- Removed MCT optics in the IMC chamber

- Rotated MC1 and MC3 in clock-wise to debias the YAW bias offsets (-5V and -8V to -1.5V and -0.5V).

- Adjusted insertion of the MC1 OSEMs so as to have the outputs of about 1.0V.

- Locked to TEM00. Trying to get the beams at the center of the mirror using Yuta's A2L.

  3873   Fri Nov 5 23:05:43 2010 ranaConfigurationIOOioo.db file changed in c1iool0 to get back MC TRANS

 

We like to have the MC TRANS channels so that we can run all of our old scripts and trends on it. This is the usual BROWN

channel that's on the LockMC screen. Its also the thing that we use for thresholding to activate the MC Autolocker Daemon.

I modified the ioo.db file in the target/c1iool0/ directory so that the MC_TRANS_SUM, _P, and _Y channels are all now just

CALC records of the MC2 OL channels (where the calculation is MC_TRANS_SUM = MC2 OL_SUM + 0.001, etc.). I then

rebooted c1iool0 a few times to get the syntax right. It SEEMS to be working now. I'm sure that this won't effect anything.
I've committed the new file to the SVN repo. Once Suresh is done hacking the QPD circuit, we can set the threshold in the Autolocker.

  3872   Fri Nov 5 21:49:12 2010 ranaSummaryCDS40m computer slow down solved

Quote:

Problem:

The 40m computers were responding sluggishly yesterday, to the point of being unusable.

Cause:

The mx_stream code running on c1iscex (the X end suspension control computer) went crazy for some reason.  It was constantly writing to a log file in /cvs/cds/rtcds/caltech/c1/target/fb/192.168.113.80.log.  In the past 24 hours this file had grown to approximatel

The moral of the story is, PUT THINGS IN THE ELOG. This wild process is one of those things where people say 'this won't effect anything', but in fact it wastes several hours of time.

  3871   Fri Nov 5 19:33:18 2010 JenneUpdateElectronicsThe beginnings of the new phase of the RF work

Joon Ho and I took a look at the RF stuff that Alberto left, and we determined that we've got most everything that we need.  On Monday, Joon Ho will list off the stuff that we're missing, and we'll have Steve order it.

Joon Ho also replaced the temporary front panel to the RF generation box with Alberto's fancy new panel.  Pics are here (although you have to sign in as foteee to see them). 

Work on the frequency distribution box will continue on Monday.

  3870   Fri Nov 5 16:40:22 2010 josephb, alexUpdateCDSc1ioo now has working awgtpman

Problem:

We couldn't set testpoints on the c1ioo machine.

Cause:

Awgtpman was getting into some strange race condition.  Alex added an additional sleep statement and shifted boot order slightly in the rc.local file.  This apparently is only a problem on c1ioo, which is a Sun X4600.  It was using up 100% of a single CPU for the awgtpman process.

Status:

We now have c1ioo test points working.

Future:

Need to examine the startc1ioo script and see if needs a similar modification, as that was tried at several points but yielded a similar state of non-functioning test points. For the moment, reboot of c1ioo is probably the best choice after making modifications to the c1ioo or c1x03 models.

Current CDS status:

MC damp dataviewer diaggui AWG c1ioo c1sus c1iscex RFM Sim.Plant Frame builder  TDS
                     
  3869   Fri Nov 5 15:20:18 2010 josephb, alexSummaryCDS40m computer slow down solved

Problem:

The 40m computers were responding sluggishly yesterday, to the point of being unusable.

Cause:

The mx_stream code running on c1iscex (the X end suspension control computer) went crazy for some reason.  It was constantly writing to a log file in /cvs/cds/rtcds/caltech/c1/target/fb/192.168.113.80.log.  In the past 24 hours this file had grown to approximately 1 Tb in size. The computer had been turned back on yesterday after having reconnected its IO chassis, which had been moved around last week for testing purposes - specifically plugging the c1ioo IO chassis in to it to confirm it had timing problems.

Current Status:

The mx_stream code was killed on c1iscex and the 1 Tb file removed.

Computers are now more usable.

We still need to investigate exactly what caused the code to start writing to the log file non-stop.

Update Edit:

Alex believes this was due to a missing entry in the /diskless/root/etc/hosts file on the fb machine.  It didn't list the IP and hostname for the c1iscex machine.  I have now added it.  c1iscex had been added to the /etc/dhcp/dhcpd.conf file on fb, which is why it was able to boot at all in the first place.  With the addition of the automatic start up of mx_streams in the past week by Alex, the code started, but without the correct ip address in the hosts file, it was getting confused about where it was running and constantly writing errors.

Future:

When adding a new FE machine, add its IP address and its hostname to the /diskless/root/etc/hosts file on the fb machine.

  3868   Fri Nov 5 14:06:19 2010 yutaUpdateIOOtried to align MC by A2L measurement

(Suresh, Kiwamu, Yuta)

Summary:
  Lastnight, we locked the MC and tried angle to length(A2L) measurement using my new python script (see elog #3863).
  Although the amount of position script shows looks too big, the response seemed somewhat reasonable.
  Using the results of A2L measurement, we managed to reduce the displacement from the center of the MC optics, but we lost TEM00 mode after changing the incident beam direction and PMC lock got off .
  We restored the alignments and now it is 00, but the displacements got worse than the best we achieved last night.

  I think I have to rethink how to align MC. Even if I could somehow get exact position of the beam, how to align the beam to the center of the optics?

What we did:
  1. At first we tried to align by changing the direction of the incident beam. We found that A2L.py shows opposite direction(lower <-> upper). It was because of my misunderstanding and we agreed that the direction is opposite.

  2. Aligned MC optics without changing the direction of the incident beam. We could understand which directions decrease the displacements from the center, and managed to decrease them.

  3. There seemed to be a limit in aligning the MC optics without changing the incident beam direction. So, we started to change the incident beam direction again by steering mirrors at PSL table.

  4. During the change, PMC lock got off. We restored it, but we lost MC's 00 mode.

  5. We restored MC 00 mode, and measured the final A2L. The result was worse than we achieved by step #2.

Result:
  The final result from last night using my script was as follows;

  MC1 MC2 MC3
vertical 36% -19% 19%
horizontal 49% 6% -37%

  % is the length compared to the half of coil to coil length. Low / right are positive.
  We can see the beam position got better by looking at the monitor from MC2, and the A2L measurement result agrees with that.

  Here's some pictures from the measurement last night. Each plots are not taken at the same time.
A2LmeasurementFigures.png
   (It was painful using slow computers to make measurement. The StripTool graph shows straight lines when computers got frozen)

Plan:
 - Plan a strategy
 - The script needs self-estimation of the measurement. Now, the script fits the plot assuming every data has the same error.
 - When the beam is near the center, the signal gets smaller and the result will be unreliable. One thing I can do is to change TO_COIL gains radically so that the axis of rotation go far from the center.

  3867   Fri Nov 5 09:08:14 2010 steveUpdateSUSepoxy

Physical Electronics: Vac-Seal #288-6000 arriving Monday. Our last bag used last week had a p/n 1002003 with expiration date   .....2009 ? and it was stored in the

refrigerator all times. We are getting 68 small bags.

We should have precision gluing notes of epoxies/procedures used on our sus upgrade.

Attachment 1: 11081001.PDF
11081001.PDF
  3866   Thu Nov 4 19:26:51 2010 SureshUpdateLockingChanges to the Video MUX reversed

All the temporary changes to the video cables and the video MUX ( 3843 ) have been reversed and the system returned to its original state.

  3865   Thu Nov 4 19:00:57 2010 SureshUpdateLockingFibre coupling 1064nm light at the south-end table

The Fluke Visual Fault locator (Visifault) arrived and I used it to couple 1064nm light into the single mode fibre at the south-end-table.

Procedure used:

When the output end of the fiber is plugged into the Visifault the light emerges from at the south end (input side for 1064nm).  This light is collimated with the fiber coupler at that end and serves as a reference for the optical axis along which the 1064 light must be directed.  Once the two beams (red and 1064) are overlapped with the beam steering mirrors, the Visifault was disconnected from the fiber and the  fibre output ( 1064 at the PSL table) is maximized by walking the beam at the input end and adjusting the collimation at the input.

The output of the fiber has been collimated with a fiber coupler.

7.5mW are incident on the input end and 1.3mW have been measured at the output.    This output power is adequate for the observing the beats with PSL NPRO.

 

 

 

  3864   Thu Nov 4 17:57:27 2010 steveUpdateGeneralBeamScanner is working again

Koji, Suresh and Steve,

The beam scanner is back from repair.  Koji and Suresh helped to move the I/O address jumpers on the interface card from default position  300 to 320

It is working again.

Attachment 1: P1070024.JPG
P1070024.JPG
  3863   Thu Nov 4 17:53:29 2010 yutaUpdateCDSprimitive python script for A2L measurement

Summary:
  I wrote a python script for A2L measurement.
 Currently it is really primitive, but I tested the basic functionality of the script.

 We already have A2L script(at /cvs/cds/rtcds/caltech/c1/scripts/A2L) that uses ezlockin, but python is more stable and easy to read.

A2L measurement method:
  1. Dither a optic using software oscillator in LOCKIN and demodulate the length signal by that frequency.
  2. Change coil output gains to change the pivot of the dithering and do step 1.
  3. Coil output gain set that gives the smallest demodulated magnitude tells you where the current beam spot is.

  Say you are dithering the optic in PIT and changing the coil gains keeping UL=UR and LL=LL.
  If the coil gain set UL=UR=1.01, LL=LR=-0.99 gives you demodulated magnitude 0, that means the current beam spot is 1% upper than the center, compared to 1/2 of UL-LL length.
  You do the same thing for YAW to find horizontal position of the beam.

Description of the script:
  Currently, the script lives at /cvs/cds/caltech/users/yuta/scripts/A2L.py
  If you run;
     ./A2L.py MC1 PIT
  it gives you vertical position of the beam at MC1.

  It changes the TO_COIL matrix gain by "DELTAGAINS", turns on the oscillator, and get X_SIN, X_COS from C1IOO_LOCKIN.
  Plots DELTAGAINS vs X_SIN/X_COS and fit them by y=a+bx+cx^2.(Ideally, c=0)
  Rotates (X_SIN, X_COS) vectors to get I-phase and Q-phase.
    (I,Q)=R*(X_SIN,X_COS)
  Rotation angle is given by;
    rot=arctan(b(X_COS)/b(X_SIN))
  which gives Q 0 slope(Ideally, Q=0).
  x-intercept of DELTAGAINS vs I plot gives the beam position.

Checking the script:
  1. I used the same setup when I checked LOCKIN(see elog #3857). C1:SUS-MC2_ULCOIL output goes directly to C1:IOO-LOCKIN_SIG input.

  2. Set oscillator frequency to 18.13Hz, put 18.13Hz band-pass filter to C1:IOO-LOCKIN_SIG filter module, and put 1Hz low-pass filter to C1:IOO-LOCKIN_X_SIN/X_COS filter modules.
        Drive frequency 18.13Hz is same as the previous script(/cvs/cds/rtcds/caltech/c1/scripts/A2L/A2L_MC2).

  3. Ran the script. Checked that Q~0 and rot=-35deg.

  4. Put phase shifting filter to C1:IOO-LOCKIN_SIG filter module and checked Q~0 and rotation angle.
     fitler rot(deg)
     w/o    -35
     +90deg  45
     -90deg  56
     -45deg -80

  5. Put some noise in C1:SUS-MC2_ULCOIL by adding SUSPOS feedback signal and ran the script.(Attachment #1)
      During the measurement, the damping servo was off, so SUSPOS feedback signal can be treated as noise.

Conclusion:
  The result from the test measurement seems reasonable.
  I think I can apply it to the real measurement, if MCL signal is not so noisy.[status: yellow]

Plan:
  - add calculating coherence procedure, averaging procedure to the script
  - add setting checking procedure to the script
  - apply it to real A2L measurement

Bay the way:
  Computers in the control room is being so slow (rossa, allegra, op440m, rosalba). I don't know why.

Attachment 1: a2ltest.png
a2ltest.png
  3862   Thu Nov 4 17:24:49 2010 steveUpdateGeneralconflat flanges for MIT

8 pieces of 10" CF blanks were shipped to MIT

Attachment 1: P1070020.JPG
P1070020.JPG
  3861   Thu Nov 4 15:27:33 2010 josephb, yutaUpdateCDSc1ioo test points not working

Problem:

We can't access any of the c1ioo computer testpoints.  Dataviewer and DTT both fail to read any data from them.

According to diag -l (when run on Rosalba in /opt/apps), the testpoints are not being set.  Also at some point during the day when debugging, we also somehow messed up all the front end connections to the framebuilder.

Errors reported by dataviewer:

Server error 13: no data found
datasrv: DataWriteRealtime failed: daq_send: Illegal seek
Server error 12: no such net-writer
Server error 13: no data found
datasrv: DataWriteRealtime failed: daq_send: Illegal seek
Server error 12: no such net-writer
read(); errno=0
Server error 6532: invalid channel name
Server error 16080: unknown error
datasrv: DataWriteRealtime failed: daq_send: Illegal seek

Error reported by daqd.log:

[Thu Nov  4 13:29:35 2010] About to request `C1:IOO-MC1_PIT_IN1' 10022
on node 34
[Thu Nov  4 13:29:35 2010] Requesting 1 testpoints; tp[0]=10022; tp[1]=32531

[Thu Nov  4 13:29:35 2010] About to request `C1:SUS-MC2_SUSPOS_IN1'
10094 on node 36
[Thu Nov  4 13:29:35 2010] Requesting 1 testpoints; tp[0]=10094; tp[1]=32531

[Thu Nov  4 13:29:38 2010] ETIMEDOUT: test point `C1:IOO-MC1_PIT_IN1'
(tp_num=10022) was not set by the test point manager; request failed
[Thu Nov  4 13:29:38 2010] About to clear `C1:IOO-MC1_PIT_IN1' 10022 on node 34

Attempted Fixes:

Remove all daq related files: /opt/rtcds/caltech/c1/target/gds/param/tpchn_c1ioo.par and /opt/rtcds/caltech/c1/chans/daq/C1IOO.ini.  Rebuilt the front end code.

Double checked ethernet connection between c1ioo and the daq router and fb. 

Confirmed open mx was running on c1ioo. Confirmed awgtpman was running (although at one point I did find duplicate awgtpman running for c1x03, the IOP associated with c1ioo).

Rebooted the c1ioo machine. Confirmed all necessary codes came back.

Restarted the daqd process several times on the fb machine.

Current Status:

Framebuilder is running, and c1sus testpoints are available.  c1ioo test points are not.  Waiting to hear back from Alex on possible ideas.

  3860   Thu Nov 4 15:15:43 2010 josephbUpdateCDSModified feCodeGen.pl, fmseq.pl, and suspension screens

Feature Requested:

Have the CPU_meter change change color at various alarm levels.  These alarm levels have been set at 2/3 maximum for Minor alarm (yellow) and 9/10 maximum for Major alarm (red).

Implementation:

Rather than hand code each EPICS .db file to add the alarm files each time we rebuild the front ends, I decided to modify it at the source (since it strikes me as a generally useful alarm level for all front end codes).

First, I modified the feCodeGen.pl script.

I changed

print EPICS "OUTVARIABLE FEC\_$dcuId\_CPU_METER epicsOutput.cpuMeter int ai 0 field(HOPR,\"$rate\") field(LOPR,\"0\")\n";

to

print EPICS "OUTVARIABLE FEC\_$dcuId\_CPU_METER epicsOutput.cpuMeter int ai 0 field(HOPR,\"$rate\") field(LOPR,\"0\") field(HIGH,\"$two_thirds_rate\") field(HSV,\"MINOR\") field(HIHI,\"$     nine_tenths_rate\") field(HHSV,\"MAJOR\")\n";

I added the following two lines just before it as well:

$two_thirds_rate = int($rate * 2 / 3);

$nine_tenths_rate = int($rate * 9 / 10);

However, only the first four fields were actually added to the database file.  Apparently fmseq.pl, which populated the database, was hard coded to only handle up to 4 fields.

I modified the fmseq.pl script in /opt/rtcds/caltech/c1/core/advLigoRTS/src/epics/util/ so as to be able to handle up to 6 field values when writing EPICS .db files.

This change was accomplished by simply changing the following line

($junk, $v_name, $v_var, $v_type, $ve_type, $v_init, $v_efield1, $v_efield2, $v_efield3, $v_efield4 ) = split(/\s+/, $_);

to 

($junk, $v_name, $v_var, $v_type, $ve_type, $v_init, $v_efield1, $v_efield2, $v_efield3, $v_efield4, $v_efield5, $v_efield6 ) = split(/\s+/, $_);

everywhere it occurred.  There were something like 10 instances of it. Also, I added the two lines

        $vardb .= "    $v_efield5\n";
        $vardb .= "    $v_efield6\n";

after each set of

         $vardb .= "    $v_efield1\n";
         $vardb .= "    $v_efield2\n";
         $vardb .= "    $v_efield3\n";
         $vardb .= "    $v_efield4\n";

Lastly, I modified the CPU_METER bar graph on the C1SUS_DEFAULTNAME.adl screen (located in /opt/rtcds/caltech/c1/medm/master/) to use alarm levels, and then ran generate_master_screens.py.

 

  3859   Thu Nov 4 03:13:46 2010 SureshUpdateLockingFibre coupling 1064nm light at the south-end table

[Kiwamu, Suresh]

We decided to use the 1064nm beam reflected from the Y1-1037-45-P mirror after the collimation lens following the doubling crystal for coupling into the optical fiber (ref 3843 and 3847 ).

We replaced a beam dump which was blocking this beam with a Y1-1037-45-P mirror and directed the beam into the fiber coupler with another Y1-1037-45-P.  The power in this beam was about 1W.  This has been stepped down to 10mW by introducing a reflective ND filter of OD=2.  The reflected power has been dumped into a blade-stack beam dump.

Steve has ordered the The Visual Fault Locator from Fluke.  It is expected to arrive within a day or two.

 

 

  3858   Wed Nov 3 23:58:45 2010 ranaUpdateElectronicsCougars

I looked at this web page: http://www.teledyne-cougar.com/Index.asp for the RF company that Rich has recently started using.

There are ~15 amplifiers that they sell which have a NF < 2 dB and work in the 10-100 MHz band. We should call them to find out if they will package some amps for us or at least sell us a few with eval. boards so that we can make our own.

  3857   Wed Nov 3 21:19:40 2010 yutaUpdateCDSput LOCKIN to c1ioo model and checked

(Joe, Yuta)

Summary:
  LOCKIN(consists of oscillator and demodulator) is needed for A2L measurement.
  So, we put LOCKIN to c1ioo model, whose outputs goes to c1mcs ASC.
  After that, I checked the functionality of LOCKIN by directly connecting DAC output for a coil to ADC input for MCL with BNC cable.

What we did:
[Putting LOCKING to c1ioo model]
1. Copied Simulink LOCKIN stuff(cdsOsc, Product, cdsPhase ...) from /cvs/cds/caltech/cds/rward-advLigo/src/epics/simLink/omc.mdl and put it into c1ioo model.

2. Copied MEDM screen file /cvs/cds/caltech/medm/c1/omc/C1OMC_LSC_LOCKIN.adl and modified it for our use.

[Checking LOCKIN]
3. Disconnected MC2_ULCOIL input to SOS Coil driver at 1X4-1-6A and checked the signal from software oscillator at c1ioo is coming.

4. Disconnected the cable labeled "MC OUT1" at 1X2 (which is MCL signal to ADC) and put MC2_ULCOIL output directly using long BNC cable.

5. Checked the functionality of LOCKIN by StripTool.
   The cable wiring did not conflict with my expectation.
   Software mixer is working.(frequency is doubled. X_SIN has offset and X_COS doesn't)

6. Put the cables back.

Result:

  Thanks to c1rfm, c1ioo and c1sus are talking without ADC timeout.
  Also, LOCKIN is working fine.

Attachment 1: Screenshot_C1IOO_LOCKIN.png
Screenshot_C1IOO_LOCKIN.png
  3856   Wed Nov 3 19:14:00 2010 ranaUpdatePSLPMC mode matching update

I moved the lens just before the PMC to check the mode matching landscape. The PMC trans went up from ~6.5 to ~6.8. That's 5% with ~1 hour of work.

As per the micrometer, this took ~7-8 mm of travel. Since there's so much power left in the HOMs, we we we will have to do a proper mode scan and re-calculate the solution.

The measured transmission is now ~610 mW. The power reflected from the PMC with it unlocked is ~1400 mW.

  3855   Wed Nov 3 17:01:01 2010 josephbSummaryCDSComparison of RFM read times

Problem:

RFM reads are slow.  Rolf has said it should take 2-3 microseconds per read. 

c1sus is taking about 7 microseconds per read, twice as slow as Rolf's claim.

Hypothesis:

The RFM card is in the IO chassis, and is sharing the PCIe bus with 4 ADC cards, 3 DAC cards, 4 BO cards, and a BIO card.  Its possible this crowded bus is causing the reads to take even longer.

Test Results:

Compare read times between the c1sus computer, which has its RFM card in the IO chassis, to c1ioo, which has its RFM card in the computer.

c1ioo:

No RFM reads: 8 microseconds

3 RFM reads: 20 microseconds (~4 per read)

6 RFM reads: 32 microseconds (~4 per read)

c1sus:

No RFM read: 25 microseconds (bigger model)

1 RFM read: 33 microseconds (~8 per read)

3 RFM read: 45 microseconds (~7 per read)

6 RFM read: Over 62 microseconds, doesn't run.

Conclusion:

It looks like moving the RFM card may help by about a factor of 2 in read speed, although its still not quite what Alex and Rolf claim it should be.

The c1mcs and c1ioo models have been reverted to their normal operations.

 

  3854   Wed Nov 3 16:49:31 2010 steveUpdateGeneralstorage cabinet is in place

The south end of IFO room 104 was reshuffled. The flow bench was moved all the way to the south end to create more room for the crane reach. The old  large drawing cabinet  was moved under the vacuum tube.

The new clear view through  Acrylic-plexyglass cabinet is anchored. It has powder finished coating so it will not out-gas too much.The back side shelf mounting holes are sealed off with kapton tape. The doors still needs some gaskit seals.

Attachment 1: P1070018.JPG
P1070018.JPG
  3853   Wed Nov 3 15:13:55 2010 josephbUpdateCDSTemporary RFM slow read work around

Problem:

Each RFM read in the c1mcs model is adding ~7 microseconds to the cycle time.  Adding too many pushes it over the 62 microsecond limit.

RFM writes do not have this problem.

Temporary Solution:

The fastest fix was to create a new front end model, called c1rfm, which does nothing but read in the MC1, MC2, MC3 PIT and YAW signals from the c1ioo machine, and then passes them along to the c1mcs model via shared memory, which is fast.

This means the data being sent is 2 cycles slow, one to go over the RFM, and one to go over shared memory.  It is running at 16384 cycles/second, so it shouldn't have much impact at the frequencies we use those channels for.

MC_L is still being sent directly to the c1mcs front end code via RFM.

Current Status:

The c1mcs model is running at  30-33 microseconds for CPU time.

The c1rfm model is running at 45-47 microseconds for CPU time.

All 7 channels, MC_L, MC1_PIT, MC1_YAW, MC2_PIT, MC2_YAW, MC3_PIT, MC3_YAW are responding.

The c1rfm model was added to the /diskless/root/etc/rtsystab file on the fb machine so that it automatically starts on the reboot of c1sus.

The USR and CPU time channels for c1rfm were added to the MCS_SLOW.ini file in /opt/rtcds/caltech/c1/chans/daq/ so that the framebuilder records them, namely:

[C1:FEC-38_USR_TIME]
[C1:FEC-38_CPU_METER]

The framebuilder was restarted to take these new channels into account.

Future:

Finish implementing and debugging the "round robin" RFM reader so as to not require a seperate model to be doing RFM reads in parallel.

Look into improving read speed by either merging timestamps and data into a single  or reading time stamp once every tenth or hundreth cycle, although this at best provides a factor of 2 improvement.

Check to see if RFM card being on the IO chassis or directly in the computer chassis makes a difference.

Get Alex and Rolf to improve RFM read speed.

  3852   Wed Nov 3 09:32:00 2010 ranaSummaryCDSEurocard board swapping

When swapping Eurocard boards, it is safest to first turn down the power supplies and then do the swapping.

Otherwise, it is sometimes the case that people plug in the board slowly and/or asymmetrically. This can cause the opamp to see one of the power supply rails without the other (e.g. +15 but not -15).

This can destroy some opamps. The true danger is that there may be damage to the board which you do not notice for several months, thereby leaving a timebomb for the next person.

Don't be an electronics terrorist!

  3851   Wed Nov 3 03:00:47 2010 KojiSummaryGreen Lockingcoarse locked green beat frequency

Wow! Great guys!!

Can I expect to see the spectra of the frequency counter output with and without the servo?

RA: I think the SBP-70 is a bad idea. It limits the capture range. So does the SHP-25. You should instead just use a DC-block; the SR620 should work from 1-200 MHz with no problems.

Also, we have to figure out a better solution for the DAC at the ends: we cannot steal the QPD gain slider in the long run and the 4116 DAC at the ends has all 8 channels used up. Should we get the purple box for testing or should we try to use the fast DAC in the EX IO chassis as the actuator?

  3850   Wed Nov 3 02:37:39 2010 yutaSummaryGreen Lockingcoarse locked green beat frequency

(Kiwamu, Yuta)

We succeeded in coarse locking the green beat frequency, using a frequency counter and feeding back the signal to the X-end laser temperature.

Setup:
  beat note -> RF PD -> SHP-25 -> SLP-100 -> ZFL-1000LN -> ZFL-1000LN -> ZFL-500LN -> ZFRSC-42 -> SBP-70 -> ZFRSC-42 -> SR620 -> c1psl(C1:PSL-126MOPA_126MON)
  c1auxey(C1:LSC-EX_GREENLASER_TEMP) -> X-end laser temp

  The frequency counter SR620 converts the beat frequency to voltage.
  We added some filters (SHP-25, SLP-100, SBP-70). Otherwise, SR620 doesn't count the frequency correctly.

What we did:

  1. Getting green beat note again
     Set PSL laser temp to 31.81 °C and X-end laser temp to 37.89 °C.
     Set PPKTP crystal temp to 37.6 °C, which maximizes output green beam power.

  2. ADC channel and DAC channel
     Disconnected one channel going into VME-3123 (at 1X1) and used c1psl's C1:PSL-126MOPA_126MON as ADC channel for the output from SR-620
     Made a new DAC channel on c1auxey named C1:LSC-EX_GREENLASER_TEMP, and disconnected one channel from VME-4116 (at 1X9) to use it as DAC channel for X-end laser temperature control.

  3. Coarse lock by ezcaservo
     Ran;
        ezcaservo C1:PSL-126MOPA_126MON -s 150 -g -0.0001 C1:LSC-EX_GREENLASER_TEMP
     "-s" option is a set value. The command locks C1:PSL-126MOPA_126MON to 150 (in counts), using 0Hz pole integrator.

Result:
  The beat frequency locked on to ~77MHz. The frequency fluctuation of the beat note during the servo is ~3MHz with ~10sec timescale.
  VCO has  ~+/-5MHz range, so this coarse locking meets the requirement.

  Here's a plot of the error signal and feed back signal;
  Screenshot_LowFreqLock.png

  3849   Wed Nov 3 02:23:11 2010 yutaSummaryCDSchecking whitening filter board

Summary:
  Last night, I found that some of the input channels have wrong hardware filter switching(see elog #3842).
  So, to check the whitening board(D000210), I swapped the one with ok switching and bad switching.
  During the checking, I somehow broke the board.
  I fixed it, and now the status is the same as last night (or, at least look like the same).

What I did:
  1. Switching for SRM_LRSEN looked bad and every input channel for MC3 looked OK.
     So, I unplugged the whitening board for SRM (1X5-1-5B) and plugged it into MC3's place(1X5-1-8B).

  2. Ran WDWchecker.py for MC3. The switching seemed OK for every input channel, which means the whitening board was not the wrong one.

  3. Swapped back the whitening board as it was.

  4. Found MC3_ULSEN_OUT and MC3_LLSEN_OUT was keep showing negative value(they should be positive).

  5. Check the board and found that one of LT1125 for UL/LL was wrong (broken virtual ground).

  6. Replaced LT1125 and put the board back to 1X5-1-8B.

  7. Checked the board with WDWchecker.py and dataviewer 5-hour minute trend.
      The input signal came back to normal value(Attachment #1), MC3 damping working, input filter switching seems working

before LT1125 replacement after LT1125 replacement
C1:SUS-MC3_ULSEN_IN1: -2.4 dB [!]
C1:SUS-MC3_URSEN_IN1: 16.9 dB
C1:SUS-MC3_LRSEN_IN1: 15.4 dB
C1:SUS-MC3_LLSEN_IN1: -1.1 dB [!]
C1:SUS-MC3_SDSEN_IN1: 18.4 dB
C1:SUS-MC3_ULSEN_IN1: 18.2 dB
C1:SUS-MC3_URSEN_IN1: 17.6 dB
C1:SUS-MC3_LRSEN_IN1: 16.6 dB
C1:SUS-MC3_LLSEN_IN1: 17.1 dB
C1:SUS-MC3_SDSEN_IN1: 16.2 dB


Result:
  The whitening board seems OK.
  The wrong one is either wiring or RT model. Or, the checking script.

Attachment 1: MC3SEN.png
MC3SEN.png
  3848   Tue Nov 2 16:49:02 2010 JenneConfigurationCamerasCabling on the PSL table

Dear whomever setup the camera on the SW corner of the PSL table,

It would be handy if, even for temporary setups, all cables went underneath the white frame around the PSL table.  As it is now, the cables are in the way of the door.  The door is pretty much closed all the way, but if someone were to open other doors, the far door can easily be pushed all the way to the end of the track, thus squishing the cables.  Squished cables are bad cables.

Thanks!

  3847   Tue Nov 2 16:24:07 2010 KojiUpdateAuxiliary lockingAlignment for the green in the X trans table

[Kiwamu Koji]

Today we found the green beam from the end was totally missing at the vertex.

- What we found was very weak green beam at the end. Unhappy.

- We removed the PBS. We should obtain the beam for the fiber from the rejection of the (sort of) dichroic separator although the given space is not large.

- The temperature controller was off. We turned it on again.

- We found everything was still misaligned. Aligned the crystal, aligned the Faraday for the green.

- Aligned the last two steering mirrors such that we hit the approximate center of the ETMX and the center of the ITMX.

- Made the fine alignment to have the green beam at the PSL table.

The green beam emerged from the chamber looks not so round as there is a clipping at an in-vac steering.
We will make the thorough realignment before closing the tank.

  3846   Tue Nov 2 15:24:18 2010 josephbUpdateCDSc1ioo and c1mcs only sending MC_L, MC1_PIT, MC1_YAW

In order to have the c1mcs model run, we're running with only 3 RFM channels between c1ioo and c1mcs at the moment.  This leaves the model at around 45 microseconds, and at least lets us damp.

Alex and I still need to track down why the RFM read calls are taking so much time to execute.

  3845   Tue Nov 2 13:51:40 2010 josephb, yutaUpdateCDSRFM slowdown problem

Problem:

Each RFM memory location which needs to be read by a front end model slows the model significantly.

With no RFM memory locations to be read (replaced with grounds), the c1mcs model runs around 25 microseconds per cycle.

With 1 RFM memory location (MC_L), it runs around 29-33 microseconds.

With 3 RFM memory locations (MC_L, MC1_PIT, MC1_YAW), it runs around 45 microseconds.

With 7 RFM memory locations, the code generally doesn't run at all, going past the 62 microsecond maximum required to be able to keep up with the 16 kHz sample rate.

Last night Yuta somehow got it running with 7 RFM memory locations, but in that case, all the odd numbered RFM channels (1,3,5 as counted by the ipc file) did not work.  It was running at around 55 microseconds in that case.

The c1ioo code which is writing the data to the RFM card is experiencing no such slow down.

Current CDS status:

MC damp dataviewer diaggui AWG c1ioo c1sus c1iscex RFM Sim.Plant Frame builder  ...
                     ... 
  3844   Tue Nov 2 11:34:53 2010 josephb, alexUpdateCDSdiagconfd running, excitations back in dtt

Problem:

Diagnostic test tools was starting with errors.

Cause:

After the reboot of the frame builder machine yesterday by Alex, the diagconfd daemon was not getting started by xinetd.  There was a sequence error in the startup where xinetd was being called before mounting drives from linux1.

Important Note:

If you do not see the "nds" line you would not have diagnostic tests enabled in the DTT:

[controls@rosalba apps]$ diag -i | grep nds
nds * * 192.168.113.202 8088 * 192.168.113.202

Solution:

Alex changed /etc/xinetd.d/diagconfd file to point to /opt/apps/gds/bin/diagconfd instead of /opt/apps/bin/diagconf.  He also ensured xinetd started after mounting from linux1.

Alex's Suggestion:
My feeling is we should get rid of this feature and have an NDS address
entry box in the "Online" tab in the DTT with the default "nds". I
mentioned this to Jim Batch and he greed with me, so maybe he is going to
implement this. So maybe you guys want to request the same thing too, send
the request to Rolf and Jim, so we can have the last demon exercised.

  3843   Tue Nov 2 00:17:01 2010 SureshConfigurationLockingTemporary changes to the Video Mux

Fiber coupling 1064 nm light at the end of X arm

This is 'work in progress'.  The attempt is to bring a few milliwatts of the 1064 nm light from the NPRO at the end of the South(X) Arm to the PSL table through an single mode optical fiber.  This would enable us to tune the two NPRO's to be less than 15 MHz apart by looking at their beat frequency before doubling.  Because we have a 1GHz bandwidth PD at 1064 nm, while the photodiode for green has a BW of about 30MHz.

A PBS (P-type) cube has been introduced into the beam of the X arm NPRO  (between the lamda/2 plate and the input lens of the doubling crystal).  By rotating the face of the PBS slightly away from normal incidence, I have diverted away 1.5mW of the 1064 light for coupling into the fiber. The beam has shifted slightly because of this and the green beam from the south arm has to be realigned to reach the PSL table.

A single mode fiber (Thorlabs SM980-5.8-125),  which was already laid half way, has been extended all the way to the PSL table. It runs along the  South arm in the cable tray. 

A pair of mirrors have been arranged in a zig-zag to steer the beam into a fiber coupler.  There was some hope that this coupler had been aligned at some point in the past and that attaching a fiber might result in some transmission.  But this is not the case and fiber coupler needs to be readjusted.

In order to see the light transmitted through the fiber, a camera has been set up on the PSL table.  Its output has been routed into the 'Ref Cavity reflected' video signal.  A video cable running from the ETMX to the Video-MUX used to be connected to the input channel 9 of the Video MUX.  This has now been shifted to output channel 25 of the MUX and disconnected from the camera at the ETMX.   The 'Ref Cav Refl.' video signal has been routed to the output channel 25.  The camera looking at the fiber output can now be seen on a local monitor at the end of the X arm and on the video monitor in the control room.

With the fiber disconnected, the 1064 nm beam was steered into the fiber coupler and its transmission maximised by observing  with an IR viewer.  The fiber was then connected and then the transmission at the PSL table was sought.  There was no transmission seen after a searching around this region for a few mins.

The plan is to purchase a Visual fault locator which would enable us to quickly get a rough alignment of the fiber coupler. A local vendor is listed as a distributor for this product from JDSU.  Contact info:

DuVac Electronics (EDGE)
Tel: 626-796-3291
Email: jack@duvac.com
1759 E Colorado Blvd
Pasadena, CA 91106

 

  3842   Mon Nov 1 23:31:05 2010 yutaUpdateCDSchecked input hardware filter in single frequency

Background:
  For input filter, we have analog whitening filter and also digital whitening filter. They have the same TF and when analog one is off, digital one should be on and vice versa.
  I made a python script that checks the switching automatically.

Method:
  Excite the suspension in a single frequency and see sensor inputs(XXSEN_IN1).
  Calculate the magnitude in the excitation frequency and compare it when digital whitening is off and on.
  When digital whitening is off, analog should be on, so sensor inputs should gone though the analog filter. That means the signal is multiplied by the TF of that filter, which makes the difference.

  We currently don't have excitation and I thought I have to wait, but instead of putting some extra excitation, I found that 60Hz line noise is useful.

Script:
  The script is /cvs/cds/caltech/users/yuta/scripts/WDWchecker.py
  For every sensor input, it;
    0. Stores current filter switching(XXSEN_SW1R)
    1. turns OFF the digital filter(FM1, using ezcaswitch)
    2. tdsdmd XXSEN_IN1 in 60Hz
    3. turns ON the digital filter
    4. tdsdmd XXSEN_IN1 in 60Hz
    5. divides mag(2.) by mag(4.) and calculate the analog filter gain in 60Hz
    6. Restores the filter switching in the state before the checking

Result:
  The results are;

C1:SUS-BS_ULSEN_IN1: 22.2 dB
C1:SUS-BS_URSEN_IN1: 18.7 dB
C1:SUS-BS_LRSEN_IN1: 22.7 dB
C1:SUS-BS_LLSEN_IN1: 16.0 dB
C1:SUS-BS_SDSEN_IN1: 21.5 dB
C1:SUS-ITMX_ULSEN_IN1: 16.9 dB
C1:SUS-ITMX_URSEN_IN1: 16.3 dB
C1:SUS-ITMX_LRSEN_IN1: 17.5 dB
C1:SUS-ITMX_LLSEN_IN1: 17.1 dB
C1:SUS-ITMX_SDSEN_IN1: 6.2 dB
C1:SUS-ITMY_ULSEN_IN1: 15.5 dB
C1:SUS-ITMY_URSEN_IN1: 16.5 dB
C1:SUS-ITMY_LRSEN_IN1: 17.4 dB
C1:SUS-ITMY_LLSEN_IN1: 16.3 dB
C1:SUS-ITMY_SDSEN_IN1: 18.0 dB
C1:SUS-PRM_ULSEN_IN1: 0.1 dB
C1:SUS-PRM_URSEN_IN1: 10.3 dB
C1:SUS-PRM_LRSEN_IN1: 13.1 dB
C1:SUS-PRM_LLSEN_IN1: -32.3 dB
C1:SUS-PRM_SDSEN_IN1: 14.6 dB
C1:SUS-SRM_ULSEN_IN1: 17.3 dB
C1:SUS-SRM_URSEN_IN1: 13.5 dB
C1:SUS-SRM_LRSEN_IN1: 1.6 dB
C1:SUS-SRM_LLSEN_IN1: 16.7 dB
C1:SUS-SRM_SDSEN_IN1: 18.3 dB

C1:SUS-MC1_ULSEN_IN1: 17.0 dB
C1:SUS-MC1_URSEN_IN1: 18.6 dB
C1:SUS-MC1_LRSEN_IN1: 14.9 dB
C1:SUS-MC1_LLSEN_IN1: 27.0 dB
C1:SUS-MC1_SDSEN_IN1: 16.6 dB
C1:SUS-MC2_ULSEN_IN1: 19.8 dB
C1:SUS-MC2_URSEN_IN1: 14.0 dB
C1:SUS-MC2_LRSEN_IN1: 20.8 dB
C1:SUS-MC2_LLSEN_IN1: 16.1 dB
C1:SUS-MC2_SDSEN_IN1: 17.3 dB
C1:SUS-MC3_ULSEN_IN1: 15.5 dB
C1:SUS-MC3_URSEN_IN1: 17.3 dB
C1:SUS-MC3_LRSEN_IN1: 18.2 dB
C1:SUS-MC3_LLSEN_IN1: 18.7 dB
C1:SUS-MC3_SDSEN_IN1: 16.8 dB


  Whitening filter has 18dB gain at 60Hz. (It's 3Hz pole, 30Hz zero, 100Hz zero and 0dB at DC)
  So, from the result, at least MC suspensions look like they have correct switching.
  But some channels doesn't look ok.
  We have to check those.

Plan:
   - check ITMX_SDSEN, PRM_ULSEN, PRM_LLSEN, SRM_LRSEN input filters
   - check the script and see if the script can really check. maybe the script needs some adjustments (# of averaging, multiple frequency, ......)
   - make AWG(, tdssine) work
   - check output hardware filter

By the way:
  fb is back. I don't know why. With help from Joe, I just compiled c1mcs again and again changing number of RFM channels.

  3841   Mon Nov 1 19:32:08 2010 yutaSummaryCDSfb crashed? during c1ioo and c1mcs connection at ASC

Frame builder died again!!

Background:
  We want to do angle to length measurement to optimize the beam position and increase visibility of MC locking.
  In order to do A2L measurement, we need excitation point, but AWG is currently not working.
  The better way is to use LOCKIN stuff like we had for OMC and put it to C1IOO WFS.
  A software oscillator in LOCKIN shakes the suspension, and demodulate the length signal.
  We can choose whatever DOF to shake, whatever signal to demodulate. It would be useful not just for A2L.

What I did:

  I started to put C1IOO WFS signal into C1SUS MC suspension RT model, but after compiling new c1mcs, fb crashed.
  Looks like daqd and mx_streams are running, but DAQ is not working(red).
  I don't know how to restart in a new way!

  3840   Mon Nov 1 17:27:47 2010 JenneUpdateSUSPRM ready for installation into chamber

[Jenne, Suresh]

Over the weekend, Bob and Daphen gave the PRM a 48hr. vacuum bake.  This afternoon Suresh and I placed it back in the wire in the tower.  We used the microscope-on-translation-stage technique to make sure the scribe lines on each side of the optic are at the same height, and then secured the PRM using all of the EQ stops.  It is wrapped in foil, and ready for its journey into the IFO room.  When we next have the BS chamber open, we should put the PRM in, and move the current PRM to its final place on the ITMY table as the SRM.

  3839   Mon Nov 1 16:43:24 2010 KojiSummaryCDSCDS time delay measurement

Um, Beautiful.

Actually, 123.5usec is almost exactly twice of 1/16384Hz.
Because of the loop, we have 1/16384Hz delay. I wonder where we do have the delay.

In order to understand the behaviour of the system can I ask you to test the following things?

1) What are the delay without IOPs with fsampl of 16k, 32k, 64k?

2) What are the delay with IOP with fsampl of 32k, 64k?

Quote:

Result:
  TF agreed well with 2-time feCoeff4x and CDS time delay was -123.5 usec.
CDSdelay2.png

 

  3838   Mon Nov 1 15:47:15 2010 yutaSummaryCDSCDS time delay measurement

Background:
  I measured CDS time delay last week, but because of my lack of understanding the system, it was incorrect.
  IOP has an anti-aliasing filter before downsampling from 64kHz(65536Hz) to 16kHz(16384Hz) and also has an anti-imaging filter before upsampling from 16kHz to 64kHz.
  So, I should have take feCoeff4x into account twice.
downupsampling.png

Result:
  TF agreed well with 2-time feCoeff4x and CDS time delay was -123.5 usec.
CDSdelay2.png


Plan:
 - make AWG(, diaggui TF measurement, tdssine) work
 - check input/output filter switching (using tdssine & tdsdmd)
 - measure openloop TF of MC suspension damping
 - divide it with my expectation and see if there are any filters I don't know

Quote:

Unsatisfactory.

Neglecting the digital anti-imaging filter makes the discrepancy. You must take into account your digital filter twice.

I attached the slides I made during my visit for March LVC '09. P.5 would be useful.

 

  3837   Mon Nov 1 15:35:41 2010 josephbUpdateCDSFront end USR and CPU times now recorded by DAQ

Problem:

We have no record of how long the CPUs are taking to perform a cycle's worth of computation

Solution:

I added the following channels to the various slow DAQ configuration files in /opt/rtcds/caltech/c1/chans/daq/

IOO_SLOW.ini:[C1:FEC-34_USR_TIME]
IOO_SLOW.ini:[C1:FEC-34_CPU_METER]
IOP_SLOW.ini:[C1:FEC-20_USR_TIME]
IOP_SLOW.ini:[C1:FEC-20_CPU_METER]
IOP_SLOW.ini:[C1:FEC-33_USR_TIME]
IOP_SLOW.ini:[C1:FEC-33_CPU_METER]
MCS_SLOW.ini:[C1:FEC-36_USR_TIME]
MCS_SLOW.ini:[C1:FEC-36_CPU_METER]
RMS_SLOW.ini:[C1:FEC-37_USR_TIME]
RMS_SLOW.ini:[C1:FEC-37_CPU_METER]
SUS_SLOW.ini:[C1:FEC-21_USR_TIME]
SUS_SLOW.ini:[C1:FEC-21_CPU_METER]

 

Notes:

To restart the daqd code, simply kill the running process.  It should restart automatically.  If it appears not to have started, check the /opt/rtcds/caltech/c1/target/fb/restart.log file and the /opt/rtcds/caltech/c1/target/fb/logs/daqd.log.xxxx files.  If you made a mistake in the DAQ channels and its complaining, fix the error and then restart init on the fb machine by running "sudo /sbin/init q"

  3836   Mon Nov 1 14:53:30 2010 josephb, alex, rolfUpdateCDSAlex updated FB and mx_streams code

Problem:

The framebuilder was being flaky.  MX_streams would go down, prevent testpoints from working and so forth.

Solution:

Send Alex up North for a week to fix the code. 

Alex came back and installed updates to the frame builder and the mx_streams code (Myrinet Express over Generic Ethernet Hardware) used by the front ends to talk to the frame builder.  Instead of 1 stream per model, there's now just 1 per front end handling all communications.

Alex did an SVN update and we now have the latest CDS code.

Self restarting codes:

The frame builder code (daqd) and nds pipe have been added to the fb machine's inittab.  Specifically it calls a script called /opt/rtcds/caltech/c1/target/fb/start_daqd.inittab and /opt/rtcds/caltech/c1/target/fb/start_nds.inittab.

The addition to the /etc/inittab file on fb is:

daq:345:respawn:/opt/rtcds/caltech/c1/target/fb/start_daqd.inittab 

nds:345:respawn:/opt/rtcds/caltech/c1/target/fb/start_nds.inittab

When these codes die they should automatically restart.

Self starting codes at boot up:

The front ends now start the mx_stream script (which lives in /opt/rtcds/caltech/c1/target/fb/ directory) at boot up.  They call it with the approriate command line options for that front end. It can be found in the /etc/rc.local file.

They look like: mx_stream -s "c1x02 c1sus c1mcs c1rms" -d fb:0

As always, the front end codes to be started are defined in the /etc/rtsystab file (or on fb, in the /diskless/root/etc/rtsystab file).

However, if it does go down you would need to restart it manually, although it seems more robust now and doesn't seem to go down every time we restart the frame builder.

All the usual front end IOCs and modules should be started and loaded on boot up as well.

 

Current CDS status:

MC damp dataviewer diaggui AWG c1ioo c1sus c1iscex RFM Sim.Plant Frame builder  ...
                     ... 
  3835   Mon Nov 1 12:38:56 2010 Leo SingerConfigurationComputerspython-sqlite installed on Allegra

I installed the Python bindings for sqlite on Allegra using

$ sudo yum install python-sqlite python-sqlite2

ELOG V3.1.3-