40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 120 of 344  Not logged in ELOG logo
ID Date Author Typeup Category Subject
  3558   Sat Sep 11 22:42:07 2010 valeraUpdatePSLPSL update

- The PMC REFL PD was moved from the temporary location to the one called for by the PSL layout (picture attached). The leakage beams were dumped.

- The FSS reference cavity was aligned using temporary periscope and scanned using NPRO temperature sweep. The amplitude of the sweep (sine wave 0.03 Hz) was set such that the PMC control voltage was going about 100 V p-p with. With rough alignment the visibility was as high as 50% - it will be better when the cavity is locked and better aligned but not better than 80% expected from the mode astigmatism that Tara and I measured on Thursday. The astigmatism appear to come from the FSS AOM as it depends on the AOM drive. We reduced the drive control voltage from 5 V to 4V beyond that the diffraction efficiency went below 50%. The FSS REFL PD was set up for this measurement as shown in the attached picture. There is also a camera in transmission not shown in the picture.

Attachment 1: DSC_2502.JPG
DSC_2502.JPG
Attachment 2: DSC_2505.JPG
DSC_2505.JPG
  3560   Sun Sep 12 23:02:53 2010 valeraUpdate PMC mode matching

Kiwamu and I found that the first lens in the PMC mode matching telescope was mislabeled. It is supposed to be PLCX-25.4-77.3-C and was labeled as such but in fact it was PLCX-25.4-103.0-C. This is why the PMC mode matching was bad. We swapped the lens for the correct one and got the PMC visibility of 82%. The attached plot shows the beam scans before and after the PMC. The data were taken with the wrong lens. The ABCD model shown in the plot uses the lens that was there at the time - PLCX-25.4-103.0-C. The model for the PMC is just the waist of 0.371 mm at the nominal location. The snap shot of the ABCD file is attached. The calculation includes the KTP for FI and LiNb for EOM with 4 cm length. The distances are as measured on the table.

Attachment 1: pmc.pdf
pmc.pdf
Attachment 2: pmc-abcd.tiff
  3561   Sun Sep 12 23:16:52 2010 valeraUpdate FSS mode matching

The attached plot shows the beam scans of the beam leaking from the back mirror of the PMC to the BS cube that first turns the S-pol beam 90 deg to the AOM and then transmits the AOM double passed and polarization rotated P-pol beam to the reference cavity. The beam from the PMC is mode matched to the AOM using a single lens f=229 mm. The ABCD file is attached. The data were taken with VCO control voltage at 5 V. We then reduced the voltage to 4 V to reduce the astigmatism. Tara has the data for the beam scan in this configuration in his notebook.

The beam from AOM is mode matched to the reference cavity using a single lens f=286.5 mm. The ABCD file is attached.

Attachment 1: fss.pdf
fss.pdf
Attachment 2: fssaom-abcd.tiff
Attachment 3: fssrc-abcd.tiff
  3562   Mon Sep 13 00:19:32 2010 ranaUpdate VCO Driver Output power v. slider control voltage

I measured the RF power output of the VCO Driver box as a function of slider value. I measured using the Gigatronics Handheld power meter and connected to the AOM side of the cable after the white Pasternak DC block.

* at low power levels, I believe the waveform is too crappy to get an accurate reading - that's probably why it looks non-monotonic.

* the meter has a sticker label on it saying 'max +20 dBm'. I went above +20 dBm, but I wonder if maybe the thing isn't linear up there...

Attachment 1: vco.png
vco.png
  3564   Mon Sep 13 10:22:48 2010 josephbUpdateCDSRCG bugs/feature request wiki page

I've started a wiki page under the Upgrade 09/New CDS section regarding known bugs and pending feature requests for the Real Time Code Generator.   It can be found at http://lhocds.ligo-wa.caltech.edu:8000/40m/Bugs_and_Pending_Feature_requests_for_the_RCG.  If you have any ideas to improve the RCG or encounter a bug in the code generation process (say a particular part doesn't work inside subsystems for example), please note them here.

Currently there are bugs with excitation points (they don't work inside of a subsystem block) and tags (they don't respect scope and only 1 "from" tag for each "goto" tag connected to the output of a subsystem block).

  3565   Mon Sep 13 11:40:50 2010 AlbertoUpdateElectronicsFrequency Box Documentation Added to the SVN

I uploaded all the material about the RF frequency Generation Box into the SVN under the path:

https://nodus.ligo.caltech.edu:30889/svn/trunk/docs/upgrade08/RFsystem/frequencyGenerationBox/

I structured the directory as shown in this tree:

freqBoxSVNdierctoryStructure.png

I'm quickly describing in a section of the Rf system upgrade document with LIGO # T1000461.

  3566   Mon Sep 13 11:49:34 2010 kiwamuUpdatePSLmode matching from PMC to IMC

I have been working on the mode matching lenses which are sitting after the boradband EOM.

Last Friday I checked the mode profile after the first mode matching lens (f=-150mm). The measured mode was good.

According to the calculation done by ABCD software, the waist size is supposed to be 80.9 um after that lens.

The measured waists are 80.5 um for the vertical mode and 79.4 um for the horizontal mode.

The screenshot of the ABCD's result and the plot for the mode measurement are shown below.

I didn't  carefully check the mode after the last convex lens (f=200mm), but it must be already good because the beam looks having a long rayleigh range.

Now the beam is reflected back from MC1 and goes to the AP table since I coarsely aligned the beam axis to the MC.

newMM.png  psl_mmt1.png

 

/****  fitting result ****/

w0_v =  80.4615      +/- 0.1695 [um] 

w0_h =  79.4468      +/- 0.1889 [um]

z_v =  -0.115234        +/- 0.0005206  [m]

z_h =  -0.109722        +/- 0.0005753 [m]

 

  3568   Mon Sep 13 19:41:38 2010 ranaUpdatePSLFSS AOM alignment

The IR sensitive Olympus 570 camera gives us a really nice view of these IR beams. Its actually a lot better than what you can get with the analog IR viewers:

 

PSLAOMdogs
  3569   Mon Sep 13 21:52:53 2010 kiwamuUpdateGreen Lockingthe X end laser is ON

 I turned ON the laser at the X end station, which had been OFF for several weeks because of the crane business.

Now the green beam hits the ITMX and I got a reflection back to the end table.   

This green beam will be a nice reference when we install the green periscope in the chamber.

If it's necessary, feel free to correct the alignment of the green beam during my absence.

  3572   Tue Sep 14 18:07:41 2010 AlbertoUpdateElectronicsFrequency Box Documentation Added to the SVN

I completed a LIGO document describing design, construction and characterization of the RF System for the 40m upgrade.

It is available on the SVN under https://nodus.ligo.caltech.edu:30889/svn/trunk/docs/upgrade08/RFsystem/RFsystemDocument/

It can also be found on the 40m wiki (http://lhocds.ligo-wa.caltech.edu:8000/40m/Upgrade_09/RF_System#preview), and DCC under the number T1000461.

  3573   Wed Sep 15 01:27:52 2010 rana, steve, valeraUpdatePSLFSS cables connected

- connected the TTFSS cables (FSS fast goes directly to NPRO PZT for now)

- measured the reference cavity 21.5 MHz EOM drive to be 17.8 dBm

-  turned on the HV for the FSS phase correcting EOM (aka PC) drive

- connected and turned on the reference cavity temperature stabilization

- connected the RefCav TRANS PD

- fine tuned the RefCav REFL PD angle

  3574   Wed Sep 15 01:58:28 2010 valeraUpdatePSLFSS locking

The RefCav is locked and aligned. I changed the fast gain sign by changing the jumper setting on the TTFSS board. The RefCav visibility is 70%. The FSS loop ugf is about 80 kHz (plot attached. there is 10 dB gain in the test point path. this is why the ugf is at 10 dB when measured using in1 and in2 spigots on the front of the board.)  with FSS common gain max out at 30 dB. There is about 250 mW coming out of the laser and 1 mW going to RefCav out of the back of the PMC. So the ugf can be made higher at full power. I have not made any changes to account for the PMC pole (the FSS is after the PMC now). The FSS fast gain was also maxed out at 30 dB to account for the factor of 5 smaller PZT actuation coefficient - it used to be 16 dB according to the (previous) snap shot. The RefCav TRANS PD and camera are aligned. I tuned up the phase of the error signal by putting cables in the LO and PD paths. The maximum response of the mixer output to the fast actuator sweep of the fringe was with about 2 feet of extra cable in the PD leg.

I am leaving the FSS unlocked for the night in case it will start oscillating as the phase margin is not good at this ugf.

Attachment 1: DSC_2510.JPG
DSC_2510.JPG
  3575   Wed Sep 15 03:08:26 2010 KojiUpdatePSLFSS locking

Brilliant! This is the VERY way how the things are to be conquered!

Quote:

The RefCav is locked and aligned. I changed the fast gain sign by changing the jumper setting on the TTFSS board. The RefCav visibility is 70%. The FSS loop ugf is about 80 kHz (plot attached)  with FSS common gain max out at 30 dB. There is about 50 mW coming out of the laser and a few mW going to RefCav out of the back of the PMC. So the ugf can be made higher at full power. I have not made any changes to account for the PMC pole (the FSS is after the PMC now). The FSS fast gain was also maxed out at 30 dB to account for the factor of 5 smaller PZT actuation coefficient - it used to be 16 dB according to the (previous) snap shot. The RefCav TRANS PD and camera are aligned. I tuned up the phase of the error signal by putting cables in the LO and PD paths. The maximum response of the mixer output to the fast actuator sweep of the fringe was with about 2 feet of extra cable in the PD leg.

I am leaving the FSS unlocked for the night in case it will start oscillating as the phase margin is not good at this ugf.

 

  3577   Wed Sep 15 16:00:26 2010 koji, steveUpdateMOPA 

We removed the Lightwave MOPA Controller from 1X1 (south)  It was a real painfully messy job to pull out the umbilical.

Note: the umbilical is shading it plastic cover. It is functional but it has to be taken out side and cleaned. Do not remove it from it's plastic bag in a clean environment.

Now Joe has room for IOO chassy  in this rack.

We also removed the Minco temp controller and ref. cavity ion pump power supply.

 

  3578   Wed Sep 15 16:12:35 2010 koji, steveUpdateMOPAMOPA Controller is taken out of the PSL rack

We removed the Lightwave MOPA Controller, PA#102, NPRO206 power supply to make room for the IOO chassy at 1X1 (south) rack.

The umbilical cord was a real pain to take out. It is shading its plastic cover. The unused Minco was disconnected and removed.

The ref. cavity ion pump controller- power supply was temporarily taken out also.

Attachment 1: P1060843.JPG
P1060843.JPG
  3580   Fri Sep 17 01:36:14 2010 valeraUpdate PMC line width

The attached plots show the PMC cavity line width measurement with 1 mW and 160 mW into the PMC. The two curves on each plot are the PMC transmitted power and the ramp of the fast input of the NPRO. The two measurements are consistent within errors - a few %. The PMC line width  3.5 ms (FWHM) x 4 V / 20 ms (slope of the ramp) x 1.1 MHz / V (NPRO fast actuator calibration from Innolight spec sheet) = 0.77 MHz.

Here is the output of the calculation using Malik Rakhmanov code:

 

modematching =  8.4121e-01

transmission1 =   2.4341e-03

transmission2 =   2.4341e-03

transmission3 =   5.1280e-05

averageLosses =  6.1963e-04

visibility =  7.7439e-01

Here are the inputs for the calculation in the param.m:

 

fw = 0.77e6;                % width of resonance (FWHM) in Hz

Plas = 0.164;                % power into the PMC in W

 

% the following number refer to the in-lock cavity state

 

Pref = 0.037;                % reflected power in W

Ptr = 0.0712;                 % transmitted power in W

Pleak = 0.0015;              % power leaking from back of PMC in W

 

 

Attachment 1: TEK00009.PNG
TEK00009.PNG
Attachment 2: TEK00010.PNG
TEK00010.PNG
  3581   Fri Sep 17 03:06:06 2010 KojiUpdateSUSSOS sent for baking

Two SOS suspensions for the ETMs were disassembled and packed for cleaning and baking by Bob.

These suspensions have been stored on the X end flow bench long years, and looked quite old.

They have some differences to the modern SOSs.

- The top suspension block is made of aluminum and had dog clamps to fix the wires.
- The side bars are not symmetric: the side OSEM can only be fixed at the right bar (left side in the picture).
- EQ stops were made of Viton.
- One of the tower bases seems to have finger prints (of Mike Zucker?).

I found that the OSEM plates had no play. We know that the arrangement of the OSEMs gets quite difficult
in this situation. Therefore the holes of the screws were drilled with the larger drill.

We decided to replace all of the screws to the new ones as all of the screws are Ag plated and got corroded
by silver sulfide (Ag2S). I checked our stock in the clean room. We have enough screws.

Important note: Use stainless screws in aluminum / Silver-plated screws in stainless
There exists some study about galling: LIGO-G020394-00-D

Attachment 1: IMG_3596.jpg
IMG_3596.jpg
Attachment 2: IMG_3597.jpg
IMG_3597.jpg
  3582   Fri Sep 17 03:32:11 2010 KojiUpdateSUSArrangement of the SUS towers

The day before yesterday, I was cleaning a flow bench in the clean room.

I found that one SOS was standing there. It is the SRM suspension.

I thought of the nice idea:

- The installed PRM is actually the SRM (SRMU04). It is 2nd best SRM but not so diiferent form the best one.
==> Use this as the final SRM

- The SRM tower at the clean room
==> Use this as the final PRM tower.
==> The mirror (SRMU03) will be stored in a cabinet.

- The two SOS towers will be baked soon
==> Use them for the ETMs

This reduces the unnecessary maneuver of the suspension towers.

  3583   Fri Sep 17 12:11:42 2010 josephbUpdateCDSDowns update

In doing a re-inventory prior to the IOO chassis installation, I re-discovered we had a missing interface board that goes in an IO chassis.  This board connects the chassis to the computer and lets them talk to each other.  After going to Downs we remembered Alex had taken a possibly broken interface board back to downs for testing. 

Apparently the results of that testing was it was broken.  This was about 2.5 months ago and unfortunately it hadn't been sent back for repairs or a replacement ordered.  Its my fault for not following up on that sooner.

I asked Rolf what the plan for the broken one was.  His response was  they were planning on repairing it, and that he'd have it sent back for repairs today.  My guess the turn around time for that is on the order of 3-4 weeks (based on conversations with Gary), however it could be longer.  This will affect when the last IO chassis (LSC) can be made fully functional.  I did however pickup the 100 foot fiber cable for going between the LSC chassis and the LSC computer (which will be located in 1X3).

As a general piece of information, according to Gary the latest part number for these cards is OSS-SHB-ELB-x4/x8-2.0 and they cost 936 dollars (latest quote).

  3584   Fri Sep 17 14:55:01 2010 josephbUpdateCDSTook 5565 RFM card from IOVME to place in the new IOO chassis

I took the 5565 RFM card out of the IOVME machine to so I could put it in the new IO chassis that will be replacing it.  It is no longer on the RFM network.  This doesn't affect the slow channels associated with the auxilliary crate.

  3585   Fri Sep 17 17:35:35 2010 steveUpdatePEMcleaned up at 1Y1 PSL rack

Cleaned up cables on the top and bottom. Vacuumed both areas. We still have some remaining shading from the MOPA umbilical and more unknown BNC cables hanging around.

  3589   Mon Sep 20 11:39:45 2010 josephbUpdateCDSSwitch over

I talked to with Alex this morning, discussing what he needed to do to have a frame builder running that was compatible with the new front ends.

 

1) We need a heavy duty router as a separate network dedicated to data acquisition running between the front ends and the frame builder.  Alex says they have one over at downs, although a new one may need to be ordered to replace that one.

2) The frame builder is a linux machine (basically we stop using the Sun fb40m and start using the linux fb40m2 directly.).

3) He is currently working on the code today.  Depending on progress today, it might be installable tomorrow.

  3590   Mon Sep 20 16:59:26 2010 josephbUpdateCDSMegatron in 1X2 rack, to be come c1ioo

[Rana, Koji, Joe]

We pulled the phase shifters in the 1X2 rack out to make room for megatron.  Megatron will be converted into c1ioo, and the 8 core, 1U computer will be used as c1lsc.  A temporary ethernet cable was run from 1X2 to 1X3 to connect megatron to the same sub-network.

The c1lsc machine was worked on today, setting it up to run the real time code, along with the correct controls accounts, passwords, .cshrc files, etc.  It needs to be moved from 1X1 to 1X4 tomorrow.

  3593   Tue Sep 21 16:05:21 2010 josephbUpdateCDSFirst pass at rack diagram

I've made a first pass at a rack diagram for the 1X1 and 1X2 racks, attached as png.

Gray is old existing boards, power supplies etc.  Blue is new CDS computers and IO chassis, and gold is for the Alberto's new RF electronics.  I still need to double check on whether some of these boards will be coming out (perhaps the 2U FSS ref board?).

Attachment 1: 1X1_1X2_racks.png
1X1_1X2_racks.png
  3594   Wed Sep 22 16:35:45 2010 josephbUpdateCDSFibers pulled, new FB install tomorrow

[Aidan, Tara, Joe]

We pulled out what used to be the LSC/ASC fiber from the 1Y3 arm rack, and then redirected it to the 1X1 rack.  This will be used as the c1ioo 1PPS timing signal.  So c1ioo is using the old c1iovme fiber for RFM communications back to the bypass switch, and the old LSC fiber for 1PPS.

The c1sus machine will be using the former sosvme fiber for communications to the RFM bypass switch.  It already had a 1 PPS timing fiber.

The c1iscex machine had a new timing fiber already put in, and will be using the c1iscey vme crate's RFM for communication.

We still need to pull up the extra blue fiber which was used to connect c1iscex directly to c1sus, and reuse it as the 1PPS signal to the new front end on the Y arm. 

Alex has said he'll come in tomorrow morning to install the new FB code.

 

  3600   Thu Sep 23 12:05:20 2010 josephb, alexUpdateCDSfb40m down, new fb in progress

Alex came over this morning and we began work on the frame builder change over.  This required fb40m be brought down and disconnected from the RAID array, so the frame builder is not available.

He brought a Netgear switch which we've installed at the top of the 1X7 rack.  This will eventually be connected, via Cat 6 cable, to all the front ends.  It is connected to the new fb machine via a 10G fiber.

Alex has gone back to Downs to pickup a Symmetricon (sp?) card for getting timing information into the frame builder.  He will also be bringing back a harddrive with the necessary framebuilder software to be copied onto the new fb machine.

He said he'd like to also put a Gentoo boot server on the machine.  This boot server will not affect anything at the moment, but its apparently the style the sites are moving towards.  So you have a single boot server, and diskless front end computers, running Gentoo.  However for the moment we are sticking with our current Centos real time kernel (which is still compatible with the new frame builder code).  However this would make a switch over to the new system possible in the future.

At the moment, the RAID array is doing a file system check, and is going slowly while it checks terabytes of data.  We will continue work after lunch. 

 Punchline: things still don't work.

  3602   Thu Sep 23 21:01:11 2010 josephb, alexUpdateCDSfb40m still down, new fb still in progress
Unfortunately, copying the data to the USB/SATA drive over at downs took longer than expected for Alex. We will be installing the new code on the new fb machine tomorrow and running it. We will be running off of a timer on that machine until Monday. On Monday, a Symmetricom card will be arriving from LLO so that we can connect an IRIG-B timing signal into the frame builder and use a proper time signal. There is no running frame builder for tonight and thus will be no trends until we get the new FB running tomorrow morning.
  3604   Fri Sep 24 00:56:35 2010 koji, taraUpdateElectronicstesting TTFSS

We found that a transistor was broken from yesterday spark too. We partially fixed TTFSS, and it should be enough for  testing purpose.

 

From yesterday test, we found that the RF amplifier for LO signal was broken. There was no spare at the electronic shop at Downs,

so we shorted the circuit for now.  Another part which was broken too was a transistor, Q3 PZT2222A, on D0901846.

It was removed and two connections, which are for Q3's 1 and 3 legs, are shorted. Now the voltages out from the regulators are back to normal.

 

We are checking a MAX333A switch, U6A on D0901894. it seems that the voltage that controls the switch disappears.

There might be a bad connection somewhere. This will be investigated next.

  3606   Fri Sep 24 22:58:40 2010 josephbUpdateCDSModified front end medm screens

To startup medm screens for the new suspension front end, do the following:

1) From a control room machine, log into megatron

ssh -X megatron

2) Move to the new medm directory, and more specifically the master sub-directory

cd /opt/rtcds/caltech/c1/medm/master/

3) Run the basic sitemap in that directory

medm -x sitemap.adl

 

The new matrix of filters replacing the old ULPOS, URPOS, etc type filters is now on the screens.  This was previously hidden.  I also added the sensor input matrix entry for the side sensor.

Lastly, the C1SUS.txt filter bank was updated to place the old ULPOS type filters into the correct matrix filter bank.

 

The suspension controls still need all the correct values entered into the matrix entries (along with gains for the matrix of filter banks), as well as the filters turned on.  I hope to have some time tomorrow morning to do this, which basically involves looking at the old screens copying the values over.  The watch dogs are still controlled by the old control screens.  This will be fixed on Monday when I finish switching the front ends over from their sub-network to the main network, at which point logging into megatron will no longer be necessary.

  3607   Fri Sep 24 23:47:10 2010 koji, taraUpdateElectronicstesting TTFSS

  Q3, a PZT2222A transistor, on D0901846 is replaced by a GE-82. However, the board is still not fully function.

 

Since Q3, PZT2222A, was broken, I went to Wilson house and got some SP3904's for replacement. But somehow, I broke it during

installation, and did not notice it, and resumed the test. When I got to test 8 on the list, the TTFSS did not work as specified.

Koji checked and found out that -15V, Nref, Vref voltages output did not work correctly. So the SP3904 I installed was removed

and replaced with another SP3904 by Koji, and Vref is working. 

Q4 transistor is broken as well and it was replaced by GE 82.

Q1 might be broken too since -15V out is not working.

I'll go to Wilson house to get more transistors next week.

 

After the broken parts have been replaced, I have to make sure that I separate the power supply board from the rest of the circuit and

check if all V outputs are  working, then reconnect the board and check if the current input is reasonable before resume the test.

I hope the wrong input voltage problem today wouldn't damage anything else.

 

  3608   Sat Sep 25 19:01:13 2010 KojiUpdateElectronicstesting TTFSS

How much current do you need for each voltages?

GE-82 was the only PNP transister I could find in the lab. It's too old but we just like to confirm any other components are still functioning.

Similarly, we can confirm the functionality of the other components by skipping those current boost transisters,
if we don't need more than 30mA.

 

  3609   Sun Sep 26 18:29:23 2010 rana, JohnUpdateCDSModified front end medm screens

Issues I notice on first glance:

  1. The OSEM Sensor Input matrix and the DOF2COIL Output matrix screens should be their own screens and linked from the overview. Right now they are not. Where is the input matrix?
  2. The SIDE GAIN looks like zero on the main screen, but the side OSEM signal seems to be getting through to the SIDE filter bank. . I think the wiring of the SIDE signal through the input matrix is bogus.
  3. The OUTPUT matrix seems to be the transpose of the previous OUTPUT matrix and we have lost the wires that connect the inputs and outputs to the matrix. We ought to think about how best to represent things on the OVERVIEW screen; probably only need to have a minimal representation and allow power users to open up the detailed screen.
  4. The TIME string is whited out. How will this be done? Does each FE display its local time on its EPICS screens?
  5. So far unable to get any channels on DV. How do we look at channels / test points?
  6. As far as we can tell, there is no connection between the output of the SUSPOS, etc. filter banks and the OUTPUT MATRIX. So....nothing actually goes to the coil driver. Its hard to imagine that this new SUS could have ever worked. Is there any evidence that the damping actually worked in the past, or was it something like "well, the watchdog values came down to small numbers eventually..." ???
  7. We are trying to debug the simulink file, but....the wiki entry on how to do this is out of date (yet updated as recently as August!) some path stuff just probably needs to be edited.

 megamind-poster3.jpg

Basically the suspensions are not functioning yet and we can't attempt locking of the MC.

  3610   Mon Sep 27 00:33:50 2010 ranaUpdatePSLHigh Voltage Driver added to TTFSS -> NPRO

We added the Thorlabs HV Driver in between the FSS and the NPRO today. The FSS is locking with it, but we haven't taken any loop gain measurements.

This box takes 0-10 V and puts out 0-150 V. I set up the FSS SLOW loop so that it now servos the output of FAST ot be at +5V instead of 0V. This is an OK

temporary solution. In the future, we should add an offset into the output of the FSS board so that the natural output is 0-10 V.

I am suspicious that the Thorlabs box has not got enough zip to give us a nice crossover and so we should make sure to measure its frequency response with a capacitive load.

  3612   Mon Sep 27 17:35:13 2010 josephbUpdateCDSUpdated Suspension screens/Megatron now c1ioo/Further work on fb

The medm screens have been updated further, with the hidden matrices added in bright colors.  An example screen shot is attached.

Megatron has been renamed c1ioo and moved to martian network.  Similarly, c1sus and c1iscex are also on the martian network.  Medm screens can be run on any of the control machines and they will work.

Currently the suspension controller is running on c1sus.

The frame builder is currently running on the fb machine *however* it is not working well.  Test points and daq channels on the new front ends tended to crash it when Alex started the mx_stream to the fb via our new DAQ network (192.168.114.XXX, accessible through the front ends or fb - has a dedicated 1 gigabit network with up to 10 gigabit for the fb).  So for the moment, we're running without front end data. Alex will be back tomorrow to work on it. 

Alex claimed to have left the frame builder in a state where it should be recording slow data, however, I can't seem to access recent trends (i.e. since we started it today).  The frame builder throws up an error "Couldn't open raw minute trend file '/frames/trend/minute_raw/C1:Vac-P1_pressure', for example.  Realtime seems to work for slow channels however.  Remember to connect to fb, not fb40m. So it seems the fb is still in a mostly non-functional state.

Alex also started a job to convert all the old trends to the correct new data format, which should finish by tomorrow.

RA: Nice screen work. The old screens had a 'slow' slider effect when ramping the bias so that we couldn't whack the optic too hard. Is the new one instantaneous?

Attachment 1: MC1_Example_Screen.png
MC1_Example_Screen.png
  3613   Mon Sep 27 21:57:59 2010 ZachUpdateelogelog restarted

 took two runs of the script as usual

  3615   Tue Sep 28 10:07:29 2010 josephbUpdateCDSUpdated Suspension screens/Megatron now c1ioo/Further work on fb

Quote:

RA: Nice screen work. The old screens had a 'slow' slider effect when ramping the bias so that we couldn't whack the optic too hard. Is the new one instantaneous?

 Looking at the sliders, I apparently still need to connect them properly.  There's a mismatch between the medm screen channel name and the model name.  At the moment there is no "slow" slider effect implemented, so they are effectively instantaneous.  Talking with Alex, he suggests writing a little c-code block and adding it to the model.  I can use the c code used in the filter module ramps as a starting point.

  3616   Tue Sep 28 14:12:14 2010 steveUpdateGeneralvertex crane drive is out of order

The vertex crane drive is overheating, it stopped functioning. Service man will be here tomorrow morning.

I crane was just turned  on for for may be  about 5 minutes. The vertical drive was fine for a while, but the horizontal did not worked at all.

The crane is tagged out again and the controller box is cooling down.

  3617   Tue Sep 28 21:11:52 2010 koji, taraUpdateElectronicsFixing the new TTFSS

We found a small PCB defect which is an excess copper shorting circuit on the daughter board,

it was removed and the signal on mixer monitor path is working properly.

 

 We were checking the new TTFSS upto test 10a on the instruction, E1000405 -V1. There was no signal at MIXER mon channel.

It turned out that U3 OpAmp on the daughter board, D040424, was not working because the circuit path for leg 15 was shorted

because of the board's defect. We can see from fig1 that the contact for the OpAmp's leg (2nd from left) touches ground.

We used a knife to scrap it out, see fig 2, and now this part is working properly.

 

Attachment 1: before.jpg
before.jpg
Attachment 2: after.jpg
after.jpg
Attachment 3: before.jpg
before.jpg
Attachment 4: after.jpg
after.jpg
  3618   Wed Sep 29 01:53:44 2010 ranaUpdatePSLpaths broken and VCO turned off

I found that several linux libraries have been moved around and disabled today. In particular, I see a bunch of new stuff in apps/linux/ and ezca tools are not working.

Who did this and why is there no ELOG ???

 

Also found that someone has pulled the power cable to the function generator I was using to set the VCO offset. This is the one on top of the Rb clocks. Why?? Why no elog? This is again a big waste of time.

  3619   Wed Sep 29 11:18:36 2010 josephbUpdateCDSApps code changes

After asking Alex specifically what he did yesterday after I left, he indicated he copied  a bunch of stuff from Hanford, including the latest gds, fftw, libframe, root.  We also now have the new dtt code as well.  But those apparently were for the Gentoo build   After asking Alex about the ezca tools this morning, he discovered they weren't complied in the gds code he brought over.  We are in the process of getting the source over here and compiling the ezca tools. 

 

Alex is indicating to me that the currently compiled new gds code may not run on the Centos 5.5 since it was compiled Gentoo (which is what our new fb is running and apparently what they're using for the front ends at Hanford).  We may need to recompile the source on our local Centos 5.5 control machines to get some working gds code.  We're in the process of transferring the source code from Hanford.  Apparently this latest code is not in SVN yet, because at some point he needs to merge it with some other work other people have been doing in parallel and he hasn't had the time yet to do the work necessary for the merge.

For the moment, Alex is undoing the soft link changes he did pointing gds at the latest gds code he copied, and pointing back at the original install we had.

  3621   Wed Sep 29 15:34:46 2010 kiwamuUpdateGeneralfixing vertex crane
From Vertex crane -- fixing


Quote:

The vertex crane drive is overheating, it stopped functioning. Service man will be here tomorrow morning.

I crane was just turned  on for for may be  about 5 minutes. The vertical drive was fine for a while, but the horizontal did not worked at all.

The crane is tagged out again and the controller box is cooling down.

 

  3622   Wed Sep 29 16:56:36 2010 yutaUpdateVAC2 doors opened

(Steve, Koji, Joe, Kiwamu, Yuta)

Background:
 The vent was started on Monday, and finished on Tuesday.
 We were to open the doors on Tuesday, but we couldn't because the vertex crane got out of order.
 Now the crane was fixed, and so we opened the doors today.

What we did:

 We opened the north side of the BS chamber and the west side of the ITMX chamber.
 Now, the light doors are put instead.

  3623   Wed Sep 29 18:28:32 2010 yutaUpdateComputersaldabella connects to the wireless network

Background:
 We need laptops that connect to the wireless network to use them in the lab.

aldabella:
 Dell Inspiron E1505 laptop
 Broadcom Corporation BCM4311 802.11b/g WLAN (rev 01) (PCIID: 14e4:4311 (rev 01))

What I did:
1. I followed this method(Japanese!): http://www.linuxmania.jp/wireless_lan.html
 Except I installed ndiswrapper-1.56 and cabextracted sp32156.exe.
  http://sourceforge.net/apps/mediawiki/ndiswrapper/index.php?title=Broadcom_BCM4311
 Also, I didn't run
  # ndiswrapper -m

2. Then I did step #6 in here: http://nodus.ligo.caltech.edu:8080/40m/1275
 Note that the hardware is eth1 instead of wlan0.

3. Added the following line to /etc/rc.d/rc.local to make ndiswrapper load on every boot:
 /sbin/modprobe ndiswrapper

Result:
 aldabella now connects to the wireless martian network on every boot!!

Note:
 Somehow, the method that uses Broadcom official driver doesn't work.
  http://wiki.centos.org/HowTos/Laptops/Wireless/Broadcom
 It returns the following error when activating eth1:
  Error for wireless request "Set Encode" (8B2A) :
    SET failed on device eth1 ; Invalid argument.
  Error for wireless request "Set Encode" (8B2A) :
    SET failed on device eth1; Invalid argument.

  3624   Thu Sep 30 09:34:58 2010 steveUpdateGeneralvertex crane trolly drive fixed

Quote:

The vertex crane drive is overheating, it stopped functioning. Service man will be here tomorrow morning.

I crane was just turned  on for for may be  about 5 minutes. The vertical drive was fine for a while, but the horizontal did not worked at all.

The crane is tagged out again and the controller box is cooling down.

 Atm1, Vertex crane controller unit on horizontal I-beam.

            Module CCES-407 1HP 2.3A 460V/3 phase on the right was replaced. Speed was increased  to 30 Hz

Atm2, See burned insulation on black wire that was shorting to the large suppressor resistor on Atm3 One can see the pit marks on the right end of it.

        This large power dissipater resistor got hot as the malfunctioning controller 407 broke down.   Touching black power wire insulation melted and made a short.

          So the heat was created and finally the fuses were blown. The unnecessary large fuses were replaced by small ones.

Fortunately we had one spare controller on hand that made this repair to be done fast.

We used the new Crane Safety Check list  from LIGO-E1000379-v1 the first time yesterday before doors were removed.

Attachment 1: P1060891.JPG
P1060891.JPG
Attachment 2: P1060887.JPG
P1060887.JPG
Attachment 3: P1060889.JPG
P1060889.JPG
Attachment 4: P1060893.JPG
P1060893.JPG
  3625   Thu Sep 30 11:07:20 2010 josephb, alexUpdateCDStest points starting to work

The centos 5.5 compiled gds code is currently living on rosalba in the /opt/app directory (this is local to Rosalba only).  It has not been fully compiled properly yet.  It is still missing ezcaread/write/ and so forth.  Once we have a fully working code, we'll propagate it to the correct directories on linux1.

So to have a working dtt session with the new front ends, log into rosalba, go to opt/apps/, and source gds-env.bash in /opt/apps (you need to be in bash for this to work, Alex has not made a tcsh environment script yet).  This will let get testpoints and be able to make transfer function measurements, for example

Also, to build the latest awgtpman, got to fb, go to /opt/rtcds/caltech/c1/core/advLigoRTS/src/gds, and type make.  This has been done and mentioned just as reference.

The awgtpman along with the front end models should startup automatically on reboot of c1sus (courtesy of the /etc/rc.local file).

  3626   Thu Sep 30 13:43:29 2010 steveUpdateSAFETYpropane gas smell in control room

The control room's north west corner smelled like propane gas  yesterday around 16:30

We all agreed that the smell was real and I called the safety office. I was told that they received 6 other calls from different parts of the campus.

The smell disappeared in about a half an hour.

  3627   Thu Sep 30 14:09:33 2010 yutaUpdateComputersmariabella connects to the wireless network

Background:
 We need laptops that connect to the wireless network to use them in the lab.

mariabella:
 Dell Inspiron 1210 laptop
 Broadcom Corporation BCM4312 802.11b/g (rev 01) (PCIID: 14e4:4315 (rev 01))

What I did:
1. I followed the same steps I did for aldabella: http://nodus.ligo.caltech.edu:8080/40m/3623
 Except I unzipped R151517-pruned.zip.
   http://myspamb8.googlepages.com/R151517-pruned.zip

2. Note that the PCIID is important for driver selection. Not the model No.
 To check whether your driver selection is correct, run:
  # ndiswrapper -l
 after installing the driver.
 If the driver selection is wrong, it will return only:
  bcmwl5 : driver installed
 If correct, it will return:
  bcmwl5 : driver installed
         device (14E4:4315) present (alternate driver: hoge)

 This page has some information for the driver selection:
   https://help.ubuntu.com/community/WifiDocs/Driver/bcm43xx/Feisty_No-Fluff#Step%202:%20Download%20and%20Extract%20Drivers

Result:
 aldabella now connects to the wireless martian network.

Note:

 Broadcom official driver didn't work for mariabella, too.

  3628   Thu Sep 30 16:29:35 2010 josephb, alexUpdateCDSfb update

There currently seems to be a timing issue with  the frame builder.  We switched over to using a symmetricom card to get an IRIG-B signal into the fb machine, but the gps time stamp is way off (~80 years Alex said).

If there is a frame buiilder issue, its currently often necessary to kill the associated mx_stream processes, since they don't seem to restart gracefully.  To fix it the following steps should be taken:

Kill frame builder, kill the two mx_stream processes, then /etc/restart_streams/, then restart the frame builder (usual daqd -c ./daqdrc >& ./daqd.log in /opt/rtcds/caltech/c1/target/fb).

To restart (or start after a boot) the nds server, you need to go to /opt/rtcds/caltech/c1/target/fb and type

./nds /opt/rtcds/caltech/c1/target/fb/pipe

At this time, testpoints are kind of working, but timing issues seem to be preventing useful work being done with it.  I'm leaving with Alex working on the code.

 

  3629   Thu Sep 30 17:11:01 2010 alex iUpdateCDSDAQ system update

The frame builder is timed from the Symmetricom GPS card now, which is getting the IRIGB timecode from the freq. distribution amplifier (from the VME GPS receiver card).

I have adjusted the GPS seconds to match the real GPS time and the DTT seems to be happy: sweeping MC2 MCL filter module produces nice plot.

Test points are working on SUS.

Excitations are working on SUS.

I am leaving the frame builder running and acquiring the data.

 

Alex

 

  3630   Thu Sep 30 18:51:50 2010 yutaUpdateComputerssetting up aldabella and mariabella

(Kiwamu, Yuta)

Background:
 We wanted to make aldabella and mariabella know how to work.

What we did:

1. Added 2 lines to /etc/rc.local
 /sbin/modprobe ndiswrapper
 sleep 10
 mount linux1:/home/cds/ /cvs/cds


2. Edited ~/.cshrc
 source /cvs/cds/caltech/cshrc.40m

Result:
 Working environment is set to aldabella and mariabella. They have their access to the main system, linux1, now.

Note:
 fstab doesn't work for aldabella and mariabella because the mount should be done after ndiswrapper loads.

ELOG V3.1.3-