40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 299 of 344  Not logged in ELOG logo
ID Datedown Author Type Category Subject
  2283   Tue Nov 17 15:54:34 2009 ranaSummaryPEM40 days of weather

the inside temperature is alarming at the red level today - should check if the HIHI value is set correctly

Attachment 1: Untitled.pdf
Untitled.pdf
  2282   Tue Nov 17 15:23:06 2009 KojiConfigurationSUSETMY suspension conencted to megatron ADC/DAC

OK. Now, Timing/ADC/DAC are working. It's almost there.

1) As a temporaly clock, I put a function generator at the back side of the ETMY.
Set it to the rectangular +/-4V@16384Hz. Connect it to D060064 PCIX Timing Interface Board in the IO Chasis.
That is a line receiver to feed the TTL signal into ADCs/DACs.

I confirmed the actual sampling clock is supplied to the ADC/DAC boards by looking at the SMB output of the D060064.

2) Restarted the realtime code.

3) I looked at DAC output by putting 5000,10000,15000,20000,25000cnt to UL/UR/LR/LL/SD coils again.
Yes! I could see the DAC channels are putting DC voltages.

4) Then I connected DAC CH0 to ADC CH0 using SCSI breaking up boards.
Yes! I could see the coil output switching change the ADC counts!

Now, we are ready to see the suspension damped. Check it out.

  2281   Tue Nov 17 13:39:37 2009 KojiConfigurationSUSETMY suspension conencted to megatron ADC/DAC

0) Now the connection for the ETMY suspension was restored in a usual state. It damps well.

1) I thought it would be nice to have dataviewer and DTT working.
   So far, I could not figure out how to run daqd and tpman.
   - I tried to configure
    /cvs/cds/caltech/target/fb/daqdrc
    /cvs/cds/caltech/target/fb/master
    /cvs/cds/caltech/chans/daq/C1TST.ini
(via daqconfig)

   - I also looked at
    /cvs/cds/caltech/targetgds/param/tpchn_C1.par
   but I don't understand how it works. The entries have dcuids of 13 and 14 although C1TST has dcuid of 10.
   The file is unmodified.

   I will try it later when I got a help of the experts.

2) Anyway, I went ahead. I tried to excite suspension by putting some offset.

It seems to have no DAC output. I checked the timing signal. It seems that looks wrong clock.

   I looked at DAC output by putting 5000,10000,15000,20000,25000cnt to UL/UR/LR/LL/SD coils.
   I could not find any voltage out of the DAC in any channels.

   Then, I checked the timing signal. This clock seems to have wrong frequency.
   What we are using now is a clock with +/-4V@4MHz. (Differential)
   Maybe 4194304Hz (=2^22Hz)?

   I went to 1Y3 and checked the timing signal for 16K. This was +/-4V@16kHz. (Diffrential)

   The possible solution would be
   - bring a function generator at the end and try to input a single end 4V clock.
   - stretch a cable from 1Y3 to 1Y9. (2pin lemo)

Quote:

I have connected ETMY sus electronics to megatron ADC/DAC.
We continue this state until 15:00 of today.

 

  2280   Tue Nov 17 11:09:43 2009 KojiConfigurationSUSETMY suspension conencted to megatron ADC/DAC

I have connected ETMY sus electronics to megatron ADC/DAC.
We continue this state until 15:00 of today. (Restored 13:00)

  2279   Tue Nov 17 10:09:57 2009 josephbUpdateEnvironmentFumes

The smell of diesel is particularly bad this morning.  Its concentrated enough to be causing me a headache.  I'm heading off to Millikan and will be working remotely on Megatron.

  2278   Tue Nov 17 00:42:12 2009 KojiUpdateComputersUpdated wiki with RCG instructions/tips

Dmass, Joe, Koji


A puzzle has been solved: Dmass gave us a great tip

"The RGC code does not work unless the name of the mdl file (simulink model) matches to the model name "

The model name is written in the second line. This is automatically modified if the mdl file is saved from simulink.
But we copied the model by using "cp" command. This prevent from the TST model working!

megatron:simLink>head tst.mdl
Model {
  Name                    "tst"
  Version                 7.3
  MdlSubVersion           0

...
...
...

This explained why the AAA model worked when the DAC block has been copied from the other model.
This was not because of the ADC block but the saving model fixed the model name mismatch!


Now our current working model is "C1TST". Most of the functionalities have been implemented now:

  • The simulink model has been modified so that some of the functionalities can be accomodated, such as LSC/ASC PIT/ASC YAW.
  • Some filter names are fixed so as to inherit the previous naming conventions.
  • The SUS-ETMY epics screen was modified to fit to the new channel names, the filter topologies, and the matrices.
  • The chans file was constructed so that the conventional filter coefficients are inherited.
  • All of the gains, filter SWs, matrix elements have been set accordingly to the current ETMY settings.
  • burt snapshot has been taken: /cvs/cds/caltech/target/c1tstepics/controls_1091117_024223_0.snap
    burtrb -f /cvs/cds/caltech/target/c1tstepics/autoBurt.req -o controls_1091117_024223_0.snap -l /tmp/controls_1091117_024215_0.read.log -v

What to do next:

  • Revisit Oplev model so that it accomodates a power normalization functionality.
  • ETMY QPD model is also missing!
  • Clean up mdl file using subsystem grouping
  • Check consistency of the whitening/dewhitening switches.
  • Connect ADC/DAC to megatron
  • Test of the controllability
  • BTW, what is happened to BIO?
  • Implementation of the RFM card

Directories and the files:

  • The .mdl file is backed up as
    /home/controls/cds/advLigo/src/epics/simLink/tst.mdl.20091116_2100

  • The default screens built by "make" is installed in
    /cvs/cds/caltech/medm/c1/tst/
    They are continuously overridden by the further building of the models.

  • The custom-built medm screens are stored in
    /cvs/cds/caltech/medm/c1/tst/CustomAdls/

    The backup is
    /cvs/cds/caltech/medm/c1/tst/CustomAdls/CustomAdls.111609_2300/

  • The custom-built chans file is
    /cvs/cds/caltech/chans/C1TST.txt

    The backup is
    /cvs/cds/caltech/chans/C1TST.111609

  • burt snap shot file
    /cvs/cds/caltech/target/c1tstepics/controls_1091117_024223_0.snap
  2277   Mon Nov 16 17:35:59 2009 kiwamuUpdateLSCOMC-LSC timing get synchronized !

An interesting thing was happened in the OMC-LSC timing clock.

Right now the clock of the OMC and the LSC are completely synchronized.

 The trend data is shown below. At the first two measurements (Oct.27 and Nov.1),  LSC had constant retarded time of 3Ts (~92usec.).

The last measurement, on Nov.15, number of shifts goes to zero, this means there are no retarded time.

Also the variance between the two signal gets zero, so I conclude the OMC and the LSC are now completely synchronized.

The measurement on Nov.8 is somehow meaningless, I guess the measurement did not run correctly by an influence from megatron(?)

 

OMC-LSC.png

 

  2276   Mon Nov 16 17:24:28 2009 josephbConfigurationComputersCamera medm functionality improved

Currently the Camera medm screen (now available from the sitemap), includes a server and client script buttons.  The server has two options.  One which starts a server, the second which (for the moment) kills all copies of the server running on Ottavia.  The client button simply starts a video screen with the camera image.  The slider on this screen changes the exposure level.  The snap shot button saves a jpeg image in the /cvs/cds/caltech/cam/c1asport directory with a date and time stamp on it (up to the second).  For the moment, these buttons only work on Linux machines.

All channels were added to C0EDCU.ini, and should be being recorded for long term viewing.

Feel free to play around with it, break it, and let me know how it works (or doesn't).

  2275   Mon Nov 16 15:58:02 2009 josephbConfigurationGeneralAdded Gige camera to AP table, added some screens

I placed a GC750 gige camera looking at a pickoff of the AS port, basically next to the analog camera, on the AP table.

I've modified the main sitemap to include a CAM button, for the digital cameras.  There's a half done screen associated with it.  At the moment, it reports on the X and Y center of mass calculation, the exposure setting, and displays a little graph with a dot indicating the COM of mass location.  Currently this screen is associated a GC750 camera looking at pickoff of the AS port.  I'm having some issues with getting shell scripts to run from it, as well as a slider having limits other than 0 and 0.

  2274   Mon Nov 16 15:18:10 2009 haixingUpdateSUSStable magnetic levitation without eddy-current damping

By including a differentiator from 10 Hz to 50 Hz, we increase the phase margin and the resulting

magnetic levitation system is stable even without the help of eddy-current damping.

The new block diagram for the system is the following:

 block_diagram_new.png

Here the eddy-current damping component is removed and we add an additional differential

circuit with an operational amplifier OP27G.

In addition, we place the Hall sensor below the magnet to minimize the coupling between

the coil and the Hall sensor.

The resulting levitation system is shown by the figure below:

mag_levi_new.jpg

  2273   Mon Nov 16 15:13:25 2009 josephbUpdateComputersezcaread updated to Yoichi style ezcawrite

In order to get the gige camera code running robustly here at the 40m, I created a "Yoichi style" ezcaread, which is now the default, while the original ezcaread is located in ezcaread.bin.  This tries 5 times before failing out of a read attempt.

  2272   Mon Nov 16 09:37:41 2009 steveUpdatePEMconstruction is getting noisier

 

ATM1: Seismometers are saturating, suspensions are OK

Atm2 : activity next door,  diesel Backhoe and diesel concrete cutter are running

Atm3: CES exhaust fans output  is pick up by 40M-Annex-North AC unit  intake. The 40m office room has some diesel smell...........see # 2377

Attachment 1: 4hces.png
4hces.png
Attachment 2: P1050734.JPG
P1050734.JPG
Attachment 3: P1050736.JPG
P1050736.JPG
  2271   Sun Nov 15 18:42:10 2009 AlbertoUpdateLockingInterferometer fully locked for 3331 seconds

This afternoon, I tried to lock the interferometer again after a few days.

After a couple of failed attempts, and relocks of the MZ, the interferometer stayed locked continuously for about 50 minutes, with arm power of about 92.

I just wanted to check the status of the interferometer so I didn't do any particular measurement in the meantime.

  2270   Sat Nov 14 06:46:48 2009 KojiUpdateComputersUpdated wiki with RCG instructions/tips

I am still working on the c1aaa code. Now it seems that C1AAA is working reasonably (...so far).

1) At a certain point I wanted clean up the system status. I have visited /etc/rc.local to add c1aaa for realtime to non-realtime task

before:
/usr/bin/setup_shmem.rtl mdp mdc tst&
after:
/usr/bin/setup_shmem.rtl mdp mdc tst aaa&

   I rebooted the system several times.

sudo /sbin/reboot

2) I found that gabage medm screens accumulated in ~/cds/advLigo/build/aaaepics/medm after many trials with several simulink models.
This directory is always copied to /cvs/cds/caltech/medm/c1/aaa at every make install-screens-aaa
This caused very confusing MEDM screens in the medm dir like C1AAA_ETMX_IN_MATRX.adl (NOT ETMY!)

I did

cd ~/cds/advLigo
make clean-aaa

to refresh aaaepics dir. The current development procedure is

killaaa
make clean-aaa
make uninstall-daq-aaa
make aaa
make install-aaa
make install-daq-aaa
make install-screens-aaa
startaaa

3) Sometimes startaaa does not start the task properly. If the task does not work, don't abandon.
Try restart the task. This may help. 

killaaa
(deep breathing several times)
startaaa

What to do next:

- MEDM works

* make more convenient custom MEDM screens so that we can easily access to the filters and switches
* retrofit the conventional SUS MEDM to the new system

- once again put/confirm the filter coeffs and the matrix elements

- configure DAQ setting so that we can observe suspension motion by dataviewer / dtt

- connect the suspension to megatron again

- test the control loop

  2269   Fri Nov 13 22:01:54 2009 KojiUpdateComputersUpdated wiki with RCG instructions/tips

I continued on the STAND ALONE debugging of the megatron codes.

- I succeeded to run c1aaa with ADC/DAC. (c1aaa is a play ground for debugging.)

  The trick was "copy DAC block from sam.mdl to aaa.mdl".
  I don't understand why this works. But it worked.
  I still have the problem of the matrices. Their medm screens are always blank. Needs more works.

- Also I don't understand why I can not run the build of c1tst when I copy the working aaa.mdl to tst.mdl.

- The problem Joe reported: "# of channels to be daqed" was solved by

make uninstall-daq-aaa
make install-daq-aaa

  This command is also useful.

daqconfig

- Now I am in the stable development loop with those commands

killaaa
make uninstall-daq-aaa
make aaa
make install-aaa
make install-daq-aaa
make install-screens-aaa
startaaa

  I have made "go_build" script under /home/controls/cds/advLigo

usage:
./go_build aaa

- Note for myself: frequently visited directories

/home/controls/cds/advLigo/src/epics/simLink (for model)
/home/controls/cds/advLigo
(to build)
/cvs/cds/caltech/target/c1aaa
(realtime code log)
/cvs/cds/caltech/target/c1aaaepics (ioc log)
/cvs/cds/caltech/medm/c1/aaa (medm screens)
/cvs/cds/caltech/chans
(filter coeffs)
/cvs/cds/caltech/chans/daq (daq settings)

  2268   Fri Nov 13 15:01:07 2009 JenneUpdateComputersUpdated wiki with RCG instructions/tips

Quote:

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).

 Dmass tells me that you have to record at least one channel.  ie at least one channel in your .ini file must be set to acquire, otherwise the DAQ will flip out.  It seems to be unhappy when you're not asking it to do things.

  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

  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.

  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.

  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.

  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
  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
  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.

  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
  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.

  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
  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.

  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.

  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

  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.

  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.

  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.

  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?

 

  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.

  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?

  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
  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
  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.

 

 

  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.

 

 

 

  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
  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.

  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)

  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.

 

  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.

  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

  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.

  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
  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
  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
  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.

ELOG V3.1.3-