40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 12 of 344  Not logged in ELOG logo
ID Date Author Typeup Category Subject
  2105   Fri Oct 16 16:08:00 2009 robConfigurationASCloop opened on PZT2 YAW at 3:40 pm

I pushed the "closed loop" button on PZT2 YAW around 3:40 pm today, then roughly recentered it using the DC Offset knob on the PiezoJena controller and the IP ANG QPD readbacks.  There was a large DC shift.    We'll watch and see how much it drifts in this state.

  2107   Fri Oct 16 18:46:36 2009 ranaConfigurationASCloop opened on PZT2 YAW at 3:40 pm

Quote:

I pushed the "closed loop" button on PZT2 YAW around 3:40 pm today, then roughly recentered it using the DC Offset knob on the PiezoJena controller and the IP ANG QPD readbacks.  There was a large DC shift.    We'll watch and see how much it drifts in this state.

 Here's the trend.

The transient at ~22:40 is Rob switching to 'Open Loop' on the Piezo Jena PZTs. I don't see any qualitative change in the drift after this event.

At 05:55 UTC, I removed an iris that was blocking the IP POS beam (the sum goes up from 2 to 6.5) without disturbing the mirrors who's oplev beam are on that table. Steve has conceded one sugar Napoleon after betting against my ninja-like iris skills.

We should recenter the beam on IP POS now that its unclipped - I'll let it sit this way overnight just to get more drift data.

  2108   Sun Oct 18 15:46:08 2009 AlbertoConfigurationGeneralAntique, unused QPD removed from the AS table

Inspecting the AS table to make an inventory of the photodiodes in use around the interferometer, I found a mysterious photodetector hiding behind PD1 (AS166).

It turned out the detector was an old type of QPD from the Squeezing Experiment a few years ago.

We removed the box and the cable to which it was connected from the table. We stored it in the optics cabinet along the X arm.

  2109   Sun Oct 18 16:09:34 2009 ranaConfigurationASCloop opened on PZT2 YAW at 3:40 pm

 

I wanted to see how long our IP POS beam has been badly clipped - turns out its since April 1, 2007.

Steve's April Fool's joke is chronicled then. The attached trend shows that the drop in IP POS is coincident with that event.

In trying to align IPPOS, I noticed that someone has placed a ND2.0 filter (factor of 100 attenuation) in front of it. This is kind of a waste - I have removed IPPOS to fix its resistors and avoid this bad optic. Also the beam coming onto the table is too big for the 1" diameter optics being used; we need to replace it with a 2" diamter optic (Y1-2037-45P).

 

IP ANG dropped by a factor of 2 back in early August of '08.

We need this guy on the investigation:

 

  2110   Sun Oct 18 19:55:45 2009 ranaConfigurationElectronicsIP POS is back: ND filter gone, new resistors in

Its back in and re-centered. Our next move on IPPOS should be to replace its steering mirror with something bigger and more rigid.

Electronics changes:

20K -> 3.65 K  (R6, R20, R42, R31) (unused)

20K -> 3.65 K  (R7, R21, R32, R43, R11, R24, R35, R46)

If you look in the schematic (D990272), you see that its an AD797 transimpedance stage with a couple of LT1125 stages set to give some switchable gain. It looks like some of these

switches are on and some are not, but I am not sure where it would be controlled from. I've attached a snapshot of one quadrant of the schematic below.

The schematic shows the switches in the so-called 'normally closed' configuration. This is what the switches do with zero volts applied to the control inputs. As the schematic also shows,

just disconnecting the 'switch' inputs cause the switch's control inputs to go high (normally open configuration, i.e. pins 2-3 connected, pin4 open). For the record, the default positions of the IPPOS switches are:

switch1   high

switch2   low

switch3   low

switch4   high

 


** EDIT (Nov 2, 2009): I forgot to attach the before and after images; here they are:

IMG_0068.JPGIMG_0072.JPG

  2112   Sun Oct 18 22:06:15 2009 ranaConfigurationElectronicsIP POS is back: ND filter gone, new resistors in

I tried to compare the IP_POS time series with the IPANG and MC_TRANS but was foiled at first:

1) The IPANG scan rate was set to 0.5 second, so it doesn't resolve the pendulum motions well. Fixed in the .db file.

2) Someone had used a Windows/DOS editor to edit the .db file and it was filled with "^M" characters. I have removed them all using this command:   tr -d "\r" <ETMXaux.db > new.db

3) The MC_TRANS P/Y channels were on the MC Lock screen but had never been added to the DAQ. Remember, if there's a useful readback on an EPICS screen. its not necessarily in the frames unless you add it to the C0EDCU file. I have done that now and restarted the fb daqd. Channels now exist.

4) Changed the PREC of the IPPOS channels to 3 from 2.

5) changed the sign for the IBQPD (aka IPANG) so that bigger signal is positive on the EPICS screen.

  2126   Tue Oct 20 16:35:24 2009 robConfigurationLSC33MHz Mod depth

The 33MHz mod depth is now controlled by the OMC (C1:OMC-SPARE_DAC_CH_15).  The setting to give us the same modulation depth as before is 14000 (in the offset field).

  2140   Sun Oct 25 14:29:45 2009 haixing, kiwamuConfigurationGeneralSR785 spectrum analyzer

In this morning, we have disconnected SR785 which was in front of 1X2 rack, to measure a Hall sensor noise.

After a while, we put back SR785 and re-connected as it has been.

But the display setup might have been changed a little bit.

 

  2150   Tue Oct 27 17:58:25 2009 JenneConfigurationPEMUnknown PEM channels in the PEM-ADCU?

Does anyone know what the channels plugged in to the PEM ADCU, channels 5,6,7,8 are?  They aren't listed in the C1ADCU_PEM.ini file which tells the channel list/dataviewer/everything about all the rest of the signals which are plugged into that ADCU, so I'm not sure if they are used at all, or if they're holdovers from some previous time.  The cables are not labeled in a way that makes clear what they are.  Thanks!

  2169   Mon Nov 2 13:34:36 2009 kiwamuConfigurationPSLremoved multiply resonant EOM

I removed the multiply resonant EOM that has been set by a SURF student from PSL table.

I will use it for checking the resonant circuit.

  2173   Tue Nov 3 12:47:01 2009 KojiConfigurationCDS1Y9 Rack configuration update

For the CDS upgrade preparation I put and moved those stuff at the rack 1Y9:

Placed 1Y9-12 ADC to DB44/37 Adapter LIGO D080397

Placed 1Y9-14 DAC to IDC Adapter LIGO D080303

Moved the ethernet switch from 1Y9-16 to 1Y9-24

Wiki has also been updated.

  2183   Thu Nov 5 16:41:14 2009 josephbConfigurationComputersMegatron's personal network

In investigating why megatron wouldn't talk to the network, I re-discovered the fact that it had been placed on its own private network to avoid conflicts with the 40m's test point manager.  So I moved the linksys router (model WRT310N V2) down to 1Y9, plugged megatron into a normal network port, and connected its internet port to the rest of the gigabit network. 

Unfortunately, megatron still didn't see the rest of the network, and vice-versa.  I brought out my laptop and started looking at the settings.  It had been configured with the DMZ zone on for 192.168.1.2, which was Megatron's IP, so communications should flow through the router. Turns out it needs the dhcp server on the gateway router (131.215.113.2) to be on for everyone to talk to each other.  However, this may not be the best practice.  It'd probably be better to set the router IP to be fixed, and turn off the dhcp server on the gateway.  I'll look into doing this tomorrow.

Also during this I found the DNS server running on linux1 had its IP to name and name to IP files in disagreement on what the IP of megatron should be.  The IP to name claimed 131.215.113.95 while the name to IP claimed 131.215.113.178.  I set it so both said 131.215.113.178.  (These are in /var/named/chroot/var/ directory on linux1, the files are 113.215.131.in-addr.arpa.zone  and martian.zone - I modified the 113.215.131.in-addr.arpa.zone file).  This is the dhcp served IP address from the gateway, and in principle could change or be given to another machine while the dhcp server is on.

  2187   Fri Nov 6 00:23:34 2009 AlbertoConfigurationComputersElog just rebooted

The elog just crashed and I rebooted it

  2195   Fri Nov 6 17:04:01 2009 josephbConfigurationComputersRFM and Megatron

I took the RFM 5565 card dropped off by Jay and installed it into megatron.  It is not very secure, as it was too tall for the slot and could not be locked down.  I did not connect the RFM fibers at this point, so just the card is plugged in.

Unfortunately, on power up, and immediately after the splash screen I get "NMI EVENT!" and "System halted due to fatal NMI". 

The status light on the RFM light remains a steady red as well.  There is a distinct possibility the card is broken in some way.

The card is a VMIPMC-5565 (which is the same as the card used by the ETMY front end machine).  We should get Alex to come in and look at it on Monday, but we may need to get a replacement.

  2208   Mon Nov 9 11:11:19 2009 AlbertoConfigurationLSCMC2 Watchdogs tripped

The MC2 watchdogs tripped. I just restored them.

I also had to relock the MZ and then the Mode Cleaner.

  2211   Mon Nov 9 13:17:07 2009 AlbertoConfigurationABSLNPRO on

I turned the auxialiary NPRO for the AbsL Experiment on. Its shutter stays closed.

  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.

  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.

  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.

  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.

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

  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)

  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.

 

  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.

  2285   Tue Nov 17 21:10:30 2009 KojiConfigurationSUSETMY suspension conencted to megatron ADC/DAC

Koji, Rana

The megatron DAC was temporaly connected to the suspension electronics for the DAC test. We went down to ETMY as we could not excite the mirror.

The DAC is putting correct voltages to the channels. However, the anti imaging filter test output does not show any signal.
This means something wrong is there in the DAC I/F box or the cables to the AI circuit. We will check those things tomorrow.

The ETMY was restored to the usual configuration.

  2290   Wed Nov 18 11:27:33 2009 Koji, josephbConfigurationSUSETMY suspension conencted to megatron ADC/DAC

Quote:

Koji, Rana

The megatron DAC was temporaly connected to the suspension electronics for the DAC test. We went down to ETMY as we could not excite the mirror.

The DAC is putting correct voltages to the channels. However, the anti imaging filter test output does not show any signal.
This means something wrong is there in the DAC I/F box or the cables to the AI circuit. We will check those things tomorrow.

The ETMY was restored to the usual configuration.

 

It appears the front panel for the DAC board is mis-labeled.  Channels 1-8 are in fact 9-16, and 9-16 are the ones labeled 1-8.  We have put on new labels to reduce confusion in the future.

  2291   Wed Nov 18 12:33:30 2009 Koji, josephbConfigurationSUSETMY suspension conencted to megatron ADC/DAC

Hurraaaah!
We've got the damping of the suspension.
The Oplev loops has also worked!

The DAC channnel swapping was the last key!

DataViewer snapshot to show the damping against an artificial excitation was attached

Quote:

Quote:

Koji, Rana

The megatron DAC was temporaly connected to the suspension electronics for the DAC test. We went down to ETMY as we could not excite the mirror.

The DAC is putting correct voltages to the channels. However, the anti imaging filter test output does not show any signal.
This means something wrong is there in the DAC I/F box or the cables to the AI circuit. We will check those things tomorrow.

The ETMY was restored to the usual configuration.

 

It appears the front panel for the DAC board is mis-labeled.  Channels 1-8 are in fact 9-16, and 9-16 are the ones labeled 1-8.  We have put on new labels to reduce confusion in the future.

 

  2293   Wed Nov 18 16:24:25 2009 peteConfigurationSUSETMY suspension conencted to megatron ADC/DAC

/cvs/cds/caltech/target/fb/daqd -c daqdrc

This starts the FB.

Now the dataviewer and DTT work!

Quote:

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.

 

 

  2301   Thu Nov 19 11:33:15 2009 josephbConfigurationComputersMegatron

I tried rebooting megatron, to see if that might help, but everything still acts the same. 

I tried using daqconfig and changed channels from deactiveated to activated.  I learned by activating them all, that the daq can't handle that, and eventually aborts from an assert checking a buffer size being too small.  I also tried activating 2 and looking at those channels, and it looks like the _DAQ versions of those channels work, or at least I get 0's out of C1:TST-ETMY_ASCPIT_OUT_DAQ (which is set in C1TST.ini file).

I've added the SENSOR channels back to the /csv/cds/caltech/chans/daq/C1TST.ini file, and those are again working in data viewer.

At this point, I'm leaving megatron roughly in the same state as last night, and am going to wait on a response from Alex.

  2302   Thu Nov 19 16:04:48 2009 AlbertoConfigurationelogElog debugging output - Down time programmed today to make changes

We want the elog process to run in verbose mode so that we can see what's going. The idea is to track the events that trigger the elog crashes.

Following an entry on the Elog Help Forum, I added this line to the elog starting script start-elog-nodus:

./elogd -p 8080 -c /cvs/cds/caltech/elog/elog-2.7.5/elogd.cfg -D -v > elogd.log 2>&1

which replaces the old one without the part with the -v argument.

The -v argument should make the verbose output to be written into a file called elogd.log in the same directory as the elog's on Nodus.

I haven't restarted the elog yet because someone might be using it. I'm planning to do it later on today.

So be aware that:

We'll be restarting the elog today at 6.00pm PT. During this time the elog might not be accessible for a few minutes.

  2303   Thu Nov 19 18:49:55 2009 AlbertoConfigurationelogElog debugging output - Down time programmed today to make changes

Quote:

We want the elog process to run in verbose mode so that we can see what's going. The idea is to track the events that trigger the elog crashes.

Following an entry on the Elog Help Forum, I added this line to the elog starting script start-elog-nodus:

./elogd -p 8080 -c /cvs/cds/caltech/elog/elog-2.7.5/elogd.cfg -D -v > elogd.log 2>&1

which replaces the old one without the part with the -v argument.

The -v argument should make the verbose output to be written into a file called elogd.log in the same directory as the elog's on Nodus.

I haven't restarted the elog yet because someone might be using it. I'm planning to do it later on today.

So be aware that:

We'll be restarting the elog today at 6.00pm PT. During this time the elog might not be accessible for a few minutes.

 I tried applying the changes but they didn't work. It seems that nodus doesn't like the command syntax.

I have to go through the problem...

The elog is up again.

  2305   Fri Nov 20 11:01:58 2009 josephb, alexConfigurationComputersWhere to find RFM offsets

Alex checked out the old rts (which he is no longer sure how to compile) from CVS to megatron, to the directory:

/home/controls/cds/rts/

In /home/controls/cds/rts/src/include you can find the various h files used.  Similarly, /fe has the c files.

In the h files, you can work out the memory offset by noting the primary offset in iscNetDsc40m.h

A line like suscomms.pCoilDriver.extData[0] determines an offset to look for.

0x108000 (from suscomms )

Then pCoilDriver.extData[#] determines a further offset.

sizeof(extData[0]) = 8240  (for the 40m - you need to watch the ifdefs, we were looking at the wrong structure for awhile, which was much smaller).

DSC_CD_PPY is the structure you need to look in to find the final offset to add to get any particular channel you want to look at.

The number for ETMX is 8, ETMY 9 (this is in extData), so the extData offset from 0x108000 for ETMY should be 9 * 82400.  These numbers (i.e. 8 =ETMX, 9=ETMY) can be found in losLinux.c in /home/controls/cds/rts/src/fe/40m/.  There's a bunch of #ifdef and #endif which define ETMX, ETMY, RMBS, ITM, etc.  You're looking for the offset in those.

So for ETMY LSC channel (which is a double) you add 0x108000 (a hex number) + (9 * 82400 + 24) (not in hex, need to convert) to get the final value of 0x11a160 (in hex).

-----------

A useful program to interact with the RFM network can be found on fb40m.  If you log in and go to:

/usr/install/rfm2g_solaris/vmipci/sw-rfm2g-abc-005/util/diag

you can then run rfm2g_util, give it a 3, then type help.

You can use this to read data.  Just type help read.  We had played around with some offsets and various channels until we were sure we had the offsets right.  For example, we fixed an offset into the ETMY LSC input, and saw the corresponding memory location change to that value.  This utility may also be useful for when we do the RFM test to check the integrity of the ring, as there are some diagnostic options available inside it.

  2306   Fri Nov 20 11:14:22 2009 josephb, alexConfigurationComputerstest points working on megatron and we may have filters with switch outputs built in

Alex tooked at the channel definitions (can be seen in tpchn_C1.par), and noticed the rmid was 0. 

However, we had set in testpoint.par the tst system to C-node1 instead of C-node0.  The final number inf that and the rmid need to be equal.   We have changed this, and the test points appear to be working now.

However, the confusing part is in the tst model, the gds_node_id is set to 1.  Apparently, the model starts counting at 1, while the code starts counting at 0, so when you edit the testpoint.par file by hand, you have to subtract one from whatever you set in the model.

In other news, Alex pointed me at a CDS_PARTS.mdl, filters, "IIR FM with controls".  Its a light green module with 2 inputs and 2 outputs.  While the 2nd set of input and outputs look like they connect to ground, they should be iterpreted by the RCG to do the right thing (although Alex wasn't positive it works, it worth trying it and seeing if the 2nd output corresponds to a usable filter on/off switch to connect to the binary I/O to control analog DW.  However, I'm not sure it has the sophistication to wait for a zero crossing or anything like that - at the moment, it just looks like a simple on/off switch based on what filters are on/off.

  2309   Fri Nov 20 16:18:56 2009 robConfigurationSUSwatchdog rampdown

I've changed the watchdog rampdown script so it brings the SUS watchdogs to 220, instead of the 150 it previously targeted.  This is to make tripping less likely with the jackhammering going on next door.  I've also turned off all the oplev damping.

  2323   Tue Nov 24 18:24:54 2009 SanjitConfigurationAdaptive FilteringASS channels added to framebuilder

 

[Sanjit, Jenne, Rob, Joe]

 

We added and tested the following channels from "/cvs/cds/gds/param/tpchn_C3.par" to "/cvs/cds/caltech/chans/daq/C1ASS.ini" appending a "_2048" extension to the channel name (as the name of a channel in .ini and .par files must be different):

[C1:ASS-TOP_CORR_IN1_2048]
[C1:ASS-TOP_ERR_EMPH_IN1_2048]
[C1:ASS-TOP_PEM_10_IN1_2048]
[C1:ASS-TOP_PEM_11_IN1_2048]
[C1:ASS-TOP_PEM_12_IN1_2048]
[C1:ASS-TOP_PEM_15_IN1_2048]
[C1:ASS-TOP_PEM_16_IN1_2048]
[C1:ASS-TOP_PEM_17_IN1_2048]
[C1:ASS-TOP_PEM_18_IN1_2048]
[C1:ASS-TOP_PEM_19_IN1_2048]
[C1:ASS-TOP_PEM_20_IN1_2048]
[C1:ASS-TOP_PEM_24_IN1_2048]
[C1:ASS-TOP_PEM_2_IN1_2048]
[C1:ASS-TOP_PEM_3_IN1_2048]
[C1:ASS-TOP_PEM_4_IN1_2048]
 

These five-line entries for each channels in the .par file were manually copy pasted from the .ini file, should think about a smarter way...

The old .par file is kept as: /cvs/cds/caltech/chans/daq/C1ASS.ini.20Nov2009

The current one is also saved as: /cvs/cds/caltech/chans/daq/C1ASS.ini.24Nov2009

And, the current one is committed to the svn.

 

NOTE: In the first attempt, the channel names were mistakenly kept the same in both the .ini and .par files and this caused DAQ daemon to crash badly. It could only be recovered by hard reboot of the frame builder.  Important info here: Jenne's elog 2316

  2384   Thu Dec 10 13:10:25 2009 AlbertoConfigurationLSC166 LO Disconnected

I temporarily disconnected the Heliax cable that brings the 166MHz LO to the LSC rack.

I'm doing a couple of measurement and I'll put it back in as soon as I'm done.

  2389   Thu Dec 10 17:05:21 2009 AlbertoConfigurationLSC166 MHz LO SMA-to-Heliax connection repaired

I replaced the SMA end connector for the 166 MHZ Local Oscillator signal that goes to the back of the flange in the 1Y2 rack. The connector had got damaged after it twisted when I was tigheting the N connector of the Heliax cable on the front panel.

  2393   Thu Dec 10 18:31:44 2009 AlbertoConfigurationLSC166 LO Disconnected

Quote:

I temporarily disconnected the Heliax cable that brings the 166MHz LO to the LSC rack.

I'm doing a couple of measurement and I'll put it back in as soon as I'm done.

 These are the losses I measured on a RG-174 cable for the two frequencies that we're planning to use in the Upgrade:

@11MHz Loss=0.22dBm/meter

@55MHz Loss=0.41dBm/meter

(The cable was 2.07m long. The input signal was +10dBm and the output voltages at the oscilloscope where: Vpk-pk(11MHz)=1.90V, Vpk-pk(11MHz)=1.82V )

  2394   Fri Dec 11 08:35:04 2009 steveConfigurationVACpumpdown has started

Oplev positions before and after drag wiped arm TMs as of yesterday. Slow-mode pumpdown has started with 3/4 turn opened  RV1 valve at 8am today.

  2395   Fri Dec 11 09:30:09 2009 KojiConfigurationLSC166 LO Disconnected

They must not be dBm, must be dB

Quote:

Quote:

I temporarily disconnected the Heliax cable that brings the 166MHz LO to the LSC rack.

I'm doing a couple of measurement and I'll put it back in as soon as I'm done.

 These are the losses I measured on a RG-174 cable for the two frequencies that we're planning to use in the Upgrade:

@11MHz Loss=0.22dBm/meter

@55MHz Loss=0.41dBm/meter

(The cable was 2.07m long. The input signal was +10dBm and the output voltages at the oscilloscope where: Vpk-pk(11MHz)=1.90V, Vpk-pk(11MHz)=1.82V )

 

  2396   Fri Dec 11 11:42:26 2009 AlbertoConfigurationLSC166 LO Disconnected

Quote:

They must not be dBm, must be dB

Quote:

Quote:

I temporarily disconnected the Heliax cable that brings the 166MHz LO to the LSC rack.

I'm doing a couple of measurement and I'll put it back in as soon as I'm done.

 These are the losses I measured on a RG-174 cable for the two frequencies that we're planning to use in the Upgrade:

@11MHz Loss=0.22dBm/meter

@55MHz Loss=0.41dBm/meter

(The cable was 2.07m long. The input signal was +10dBm and the output voltages at the oscilloscope where: Vpk-pk(11MHz)=1.90V, Vpk-pk(11MHz)=1.82V )

 

I apologize for the lack of correctness on the units in yesterday's elog entry, but I wasn't very sharp last night.

I repeated the measurement today, this time also making sure that I had a 50ohm input impedance set in the scope. These the results for the losses.

RG-174 Cable 0.053 dB/m @ 11MHz  0.155 dB/m @ 55 MHz

 I also measured the losses in the Heliax cable going from the 166 MHz LO to the LSC rack:

166MHz LO Heliax 0.378 dB @ 11MHz  1.084 dB @ 55 MHz

 

  2397   Fri Dec 11 13:18:17 2009 AlbertoConfigurationVACpumpdown has started

Quote:

Oplev positions before and after drag wiped arm TMs as of yesterday. Slow-mode pumpdown has started with 3/4 turn opened  RV1 valve at 8am today.

 I'm leaving the lab now for less than 2 hours. I should be back in time for when the pumping is finished so that I can measure the finesse again.

  2398   Fri Dec 11 14:12:32 2009 ranaConfigurationLSC166 LO Disconnected

 

 Seems like very strange cable loss numbers. The Heliax is lossier than the RG-174? I wonder how these compare with the specs in the cable catalog?

  2399   Fri Dec 11 14:19:22 2009 KojiConfigurationVACpumpdown has started

Wait, Wait, Wait. You are moving too fast. Go one by one.

Check the PZTs, the MC, initial pointings, IFO mirrors, some of the partial locks, and maybe some momentary full locks?
Once the recover of the IFO is declared, you can proceed to the measurements.

I hope the grad students can take this precious opportunity to have their fun time for restoring everything by themselves.

Quote:

 I'm leaving the lab now for less than 2 hours. I should be back in time for when the pumping is finished so that I can measure the finesse again.

 

  2400   Fri Dec 11 15:21:40 2009 steveConfigurationVACpumpdown#67 is completed

Quote:

Oplev positions before and after drag wiped arm TMs as of yesterday. Slow-mode pumpdown has started with 3/4 turn opened  RV1 valve at 8am today.

 Pump down is completed. Valve configuration is VACUUM NORMAL. CC1 pressure is in the ~8 e-5 torr   PSL output shutter is opened.

  2402   Fri Dec 11 19:51:13 2009 AlbertoConfigurationLSC166 LO Disconnected

Quote:

 

 Seems like very strange cable loss numbers. The Heliax is lossier than the RG-174? I wonder how these compare with the specs in the cable catalog?

In my last entry there was a typo for the measurement of the Heliax at 55 MHz. I corrected it. It was 1.084 dB instead of 1.084 dB/m.
For the Heliax I don't have the measurement of the loss per meter since I don't know the cable actual length.
 
Except for that, I checked the values I found on the Internet.
My measurements for the RG-174 seem comparable to the loss specified in the catalog (here): 6.6dB in 100ft @ 55 MHz, that is 0.22 dB/m, that compare with 0.155 dB/m that I measured.

I did the measurement on a 4.33 meter long cable with SMA connectors at the ends.

  2432   Sat Dec 19 14:33:25 2009 KojiConfigurationComputersPDFlib lite / gnuplot 4.2.6 on Rosalba/Allegra

In order to enable 'set terminal pdf' in gnuplot on Rosalba/Allegra, I installed PDFlib lite and gnuplot v4.2.6. to them.
(PDFlib lite is required to build the pdf-available version of gnuplot)


Installation of PDFlib lite:

  • Building has been done at rosalba
  • Download the latest distribution of PDFlib lite from http://www.pdflib.com/products/pdflib-7-family/pdflib-lite/
  • Expand the archive. Go into the expanded directory
          tar zxvf PDFlib-Lite-7.0.4p4.tar.gz
          cd ./PDFlib-Lite-7.0.4p4
  • configure & make
          ./configure
          make
  • install the files to the system / configure the dinamic linker
          sudo make install
          sudo ldconfig

Installation of gnuplot:

  • Building has been done at rosalba
  • Download the latest distribution of gnuplot form http://www.gnuplot.info/
  • Expand the archive. Go into the expanded directory
          tar zxvf gnuplot-4.2.6.tar.gz
          cd ./gnuplot-4.2.6.tar.gz
  • configure & make
          ./configure --prefix=/cvs/cds/caltech/apps/linux/gnuplot
          make
          make install
  • Create symbolic links of the executable at
          /cvs/cds/caltech/apps/linux/bin
          /cvs/cds/caltech/apps/linux64/bin
  • Note: Although the original (non-PDF) gnuplot is still at
          /usr/bin/gnuplot
    new one is active because of the path setting
          rosalba:linux>which gnuplot
          /cvs/cds/caltech/apps/linux64/bin/gnuplot

 

  2447   Tue Dec 22 18:42:40 2009 Sanjit, KojiConfigurationAdaptive FilteringReadded DAQ channels to active list

Sometimes back we modified /cvs/cds/caltech/chans/daq/C1ASS.ini to save some of the channels. The file was reverted to default after the recent changes in ASS.

We again uncommented and made acquire=1 to save the following three channels using daqconfig:

C1:ASS-TOP_ERR_MCL_IN1_2048

C1:ASS-TOP_PEM_15_IN1_2048

C1:ASS-TOP_PEM_18_IN1_2048

The script automatically created a back up in /cvs/cds/caltech/chans/daq/archive

 

  2469   Wed Dec 30 20:33:36 2009 rana, albertoConfigurationCamerasITMY & MC2 Camera work

We restored the good state of the ITMY camera and neatened both the MC2 and ITMY camera.

The MC2 camera was driving a triple T jungle into some random cables and spoiling the image. We removed all T's and the MC2 camera now drives only The Matrix.

The ITMY camera was completely unmounted and T'd. So it was misaligned just by the force of gravity acting on its BNC cable. We swapped the lens for a reasonable sized one and remounted it in its can. We then used orange cable ties to secure the power and BNC cable for the MC2 and ITMY cameras so that tugging on the cables doesn't misalign the cameras. This is part of the camera's SOP.

No more driving 50 Ohm cables and T's with video cables, Steve! If you need a portable video, just use a spigot of the Matrix and then you can control it with a web browser.

DSC_1064.JPGDSC_1065.JPGDSC_1066.JPG

I also wiped out the D40's memory card after uploading all of the semi-useful files to the Picasa page.

  2471   Sun Jan 3 08:23:39 2010 ranaConfigurationCDSautoburt.pl 'fixed' for post 2009 years

Tobin & Keith pointed out in the LLO ilog that there was a code bug in the autoburt.pl script for autoburts.

I edited the autoburt.pl script so that it will work from now until 2099 (by which time we may no longer be using this version of perl):

nodus:autoburt>diff autoburt.pl~ autoburt.pl
234c234
<     $thisyear = "200".$timestamp[5];
---
>     $thisyear = "20".$timestamp[5];

The autoburt has not been working ever since 11PM on New Year's eve.

I ran it by hand and it seems to run fine. I noticed along the way that it was running on op340m (our old Sun Blade 150 machine). The autoburt.pl was pointing at /cvs/cds/bin/perl

which is Perl v5.0. I changed it to use '/usr/bin/env' and now points at '/usr/bin/perl' which is perl 5.8. It runs fine with the new perl:

op340m:scripts>time perl /cvs/cds/scripts/autoburt.pl >> /cvs/cds/caltech/logs/autoburtlog.log
5.37u 6.29s 2:13.41 8.7%

Also ran correctly, via cron, at 9AM.

ELOG V3.1.3-