40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  ATF eLog, Page 36 of 56  Not logged in ELOG logo
ID Date Author Type Category Subject
  1039   Thu Sep 9 22:38:06 2010 ZachElectronicsstuff happensRouter Crashed again?

I noticed yesterday that although mDV was working again (I could get data by supplying the channel names manually into get_data), ligoDV could not obtain channel lists for C2 as it could before. Not sure if this is related.

Quote:

looks like you have to work in the lab instead of sitting on the couch 
It's working if you try to get data from there... Or try to tunnel port 8088 through ssh, that should work too. That's the way i usually forward any services which are not accessible from outside.

Time to replace the router....

Quote:

Quote:

Router crashed? Can't get channel list.

- Had Tara restart router, still can't get channel list. Was fine this afternoon.

 nds and daqd both seem to be running on fb0.

 

  1038   Thu Sep 9 21:57:37 2010 FrankElectronicsstuff happensRouter Crashed again?

looks like you have to work in the lab instead of sitting on the couch 
It's working if you try to get data from there... Or try to tunnel port 8088 through ssh, that should work too. That's the way i usually forward any services which are not accessible from outside.

Time to replace the router....

Quote:

Quote:

Router crashed? Can't get channel list.

- Had Tara restart router, still can't get channel list. Was fine this afternoon.

 nds and daqd both seem to be running on fb0.

  1037   Thu Sep 9 21:56:29 2010 DmassElectronicsstuff happensCan't get data from 40m network?

Get_data worked without hitch when I used a vpn caltech connection. I think I am on the 40m ligo network (131.215...). I toggled on and off a couple times to check, and it only worked with the VPN on.

  1036   Thu Sep 9 21:45:26 2010 DmassElectronicsstuff happensRouter Crashed again?

Quote:

Router crashed? Can't get channel list.

- Had Tara restart router, still can't get channel list. Was fine this afternoon.

 nds and daqd both seem to be running on fb0.

  1035   Thu Sep 9 21:12:50 2010 DmassElectronicsstuff happensRouter Crashed again?

Router crashed? Can't get channel list.

- Had Tara restart router, still can't get channel list. Was fine this afternoon.

  1034   Thu Sep 9 20:28:12 2010 KojiLaserGYROPDH box SWEEP -> OUT TF

Yes, that's another technique.

Make certain the coherence of the measurement is ok. As the signal before the filter is suppressed by the huge loop gain. the SNR easily gets bad.

Quote:

Thank you for the tips, Koji. Frank also mentioned to me today that it would be easier to do the measurement with the loop closed (i.e. measure output / input while driving somewhere else in the loop). I'm not sure how we will be able to do this for the SWEEP -> OUT measurement, though, and we still need to understand why turning the boost on while locked kicks us out of lock.

 

  1033   Thu Sep 9 18:31:48 2010 DmassElectronicsstuff happensWho cares!

I switched both HEPAs on to "low" and relocked the PMC at 6:40 PM today.

8:07 PM - both HEPAs turned to "med"

NTC Thermistor SR560 Gain set to 10 (was overloading @ 20).

NTC Thermistor mode set to "A-B" on one of the 560s with nothing hooked into B. Unknown if this makes it fluctuate or not. Channel is "daq1-gen4"

  1032   Thu Sep 9 17:10:39 2010 ZachLaserGYROPDH box SWEEP -> OUT TF

Thank you for the tips, Koji. Frank also mentioned to me today that it would be easier to do the measurement with the loop closed (i.e. measure output / input while driving somewhere else in the loop). I'm not sure how we will be able to do this for the SWEEP -> OUT measurement, though, and we still need to understand why turning the boost on while locked kicks us out of lock.

Quote:

That's the natural desire, but it is often not straightforward.

It depends on the feature of your LF boost, but in general a LF boost yields a huge gain at DC. Every circuits has some small mount of DC offset and it is amplified by the boost.
e.g. Suppose 1mV input-equivalent offset with DC gain of 10^4. This causes the output of 10V.

What you may be able to do is put an offset to the FFT analyzer output such that the output offset of the box is nulled. If you are lucky, this would let you measure the boost TF.

---------

Even if you have some offset in the servo filter, usually it is not the matter as the servo try to squeeze the offset by the feedback.
Usually small input-equivalent offset of the servo filter turned into huge offset at the output of the filter module, if the loop is not closed.
Once the loop is closed, the feedback signal is adjusted such that the error signal cancels this offset.

Of course, the actual situation depends on how much offset you do actually have. So the above mentions are just general comments.

Quote:

Trying to take a TF with the BOOST on (to emulate the state of the system while running the gyro) proved fruitless, as this causes the output to rail regardless of how low you make the source or whether you go in at SWEEP or INPUT. This is problematic because we would like to do the closed-loop measurements on the actual (BOOST on) running state of the gyro. It is possible that engaging the boost produces an unwanted offset, and this would explain why doing so with the cavity locked sometimes causes it to drop. I will take a look at the schematic to see if something is obviously wrong with the circuit. 

 

 

  1031   Thu Sep 9 14:49:01 2010 KojiLaserGYROPDH box SWEEP -> OUT TF

That's the natural desire, but it is often not straightforward.

It depends on the feature of your LF boost, but in general a LF boost yields a huge gain at DC. Every circuits has some small mount of DC offset and it is amplified by the boost.
e.g. Suppose 1mV input-equivalent offset with DC gain of 10^4. This causes the output of 10V.

What you may be able to do is put an offset to the FFT analyzer output such that the output offset of the box is nulled. If you are lucky, this would let you measure the boost TF.

---------

Even if you have some offset in the servo filter, usually it is not the matter as the servo try to squeeze the offset by the feedback.
Usually small input-equivalent offset of the servo filter turned into huge offset at the output of the filter module, if the loop is not closed.
Once the loop is closed, the feedback signal is adjusted such that the error signal cancels this offset.

Of course, the actual situation depends on how much offset you do actually have. So the above mentions are just general comments.

Quote:

Trying to take a TF with the BOOST on (to emulate the state of the system while running the gyro) proved fruitless, as this causes the output to rail regardless of how low you make the source or whether you go in at SWEEP or INPUT. This is problematic because we would like to do the closed-loop measurements on the actual (BOOST on) running state of the gyro. It is possible that engaging the boost produces an unwanted offset, and this would explain why doing so with the cavity locked sometimes causes it to drop. I will take a look at the schematic to see if something is obviously wrong with the circuit. 

 

  1030   Thu Sep 9 13:12:24 2010 AlastairComputingGeneralpaths and aliases

 Some of our standard stuff from bash wasn't working in tcsh shell, so I've added some extra paths and aliases.  The tcsh path file (.cshrc) now has the following added

 

setenv PATH ${PATH}:/opt/apps/Linux/medm/bin

setenv PATH ${PATH}:/opt/apps/Linux/dataviewer

setenv PATH ${PATH}:/opt/apps/Linux/grace/bin

setenv PATH ${PATH}:/opt/apps/Linux/tds

setenv PATH ${PATH}:/opt/apps/Linux/gds/binsetenv PATH ${PATH}:/opt/apps/Linux/ZooZ-1.2

setenv PATH ${PATH}:/caltech/scripts

 

I also added the following aliases
alias dv 'dataviewer'
alias sitemap 'medm -x /cvs/cds/caltech/medm/c2/atf/C2ATF_MASTER.adl &'
 
The following now work which previously did not work in tcsh
medm
dataviewer
dv (an alias to open dataviewer)
sitemap (opens medm with the top level medm file)
 
For some reason 'diaggui',  'foton' and 'mainmenu' still won't work.  You just get 'Abort'.  If you cd into the correct folder for them and run them using ./diaggui, ./foton or ./mainmenu then you get the same thing.  Using bash if I cd into the directory and run them in this way they work.  Does tcsh need to know of some other paths to get these to work?

 

  1029   Thu Sep 9 12:23:50 2010 ZachLaserGYROPDH box SWEEP -> OUT TF

Below is the transfer function of the PDH box from the SWEEP input to the output. This input will be used for the closed-loop measurements of the gyro loops, so we need to know this information. It appears that the TF is flat at 0 dB up to around 10 kHz, where there is some strange behavior. It also appears to be independent of the gain setting, which is a nice feature. The two seemingly arbitrary gain settings chosen to test this are 1) 0.5: the setting at which we took the IN -> OUT TFs, and 2) 7.0: the typical running setting for the gyro.

sweep-out_tf_plot.png

Trying to take a TF with the BOOST on (to emulate the state of the system while running the gyro) proved fruitless, as this causes the output to rail regardless of how low you make the source or whether you go in at SWEEP or INPUT. This is problematic because we would like to do the closed-loop measurements on the actual (BOOST on) running state of the gyro. It is possible that engaging the boost produces an unwanted offset, and this would explain why doing so with the cavity locked sometimes causes it to drop. I will take a look at the schematic to see if something is obviously wrong with the circuit. 

 

 

 

  1028   Thu Sep 9 05:17:19 2010 DmassElectronicsstuff happensWho cares!

I switched to using one newport to control both ovens (one has no sensor, is just getting the actuation signal from teh other).

I was able to get the Mach Zehnder back and running.

Leaving it running overnight with with its calibration line on and HEPA off...I also have AC coupled thermistors on each oven being recorded by the DAQ now, so this should tell me exactly how "not ok" it is to use one controller for two ovens, which comes down to how correlated the low frequency temperature changes are inside the box.

Next up - HEPA on / off test, and comparison of 1 controller phase noise spectrum with 2 controller phase noise spectrum.

  1027   Thu Sep 9 00:22:14 2010 DmassElectronicsstuff happensNewport 3040 fukt?

I spent the better half of the day trying to debug the 3040 - I returned to an old working hardware setup with some extra 100 Ohm platinum RTDs, but I couldn't get one of the 3040's to read it in the right way. Resistance is "err", and nothing I seem to do or plug in seems to change it.

  • I checked the cabling to the 3040 - it was fine (no open connections, or mysterious shorts)
  • I checked the software limits and tried to make them as large as possible
  • I checked the sensor type and its coefficients
  • I switched the RTDs between 3040's, the failure followed the 3040
  • I did the onboard calibration for the RTD with a 100 Ohm thin film, as per the manuals instructions
  • I calibrated out the RTDs leads with a short, as per the manuals instructions.
  • I restored the machine to an earlier state (presumably from when it was still @ MIT), and repeated the above - still nothing.

Back story which may or may not be pertinent (guesses at possible damage here).

  • I snapped off the lead from my 100 Ohm RTD on my oven a few days ago.
  • I tried to use a 1000 kOhm RTD which I already had affixed to the oven as a spare, but the 3040 doesn't seem to know about these -
  • I had a 1 kOhm RTD in with the coefficients from a 100 Ohm for a bit (as it wouldn't let me switch them)
  • It seems unlikely that the having wrong sensor type could damage your 3040, as you have to cycle through types with the ipod-esque wheel to select the right one.

I then tried to use an NTC thermistor as the sensor, since I had some already wired up.

  • The manual quoted +/- ranges for the Steinhart-Hart coefficients for thermistors, which seems to imply that NTC and PTC are O.K to use
  • I pulled the NTC Steinhart-Hart coefficients from a quick matlab fit
  • When I tried to use them,the 3040 told me they were illegal and forced the coefficients back to their default positive values

I abandoned this and soldered some connectors on some spare 100 Ohm RTDs, of the exact same type which is working on the other 3040. I then experienced the problems from the first list...

I hope there is something stupid that I am somehow missing, otherwise I either have to skip the last couple measurements for the paper, or wait wait wait for a replacement / refurb / homestyle debugging of the 3040 - I will try to recruit a fresh set of eyes tomorrow to look at this.

  1026   Wed Sep 8 18:13:26 2010 Alastair & ZachLaserGYROWindows are in

Alignment is done and the gyro is taking data now. We will post a new spectrum after a short while.

Quote:

 We installed the four CVI W2 windows on the box this afternoon.  We decided that to do the best job we would remove each side of the box so that the lens mounts could be put in place on a flat surface.

The sealant that we used was RTV108 which had very little smell as we were applying it.  As you can see from picture 2, it went on pretty smoothly and I'm confident that all windows are sealed nicely.  After leaving it to set for ~30mins the windows were installed and the box put back together round the cavity mirrors.

Unfortunately our best efforts at not moving anything have still resulted in the cavity becoming mis-aligned.  It is probably as a result of un-dog-clamping the box from the table and then re-clamping it again.  Working on realignment right now.

 

  1025   Wed Sep 8 17:51:15 2010 Alastair & ZachLaserGYROWindows are in

 We installed the four CVI W2 windows on the box this afternoon.  We decided that to do the best job we would remove each side of the box so that the lens mounts could be put in place on a flat surface.

The sealant that we used was RTV108 which had very little smell as we were applying it.  As you can see from picture 2, it went on pretty smoothly and I'm confident that all windows are sealed nicely.  After leaving it to set for ~30mins the windows were installed and the box put back together round the cavity mirrors.

Unfortunately our best efforts at not moving anything have still resulted in the cavity becoming mis-aligned.  It is probably as a result of un-dog-clamping the box from the table and then re-clamping it again.  Working on realignment right now.

Attachment 1: photo_3.jpg
photo_3.jpg
Attachment 2: photo_4.jpg
photo_4.jpg
Attachment 3: photo_2.JPG
photo_2.JPG
Attachment 4: photo_5.JPG
photo_5.JPG
  1024   Wed Sep 8 02:00:36 2010 DmassLaserDoublingOven Snafu Update

I had a minor accident with the ovens a couple days ago - the lead of the 100 Ohm platinum RTD broke off at the RTD. I was using this for the loop.

I have a 1 kOhm platinum RTD affixed to the oven, but apparently the newport 3040 doesn't "know about" 1 kOhm RTDs, and forbids setting that as its resistance internally. I am opting to grab another 100 Ohm RTD from my pile at home and tape it on top tomorrow.

I feel the need to say this internal limitation from the 3040 is this months "most ridiculous thing I have encountered from anything which costs more than 2$," as it is totally unneccesary.

  1023   Tue Sep 7 23:43:46 2010 DmassLaserDoublingMZ Freq Noise Spectrum / Noise Budget

Adding in temperature to the noise budget.

From this entry (this sinc^2 phase matching curve), I get a temperature calibration of

  • ~(43 - 37.5 C)=pi radians
  • 5.5 Kelvin / radian   or  0.18 rad / K

From this entry we see the level of temperature noise expected.

Sadly, I only trust this curve for one of my temperature controllers, because the resistors (for temperature sensing) are at very different places on the oven, and (probably related) the loop gains which make it not oscillate seemed to be at different settings.

The lowest upper bound which I can get from my data is made of the following:

  • The 300 Fast temperature curve (which reflects the settings on one of my temperature controllers - presumably the one which was used in the measurement)
  • The calibration above
  • A single pole at 0.1 Hz (details on its estimation below)

Pole Freq Estimation:

  1. From looking at the step response of the oven to a current, I found a pole at 1/60 Hz.
  2. This is the response from the bottom of the oven to the top (where the temp. sensor is)
  3. I assume the pole frequency scales as 1 / thermal mass (Volume)
  4. The bottom piece of the oven (between the TEC and the PPKTP) is 3-5x as thick as the top (between the PPKTP and the resistor)
  5. This implies the transfer function between the temp sensor and the PPKTP is a pole @ ~1/60*(4 or 6) which is 1/15 to 1/10 Hz

Note that at 0.1 Hz, my temperature noise is ~4 mK/rtHz ~ 0.5 mrad/rtHz (sqrt(2) added to the obvious calibration). The temperature noise of the other oven could easily differ by a factor of 2-3 and account for this, or the excess noise could still be some air current left over after the HEPA is off.

 

  1022   Tue Sep 7 13:28:16 2010 DmassLaserDoublingMZ Freq Noise Spectrum / Noise Budget

Added in dark and shot noise, as well as lower band RMS's

Attachment 1: MZFreqNoiseBud.pdf
MZFreqNoiseBud.pdf
  1021   Mon Sep 6 16:37:05 2010 ZachLaserGYRONew gyro noise spectrum

Now that stuff is working again, I took a spectrum of the gyro in the newest configuration (the one detailed here).

The calibration is: 6.103 x 10-4 V/ct * 375 kHz/V * (lambda * S)/(4*A) [rad/s / Hz] = 3.09 x 10-4 rad/s /ct

gyro_noise_9_3_2010.png

It is roughly a factor of 10 better than before at and below 10 Hz, though this comes with the grain of salt that the calibration was off by a factor of 2*pi before, and that there exists some ambiguity over whether or not the measurement can be trusted due to our incomplete understanding of the loop. The noise above 10 Hz is pretty much the same.

It appears that someone was futzing with the gyro over the week, as the BOOSTs on both boxes were turned OFF and the CW camera was off center. Please document your futzings.

  1020   Mon Sep 6 16:23:19 2010 DmassComputingDAQSSHD (re?)started

FB1 was sitting at login so it seems like it hasn't been opened up since its last restart. SSHD was not running (ps -elf |grep sshd returned nothing).

From /etc/init.d I ran:

sudo ./sshd start

sshing now works again, though we are still trying not to do it as per Rana's earlier post.

 

I also clicked the "DAQ RELOAD" button in the GDS TP medm screen, and the FB0 config light went from red to green.

  1019   Sat Sep 4 03:34:42 2010 DmassComputingDAQUndocumented change?

I don't know if this was automatically restarted, or some ninja did something, but I can get data now. It seems this should not be possible without SSHing into the ATF network and playing around with the medm buttons (or their corresponding commands).

If no one was touching it, I am confused, as controls@131.215.115.216 is still refusing SSH's

  1018   Sat Sep 4 02:21:46 2010 FrankComputingDAQUndocumented change?

Quote:

Quote:

Quote:

I could not ssh into fb1 from ws2 to run apps (DTT). I checked from the outside world, and same thing. 131. 215.115.216 no longer says hello.

Did someone reconfigure something to disable ssh'ing, or is this a spontaneous change?

 As of 12:40 am Sat morning, I can no longer get data from offsite (my channel list request fails). It was working this afternoon, and seems to have been working 40 minutes ago when I asked it for 2 hours of 256 Hz, but it may have choked on that.

 As of 1:48 AM the error is:
C
Warning: Error number -1 while querying for C2:ATF-DAQ1_GEN2_OUT_DAQ

darkness =

        name: 'C2:ATF-DAQ1_GEN2_OUT_DAQ'
        data: []
        rate: 256
       start: 967625192
    duration: 18

On a get data. Same for other channels.

The only thing I have done to the entire front end set up is add a DAQ channel, and killed the daqdaemon (on fb0).

 i think you have to reload the daq too, otherwise the channel count and datarate of the daq (rt model running) is different from the one of the daqd expects to find. They use a shared memory to exchange data. If think you don't reload the daq the amount and order of data/channels exchanged is different from what the daqd expects to find in the shared memory (and maybe in which order). We should ask alex if this is true..

You can find that button in the upper left corner of the main medm screen for your subsystem.  The last time we had this issue i reloaded the daq, reloaded all filters and coefficients (which both i think are not necessary) and then restarted the daqd by using sudo pkill daqd and everything worked fine.  That's how did this all the time with the psl subsystem and i never had problems with getting data from that...

  1017   Sat Sep 4 01:49:23 2010 DmassComputingDAQUndocumented change?

Quote:

Quote:

I could not ssh into fb1 from ws2 to run apps (DTT). I checked from the outside world, and same thing. 131. 215.115.216 no longer says hello.

Did someone reconfigure something to disable ssh'ing, or is this a spontaneous change?

 As of 12:40 am Sat morning, I can no longer get data from offsite (my channel list request fails). It was working this afternoon, and seems to have been working 40 minutes ago when I asked it for 2 hours of 256 Hz, but it may have choked on that.

 As of 1:48 AM the error is:
C
Warning: Error number -1 while querying for C2:ATF-DAQ1_GEN2_OUT_DAQ

darkness =

        name: 'C2:ATF-DAQ1_GEN2_OUT_DAQ'
        data: []
        rate: 256
       start: 967625192
    duration: 18

On a get data. Same for other channels.

The only thing I have done to the entire front end set up is add a DAQ channel, and killed the daqdaemon (on fb0).

  1016   Sat Sep 4 00:44:20 2010 DmassComputingDAQUndocumented change?

Quote:

I could not ssh into fb1 from ws2 to run apps (DTT). I checked from the outside world, and same thing. 131. 215.115.216 no longer says hello.

Did someone reconfigure something to disable ssh'ing, or is this a spontaneous change?

 As of 12:40 am Sat morning, I can no longer get data from offsite (my channel list request fails). It was working this afternoon, and seems to have been working 40 minutes ago when I asked it for 2 hours of 256 Hz, but it may have choked on that.

  1015   Fri Sep 3 14:45:20 2010 DmassComputingDAQUndocumented change?

I could not ssh into fb1 from ws2 to run apps (DTT). I checked from the outside world, and same thing. 131. 215.115.216 no longer says hello.

Did someone reconfigure something to disable ssh'ing, or is this a spontaneous change?

  1014   Fri Sep 3 10:21:29 2010 KojiElectronicsDoublingCalibration Line

Those plots are so beautifull...I was so much impressed

Quote:

Here is the calibrated spectra generated from about 2 hours of data last night. I included a coherent subtraction of the IR from the green (the black curve). Table resonances nicely decimated.

I have put a script which auto calibrates and generates spectra in the svn under /mDV/extra/C2/dmass/MZSpecGenerator.m

 

 

Edit - Added shot noise, and put a plot in terms of frequency noise (Note that the y axis is mislabeled, and should read Hz/rtHz).

NOTE THE RELATIVE FREQUENCY STABILITY. When I look at it like this, chasing the "excess phase noise" leftover from locking the MZ at low frequency seems a lot less important.

 

  1013   Thu Sep 2 19:10:04 2010 DmassElectronicsDoublingCalibration Line

Here is the calibrated spectra generated from about 2 hours of data last night. I included a coherent subtraction of the IR from the green (the black curve). Table resonances nicely decimated.

I have put a script which auto calibrates and generates spectra in the svn under /mDV/extra/C2/dmass/MZSpecGenerator.m

 

 

Edit - Added shot noise, and put a plot in terms of frequency noise (Note that the y axis is mislabeled, and should read Hz/rtHz).

NOTE THE RELATIVE FREQUENCY STABILITY. When I look at it like this, chasing the "excess phase noise" leftover from locking the MZ at low frequency seems a lot less important.

Attachment 1: MZNoiseBud.pdf
MZNoiseBud.pdf
Attachment 2: MZFreqSubRMS.pdf
MZFreqSubRMS.pdf
  1012   Wed Sep 1 20:31:26 2010 DmassElectronicsDoublingCalibration Line

I added a calibration line to the MZ PZT - I used the "Dither in" input on the HV PZT Drive Box (D060283)

I am using a function generator (SRDS335) to put a 12Vpp 100 Hz sine wave into this input.

The input goes through a Sallen-Key high pass with a corner of 2.4kHz, so this is around 58 dB down by the time it gets added into the drive signal. I looked at the gain in RMS from this, and it was not dominant in the band of interest.

I took some spectra with a relatively precise (< 5%) calibration of:

2 V/rad for Green diff

4.5 V/rad for IR diff

With a 0.03 Hz BW measurement in DTT, these show up with about an SNR > 10 with peak heights of:

0.00261 for IR

0.00239 for Green

These were spectra taken in Volts/rtHz

 

 

 

 

Attachment 1: MZCalLinePZT.pdf
MZCalLinePZT.pdf
  1011   Wed Sep 1 04:43:45 2010 DmassComputingDAQsome restarts on fb0: too many cooks

For the record - one of the symptoms was that we couldn't get data through mdv. This was fixed by rebooting the router. The system as built is not very robust - I will need a couple days of stable quiet operation to get all the data I need to wrap up my paper.

  1010   Wed Sep 1 02:21:23 2010 ranaComputingDAQsome restarts on fb0: too many cooks

Today Frank, me and Dmass all started making changes at the same time and broke everything. Please stop booting and fiddling at random. This means you Frank!

I set the time on fb0 to the correct time by using the command 'date -s'. It still has the issue that the ntp.conf is set to point at the wrong place. We need a NAT router and a gateway...

I also restarted the daqd process by the usual way of killing the running process. Same for nds. I changed the syntax in the start_nds.inittab to have the same error and logging

redirection as what we have at the 40m. This required knowledge of obscure Bourne shell stdout and stderr redirection sadly.

 

After restarting daqd, we could get data again by running diaggui on fb1 from the /apps directory (not /opt/apps/).

 

To conduct an experiment in DAQ stability, please stop even ssh'ing in to the router or fb1 until further notice. We want to see if the system dies by itself while taking data even if we stop

doing our 'this won't effect anything' nonsense.

  1009   Wed Sep 1 00:33:56 2010 DmassComputingDAQmDV NDS DTT DV etc

I looked on fb1, and noticed that:

[controls@fb1 fb1]$ ps -elf |grep nds
4 S root      3745     1  0  78   0 - 11481 wait   Aug26 ?        00:00:00 su controls -c env /cvs/cds/caltech/target/fb1/nds /cvs/cds/caltech/target/fb1/pipe
4 S controls  3769  3745  0  78   0 - 17209 rt_sig Aug26 ?        00:00:00 tcsh -c env /cvs/cds/caltech/target/fb1/nds /cvs/cds/caltech/target/fb1/pipe
0 S controls  3846  3769  0  78   0 - 13161 -      Aug26 ?        00:00:00 /cvs/cds/caltech/target/fb1/nds /cvs/cds/caltech/target/fb1/pipe
0 S controls 22459 22333  0  77   0 - 15297 pipe_w 00:29 pts/5    00:00:00 grep nds

I saw a tcsh thing running, and tried to kill it (sudo kill -9 PID), to see if this might be part of the problem

[controls@fb1 fb1]$ ps -elf |grep nds
0 S controls  3846     1  0  78   0 - 13161 -      Aug26 ?        00:00:00 /cvs/cds/caltech/target/fb1/nds /cvs/cds/caltech/target/fb1/pipe
4 S root     22506     1  0  77   0 - 11481 wait   00:30 ?        00:00:00 su controls -c env /cvs/cds/caltech/target/fb1/nds /cvs/cds/caltech/target/fb1/pipe
4 S controls 22507 22506  0  78   0 - 13161 -      00:30 ?        00:00:00 /cvs/cds/caltech/target/fb1/nds /cvs/cds/caltech/target/fb1/pipe
0 S controls 22563 22333  0  78   0 - 15297 pipe_w 00:32 pts/5    00:00:00 grep nds

 

 

  1008   Wed Sep 1 00:13:32 2010 FrankComputingDAQmDV NDS DTT DV etc

daqd on fb0 seems to be broken. i can't get any data from the past, hours, days or weeks ago.
I always get:

Connecting to NDS Server fb0 (TCP port 8088)
Connecting.... done
read(); errno=0
LONG: DataRead = -1
No data found

even, when using slow epics channels.
But if i telnet into it and pull up the channel status everything is fine and lots of channels are written with the correct data rate.
So i don't know, fb1 is working fine. Getting a channel list from fb0 too.

The error message you get when starting the daqd on fb1 is not new, but Alex doesn't know what it means and it only happened a couple of times so far and everything is working.
ca "CA.Client.Exception" is our network problem in the PSL lab...

 

  1007   Tue Aug 31 23:02:35 2010 FrankComputingDAQcurrent channel list on fb1 - note to remove dead/unused channels

241 channels total
0 gds channels
0 gds channels aliases
240 trend channels
1Hz clock
chnum   slow    |name                           |rate   |trend  |group  |bps    |bytes  |offset |type   |active
0       0       C2:PEM-SENS1_TEMP                               16      1       0       4       64      0       4       1
0       0       C2:PEM-SENS1_HUMIDITY                           16      1       0       4       64      64      4       1
0       0       C2:PEM-SENS1_PRESSURE                           16      1       0       4       64      128     4       1
0       0       C2:PEM-SENS1_BATTERY                            16      1       0       4       64      192     4       1
0       0       C2:PEM-SENS1_UPDATE                             16      1       0       4       64      256     4       1
0       0       C2:PEM-SENS1_STRENGTH                           16      1       0       4       64      320     4       1
0       0       C2:PEM-SENS1_SUCCESS                            16      1       0       4       64      384     4       1
0       0       C2:PEM-SENS1_ACTIVE                             16      1       0       4       64      448     4       1
0       0       C3:PEM-SENS1_TEMP                               16      1       0       4       64      512     4       1
0       0       C3:PEM-SENS1_HUMIDITY                           16      1       0       4       64      576     4       1
0       0       C3:PEM-SENS1_PRESSURE                           16      1       0       4       64      640     4       1
0       0       C3:PEM-SENS1_BATTERY                            16      1       0       4       64      704     4       1
0       0       C3:PEM-SENS1_UPDATE                             16      1       0       4       64      768     4       1
0       0       C3:PEM-SENS1_STRENGTH                           16      1       0       4       64      832     4       1
0       0       C3:PEM-SENS1_SUCCESS                            16      1       0       4       64      896     4       1
0       0       C3:PEM-SENS1_ACTIVE                             16      1       0       4       64      960     4       1
0       0       C4:PEM-SENS1_TEMP                               16      1       0       4       64      1024    4       1
0       0       C4:PEM-SENS1_HUMIDITY                           16      1       0       4       64      1088    4       1
0       0       C4:PEM-SENS1_PRESSURE                           16      1       0       4       64      1152    4       1
0       0       C4:PEM-SENS1_BATTERY                            16      1       0       4       64      1216    4       1
0       0       C4:PEM-SENS1_UPDATE                             16      1       0       4       64      1280    4       1
0       0       C4:PEM-SENS1_STRENGTH                           16      1       0       4       64      1344    4       1
0       0       C4:PEM-SENS1_SUCCESS                            16      1       0       4       64      1408    4       1
0       0       C4:PEM-SENS1_ACTIVE                             16      1       0       4       64      1472    4       1
0       0       C5:PEM-SENS1_TEMP                               16      1       0       4       64      1536    4       1
0       0       C5:PEM-SENS1_HUMIDITY                           16      1       0       4       64      1600    4       1
0       0       C5:PEM-SENS1_PRESSURE                           16      1       0       4       64      1664    4       1
0       0       C5:PEM-SENS1_BATTERY                            16      1       0       4       64      1728    4       1
0       0       C5:PEM-SENS1_UPDATE                             16      1       0       4       64      1792    4       1
0       0       C5:PEM-SENS1_STRENGTH                           16      1       0       4       64      1856    4       1
0       0       C5:PEM-SENS1_SUCCESS                            16      1       0       4       64      1920    4       1
0       0       C5:PEM-SENS1_ACTIVE                             16      1       0       4       64      1984    4       1
0       0       C6:PEM-SENS1_TEMP                               16      1       0       4       64      2048    4       1
0       0       C6:PEM-SENS1_HUMIDITY                           16      1       0       4       64      2112    4       1
0       0       C6:PEM-SENS1_PRESSURE                           16      1       0       4       64      2176    4       1
0       0       C6:PEM-SENS1_BATTERY                            16      1       0       4       64      2240    4       1
0       0       C6:PEM-SENS1_UPDATE                             16      1       0       4       64      2304    4       1
0       0       C6:PEM-SENS1_STRENGTH                           16      1       0       4       64      2368    4       1
0       0       C6:PEM-SENS1_SUCCESS                            16      1       0       4       64      2432    4       1
0       0       C6:PEM-SENS1_ACTIVE                             16      1       0       4       64      2496    4       1
0       0       C2:PSL-AMP_MANUALMODE                           16      1       0       4       64      2560    4       1
0       0       C2:PSL-AMP_DBILOCK                              16      1       0       4       64      2624    4       1
0       0       C2:PSL-AMP_DCUROK                               16      1       0       4       64      2688    4       1
0       0       C2:PSL-AMP_ENABLETEC                            16      1       0       4       64      2752    4       1
0       0       C2:PSL-AMP_ERR                                  16      1       0       4       64      2816    4       1
0       0       C2:PSL-AMP_OFF                                  16      1       0       4       64      2880    4       1
0       0       C2:PSL-AMP_RESET                                16      1       0       4       64      2944    4       1
0       0       C2:PSL-AMP_DTEMPERR                             16      1       0       4       64      3008    4       1
0       0       C2:PSL-AMP_ENABLEPWRDOG                         16      1       0       4       64      3072    4       1
0       0       C2:PSL-AMP_SYSTEMOK                             16      1       0       4       64      3136    4       1
0       0       C2:PSL-AMP_LOWPWR                               16      1       0       4       64      3200    4       1
0       0       C2:PSL-AMP_CHILLERR                             16      1       0       4       64      3264    4       1
0       0       C2:PSL-AMP_DVOLT1                               16      1       0       4       64      3328    4       1
0       0       C2:PSL-AMP_DVOLT2                               16      1       0       4       64      3392    4       1
0       0       C2:PSL-AMP_PWR1                                 16      1       0       4       64      3456    4       1
0       0       C2:PSL-AMP_PWR2                                 16      1       0       4       64      3520    4       1
0       0       C2:PSL-AMP_PWR3                                 16      1       0       4       64      3584    4       1
0       0       C2:PSL-AMP_D1TEMP                               16      1       0       4       64      3648    4       1
0       0       C2:PSL-AMP_D2TEMP                               16      1       0       4       64      3712    4       1
0       0       C2:PSL-AMP_D3TEMP                               16      1       0       4       64      3776    4       1
0       0       C2:PSL-AMP_D4TEMP                               16      1       0       4       64      3840    4       1
0       0       C2:PSL-AMP_D1PWR                                16      1       0       4       64      3904    4       1
0       0       C2:PSL-AMP_D2PWR                                16      1       0       4       64      3968    4       1
0       0       C2:PSL-AMP_D3PWR                                16      1       0       4       64      4032    4       1
0       0       C2:PSL-AMP_D4PWR                                16      1       0       4       64      4096    4       1
0       0       C2:PSL-AMP_DCUR1                                16      1       0       4       64      4160    4       1
0       0       C2:PSL-AMP_DCUR2                                16      1       0       4       64      4224    4       1
0       0       C2:PSL-AMP_XTALTEMP                             16      1       0       4       64      4288    4       1
0       0       C2:PSL-AMP_SECS                                 16      1       0       4       64      4352    4       1
0       0       C2:PSL-AMP_MINS                                 16      1       0       4       64      4416    4       1
0       0       C2:PSL-AMP_HRS                                  16      1       0       4       64      4480    4       1
0       0       C2:PSL-AMP_DAYS                                 16      1       0       4       64      4544    4       1
0       0       C2:PSL-NPRO_D1PWR                               16      1       0       4       64      4608    4       1
0       0       C2:PSL-NPRO_D2PWR                               16      1       0       4       64      4672    4       1
0       0       C2:PSL-NPRO_D1TEMPSET                           16      1       0       4       64      4736    4       1
0       0       C2:PSL-NPRO_D2TEMPSET                           16      1       0       4       64      4800    4       1
0       0       C2:PSL-NPRO_D1TEMP                              16      1       0       4       64      4864    4       1
0       0       C2:PSL-NPRO_D2TEMP                              16      1       0       4       64      4928    4       1
0       0       C2:PSL-NPRO_D1TEMPERR                           16      1       0       4       64      4992    4       1
0       0       C2:PSL-NPRO_D2TEMPERR                           16      1       0       4       64      5056    4       1
0       0       C2:PSL-NPRO_TEMPGUARD1                          16      1       0       4       64      5120    4       1
0       0       C2:PSL-NPRO_TEMPGUARD2                          16      1       0       4       64      5184    4       1
0       0       C2:PSL-NPRO_XTALTEMPSET                         16      1       0       4       64      5248    4       1
0       0       C2:PSL-NPRO_XTALTEMP                            16      1       0       4       64      5312    4       1
0       0       C2:PSL-NPRO_XTALTEMPERR                         16      1       0       4       64      5376    4       1
0       0       C2:PSL-NPRO_CURSET                              16      1       0       4       64      5440    4       1
0       0       C2:PSL-NPRO_CUR                                 16      1       0       4       64      5504    4       1
0       0       C2:PSL-NPRO_NEMON                               16      1       0       4       64      5568    4       1
0       0       C3:PSL-GEN_DAQ14                                16      1       0       4       64      5632    4       1
0       0       C3:PSL-GEN_DAQ15                                16      1       0       4       64      5696    4       1
0       0       C3:PSL-GEN_DAQ16                                16      1       0       4       64      5760    4       1
0       0       C3:PSL-GEN_D2A3                                 16      1       0       4       64      5824    4       1
0       0       C3:PSL-GEN_D2A4                                 16      1       0       4       64      5888    4       1
0       0       C3:PSL-GEN_D2A5                                 16      1       0       4       64      5952    4       1
0       0       C3:PSL-GEN_D2A6                                 16      1       0       4       64      6016    4       1
0       0       C3:PSL-GEN_D2A7                                 16      1       0       4       64      6080    4       1
0       0       C3:PSL-GEN_D2A8                                 16      1       0       4       64      6144    4       1
0       0       C3:PSL-ACAV_SENS1                               16      1       0       4       64      6208    4       1
0       0       C3:PSL-ACAV_SENS2                               16      1       0       4       64      6272    4       1
0       0       C3:PSL-ACAV_SENS3                               16      1       0       4       64      6336    4       1
0       0       C3:PSL-ACAV_SENS4                               16      1       0       4       64      6400    4       1
0       0       C3:PSL-ACAV_OOL                                 16      1       0       4       64      6464    4       1
0       0       C3:PSL-ACAV_TEMP                                16      1       0       4       64      6528    4       1
0       0       C3:PSL-ACAV_TEMPAVG                             16      1       0       4       64      6592    4       1
0       0       C3:PSL-ACAV_HEATER                              16      1       0       4       64      6656    4       1
0       0       C3:PSL-ACAV_SETPT                               16      1       0       4       64      6720    4       1
0       0       C3:PSL-ACAV_KP                                  16      1       0       4       64      6784    4       1
0       0       C3:PSL-ACAV_KI                                  16      1       0       4       64      6848    4       1
0       0       C3:PSL-ACAV_KD                                  16      1       0       4       64      6912    4       1
0       0       C3:PSL-ACAV_ENABLE                              16      1       0       4       64      6976    4       1
0       0       C3:PSL-ACAV_TIMEOUT                             16      1       0       4       64      7040    4       1
0       0       C3:PSL-ACAV_SCALE                               16      1       0       4       64      7104    4       1
0       0       C3:PSL-ACAV_RFPDDC                              16      1       0       4       64      7168    4       1
0       0       C3:PSL-ACAV_RCTRANSPD                           16      1       0       4       64      7232    4       1
0       0       C3:PSL-ACAV_LOCKEDLEVEL                         16      1       0       4       64      7296    4       1
0       0       C3:PSL-RCAV_SENS1                               16      1       0       4       64      7360    4       1
0       0       C3:PSL-RCAV_SENS2                               16      1       0       4       64      7424    4       1
0       0       C3:PSL-RCAV_SENS3                               16      1       0       4       64      7488    4       1
0       0       C3:PSL-RCAV_SENS4                               16      1       0       4       64      7552    4       1
0       0       C3:PSL-RCAV_OOL                                 16      1       0       4       64      7616    4       1
0       0       C3:PSL-RCAV_TEMP                                16      1       0       4       64      7680    4       1
0       0       C3:PSL-RCAV_TEMPAVG                             16      1       0       4       64      7744    4       1
0       0       C3:PSL-FSS_HEATER                               16      1       0       4       64      7808    4       1
0       0       C3:PSL-RCAV_SETPT                               16      1       0       4       64      7872    4       1
0       0       C3:PSL-RCAV_KP                                  16      1       0       4       64      7936    4       1
0       0       C3:PSL-RCAV_KI                                  16      1       0       4       64      8000    4       1
0       0       C3:PSL-RCAV_KD                                  16      1       0       4       64      8064    4       1
0       0       C3:PSL-RCAV_ENABLE                              16      1       0       4       64      8128    4       1
0       0       C3:PSL-RCAV_TIMEOUT                             16      1       0       4       64      8192    4       1
0       0       C3:PSL-RCAV_SCALE                               16      1       0       4       64      8256    4       1
0       0       C3:PSL-RCAV_RFPDDC                              16      1       0       4       64      8320    4       1
0       0       C3:PSL-RCAV_RCTRANSPD                           16      1       0       4       64      8384    4       1
0       0       C3:PSL-RCAV_LOCKEDLEVEL                         16      1       0       4       64      8448    4       1
0       0       C3:PSL-FSS_RFPDDC                               16      1       0       4       64      8512    4       1
0       0       C3:PSL-FSS_LODET                                16      1       0       4       64      8576    4       1
0       0       C3:PSL-FSS_PCDET                                16      1       0       4       64      8640    4       1
0       0       C3:PSL-FSS_FAST                                 16      1       0       4       64      8704    4       1
0       0       C3:PSL-FSS_PCDRIVE                              16      1       0       4       64      8768    4       1
0       0       C3:PSL-FSS_RCTRANSPD                            16      1       0       4       64      8832    4       1
0       0       C3:PSL-FSS_RCTLL                                16      1       0       4       64      8896    4       1
0       0       C3:PSL-FSS_VCODET                               16      1       0       4       64      8960    4       1
0       0       C3:PSL-FSS_TIDALOUT                             16      1       0       4       64      9024    4       1
0       0       C3:PSL-FSS_MODET                                16      1       0       4       64      9088    4       1
0       0       C3:PSL-FSS_VCODETPWR                            16      1       0       4       64      9152    4       1
0       0       C3:PSL-FSS_MIXERM                               16      1       0       4       64      9216    4       1
0       0       C3:PSL-FSS_SLOWM                                16      1       0       4       64      9280    4       1
0       0       C3:PSL-FSS_VCOM                                 16      1       0       4       64      9344    4       1
0       0       C3:PSL-FSS_TIDALINPUT                           16      1       0       4       64      9408    4       1
0       0       C3:PSL-FSS_SW1                                  16      1       0       4       64      9472    4       1
0       0       C3:PSL-FSS_SW2                                  16      1       0       4       64      9536    4       1
0       0       C3:PSL-FSS_PHFLIP                               16      1       0       4       64      9600    4       1
0       0       C3:PSL-FSS_VCOTESTSW                            16      1       0       4       64      9664    4       1
0       0       C3:PSL-FSS_VCOWIDESW                            16      1       0       4       64      9728    4       1
0       0       C3:PSL-FSS_INOFFSET                             16      1       0       4       64      9792    4       1
0       0       C3:PSL-FSS_MGAIN                                16      1       0       4       64      9856    4       1
0       0       C3:PSL-FSS_FASTGAIN                             16      1       0       4       64      9920    4       1
0       0       C3:PSL-FSS_PHCON                                16      1       0       4       64      9984    4       1
0       0       C3:PSL-FSS_RFADJ                                16      1       0       4       64      10048   4       1
0       0       C3:PSL-FSS_SLOWDC                               16      1       0       4       64      10112   4       1
0       0       C3:PSL-FSS_VCOPWR                               16      1       0       4       64      10176   4       1
0       0       C3:PSL-FSS_VCOMODLEVEL                          16      1       0       4       64      10240   4       1
0       0       C3:PSL-FSS_TIDALSET                             16      1       0       4       64      10304   4       1
0       0       C3:PSL-FSS_LOCK                                 16      1       0       4       64      10368   4       1
0       0       C3:PSL-FSS_SLOWLOOP                             16      1       0       4       64      10432   4       1
0       0       C3:PSL-PMC_PMCTLL                               16      1       0       4       64      10496   4       1
0       0       C3:PSL-PMC_RFPDDC                               16      1       0       4       64      10560   4       1
0       0       C3:PSL-PMC_LODET                                16      1       0       4       64      10624   4       1
0       0       C3:PSL-PMC_PMCTRANSPD                           16      1       0       4       64      10688   4       1
0       0       C3:PSL-PMC_PCDRIVE                              16      1       0       4       64      10752   4       1
0       0       C3:PSL-PMC_PZT                                  16      1       0       4       64      10816   4       1
0       0       C3:PSL-PMC_MODET                                16      1       0       4       64      10880   4       1
0       0       C3:PSL-PMC_PMCERR                               16      1       0       4       64      10944   4       1
0       0       C3:PSL-PMC_SW1                                  16      1       0       4       64      11008   4       1
0       0       C3:PSL-PMC_SW2                                  16      1       0       4       64      11072   4       1
0       0       C3:PSL-PMC_PHFLIP                               16      1       0       4       64      11136   4       1
0       0       C3:PSL-PMC_BLANK                                16      1       0       4       64      11200   4       1
0       0       C3:PSL-PMC_GAIN                                 16      1       0       4       64      11264   4       1
0       0       C3:PSL-PMC_INOFFSET                             16      1       0       4       64      11328   4       1
0       0       C3:PSL-PMC_PHCON                                16      1       0       4       64      11392   4       1
0       0       C3:PSL-PMC_RFADJ                                16      1       0       4       64      11456   4       1
0       0       C3:PSL-PMC_RAMP                                 16      1       0       4       64      11520   4       1
0       0       C3:PSL-PMC_LOCK                                 16      1       0       4       64      11584   4       1
0       0       C3:PSL-PEM_RMTEMP                               16      1       0       4       64      11648   4       1
0       0       C3:PSL-PEM_BOXTEMP                              16      1       0       4       64      11712   4       1
0       0       C4:TCS-HWS_TEMP_SENSOR                          16      1       0       4       64      11776   4       1
0       0       C4:TCS-HWS_TEMP_DIGITIZER                       16      1       0       4       64      11840   4       1
0       0       C4:TCS-HWS_TAP1GAIN                             16      1       0       4       64      11904   4       1
0       0       C4:TCS-HWS_TAP2GAIN                             16      1       0       4       64      11968   4       1
0       0       C4:TCS-HWS_PRETRIGGER                           16      1       0       4       64      12032   4       1
0       0       C4:TCS-HWS_DATA_MODE                            16      1       0       4       64      12096   4       1
0       0       C4:TCS-HWS_BINNING_MODE                         16      1       0       4       64      12160   4       1
0       0       C4:TCS-HWS_GAIN_MODE                            16      1       0       4       64      12224   4       1
0       0       C4:TCS-HWS_OUTPUT_CONFIG                        16      1       0       4       64      12288   4       1
0       0       C4:TCS-HWS_EXPOSURE_MODE                        16      1       0       4       64      12352   4       1
0       0       C4:TCS-HWS_SYNC_FREQ                            16      1       0       4       64      12416   4       1
0       0       C4:TCS-HWS_EXPOSURE_TIME                        16      1       0       4       64      12480   4       1
0       0       C4:TCS-HWS_SERIAL_COMMS_STATUS                  16      1       0       4       64      12544   4       1
0       0       C4:TCS-HWS_DEFOCUS                              16      1       0       4       64      12608   4       1
0       0       C4:TCS-HWS_CENTROID_RMS                         16      1       0       4       64      12672   4       1
0       0       C4:TCS-HWS_SINGLE_FRAME_BKGD                    16      1       0       4       64      12736   4       1
0       0       C4:TCS-HWS_AVERAGE_INTENSITY                    16      1       0       4       64      12800   4       1
0       0       C4:TCS-HWS_N_CENTROID_CALC                      16      1       0       4       64      12864   4       1
0       0       C4:TCS-HWS_ZERNIKE_P_-1+1                       16      1       0       4       64      12928   4       1
0       0       C4:TCS-HWS_ZERNIKE_P_+1-1                       16      1       0       4       64      12992   4       1
0       0       C4:TCS-HWS_ZERNIKE_P_-2+2                       16      1       0       4       64      13056   4       1
0       0       C4:TCS-HWS_ZERNIKE_P_-0+2                       16      1       0       4       64      13120   4       1
0       0       C4:TCS-HWS_ZERNIKE_P_+2+2                       16      1       0       4       64      13184   4       1
0       0       C4:TCS-HWS_ZERNIKE_P_-3+3                       16      1       0       4       64      13248   4       1
0       0       C4:TCS-HWS_ZERNIKE_P_-1+3                       16      1       0       4       64      13312   4       1
0       0       C4:TCS-HWS_ZERNIKE_P_+1+3                       16      1       0       4       64      13376   4       1
0       0       C4:TCS-HWS_ZERNIKE_P_+3+3                       16      1       0       4       64      13440   4       1
0       0       C4:TCS-HWS_ZERNIKE_P_-4+4                       16      1       0       4       64      13504   4       1
0       0       C4:TCS-HWS_ZERNIKE_P_-2+4                       16      1       0       4       64      13568   4       1
0       0       C4:TCS-HWS_ZERNIKE_P_-0+4                       16      1       0       4       64      13632   4       1
0       0       C4:TCS-HWS_ZERNIKE_P_+2+4                       16      1       0       4       64      13696   4       1
0       0       C4:TCS-HWS_ZERNIKE_P_+4+4                       16      1       0       4       64      13760   4       1
0       0       C4:TCS-ATHENA_ADC0                              16      1       0       4       64      13824   4       1
0       0       C4:TCS-ATHENA_ADC1                              16      1       0       4       64      13888   4       1
0       0       C4:TCS-ATHENA_ADC2                              16      1       0       4       64      13952   4       1
0       0       C4:TCS-ATHENA_ADC3                              16      1       0       4       64      14016   4       1
0       0       C4:TCS-ATHENA_ADC4                              16      1       0       4       64      14080   4       1
0       0       C4:TCS-ATHENA_ADC5                              16      1       0       4       64      14144   4       1
0       0       C4:TCS-ATHENA_ADC6                              16      1       0       4       64      14208   4       1
0       0       C4:TCS-ATHENA_ADC7                              16      1       0       4       64      14272   4       1
0       0       C4:TCS-ATHENA_ADC8                              16      1       0       4       64      14336   4       1
0       0       C4:TCS-ATHENA_ADC9                              16      1       0       4       64      14400   4       1
0       0       C4:TCS-ATHENA_ADC10                             16      1       0       4       64      14464   4       1
0       0       C4:TCS-ATHENA_ADC11                             16      1       0       4       64      14528   4       1
0       0       C4:TCS-ATHENA_ADC12                             16      1       0       4       64      14592   4       1
0       0       C4:TCS-ATHENA_ADC13                             16      1       0       4       64      14656   4       1
0       0       C4:TCS-ATHENA_ADC14                             16      1       0       4       64      14720   4       1
0       0       C4:TCS-ATHENA_ADC15                             16      1       0       4       64      14784   4       1
0       0       C4:TCS-ATHENA_DAC0                              16      1       0       4       64      14848   4       1
0       0       C4:TCS-ATHENA_DAC1                              16      1       0       4       64      14912   4       1
0       0       C4:TCS-ATHENA_PD_VOLTAGE                        16      1       0       4       64      14976   4       1
0       0       C4:TCS-ATHENA_TEMP_SENS_V                       16      1       0       4       64      15040   4       1
0       0       C4:TCS-ATHENA_I_SET_VOLTS                       16      1       0       4       64      15104   4       1
0       0       C4:TCS-ATHENA_I_ACTUAL_VOLTS                    16      1       0       4       64      15168   4       1
0       0       C4:TCS-ATHENA_I_LIM_VOLTS                       16      1       0       4       64      15232   4       1
0       0       C4:TCS-ATHENA_PD_EXTERNAL_V                     16      1       0       4       64      15296   4       1
10001   0       C2:FB1-FB_DUMMY                                 16384   0       0       4       65536   15360   4       0

  1006   Tue Aug 31 22:07:03 2010 DmassComputingDAQmDV NDS DTT DV etc

I can't get data. mDV and DV showed the same failed behavior. (They did nothing when you request data).

I looked in the daqd log files:

/cvs/cds/caltech/target/fb/daqd.log had:

[Tue Aug 31 22:01:37 2010] ->19: version
[Tue Aug 31 22:01:37 2010] ->19: revision
[Tue Aug 31 22:01:37 2010] no_average=1

Tue Aug 31 22:01:37 2010 [16601]:decimation flag=1
[Tue Aug 31 22:01:37 2010] ->19: start net-writer 967351844 20 {"C2:ATF-CTRL_ISS_1_OUT_DAQ" 256}
[Tue Aug 31 22:01:37 2010] UNIX connect(); errno=111

[Tue Aug 31 22:01:37 2010] connection closed on fd=20

The channel I requested is shown as being written in the C2ATF.ini file.

/cvs/cds/caltech/target/fb1/daqd.log had:

[Tue Aug 31 21:42:30 2010] ->8: revision
[Tue Aug 31 21:42:30 2010] ->8: status channels 3
[Tue Aug 31 21:42:30 2010] connection on fd 10 closed
[Tue Aug 31 21:42:31 2010] connection on port 38943 from 10.0.1.11; fd=17
[Tue Aug 31 21:42:32 2010] ->8: version
[Tue Aug 31 21:42:32 2010] ->8: revision
[Tue Aug 31 21:42:32 2010] ->8: gps
[Tue Aug 31 21:42:32 2010] connection on fd 17 closed
CA.Client.Exception...............................................
    Warning: "Virtual circuit unresponsive"
    Context: "10.0.0.3:5064"
    Source File: ../tcpiiu.cpp line 921
    Current Time: Tue Aug 31 2010 21:43:43.255113000
..................................................................
CA.Client.Exception...............................................
    Warning: "Virtual circuit unresponsive"
    Context: "10.0.0.2:5064"
    Source File: ../tcpiiu.cpp line 921
    Current Time: Tue Aug 31 2010 21:44:20.907151000
..................................................................
CA.Client.Exception...............................................
    Warning: "Virtual circuit unresponsive"
    Context: "10.0.0.3:5064"
    Source File: ../tcpiiu.cpp line 921
    Current Time: Tue Aug 31 2010 21:45:43.759006000
..................................................................
CA.Client.Exception...............................................
    Warning: "Virtual circuit unresponsive"
    Context: "10.0.0.2:5064"
    Source File: ../tcpiiu.cpp line 921
    Current Time: Tue Aug 31 2010 21:47:12.898705000
..................................................................
CA.Client.Exception...............................................
    Warning: "Virtual circuit unresponsive"
    Context: "10.0.0.3:5064"
    Source File: ../tcpiiu.cpp line 921
    Current Time: Tue Aug 31 2010 21:49:51.762671000
..................................................................
CA.Client.Exception...............................................
    Warning: "Virtual circuit unresponsive"
    Context: "10.0.0.2:5064"
    Source File: ../tcpiiu.cpp line 921
    Current Time: Tue Aug 31 2010 21:53:36.383864000
..................................................................
CA.Client.Exception...............................................
    Warning: "Virtual circuit unresponsive"
    Context: "10.0.0.3:5064"
    Source File: ../tcpiiu.cpp line 921
    Current Time: Tue Aug 31 2010 21:53:58.267296000
..................................................................
CA.Client.Exception...............................................
    Warning: "Virtual circuit unresponsive"
    Context: "10.0.0.2:5064"
    Source File: ../tcpiiu.cpp line 921
    Current Time: Tue Aug 31 2010 21:55:14.367285000
..................................................................
CA.Client.Exception...............................................
    Warning: "Virtual circuit unresponsive"
    Context: "10.0.0.2:5064"
    Source File: ../tcpiiu.cpp line 921
    Current Time: Tue Aug 31 2010 21:56:37.363180000
.................................................................

I then restarted the daq daemon on fb1 (sudo pkill daqd), and the logfile poopped this out:

A call to "assert (pE == &entry)" failed in ../../cds/project/daq/fb2/exServer.h line 346.
EPICS Release EPICS R3.14.10- $R3-14-10-RC2$ $2008/10/10 15:01:51$.
Current time Tue Aug 31 2010 22:02:42.341179000.
Please E-mail this message to the author or to tech-talk@aps.anl.gov
Calling epicsThreadSuspendSelf()
[Tue Aug 31 22:02:43 2010] Minute trender made GPS time correction; gps=967352577; gps%60=57\

Dataviewers error was:

Connecting to NDS Server fb (TCP port 8088)
Connecting.... done
read(); errno=0
LONG: DataRead = -1
No data found

read(); errno=9
read(); errno=9
T0=10-09-01-05-13-55; Length=10 (s)
No data output.
 


 

 


 

  1005   Tue Aug 31 21:46:21 2010 DmassComputingDAQchanged default shell on fb1 back to bash

Is there a reason for this (on ssh into fb from ws2):

RSA host key for fb has changed and you have requested strict checking.
Host key verification failed.

 

  1004   Tue Aug 31 21:06:02 2010 DmassComputingDAQFB1 SOFTWARE FREEZE

I am running some stuff on FB1 (awg for a Cal line mainly) on which my data depends. Please restart/reboot/rebuild nothing on fb1 or fb(0). WS1 and 2 are meat as soon as I get everything set.

  1003   Tue Aug 31 13:12:14 2010 FrankComputingDAQchanged default shell on fb1 back to bash

changed default shell on fb1 back to bash temporarily, until the problems with tcsh are solved. The change to tcsh also causes that no sftp-service is running on fb1 and one can't use putty/winscp or other sftp tools for file transfer from/to fb1. changing back to bash fixes all the problems, including that all tools are working now.

Once we fixed those problems we can change to tcsh permanently

Quote:

or switch back to bash shell in the meantime. That's working too. Simply open a shell, type in bash and then run them from the command line.

All computers have problems finding stuff since rana changed the shell.. This includes fb1 where the path doesn't contain the right directories anymore and you can't run dataviewer, diaggui, foton, ezcaread, ezcawrite etc...
Also fb1 isn't running sftp services anymore and i can't copy anything via sftp on that machine...

Quote:

probably my fault. It looks like the working DTT is on fb1 in the /apps directory, but not in the /opt/apps directory. Something has gotten pointed to the wrong DTT during my path/shell cleanup.

Just use the fb1 version of diaggui and foton for now. I'll figure out which binaries are bad and then delete them tomorrow.

 

 

 

  1002   Tue Aug 31 12:30:40 2010 FrankComputingDAQFoton and DTT brokeded

or switch back to bash shell in the meantime. That's working too. Simply open a shell, type in bash and then run them from the command line.

All computers have problems finding stuff since rana changed the shell.. This includes fb1 where the path doesn't contain the right directories anymore and you can't run dataviewer, diaggui, foton, ezcaread, ezcawrite etc...
Also fb1 isn't running sftp services anymore and i can't copy anything via sftp on that machine...

Quote:

probably my fault. It looks like the working DTT is on fb1 in the /apps directory, but not in the /opt/apps directory. Something has gotten pointed to the wrong DTT during my path/shell cleanup.

Just use the fb1 version of diaggui and foton for now. I'll figure out which binaries are bad and then delete them tomorrow.

 

 

  1001   Tue Aug 31 02:37:53 2010 ranaComputingDAQFoton and DTT brokeded

probably my fault. It looks like the working DTT is on fb1 in the /apps directory, but not in the /opt/apps directory. Something has gotten pointed to the wrong DTT during my path/shell cleanup.

Just use the fb1 version of diaggui and foton for now. I'll figure out which binaries are bad and then delete them tomorrow.

 

  1000   Tue Aug 31 01:19:12 2010 DmassComputingDAQFoton and DTT brokeded

The Foton button didn't work on WS1.

  • The button does: sh -c 'cd /cvs/cds/caltech/chans; /opt/apps/Linux/gds/bin/foton'
  • I looked in /opt/apps/Linux/gds/bin and foton was there.
  • I tried to manually execute the command and got the error:   sh: line 1:  2793 Aborted                 /opt/apps/Linux/gds/bin/foton
  • DTT is similarly broken, and says "abort" when I try to run it in a terminal.
  • Same problem on ws2
  • The DV button (/opt/apps/Linux/dataviewer/dataviewer) works.

Have we started changing things?

I also restarted WS1 - no change. Not sure if there's some reason to not restart the frontend (via startatf then reboot) - there were silly reasons not to do other things.

 

  999   Sun Aug 29 23:04:17 2010 ranaLab Infrastructurestuff happenslab cleanup

The lab has turned into a pit again. Please clean up your stuff. There cannot be tools lying around or drinks or water bottles or used booties or scraps of paper.

Empty the trashes, change the sticky mats, etc.

I also power cycled the router. This router was just a bad choice - I suggest we just get the 24-port router which the 40m is using. I'll ask Joe if it will work.

  998   Fri Aug 27 16:55:55 2010 FrankComputingDAQworking mDV example

i've tested it again and it's still working. You can find a simple,  working example for mDV getting some trend data for two of my channels a couple of days ago attached here: temp_test.m

 you have to change the mdv_config file to point to 131.215.115.216:8088 instead of the 40m framebuilder

Quote:

Still having issues, but now more stuff is not working. Yesterday evening before I left, I noticed that I could load realtime data in DV, but not trended playback (didn't try raw). Still the same issue from here in FL: I get "NO DATA FOUND". I have verified that my channels are active and acquired.

As far as mDV is concerned, I don't get an error anymore when trying to get C2 data with get_data, but instead it just freezes at "C...". Now ligoDV doesn't work, either; it just spits out errors.

I want to try DTT, but without any time series data I don't know of a good time to try taking a spectrum. Is anything working for anyone?

Quote:

Seems to be working now for me. Maybe Zach can tell us when he gets to Fla if his issues are resolved post reboot.

 

 

  997   Fri Aug 27 11:51:41 2010 ZachLaserGYROgyro back to gyro configuration

I got the PLL back up and running yesterday before I left. I spent a disproportionate amount of time not knowing that the loop was not closed because "external source" was not on, despite that FM modulation was on and the source was set to external. I'm surprised there is no "modulation source to modulation ON/OFF" or "Displayed instrument settings to actual instrument settings ON/OFF" toggle on top of this.

The gyro is now in a state where it auto-acquires lock in both directions (though it sometimes catches on the TEM10), and the beat frequency is well within the PLL's lock range, so we get a gyro signal automatically. This signal (external voltage on the VCO) is acquired at GENERIC_DOF6_OUT, while TRANS DC is picked up at GENERIC_DOF7_OUT. I think DOF8_OUT has the actuation signal to the AOM VCO, but I don't remember for sure.

I made changes to various settings along the way. Here are the current ones:

  • CW PDH (AOM): G = 7, inv ON, boost ON, phi = 5. There is now a 20 dB attenuator at the output to the VCO. This seemed to help with keeping the gain at a reasonable value while not limiting our range on the VCO in lowering the deviation.
  • CCW PDH: G = 7, inv OFF, boost ON, phi = 4
  • AOM VCO: fnom = 47.451 MHz, dev = 100 kHz
  • PDH LO: fmod = 18 MHz. I tried using 33 MHz but the signal out of the (low-bandwidth) CW PD was puny and this generated noise downstream. This frequency appears devoid of other-modely interference.
  • PLL: fnom = 94.895719 MHz, dev = 375 kHz, SR560 G = 1 with no filtering (i.e. doing nothing)

I was not able to take a spectrum with DTT as the FB was dead, but I dumped the gyro signal into the SR785 as I was monkeying in the parameter space, and I was able to get the gyro noise at and slightly below 10 Hz to be on par with or ~ a factor of 2 or 3 better than it was before. This is taking into account that the previous calibration was off by a factor of 2*pi (lambdaP/4A takes optical Hz to rad/s, not RPS), so the noise can be made roughly 10-20 times lower than it used to be.

That said, it bothers me that we have no way of knowing at present if we are increasing our SNR or just reducing both noise AND signal whenever we make a change to a setting. I could have "made the noise much lower" by simply reducing the gain in the CW path, but this is not what would really be happening.

My issues with the PLL and settings-tweaking, along with Pinkesh's defense, precluded me from taking the transfer functions I wanted to take. These are the first step in characterizing our loops and ultimately in improving our SNR. They must be done before anything else.

Quote:

 I put the gyro back into the normal configuration today. It is now locking in both directions again. The bandwidth seems slightly improved, as I didn't have to be quite as careful when working on the table to keep it from dropping, but it is far from good, and the 200kHz+ oscillation still shows up with enough gain. I had set up the PLL but was having problems locking it when I had to leave.

A couple changes:

  • I kept the high-speed PDA10A that I used for the linear cavity in place as the CCW REFL PD, instead of the old PDA36A. We eventually want to have the same two PDs for both REFLs, but this doesn't really matter at the moment, and we might as well maximize our optical gain in the main locking loop while using the design modulation frequency of 33 MHz. The CW loop is still a 17-MHz diode, but this loop seems to like the lowest gain setting anyway, and we may end up wanting to reduce lower gain limit of the CW PDH box.
  • The BS1 in the TRANS readout was a 45P, but we are using S, so I changed it to a 45S.

I took some time to label nearly all of the cables we work with at the controls interface. The REFL PD signals, the CW & CCW error signals, the PZT and AOM VCO control signals, the TRANS DC signal, the SWEEP drive from the function generator, and two cables going to dedicated DAQ channels have all been labeled. This way we don't have to tug on cables or follow them across the table to figure out what is what. We should be prudent that we don't change them around without relabeling them appropriately

2010-08-25_13.19.11.jpg2010-08-25_13.20.31.jpg

Tomorrow morning I'm going to figure out what's wrong with the PLL, then lock it and take a spectrum to see if things have gotten better with the new PD, new modulation frequency, and fresh realignment. Then I plan to take a bunch of transfer functions to try and diagnose our loop problem. Specifically:

  1. The closed-loop TF of each direction
  2. The OLTF from the SWEEP input of each PDH box to its output

(2) is necessary to obtain the OLTF of the loops from (1), as we will be using the SWEEP input for the excitation, and the TF from SWEEP to OUT is not the same as that from IN to OUT.

 

  996   Fri Aug 27 11:20:54 2010 ZachComputingDAQfb1 down?

Still having issues, but now more stuff is not working. Yesterday evening before I left, I noticed that I could load realtime data in DV, but not trended playback (didn't try raw). Still the same issue from here in FL: I get "NO DATA FOUND". I have verified that my channels are active and acquired.

As far as mDV is concerned, I don't get an error anymore when trying to get C2 data with get_data, but instead it just freezes at "C...". Now ligoDV doesn't work, either; it just spits out errors.

I want to try DTT, but without any time series data I don't know of a good time to try taking a spectrum. Is anything working for anyone?

Quote:

Seems to be working now for me. Maybe Zach can tell us when he gets to Fla if his issues are resolved post reboot.

 

  995   Thu Aug 26 21:59:32 2010 DmassComputingDAQfb1 down?

Seems to be working now for me. Maybe Zach can tell us when he gets to Fla if his issues are resolved post reboot.

  994   Thu Aug 26 19:52:15 2010 FrankComputingDAQfb1 down?

Quote:

It was (unintentionally?) rebooted when Koji and I were working down here a couple months ago. mDV update incoming

 i used mDV to get temp data about an hour ago and it was working...

  993   Thu Aug 26 19:45:52 2010 DmassComputingDAQfb1 down?

It was (unintentionally?) rebooted when Koji and I were working down here a couple months ago. mDV update incoming

  992   Thu Aug 26 17:09:08 2010 AlastairThings to BuyGYROPossible Vacuum system for the GYRO

Quote:

We're not looking for super high-vacuum though are we?  Maybe we can get away with borrowing the small turbo pumping station from the suspensions lab to pump it down and then we can just valve it off.

Also, we have the cylinder head for a tank of helium now so we should order in a tank to try that (the tanks get delivered really fast so that shouldn't be a problem).  Of course we'll at least need windows before doing that.

I've asked Gina to check on the CVI W2 window order.  The order went in on 22nd July and CVI said that they had them in stock.

 I think that's right - we won't need any better than 1 mTorr. As long as there is no huge leak, we should be fine. It would be handy to have a (EPICS trendable) gauge on the system so that we can know if its leaking.

The system's total volume will be ~20 liters. So we need the leak rate to be below ~1e-6 Torr-liters / hour. A suggestion from Mike Z is to use the usual flexi-hosing from Norcal instead of the rigid nipple type of tube

I was talking about before. flexi hose link ..... I think we can use the 2" ID, 24" long tubes and make up for the difference in the length in the corner chambers. The length of each side of the gyro should be 29.5" with a 100 MHz FSR.

  991   Thu Aug 26 17:00:12 2010 FrankComputingDAQfb1 down?

Quote:

Quote:

can someone plz check or reboot fb1. It doesn't respond anymore but the router is working fine as i can log into it...

if it doesn't come up plz check the main monitor on top of the blck rack what it says...

fb1 appears to have crashed or been restarted. ws1 and ws2 are nonresponsive (as a result?).

fb1 wants to check sdb1, I will let it do so (check forced blah blah).

If I understand correctly, ws1 and 2 drop when fb1 drops because fb1 hosts the /cvs/cds filesystem. I don't understand why this makes them die.

Thanks for taking care David.

It shouldn't make them die as only the tools we use are located on fb1, nothing else. So i don't know. But they should cpme back as soon fb1 is back too.

I can't remember but the last time we rebooted fb1 was last year or so i think. I know it's not a windows computer but maybe it needs to be rebooted once a year

Do you still have problems using mDV?

  990   Thu Aug 26 16:42:01 2010 DmassComputingDAQfb1 down?

Quote:

can someone plz check or reboot fb1. It doesn't respond anymore but the router is working fine as i can log into it...

if it doesn't come up plz check the main monitor on top of the blck rack what it says...

fb1 appears to have crashed or been restarted. ws1 and ws2 are nonresponsive (as a result?).

fb1 wants to check sdb1, I will let it do so (check forced blah blah).

If I understand correctly, ws1 and 2 drop when fb1 drops because fb1 hosts the /cvs/cds filesystem. I don't understand why this makes them die.

ELOG V3.1.3-