40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 45 of 341  Not logged in ELOG logo
ID Dateup Author Type Category Subject
  2217   Mon Nov 9 15:11:02 2009 AlbertoUpdateLSCEverything put back as it was

Quote:

I disconnected the setup for the arm cavity TF measurement. I opened the scitation switch on the ISS medm screen. I reconnected the OMC ISS EXC cable to the breakout box on the floor.

The photodiode on the Y end is stilll connected.

Also the RFAm (whish is not disbaled anymore) still has a 50% beam splitter before it.

I'm also running the Align Full IFO script.

 

I removed the beam splitter and the PDA 255.

the beam path to the RFAM photodiode is clear again.

  2218   Mon Nov 9 15:21:37 2009 JenneUpdateGeneralDrill Press is down for the count

Quote:

The on/off switch for the drill press is broken.  Replacement parts should be here tomorrow. 

 Drill press is all better now.  A spare switch is in the top drawer with the drill bits.

  2219   Mon Nov 9 16:32:36 2009 AlbertoFrogsEnvironmentShot of the white board yesterday before erasing

Yesterday Rana and I needed some room on the white board in the Control Room. We had to erase some of the stuff present on the board despite the bif warning "Do Not Erase".

This is how it looked like before erasing.

DSC_0980.JPG

Attachment 1: DSC_0980.JPG
DSC_0980.JPG
  2220   Mon Nov 9 18:27:30 2009 AlbertoFrogsComputersOMC DCPD Interface Box Disconnected from the power Supply

This afternoon I inadvertently disconnected one of the power cables coming from the power supply on the floor next to the OMC cabinet and going to the DCPD Interface Box.

Rob reconnected the cable as it was before.

  2221   Mon Nov 9 18:32:38 2009 robUpdateComputersOMC FE hosed

It won't start--it just sits at Waiting for EPICS BURT, even though the EPICS is running and BURTed.

 

[controls@c1omc c1omc]$ sudo ./omcfe.rtl
cpu clock 2388127
Initializing PCI Modules
3 PCI cards found
***************************************************************************
1 ADC cards found
        ADC 0 is a GSC_16AI64SSA module
                Channels = 64
                Firmware Rev = 3

***************************************************************************
1 DAC cards found
        DAC 0 is a GSC_16AO16 module
                Channels = 16
                Filters = None
                Output Type = Differential
                Firmware Rev = 1

***************************************************************************
0 DIO cards found
***************************************************************************
1 RFM cards found
        RFM 160 is a VMIC_5565 module with Node ID 130
***************************************************************************
Initializing space for daqLib buffers
Initializing Network
Waiting for EPICS BURT


  2222   Mon Nov 9 19:04:23 2009 robUpdateComputersOMC FE hosed

Quote:

It won't start--it just sits at Waiting for EPICS BURT, even though the EPICS is running and BURTed.

 

[controls@c1omc c1omc]$ sudo ./omcfe.rtl
cpu clock 2388127
Initializing PCI Modules
3 PCI cards found
***************************************************************************
1 ADC cards found
        ADC 0 is a GSC_16AI64SSA module
                Channels = 64
                Firmware Rev = 3

***************************************************************************
1 DAC cards found
        DAC 0 is a GSC_16AO16 module
                Channels = 16
                Filters = None
                Output Type = Differential
                Firmware Rev = 1

***************************************************************************
0 DIO cards found
***************************************************************************
1 RFM cards found
        RFM 160 is a VMIC_5565 module with Node ID 130
***************************************************************************
Initializing space for daqLib buffers
Initializing Network
Waiting for EPICS BURT


 

From looking at the recorded data, it looks like the c1omc started going funny on the afternoon of Nov 5th, perhaps as a side-effect of the Megatron hijinks last week.

 

It works when megatron is shutdown.

  2223   Mon Nov 9 19:09:09 2009 JenneUpdatePEMNoise floor of the Ranger Seismometer

To estimate the noise floor of the Ranger, Rana and I locked the mass on the seismometer, so there will be no (aka minimal) signal from the motion of the ground in the pickup coil.  We should be seeing primarily the noise of the readout electronics.  We also put the Ranger on top of one of the foam lids from the Seismometer Isolation Boxes to further isolate from ground motion (this didn't change the signal noticeably).  

In this plot, Green is the locked-mass-on-foam noise floor, blue is the regular spectra, with the SR560 AC coupled, and the red is the regular seismic spectra with the SR560 DC coupled.  There doesn't seem to be a noticeable difference between blue and red (the spectra were taken at different times of day, with the red taken at night, when we generally expect things to be quieter).  I'm leaving the SR560 DC coupled.  (Rana had found it earlier this afternoon GND coupled....not sure yet why).

Also, we're not sure that the green curve is true readout noise, vs. how much of it is specifically due to the fact that the mass is locked down.  Especially around a few hundred Hz, the green curve is much higher than the other 2, and at a few tens of Hz there is some weird peak action.  However, this will be okay as a first-run noise estimate for the Ranger's noise floor.

The question at hand is: Do we need to redo any of the Ranger's readout electronics (i.e. replace the SR560 with a Pomona Box circuit) to lower the noise floor, or is it okay as-is?

Attachment 1: Ranger_noiseFloor_Spectra.png
Ranger_noiseFloor_Spectra.png
  2224   Mon Nov 9 19:44:38 2009 rob, ranaUpdateComputersOMC FE hosed

 

We found that someone had set the name of megatron to scipe11. This is the same name as the existing c1aux in the op440m /etc/hosts file.

We did a /sbin/shutdown on megatron and the OMC now boots.

Please: check to see that things are working right after playing with megatron or else this will sabotage the DR locking and diagnostics.

  2225   Tue Nov 10 10:51:00 2009 josephb, alexUpdateComputersMegatron on, powercycled c1omc, and burt restored from 3am snapshot

Last night around 5pm or so, Alex had remotely logged in and made some fixes to megatron.

First, he changed the local name from scipe11 to megatron.  There were no changes to the network, this was a purely local change.  The name server running on Linux1 is what provides the name to IP conversions.  Scipe11 and Megatron both resolve to distinct IPs. Given c1auxex wasn't reported to have any problems (and I didn't see any problems with it yesterday), this was not a source of conflict.  Its possible that Megatron could get confused while in that state, but it would not have affected anything outside its box.

Just to be extra secure, I've switched megatron's personal router over from a DMZ setup to only forwarding port 22.  I have also disabled the dhcp server on the gateway router (131.215.113.2).

Second, he turned the mdp and mdc codes on.  This should not have conflicted with c1omc.

This morning I came in and turned megatron back on around 9:30 and began trying to replicate the problems from last night between c1omc and megatron.  I called Alex and we rebooted c1omc while megatron was on, but not running any code, and without any changes to the setup (routers, etc).  We were able to burt restore.  Then we turned the mdp, mdc and framebuilder codes on, and again rebooted c1omc, which appeared to burt restore as well (I restored from 3 am this morning, which looks reasonable to me). 

Finally, I made the changes mentioned above to the router setups in the hope that this will prevent future problems but without being able to replicate the issue I'm not sure.

  2226   Tue Nov 10 13:02:36 2009 AlbertoUpdateLSCX and Y Arm Cavity Poles Measurement

From fitting the arm cavity transfer functions I got the following values for the cavity pole frequencies.

X ARM: fp_x = (1720 +/- 70) Hz

Y ARM: fp_y = (1650 +/- 70) Hz

Attached are the plots from the fitting.

Attachment 1: SummaryOfFits.pdf
SummaryOfFits.pdf SummaryOfFits.pdf
Attachment 2: CodeAndData.tar
  2227   Tue Nov 10 17:01:33 2009 AlbertoConfigurationIOOc1ioovme and c1iool0 rebooted

This afternoon, while I was trying to add the StochMon channels to the frames, I rebooted the c1ioovme and c1iool0.

I had to do it twice because of a mispelling in the C1IOO.INI file that the first time prevented the computer to restart properly.

Eventually I restored the old .ini file, as it was before the changes.

After rebooting I also burtrestored.

During the process the mode cleaner got unlocked. Later on the autoclokcer couldn't engage. I had to run the MC_down and MC_up scripts.

  2228   Tue Nov 10 17:49:20 2009 AlbertoMetaphysicsComputersTest Point Number Mapping

I found this interesting entry by Rana in the old (deprecated) elog : here

I wonder if Rolf has ever written the mentioned GUI that explained the rationale behind the test point number mapping.

I'm just trying to add the StochMon calibrated channels to the frames. Now I remember why I kept forgetting of doing it...

  2229   Tue Nov 10 19:19:57 2009 AlbertoUpdateABSLRotated polarizer on the PSL table, along the MC input pick off beam

Aligning the beam for the PLL of the AbsL Experiement I rotated the polarizer along the path of the MC Input pick off beam (= the pick off coming from the MC periscope).

  2230   Tue Nov 10 19:21:53 2009 AlbertoUpdateABSLPLL Alignment

I've been trying to lock the PLL for the AbsL Experiment but I can't see the beat (between the auxiliary NPRO and the PSL).

I believe the alignment of the PLL is not good. The Farady Isolator is definitely not perfectly aligned (you can see it from the beam spot after it) but still it should be enough to see something at the PLL PD.

it's probably just that the two beams don't overlap well enough on the photodiode. I'll work on that later on.

I'm leaving the lab now. I left the auxiliary NPRO on but I closed its shutter.

All the flipping mirrors are down.

  2231   Tue Nov 10 21:46:31 2009 ranaSummaryComputersTest Point Number Mapping

Quote:

I found this interesting entry by Rana in the old (deprecated) elog : here

I wonder if Rolf has ever written the mentioned GUI that explained the rationale behind the test point number mapping.

I'm just trying to add the StochMon calibrated channels to the frames. Now I remember why I kept forgetting of doing it...

 As far as I know, the EPICS channels have nothing to do with test points.

  2232   Wed Nov 11 00:55:47 2009 JenneUpdateAdaptive FilteringTerms put on some ADC inputs

Mostly a note to self:  I have put terminators on the ADC inputs which are usually the PEM-SEIS-GUR2_(XYZ) channels.  Since these 3 signals are currently going into the ASS ADC, these PEM ADC inputs are open, and have predefined channel names.  I'll collect the data and put it as the ADC noise level in my nifty plot which will show the noise limits of all things which affect Wiener Filtering.

  2233   Wed Nov 11 01:33:52 2009 peteUpdateCDSRCG ETMY code update

 I've added the side coil to the model controller and plant, and the oplev quad to the model controller and plant.  After the megatron wipe, the code now lives in /home/controls/cds/advLigo/src/epics/simLink.  The files are mdc.mdl (controller) and mdp.mdl (plant).  These RCG modules go at 16K with no decimation (no_oversampling=1 in the cdsParameters block) so hopefully will work with the old (16K) timing.

I've loaded many of the filters, there are some eft to do.  These filters are simply copied from the current frontend.  

Next I will port to the SUS module (which talks to the IO chassis).  This means channel names will match with the current system, which will be important when we plug in the RFM.

  2234   Wed Nov 11 09:48:04 2009 steveUpdateIOOwhere is IOO-RFAMPD_DCMON ?

RFAMPD_DCMON disappered on Nov 5, 2009

Attachment 1: rfampddc.jpg
rfampddc.jpg
  2236   Wed Nov 11 12:29:44 2009 AlbertoFrogsPSLMC Locked on the wrong mode?

This morning, after Steve pointed out that the readout RFAMPD_DC was zero, I thought of realigning the beam on the photodiode. Maybe I touched the lens or the beam splitter that send the beam on the diode when I installed an other beam splitter to make the measurement of the calibration between two ThorLabs PDA255 photodiodes.

After aligning the beam on the RFAMPD, the voltage of the DC readout was lower than it used to be (C1:IOO-RFAMPD_DC ~ 0.4 now vs. 4 as it was on November 4th).

I maximized the DC readout but the problem seems to be that the beam spot is not a round TEM00. In particular the spot looks like that of a TEM10 mode.

Since we're looking at the MC transmitted beam, is it possible that the MC is locked on the wrong mode?

Check out the attached picture.

Attachment 1: PB110184-1.JPG
PB110184-1.JPG
  2237   Wed Nov 11 12:50:10 2009 JenneUpdatePEMSeismometer Noise Characteristics

The attached plot shows the spectra of the 3 Z axes of the 3 seismometers we have (this data is from ~20Aug2009, when the Ranger was in the Z orientation) in Magenta, Cyan and Green, and the noise of each of the sensors in Red, Blue and Black.  The noise curves were extracted from the spectra using the Huddle Test / 3 Corner Hat method.  The Blue and Black traces which are just a few points are estimates of the noise from other spectra.  The Blue points come from the Guralp Spec Sheet, and the Black comes from the noise test that Rana and I did the other day with the Ranger (elog 2223).  

I'm not really happy with the black spectra - it looks way too high.  I'm still investigating to see if this is a problem with my calibration/method....

Attachment 1: HuddleTest_Aug2009data.png
HuddleTest_Aug2009data.png
  2238   Wed Nov 11 15:04:52 2009 AlbertoUpdateABSLWorking on the AP table

I've opened the AP table and I'm working on it.

  2239   Wed Nov 11 16:18:57 2009 AlbertoUpdateABSLWorking on the AP table

Quote:

I've opened the AP table and I'm working on it.

I re-aligned the Faraday on the AP table. I also aligned the beam to the periscope on the PSL and all the other optics along the beam path.  Now I have a nice NPRO beam at the PLL which overlaps with the PSL beam. The alignment has to be further improved because I see no beat yet.

I wonder if the all the tinkering on the PSL laser done recently to revive the power has changed the PSL NPRO temperature and so its frequency. That could also explain why the beat doesn't show up at the same temperature of the NPRO as I used to operate it. Although I scanned the NPRO temperature +/- 2 deg and didn't see the beat. So maybe the misalignment is the casue.

Not feeling very well right now. I need to go home for a while.

AP table closed at the moment.

NPRO shutter closed

  2240   Wed Nov 11 17:10:51 2009 JenneUpdateABSLWorking on the AP table

Quote:

Quote:

I've opened the AP table and I'm working on it.

I re-aligned the Faraday on the AP table. I also aligned the beam to the periscope on the PSL and all the other optics along the beam path.  Now I have a nice NPRO beam at the PLL which overlaps with the PSL beam. The alignment has to be further improved becasue I see no beat yet.

I wonder if the all the tinkering on the PSL laser done recently to revive the power have changed the PSL NPRO temperature and so its frequency. That could also explain why the beat doesn't show up at the same temperature of the NPRO as I used to operate it. Although I scanned the NPRO temperature +/- 2 deg and didn't see the beat. So maybe the misalignment is the casue.

Not feeling very well right now. I need to go home for a while.

AP table closed at the moment.

NPRO shutter closed

 We definitely changed the PSL NPRO temp while fiddling around, trying to increase the laser power.  I think it's noted in the elog both times that it's happened in the last few months (once when Rana, Koji and I worked on it, and then again when it was just Koji), but we opened up the side of the MOPA box so that we could get at (and change) the potentiometer which adjusts the NPRO temp.  So you may have to search around for a while.

  2241   Wed Nov 11 17:33:54 2009 KojiUpdateABSLWorking on the AP table

Yes it did.

For long time, the crystal temperature C1:PSL-126MOPA_LTMP was 43~46deg. Now it is 34deg. Try ~10deg lower temperature.

Quote:

I wonder if the all the tinkering on the PSL laser done recently to revive the power have changed the PSL NPRO temperature and so its frequency. That could also explain why the beat doesn't show up at the same temperature of the NPRO as I used to operate it. Although I scanned the NPRO temperature +/- 2 deg and didn't see the beat.

 

  2242   Wed Nov 11 18:43:57 2009 rana, kojiHowToPhotosIlluminated Paintbrush Technique

IMG_0215.JPGIMG_0214.JPG

1/4" exposure, standard room lights                                                                              3" exposure, slowly moving LED bar light from ~60 cm distance

Note:
Because of the light behind, the focus was attracted by the far objects...
Evenso the magnet ball looks better in the right picture.

The technique is as follows:
Use longer exposure time, move the LED bar illumination through the area like painting the light everywhere.
It is supposed to provide a picture with more uniform light and the diminished shadow.

(KA)

  2243   Wed Nov 11 20:46:07 2009 peteUpdateCDSRCG ETMY phase I update

The .mdl code for the mdc and mdp development modules is finished.  These modules need more filters, and testing.  Probably the most interesting piece left to do is putting in the gains and filters for the oplev model in mdp.  It might be OK to simply ignore oplevs and first test damping of the real optic without them.   However, it shouldn't be hard to get decent numbers for oplevs, add them to the mdp (plant) module, and make sure the mdc/mdp pair is stable.  In mdp, the oplev path starts with the SUSPIT and SUSYAW signals. Kakeru recently completed calibration of the oplevs from oplev cts to radians:   1403  .  From this work we should find the conversion factors from PIT and YAW to oplev counts, without making any new measurements.  (The measurements wouldn't be hard either, if we can't simply pull numbers from a document.)  These factors can be added to mdp as appropriate gains.

I've also copied mdc to a new module, which I've named "sas" to address fears of channel name collisions in the short term, and replaced the cpu-to-cpu connections with ADC and DAC connections.  sas can be the guy for the phase I ETMY test.  When we're happy with mdc/mdp, we hopefully can take the mdc filter file from chans, replace all the "MDC" strings with "SAS", and use it.

  2244   Wed Nov 11 20:57:06 2009 kiwamuUpdateElectronicsMulti-resonant EOM --- LC tank circuit ---

I have been working about multi-resonant EOM since last week.

In order to characterize the behavior of the each components, I have made a simple LC tank circuit.

You can see the picture of the circuit below.

DSCN0160.JPG

Before constructing the circuit, I made an "ideal" calculation of the transfer function without any assumptions by my hand and pen.

Most difficult part in the calculation is the dealing with a transformer analytically. Eventually I found how to deal with it in the analytical calculation.

The comparison of the calculated and measured transfer function is attached.

 It shows the resonant frequency of ~50MHz as I expected. Those are nicely matched below 50MHz !!

For the next step, I will make the model of the circuit with stray capacitors, lead inductors, ... by changing the inductance or something. 

 

Attachment 2: LCtank_complete.png
LCtank_complete.png
  2245   Wed Nov 11 21:30:20 2009 HaixingUpdateGeneralmagnetic levitation modelling files uploaded to svn

I have created a directory under the svn. The link is https://nodus.ligo.caltech.edu:30889/svn/trunk/docs/haixing

In the directory, there are three folders are related to the magnetic levitation.

 

The experimental data is in the "experiment_data".

 

The comsol numerical modelling files are in "mag_levi_comsol_modelling" which contains "1x1 magnets",

"4x4 magnets" and "16x16 magnets" sub-folders where detailed modelling results are included.The mathematica

notebooks in those folders are used to produce the plots I posted on the wiki page.

 

The "mag_levi_feedback" contains the Simulink modelling of the feedback loop. To generate the plot for the

open-loop transfer function. One needs to ruc the "mag_lev.m" file.

 

 

 

  2246   Thu Nov 12 01:18:34 2009 haixingUpdateSUSopen-loop transfer function of mag levi system (comparison between simulink and measurement)

I built a Simulink model of the magnetic levitation system and try to explain the dip in the open-loop transfer function that was observed.

One can download the model in the svn. The corresponding block diagram is shown by the figure below.

 

block_diagram.png

Here "Magnet" is equal to inverse of the magnet mass. Integrator "1/s" gives the velocity of the magnet. A further integrator gives the displacement of the magnet.

 

Different from the free-mass response, the response of the magnet is modified due to the existence of the Eddy-current damping  and negative spring in the vertical

direction, as indicated by the feedback loops after two integrals respectively. The motion of the magnet will change the magnetic field strength which in turn will pick

up by the Hall-effect sensor. Unlike the usual case, here the Hall sensor also picks up the magnetic field created by the coil as indicated by the loop below the mechanical

part. This is actually the origin of the dip in the open-loop transfer function. In the figure below, we show the open-loop transfer function and its phase contributed by both

the mechanical motion of the magnet and the Hall sensor with the black curve "Total". The contribution from the mechanical motion alone is shown by the magenta curve

"Mech" which is obtained by disconnecting the Hall sensor loop (I rescale the total gain to fit the measurement data due to uncertainties in those gains indicated in the figure). 

The contribution from the Hall sensor alone is indicated by the blue curve "Hall" which  is obtained by disconnecting the mechanical motion loop. Those two contributions

have the different sign as shown by the phase plot, and they destructively interfere with each other and create the dip in the open-loop transfer function.

contribution_plot.png

In the following figure, we show the close-loop response function of the mechanical motion of the magnet.

 

mech_resp_plot.png

As we can see, even though the entire close loop of the circuit is stable, the mechanical motion is unstable around 10 Hz. This simply comes from the fact that

around this frequency, the Hall sensor almost has no response to the mechanical motion due to destructive interference as mentioned.

 

In the future, we will replace the Hall sensor with an optical one to get rid of this undesired destructive interference.

 

 

  2247   Thu Nov 12 02:02:18 2009 ranaSummaryLSCArm Locking with no feedback to the ETM or ITM

Steps:

1) Turn off feedback to ETMY (the ETMY button on the LSC screen).

2) Put a 1 into the YARM->MC2 output matrix element on the LSC screen.

3) Turn off FM6 (comb), FM7 (0.1:10) on the MC2_MCL filter bank. This is to make the IOO-MCL loop more stable and to reduce the IOO-MCL low frequency gain.

4) Set the MC2-LSC gain to 0.5, turn the output ON, turn ON FM4 & FM5 & FM6 of the MC2-LSC filter bank.

5) Turn on the input of MC2-LSC and the arm should now lock.

6) After locking, set the MC2-MCL gain to zero. Hopefully with a few second ramp time.

Voila!

(A comment by KA - c.f. this entry )

Attachment 1: nohands-2.pdf
nohands-2.pdf
  2248   Thu Nov 12 09:43:29 2009 steveUpdatePEMconstruction has started at CES

The concrete  floor cutting has begun next door at CES

Attachment 1: cuttingconcr.jpg
cuttingconcr.jpg
Attachment 2: cutcon1.JPG
cutcon1.JPG
Attachment 3: cutcon2.JPG
cutcon2.JPG
  2249   Thu Nov 12 10:45:02 2009 AlbertoUpdatePSLAbandoned Frequency Generator

This morning I found a frequency generator connected to something on the PSL table sitting on the blue step next to the sliding doors.

Is anyone using it? Has it been forgotten there? If that's the case, can the interested person please take care of removing it?

  2250   Thu Nov 12 10:45:36 2009 AlbertoUpdateABSLWorking on the AP table

I've opened the AP table and I'm working on it.

Also auxiliary NPRO turned on and mechanical shutter opened.

  2251   Thu Nov 12 11:19:10 2009 KojiUpdatePSLAbandoned Frequency Generator

Last night there was an activity for a calibratuon work, which I helped. I can take care of the FG.

Quote:

This morning I found a frequency generator connected to something on the PSL table sitting on the blue step next to the sliding doors.

Is anyone using it? Has it been forgotten there? If that's the case, can the interested person please take care of removing it?

 

  2252   Thu Nov 12 11:34:38 2009 AlbertoUpdateABSLWorking on the AP table

Quote:

Yes it did.

For long time, the crystal temperature C1:PSL-126MOPA_LTMP was 43~46deg. Now it is 34deg. Try ~10deg lower temperature.

Quote:

I wonder if the all the tinkering on the PSL laser done recently to revive the power have changed the PSL NPRO temperature and so its frequency. That could also explain why the beat doesn't show up at the same temperature of the NPRO as I used to operate it. Although I scanned the NPRO temperature +/- 2 deg and didn't see the beat.

 

 Beat found at 30MHz with auxiliary NPRO temperature of 37.19 degrees, vs. ~48 deg as it used to be.

The beat is small (-70dBm). PLL alignment has to be improved.

  2253   Thu Nov 12 12:50:35 2009 AlbertoUpdateComputersStochMon calibrated channels added to the data trend

I added the StochMon calibrated channels to the data trend by including the following channel names in the C0EDCU.ini file:

[C1:IOO-RFAMPD_33MHZ_CAL]
[C1:IOO-RFAMPD_133MHZ_CAL]
[C1:IOO-RFAMPD_166MHZ_CAL]
[C1:IOO-RFAMPD_199MHZ_CAL]

Before saving the changes I committed C0EDCU.ini to the svn.

Then I restarted the frame builder so now the new channels can be monitored and trended.

  2254   Thu Nov 12 12:51:45 2009 AlbertoUpdateABSLWorking on the AP table

Quote:

I've opened the AP table and I'm working on it.

Also auxiliary NPRO turned on and mechanical shutter opened.

AP table and aux NPRO shutter just closed.

  2255   Thu Nov 12 15:40:27 2009 josephb, koji, peterUpdateComputersETMY and Megatron test take 1

We connected megatron to the IO chassis which in turn was plugged into the rest of the ITMY setup.  We had manually turned the watchdogs off before we touched anything, to ensure we didn't accidently drive the optic.  The connections seem to go smoothly.

However, on reboot of megatron with the IO chassis powered up, we were unable to actually start the code.  (The subsystem has been renamed from SAS to TST, short for test).  While starttst claimed to start the IOC Server, we couldn't find the process running, nor did the medm screens associated with it work.

As a sanity test, we tried running mdp, Peter's plant model, but even that didn't actually run.  Although it also gave an odd error we hadn't seen before:

"epicsThreadOnceOsd epicsMutexLock failed."

Running startmdp a second time didn't give the error message, but still no running code.  The mdp medm screens remained white.

We turned the IO chassis off and rebooted megatron, but we're still having the same problem.

 

Things to try tomorrow:

1) Try disconnecting megatron completely from the IO chassis and get it to a state identical to that of last night, when the mdp and mdc did run.

2) Confirm the .mdl files are still valid, and try rebuilding them

  2256   Thu Nov 12 16:13:05 2009 AlbertoUpdatePSLMC Trans Offset

On Rana's suggestion I checked the MC transmission QPD (C1:IOO-MC_TRANS_SUM). I found that the readout is almost zero when the MC is unlocked.

I unlocked the Mode Cleaner turning off the LSC control and disabling the autolocker. The QPD reads 0.014. It seems that there is no offset.

I also checked with the IR card around the photodetector and I didn't see any stray beam.

  2257   Thu Nov 12 16:53:59 2009 AlbertoUpdateABSLWorking on the AP table

Quote:

Quote:

Yes it did.

For long time, the crystal temperature C1:PSL-126MOPA_LTMP was 43~46deg. Now it is 34deg. Try ~10deg lower temperature.

Quote:

I wonder if the all the tinkering on the PSL laser done recently to revive the power have changed the PSL NPRO temperature and so its frequency. That could also explain why the beat doesn't show up at the same temperature of the NPRO as I used to operate it. Although I scanned the NPRO temperature +/- 2 deg and didn't see the beat.

 

 Beat found at 30MHz with auxiliary NPRO temperature of 37.19 degrees, vs. ~48 deg as it used to be.

The beat is small (-70dBm). PLL alignment has to be improved.

 PLL alignment improved. Beat amplitude = -10dBm. Good enough.

DC readouts at the PLL photodiode:

V_NPRO = -4.44V

V_PSL = -3.76V

The NPRO beam is attenuated by a N.D.=1 attenuator just before going to the photodiode.

Something strange happened at the last. Right before -10dBm, the amplitude of the beat was about -33dBm. Then I was checking the two interfering beams with the IR card and saw that they overlapped quite well. I then turned my head back to the spectrum analyzer and suddenly the beat was at -10dBm. Not only, but a bunch of new peaks had appeared on the spectrum. Either I inadvertently hit the PD moving it to a better position or something else happened.

Like if someone was making some other modulation on the beam or the modulation depth of the PSL's sidebands had gone up.

  2258   Thu Nov 12 17:15:43 2009 KojiUpdatePSLMC Trans Offset

OK. I have been keeping my eyes on the MC transmission. In deed, the MC trans has been well kept at around 7.7 since the last PSL work.
Even it was over the 8 today!

Quote:

On Rana's suggestion I checked the MC transmission QPD (C1:IOO-MC_TRANS_SUM). I found that the readout is almost zero when the MC is unlocked.

I unlocked the Mode Cleaner turning off the LSC control and disabling the autolocker. The QPD reads 0.014. It seems that there is no offset.

I also checked with the IR card around the photodetector and I didn't see any stray beam.

 

Attachment 1: MC_TRANS.png
MC_TRANS.png
  2259   Thu Nov 12 17:24:29 2009 Koji, Joe, PeterConfigurationCDSETMY CDS test started

We started the test of the new CDS system at ETMY.

The plan is as follows:
We do the ETMY test from 9:30 to 15:00 at ETMY from Nov 12~17. This disables the ETMY during this period.
From 15:00 of the each day, we restore the ETMY configuration and confirm the ETMY work properly.


Today we connected megatron to the existing AA/AI modules via designated I/F boxes. The status of the test was already reported by the other entry.

During the test, c1iscey was kept running. We disabled the ETMY actuation by WatchDog. We did not touch the RFM network.

After the test we disconnected our cables and restored the connection to ICS110B and the AI/AA boards.

The WatchDog switches were released.

The lock of the ETMY was confirmed. The full interferometer was aligned one by one. Left in the full configuration with LA=off.

  2260   Thu Nov 12 17:42:04 2009 KojiUpdatePSLMC Trans Offset

PC_DRIVE is also improving after the last PSL work!

Quote:

OK. I have been keeping my eyes on the MC transmission. In deed, the MC trans has been well kept at around 7.7 since the last PSL work.
Even it was over the 8 today!

 

Attachment 1: PC_DRV.png
PC_DRV.png
  2261   Thu Nov 12 18:10:27 2009 AlbertoUpdateABSLPLL Locked

I locked the PLL and made some first measuremtns of the spectrum of the error signal. I'll post them later.

I closed the shutter of the NPRO.

  2262   Fri Nov 13 03:38:47 2009 kiwamuUpdateElectronicsmulti-resonant EOM --- impedance of LC tank circuit ----

I have measured the impedance of the LC tank circuit which I referred on my last entry.

The configuration of the circuit is exactly the same as that time.

In order to observe the impedance, by using Koji's technique I injected a RF signal into the output of the resonant circuit.

In addition I left the input opened, therefore the measured impedance does not include the effect of the transformer.

 

- - - - - - - - - - - - results

The measured impedance is attached below; "LCtank_impedance.png"

The peak around 50MHz is the main resonance and it has impedance of ~1500 [Ohm], which should go to infinity in the ideal case (no losses).

In fact the impedance looked from the input of the circuit gets reduced by 1/n^2, where "n" is the turn ratio of the transformer.

By putting the n=4, the input impedance of the circuit should be 93 [Ohm]. This is a moderate value we can easily perform impedance-matching by some technique.

I also fitted the data with a standard model of equivalent circuit (see attachment 2).

In the figure.2 red component and red letter represents the design. All the other black stuff are parasites.

But right now I have no idea the fitted value is reasonable or not.

For the next I should check the input impedance again by the direct way; putting the signal into the input.

 

 

 

Attachment 1: LCtank_impedance.png
LCtank_impedance.png
Attachment 2: LCtank_model.png
LCtank_model.png
  2263   Fri Nov 13 05:03:09 2009 kiwamuUpdateElectronicsmulti-resonant EOM --- input impedance of LC tank ----

I measured the input impedance of the LC tank circuit with the transformer. The result is attached.

It looks interesting because the input impedance is almost dominated

by the primary coil of the transformer with inductance of 75nH (see attachment 1).

The impedance at the resonance is ~100 [Ohm], I think this number is quite reasonable because I expected that as 93 [Ohm]

 

Note that the input impedance can be derived as follower;

(input impedance) = L1 + Z/n^2.

Where L1 is the inductance of the primary coil, Z is the load in the secondary loop and n is the turn ratio.

 

I think now I am getting ready to enter the next phase \(^o^)/

Attachment 1: input_impedance.png
input_impedance.png
Attachment 2: input_impedance2.png
input_impedance2.png
  2264   Fri Nov 13 09:47:18 2009 josephbUpdateComputersMegatron status lights lit

Megatron's top fan, rear ps, and temperature front panel lights were all lit amber this morning.  I checked the service manual, found at :

http://docs.sun.com/app/docs/prod/sf.x4600m2?l=en&a=view

According to the manual, this means a front fan failed, a voltage event occured, and we hit a high temperature threshold.  However, there were no failure light on any of the individual front fans (which should have been the case given the front panel fan light).  The lights remained on after I shutdown megatron.  After unplugging, waiting 30 seconds, and replugging the power cords in, the lights went off and stayed off.  Megatron seems to come up fine.

I unplugged the IO chassis from megatron, rebooted, and tried to start Peter's plant model.  However, it still prints that its starting, but really doesn't.  One thing I forgot to mention in the previous elog on the matter, is that on the local monitor it prints "shm_open(): No such file or directory" every time we try to start one of these programs.

  2265   Fri Nov 13 09:54:14 2009 josephbConfigurationComputersMegatron switched to tcsh

I've changed megatron's controls account default shell to tcsh (like it was before).  It now sources cshrc.40m in /cvs/cds/caltech/ correctly at login, so all the usual aliases and programs work without doing any extra work.

  2266   Fri Nov 13 10:28:03 2009 josephb, alexUpdateComputersMegatron is back to its old self

I called Alex this morning and explained the problems with megatron.

Turns out when he had been setting up megatron, he thought a startup script file, rc.local was missing in the /etc directory.  So he created it.  However, the rc.local file in the /etc directory is normally just a link to the /etc/rc.d/rc.local file.  So on startup (basically when we rebooted the machine yesterday), it was running an incorrect startup script file.  The real rc.local includes line:

/usr/bin/setup_shmem.rtl mdp mdc&

Hence the errors we were getting with shm_open().  We changed the file into a soft link, and resourced the rc.local script and mdp started right up.  So we're back to where we were 2 nights ago (although we do have an RFM card in hand).

Update:  The tst module wouldn't start, but after talking to Alex again, it seems that I need to add the module tst to the /usr/bin/setup_shmem.rtl mdp mdc& line in order for it to have a shared memory location setup for it.  I have edited the file (/etc/rc.d/rc.local), adding tst at the end of the line.  On reboot and running starttst, the code actually loads, although for the moment, I'm still getting blank white blocks on the medm screens.

  2267   Fri Nov 13 14:04:27 2009 josephb, kojiUpdateComputersUpdated wiki with RCG instructions/tips

I've placed some notes pertaining to what Koji and I have learned today about getting the RCG code working on the 40m wiki at:

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

We're still trying to fix the tst system, as the moment its reporting an invalid number of daq channels and during daq initialization it fails.  (This from the /cvs/cds/caltech/target/c1tst/log.txt file). Note: This problem is only on megatron and separated from the conventional DAQ system of the 40m.

cpu clock 2800014
Warning, could open `/rtl_mem_tst' read/write (errno=0)
configured to use 2 cards
Initializing PCI Modules
2 PCI cards found
***************************************************************************
1 ADC cards found
        ADC 0 is a GSC_16AI64SSA module
                Channels = 64
                Firmware Rev = 512

***************************************************************************
1 DAC cards found
        DAC 0 is a GSC_16AO16 module
                Channels = 16
                Filters = None
                Output Type = Differential
                Firmware Rev = 3

***************************************************************************
0 DIO cards found
***************************************************************************
0 IIRO-8 Isolated DIO cards found
***************************************************************************
0 IIRO-16 Isolated DIO cards found
***************************************************************************
0 Contec 32ch PCIe DO cards found
0 DO cards found
***************************************************************************
0 RFM cards found
***************************************************************************
Initializing space for daqLib buffers
Initializing Network
Found 1 frameBuilders on network
Waiting for EPICS BURT at 0.000000 and 0 ns 0x3c40c004
BURT Restore = 1
Waiting for Network connect to FB - 10
Reconn status = 0 1
Reconn Check = 0 1
Initialized servo control parameters.
DAQ Ex Min/Max = 1 32
DAQ Tp Min/Max = 10001 10094
DAQ XTp Min/Max = 10094 10144
DAQ buffer 0 is at 0x8819a020
DAQ buffer 1 is at 0x8839a020
daqLib DCU_ID = 10
DAQ DATA INFO is at 0x3e40f0a0
Invalid num daq chans = 0
DAQ init failed -- exiting

ELOG V3.1.3-