40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 10 of 335  Not logged in ELOG logo
ID Date Author Type Category Subjectdown
  13311   Tue Sep 12 11:44:16 2017 KiraUpdatePEMtemp sensor update

Got it to work. A cable was broken and the AD586 also broke at the same time so it took a while to find the problem. I had to create a makeshift cable out of three parts so once I replace it for an actual cable, it will be good to go for a test.

Quote:

Today, I stuck on the sensors to a metal block using a flag, rubber bands, and some thermal paste (1st attachment). I then wrapped the whole thing in about 4 layers of insulation and a lot of tape (2nd attachment). The only things leading out of the box were the three connections to the sensors and a thermometer. I then connected the wires to their respective places on the board of the sensor. To get the readings out we would need to use an ADC. Gautam and I checked to make sure the ADC we have inside the lab goes from -10V to 10V so that it would be able to measure the 3V value the sensor typically measures. We then tried to connect all three sensors to a DC source simultaneously, but unfortunately one of them seems to have disconnected somewhere during the process, as it only showed 1.2V instead of 3V. I plan to fix this tomorrow morning so that we can hopefully set this up soon.

Quote:

I took off the AD590 and attached it to two long wires leading out from the board. This will allow us to attach the sensor to a metal block and not have to stick the whole board to it. I have also completed three identical copies of this and it's pretty much ready to be tested. According to Craig and Andrew's elog here, the sensor is very noisy and they added in a low pass filter to fix that, so that's something to consider for the final version of the circuit. I'll test what I have so far and see how that goes. We still need to figure out how to get readings from the sensors.

To attach the sensor to the metal block, I'll use some thermal paste and fasteners. I'll also put a thermometer on the block to record the actual temperature. I'll then wrap it in some insulation we have in the lab and have only some wires leading out of it to make measurements. I'll leave this setup overnight and record the outputs for about a full day. The fluctuations between the sensors will then indicate the noise of each individual sensor.

 

 

  13209   Tue Aug 15 11:50:21 2017 KiraSummaryPEMtemp sensor packaging/mount

For the final packaging/mounting of the sensor to the seismometer, I have thought of two options.

1. Attach circuit to a PCB board and place it inside the can, while leaving the AD590 open to the air inside the can.

  • This makes sure that the sensor gets a direct measurement of the temperature of the air in the can, as it is exposed to the air. 
  • But, it takes a limited area of measurement, so it could be the case that the area we place it in happens to be a hot or cold pocket, and the measurement would be inaccurate.
  • This can be solved by placing multiple copies of the circuit in various places of the can and averaging the values.

2. Attach the AD590 to a copper plate with thermal paste and put it into a pomona box.

  • This solves the problem of having a limited sample area the first option had, as the copper plate should have a uniform temp distribution, thus we are sampling the temp of that whole area.
  • Need to make sure that the response time to the temperature variations of copper is less than the frequency that we are measuring.
  • This can be calculated using equations for heat transfer (listed below).

If anyone has input on which method is preferred or any additional options that we may have, I would appreciate it.

Heat transfer:

q = k A dT / s

  • k = thermal conductivity
  • A = area
  • dT = temperature gradient
  • s = thickness

For copper, k = 401 W/mK, x = 1.27 mm, A = 2.66x10^-3 m^2 (for the particular copper plate I measured), dT = 1K (assume). Thus the heat transfer will be 839 J/s.

I'm not completely sure what to do with this yet, but it could help us decide whether the copper plate option will be useful for us.

 

  13651   Thu Feb 22 16:16:43 2018 KiraUpdatePEMtemp sensor input

Rewired the temperature sensor inputs to Molex connectors so that we can now attach them to the +/- 15V Sorensens for input instead of using a power supply.

Attachment 1: IMG_20180222_160602.jpg
IMG_20180222_160602.jpg
  13656   Mon Feb 26 16:22:10 2018 KiraUpdatePEMtemp sensor input

[Kira, Gautam]

We began the setup for the lab temperature sensor today. First, we needed to add in a DIN fuse for both temperature sensors, which required us to shut down everything else first. To avoid having to do that next time, we made three instead of two spaces where we have + and - 15V. Attachment 1 shows the new fuses we installed, along with the fuses they connect to. Attachment 2 shows the wiring that we used to connect all the fuses. Attachment 3 shows the labeled long wires that are attached to the lab temperature sensor. The other end is labeled as well. I measured the voltage at the other end of the long cables, and while the -15V one looks good, the +15V one shows only about 13.5V. 

-----

edit (Tuesday) - I set up the other set of cables that will eventually lead to the sensor in the can, but neither of them are showing any voltage on the other end. I'll work on this issue tomorrow.


gautam: some additional remarks about the procedure followed:

  • Wires were tinned with solder to facilitate easier insertion into DIN fuse blocks.
  • ETMX watchdog was shutdown. I then unplugged the satellite box at the X end to avoid any sort of electrical impulse being sent to the optic.
  • Shut down all the sorensens in the EX rack.
  • Tapped new +15VDC and -15 VDC outputs at the EX rack in the locations Kira indicated.
  • Turned Sorensens back on. Checked that all voltages as reported by front panel monitor points were as they were expected to be.
  • Had some trouble getting the modbus IOC going after this work. Kept throwing an error that modbus couldn't be initialized by procserv. Ended up having to reboot c1auxex2, after which it worked fine.
Attachment 1: 1.jpg
1.jpg
Attachment 2: IMG_20180226_154649.jpg
IMG_20180226_154649.jpg
Attachment 3: IMG_20180226_154720.jpg
IMG_20180226_154720.jpg
  13660   Wed Feb 28 12:31:28 2018 KiraUpdatePEMtemp sensor input

I switched out the DIN fuses for the long cables and it fixed the issue of them not showing any votage on the other end. At first, the +15V cable worked and the -15V didn't, but when I switched the fuse for the -15V it began working, but the +15V stopped working. I then switched out the fuse for +15V and both cables began showing voltage. But for both the long cables and the shorter ones, they show +13.4V instead of +15V. Not sure what's going on there.

  7244   Tue Aug 21 15:26:04 2012 SteveUpdatePEMtemp sensor for vacuum

Temperature sensor for vacuum. How many : 2 or 3 ?  $350 each

Glass encapsulated thermistor #55007  with Ceramabond 835-m glued onto spade connector and hooked up to controller DP25-TH-A with analoge output.

This zero to 10Vdc can go to ADC

  13214   Wed Aug 16 16:05:53 2017 KiraUpdatePEMtemp sensor PCB

Tried taking the circuit from the breadboard to the PCB. I attached all the components to adapters that would allow them to be connected to the PCB. From the first picture, the first component is AD586, the second is AD590, and the third is LT1012, along with a resistor across it. I then soldered the connections between the components, as can be seen in the second picture. When I tested out this version of the circuit by hooking it up to the DC source, I got a reading of ~-15V. I will have to check all the connections to make sure there is contact where there should be one, and no contact where there shouldn't be. I had issues attaching the tiny AD590 and LT1012 to its adaptor, so the issue may lie there as well. I'll also check that each component is in working order as well.

Once I figure out where my error is, my plan is to build two more of these and place a metal object such that it contacts only the surface of the AD590s. This would allow me to compare the three values to the actual temperature of the metal, which would then tell me how accurate this setup is.

Note on the resistor: I measured all the resistors and chose three that had exactly 10.00k Ohm. The voltage detected is dependent on the resistor, so if we are to take three identical copies, I ensured that there would be no error due to the resistors being a little different.

Attachment 1: IMG_20170816_154514.jpg
IMG_20170816_154514.jpg
Attachment 2: IMG_20170816_154541.jpg
IMG_20170816_154541.jpg
  13224   Thu Aug 17 10:41:58 2017 KiraUpdatePEMtemp sensor PCB

Got it to work. One of the connections was faulty. I decided to check the temperature measured against a thermometer. The sensor showed 26.1 C, but the thermometer showed 25.8 C after I let them both cool down after heating them up. The temperature of the thermometer was dropping at the time of measurement, but the temperature of the sensor was not. This is still a rough version of the final sensor, so I'm not sure what exactly causes this discrepancy.

Quote:

Tried taking the circuit from the breadboard to the PCB. I attached all the components to adapters that would allow them to be connected to the PCB. From the first picture, the first component is AD586, the second is AD590, and the third is LT1012, along with a resistor across it. I then soldered the connections between the components, as can be seen in the second picture. When I tested out this version of the circuit by hooking it up to the DC source, I got a reading of ~-15V. I will have to check all the connections to make sure there is contact where there should be one, and no contact where there shouldn't be. I had issues attaching the tiny AD590 and LT1012 to its adaptor, so the issue may lie there as well. I'll also check that each component is in working order as well.

Once I figure out where my error is, my plan is to build two more of these and place a metal object such that it contacts only the surface of the AD590s. This would allow me to compare the three values to the actual temperature of the metal, which would then tell me how accurate this setup is.

Note on the resistor: I measured all the resistors and chose three that had exactly 10.00k Ohm. The voltage detected is dependent on the resistor, so if we are to take three identical copies, I ensured that there would be no error due to the resistors being a little different.

 

Attachment 1: IMG_20170817_095917.jpg
IMG_20170817_095917.jpg
  13232   Mon Aug 21 13:07:08 2017 KiraUpdatePEMtemp sensor PCB

On Friday, I cleaned up the circuit so that there are only three connections needed (+15V, -15V, GND) and a BNC connector for reading the output. Today, I added in bypass capacitors. The small yellow ones are 0.1 microF ceramic, and the large ones are 100 microF electrolytic. They are used to stabilize the +15V and -15V inputs to the OP amp and minimize fluctuations, since it doesn't have a regulator for stability. I have also attached the circuit diagram for the OP amp only, where 1 are the electrolytic and 2 are the ceramic. The temperature is still about 2 degrees off, but if that difference is constant for all temperatures in our range we can just calibrate it later.

Here is a helpful link on bypass capacitors (thanks to Kevin for sending it to me).

As a note, the electrolytic capacitors do have a polarity, so it is important to place them correctly (the negative side is towards the lower voltage potential, and not always towards ground).

Quote:

Got it to work. One of the connections was faulty. I decided to check the temperature measured against a thermometer. The sensor showed 26.1 C, but the thermometer showed 25.8 C after I let them both cool down after heating them up. The temperature of the thermometer was dropping at the time of measurement, but the temperature of the sensor was not. This is still a rough version of the final sensor, so I'm not sure what exactly causes this discrepancy.

Quote:

Tried taking the circuit from the breadboard to the PCB. I attached all the components to adapters that would allow them to be connected to the PCB. From the first picture, the first component is AD586, the second is AD590, and the third is LT1012, along with a resistor across it. I then soldered the connections between the components, as can be seen in the second picture. When I tested out this version of the circuit by hooking it up to the DC source, I got a reading of ~-15V. I will have to check all the connections to make sure there is contact where there should be one, and no contact where there shouldn't be. I had issues attaching the tiny AD590 and LT1012 to its adaptor, so the issue may lie there as well. I'll also check that each component is in working order as well.

Once I figure out where my error is, my plan is to build two more of these and place a metal object such that it contacts only the surface of the AD590s. This would allow me to compare the three values to the actual temperature of the metal, which would then tell me how accurate this setup is.

Note on the resistor: I measured all the resistors and chose three that had exactly 10.00k Ohm. The voltage detected is dependent on the resistor, so if we are to take three identical copies, I ensured that there would be no error due to the resistors being a little different.

 

 

Attachment 1: IMG_20170821_124121.jpg
IMG_20170821_124121.jpg
Attachment 2: IMG_20170821_124429~2.jpg
IMG_20170821_124429~2.jpg
Attachment 3: IMG_20170821_124108.jpg
IMG_20170821_124108.jpg
  1769   Tue Jul 21 17:01:18 2009 peteDAQDAQtemp channel PEM-PETER_FE

I added a temporary channel, to input 9 on the PEM ADCU.    Beware the 30, 31, and 32 inputs.  I tried 32 and it only gave noise.

 

 

  73   Tue Nov 6 23:45:38 2007 tobinConfigurationComputerstektronix scripts!
I cooked up a little script to fetch the data from the networked Tektronix scope. Example usage:

linux2:scripts>tektronix/tek-dump scope0 ch1 foo.csv

"scope0" is the hostname of the scope, "ch1" is the channel you want to dump, and "foo.csv" is the file you want to dump it to. The script is written in Python since Python's libhttp gave me less trouble than Perl's HTTP::Lite.
  1699   Wed Jun 24 14:43:19 2009 robUpdateComputerstdsresp on linux => pzresp

 

tdsresp is broken on our linux control room machines.  I made a little perl replacement which uses the DiagTools.pm perl module, called pzresp.  It's in the $SCRIPTS/general directory, and so in the path of all the machines.  I also edited the cshrc.40m file so that on linux machines tdsresp points to this perl replacement.

I've patched DiagTools.pm to circumnavigate the tdsdmd bug described here.  I also added a function to DiagTools.pm called diagRespNoLog, which is just like diagResp but without that pesky log file.

 


Here's the output from the tdsresp binary on CentOS:
allegra:~>tdsresp 941.54 10000 100 10 C1:LSC-ITMX_EXC C1:LSC-PD1_Q C1:LSC-PD1_I
nan nan nan nan nan nan nan
nan nan nan nan nan nan nan
nan nan nan nan nan nan nan
*** glibc detected *** tdsresp: free(): invalid next size (fast): 0x089483e8 ***
======= Backtrace: =========
/lib/libc.so.6[0xa800f1]
/lib/libc.so.6(cfree+0x90)[0xa83bc0]
/usr/lib/libstdc++.so.6(_ZdlPv+0x21)[0xf7f36571]
tdsresp[0x8057fbb]
tdsresp[0x805b394]
/lib/libc.so.6(__libc_start_main+0xdc)[0xa2ce8c]
tdsresp(__gxx_personality_v0+0x169)[0x804ddd1]
======= Memory map: ========
00242000-00249000 r-xp 00000000 fd:00 15400987                           /lib/librt-2.5.so
00249000-0024a000 r--p 00006000 fd:00 15400987                           /lib/librt-2.5.so
0024a000-0024b000 rw-p 00007000 fd:00 15400987                           /lib/librt-2.5.so
009f9000-00a13000 r-xp 00000000 fd:00 15400963                           /lib/ld-2.5.so
00a13000-00a14000 r--p 00019000 fd:00 15400963                           /lib/ld-2.5.so
00a14000-00a15000 rw-p 0001a000 fd:00 15400963                           /lib/ld-2.5.so
00a17000-00b55000 r-xp 00000000 fd:00 15400974                           /lib/libc-2.5.so
00b55000-00b57000 r--p 0013e000 fd:00 15400974                           /lib/libc-2.5.so
00b57000-00b58000 rw-p 00140000 fd:00 15400974                           /lib/libc-2.5.so
00b58000-00b5b000 rw-p 00b58000 00:00 0 
00b5d000-00b70000 r-xp 00000000 fd:00 15400984                           /lib/libpthread-2.5.so
00b70000-00b71000 r--p 00012000 fd:00 15400984                           /lib/libpthread-2.5.so
00b71000-00b72000 rw-p 00013000 fd:00 15400984                           /lib/libpthread-2.5.so
00b72000-00b74000 rw-p 00b72000 00:00 0 
00b76000-00b78000 r-xp 00000000 fd:00 15400981                           /lib/libdl-2.5.so
00b78000-00b79000 r--p 00001000 fd:00 15400981                           /lib/libdl-2.5.so
00b79000-00b7a000 rw-p 00002000 fd:00 15400981                           /lib/libdl-2.5.so
00b7c000-00ba1000 r-xp 00000000 fd:00 15400975                           /lib/libm-2.5.so
00ba1000-00ba2000 r--p 00024000 fd:00 15400975                           /lib/libm-2.5.so
00ba2000-00ba3000 rw-p 00025000 fd:00 15400975                           /lib/libm-2.5.so
00bca000-00bdd000 r-xp 00000000 fd:00 15401011                           /lib/libnsl-2.5.so
00bdd000-00bde000 r--p 00012000 fd:00 15401011                           /lib/libnsl-2.5.so
00bde000-00bdf000 rw-p 00013000 fd:00 15401011                           /lib/libnsl-2.5.so
00bdf000-00be1000 rw-p 00bdf000 00:00 0 
00dca000-00dd5000 r-xp 00000000 fd:00 15400986                           /lib/libgcc_s-4.1.2-20080825.so.1
00dd5000-00dd6000 rw-p 0000a000 fd:00 15400986                           /lib/libgcc_s-4.1.2-20080825.so.1
08048000-080b7000 r-xp 00000000 00:17 6455328                            /cvs/cds/caltech/apps/linux/tds/bin/tdsresp
080b7000-080ba000 rw-p 0006e000 00:17 6455328                            /cvs/cds/caltech/apps/linux/tds/bin/tdsresp
080ba000-080bb000 rw-p 080ba000 00:00 0 
0893d000-0896b000 rw-p 0893d000 00:00 0                                  [heap]
f5e73000-f5e74000 ---p f5e73000 00:00 0 
f5e74000-f6874000 rw-p f5e74000 00:00 0 
f692d000-f6931000 r-xp 00000000 fd:00 15400995                           /lib/libnss_dns-2.5.so
f6931000-f6932000 r--p 00003000 fd:00 15400995                           /lib/libnss_dns-2.5.so
f6932000-f6933000 rw-p 00004000 fd:00 15400995                           /lib/libnss_dns-2.5.so
f6956000-f6a12000 rw-p f6a31000 00:00 0 
f6a74000-f6a7d000 r-xp 00000000 fd:00 15400997                           /lib/libnss_files-2.5.so
f6a7d000-f6a7e000 r--p 00008000 fd:00 15400997                           /lib/libnss_files-2.5.so
f6a7e000-f6a7f000 rw-p 00009000 fd:00 15400997                           /lib/libnss_files-2.5.so
f6a7f000-f6a80000 ---p f6a7f000 00:00 0 
f6a80000-f7480000 rw-p f6a80000 00:00 0 
f7480000-f7481000 ---p f7480000 00:00 0 
f7481000-f7e83000 rw-p f7481000 00:00 0 
f7e83000-f7f63000 r-xp 00000000 fd:00 6236924                            /usr/lib/libstdc++.so.6.0.8
f7f63000-f7f67000 r--p 000df000 fd:00 6236924                            /usr/libAbort

 
  1702   Thu Jun 25 17:27:42 2009 ranaUpdateComputerstdsresp on linux
I downloaded the tdsresp.pl from LLO and put it into the various TDS/bin paths. Also updated the LLO specific path stuff. It runs.
  180   Fri Dec 7 14:14:48 2007 robMetaphysicsComputer Scripts / Programstdsread problems on Solaris

tdsread has developed a strange new illness, whereby it cannot read EPICS values from two subsystems at once (e.g., getting an LSC and SUS value simultaneously). I thought this might have something to with the fact that both losepics and iscepics are running on the same box,
but the same thing happens with IOO EPICS records, so that's not the culprit.

This is new behaviour, and it's only happening on the solaris machines. I suspect some ENV/cshrc juju has caused it, as the tdsread executable is the same one from April, and I don't think our EPICS infrastructure has changed otherwise. In the near term we can either try running the scripts on linux, or modify the IFO scripts to not do these types of calls.
  430   Sun Apr 20 20:29:46 2008 ranaUpdateComputer Scripts / Programstdsread bugs
There seems to be a problem with reading the C1:IOO-MASTER_OVERFLOW field
when it is read in as part of an array. The only way for me to describe it
is to just attach the terminal output in this entry...this is mainly for
Matt and Rob
.


I first noticed that the output of the MC-WFS sensing matrix was different than
the outputs from a year ago, namely that the excitation channel was not being
processed and outputted to the file. This made the output matrix diagonalization
scripts fail.

I noticed that there are several different copies of tdsread.cc sitting around.
Looks like they have been hacked in the last year but I am not sure if this
excitation channel readback is an intentional change; email has been sent to the
authors to find out -- they will probably post some kind of response in the log
to resolve what's up.


My guess is that the problem with the IOO channel is not related, but I'm not sure:
op440m:WFS>set ioo_head = "${ifo}:IOO-"
op440m:WFS>set sus_head = "${ifo}:SUS-"
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW ${sus_head}MC3
_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW ${ioo_head}MAS
TER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
op440m:WFS>set oflows = `tdsread ${ioo_head}MASTER_OVERFLOW`
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
op440m:WFS>echo $oflows
0
op440m:WFS>set oflows = `tdsread ${ioo_head}MASTER_OVERFLOW`
op440m:WFS>echo $oflows
0
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW ${sus_head}MC3_MASTER_OVERFLOW`
op440m:WFS>echo $oflows
0 0 0
op440m:WFS>echo `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
0
op440m:WFS>echo "tdsread ${sus_head}MC1_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW"
tdsread C1:SUS-MC1_MASTER_OVERFLOW C1:IOO-MASTER_OVERFLOW C1:SUS-MC2_MASTER_OVERFLOW
op440m:WFS>
  433   Mon Apr 21 13:12:21 2008 robUpdateComputer Scripts / Programstdsread bugs

Quote:
There seems to be a problem with reading the C1:IOO-MASTER_OVERFLOW field
when it is read in as part of an array. The only way for me to describe it
is to just attach the terminal output in this entry...this is mainly for
Matt and Rob
.


I first noticed that the output of the MC-WFS sensing matrix was different than
the outputs from a year ago, namely that the excitation channel was not being
processed and outputted to the file. This made the output matrix diagonalization
scripts fail.

I noticed that there are several different copies of tdsread.cc sitting around.
Looks like they have been hacked in the last year but I am not sure if this
excitation channel readback is an intentional change; email has been sent to the
authors to find out -- they will probably post some kind of response in the log
to resolve what's up.


My guess is that the problem with the IOO channel is not related, but I'm not sure:
op440m:WFS>set ioo_head = "${ifo}:IOO-"
op440m:WFS>set sus_head = "${ifo}:SUS-"
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW ${sus_head}MC3
_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW ${ioo_head}MAS
TER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
op440m:WFS>set oflows = `tdsread ${ioo_head}MASTER_OVERFLOW`
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
op440m:WFS>echo $oflows
0
op440m:WFS>set oflows = `tdsread ${ioo_head}MASTER_OVERFLOW`
op440m:WFS>echo $oflows
0
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW ${sus_head}MC3_MASTER_OVERFLOW`
op440m:WFS>echo $oflows
0 0 0
op440m:WFS>echo `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
0
op440m:WFS>echo "tdsread ${sus_head}MC1_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW"
tdsread C1:SUS-MC1_MASTER_OVERFLOW C1:IOO-MASTER_OVERFLOW C1:SUS-MC2_MASTER_OVERFLOW
op440m:WFS>



This is the same bug described in entry 180. I believe it has nothing to do with tdsread, which did not change in the time period before the bug appeared, but perhaps has something to do with other EPICS libraries somewhere (tdsread relies on these epics libraries to do its dirty work). Here is entry 180 for reference:


Quote:
tdsread has developed a strange new illness, whereby it cannot read EPICS values from two subsystems at once (e.g., getting an LSC and SUS value simultaneously). I thought this might have something to with the fact that both losepics and iscepics are running on the same box,
but the same thing happens with IOO EPICS records, so that's not the culprit.

This is new behaviour, and it's only happening on the solaris machines. I suspect some ENV/cshrc juju has caused it, as the tdsread executable is the same one from April, and I don't think our EPICS infrastructure has changed otherwise. In the near term we can either try running the scripts on linux, or modify the IFO scripts to not do these types of calls.


The solution that's been in effect for the past few months has just been to modify the scripts to not make these kinds of calls.
  1328   Fri Feb 20 01:54:18 2009 KakeruUpdateComputer Scripts / Programstdsdata might have a bug

I found a strange jump of value in my data taken with tdsdata.
I couldn't find same jump in a playback of DataViewer, so I think this is a problem of tdsdata.
Be careful when you use tdsdata!

The attached file is an example of jumped data.
I try to get data with allegra and op440m, and both has same kind of jump.
(A downsampling or interpolation may be wrong.)

Rana said there is a fixed version of tdsdata in some PC, but 64bit linux may not have.
I try it tomorrow.

Attachment 1: jumped_data.png
jumped_data.png
  1362   Thu Mar 5 23:18:38 2009 KakeruConfigurationComputerstdsdata doesn't work
I found that tdsdata doesn't work.

When I star tdsdata, he takes a few ~ 10 seconds of data, and he dies with a message "Segmentation fault".
I tried to get data for some times and some channels, and this problem was observed everytime.
I also tried tdsdata on allegra, op440m and mafalda, and it didn't work on all of them.

Yesterday, I got a new version of tdsdata (which modified the problem of Message ID: 1328) and tried to build 
thme on my directory (/cvs/cds/caltech/users/kakeru.....)
This may have some relation to this problem.
  1371   Sun Mar 8 23:14:52 2009 ranaUpdateComputer Scripts / Programstdsdata doesn't work

Matt logged in and rebuilt the TDS stuff for us on Mafalda in /cvs/cds/caltech/apps/linux/tds_090304.

He says that he can't build his stuff on 64-bit because there's not a sanctioned 64-bit build of GDS yet.

This should have all the latest fixes in it. I tried using both the old and new code from allegra and they both are fine:

./tdsdata 16384 2 C1:IOO-MC_F > /users/rana/test.txt

I loaded the data I got with the above command and there were no data dropouts. Possibly the dropout problem is only

associated with testpoints and so we have to wait for the TP fix.

  1375   Mon Mar 9 14:57:30 2009 KakeruUpdateComputer Scripts / Programstdsdata doesn't work

I tested new tdsdata and found it was working well.

I excited C1:SUS-ITMY_SUSPIT_EXC with tdssine, and get data from C1:LSC-TRY_OUT (testpoint) and C1:SUS- ITMY_OPLEV_PERROR (recorded point) with new and old tdsdata.

With old tdsdata (/cvs/cds/caltech/apps/linux/tds/bin/tdsdata), I found some jumps of datapoint, which is a same problem with before (Attachment 1).

With new tdsdata (/cvs/cds/caltech/apps/linux/tds_090304/bin/tdsdata), there looks to be no jumps (Attachment 2; taken about 10 minutes after Attachment 1).

The problem of old tdsdata looks to be remaining even for recordedpoints.

You should use /cvs/cds/caltech/apps/linux/tds_090304/bin/tdsdata.

Quote:

Matt logged in and rebuilt the TDS stuff for us on Mafalda in /cvs/cds/caltech/apps/linux/tds_090304.

He says that he can't build his stuff on 64-bit because there's not a sanctioned 64-bit build of GDS yet.

This should have all the latest fixes in it. I tried using both the old and new code from allegra and they both are fine:

./tdsdata 16384 2 C1:IOO-MC_F > /users/rana/test.txt

I loaded the data I got with the above command and there were no data dropouts. Possibly the dropout problem is only

associated with testpoints and so we have to wait for the TP fix.

 

Attachment 1: oldtds.png
oldtds.png
Attachment 2: newtds.png
newtds.png
  1376   Mon Mar 9 16:54:52 2009 Kakeru, RanaUpdateComputer Scripts / Programstdsdata doesn't work

We confirmed that new tds(/cvs/cds/caltech/apps/linux/tds_090304/) works well on linux 64, and replaced it to /cvs/cds/caltech/apps/linux/tds/

The old /cvs/cds/caltech/apps/linux/tds is put in /cvs/cds/caltech/apps/linux/tds.bak

  1380   Mon Mar 9 23:13:22 2009 YoichiUpdateComputer Scripts / Programstdsdata doesn't work

Quote:

We confirmed that new tds(/cvs/cds/caltech/apps/linux/tds_090304/) works well on linux 64, and replaced it to /cvs/cds/caltech/apps/linux/tds/

The old /cvs/cds/caltech/apps/linux/tds is put in /cvs/cds/caltech/apps/linux/tds.bak

 The tdscntr.pl in the new tds was probably the one from LLO, which is actually the version I sent to Tobin. It had paths and channel names defined for the LLO. So I copied back my original 40m version.

  1178   Fri Dec 5 01:58:58 2008 YoichiConfigurationASCtdscntr.pl now works at 40m
Tobin gave me the perl version of tdscntr some time ago.
Pinkesh and I modified and tested it at LHO.
I further modified it today and now it runs fine on the linux machines at the 40m. I haven't tested it with the Solaris machines.
My modifications include changing channel names to 40m ones, and using tdsavg to get QPD data rather than ezcaread.
The use of tdsavg is intended to avoid aliasing problem.
tdscntr.pl is installed in /cvs/cds/caltech/apps/linux/tds/bin

Now, the alignX runs on linux up to the centering of the QPDs.
However, ezcademod seems to behave wrongly on linux. I plan to investigate on this problem tomorrow.
I may try tdsdmd instead.
  6319   Fri Feb 24 23:14:09 2012 kiwamuUpdateCDStdsavg went crazy

I found that the LSCoffset script didn't work today. The script is supposed to null the electrical offsets in all the LSC channels.

I went through the sentences in the script and eventually found that the tdsavg command returns 0 every time.

I thought this was related to the test points, so I ran the following commands to flush all the test point running and the issue was solved.

[term]> diag              
[diag]>open               
[diag]> diag  tp clear *  
 

EDIT, JCD 11June2012:  3rd line there should just be [diag]> tp clear *

  6795   Mon Jun 11 22:51:11 2012 JenneUpdateComputerstdsavg not working

tdsavg isn't working:

controls@rossa:/opt/rtcds/caltech/c1/scripts/LSC 6$ tdsavg 10 C1:LSC-ASDC_IN1
ERROR: LDAQ - Unable to find NDS host "fb0"
ERROR: LDAQ - Unable to find NDS host "fb1"
ERROR: LDAQ - Unable to open socket to NDS.

 

When this command is executed inside a script, it doesn't return anything.  eg:

set offset = `tdsavg 10 C1:LSC_ASDC_IN1`
echo $offset

returns a blank line. 

Past elog research said lots of things about test points.  I didn't suspect that, since there aren't many test points occupied (according to the CDS status screens), but I cleared the test points anyway (elog 6319).  Didn't change anything, still broken.

LSCoffsets script, and any others depending on tdsavg will not work until this is fixed.

  6866   Mon Jun 25 11:23:14 2012 JenneUpdateComputerstdsavg not working

Quote:

LSCoffsets script, and any others depending on tdsavg will not work until this is fixed.

 LSCoffsets is working again. 

tdsavg (now, but didn't used to) needs "LIGONDSIP=fb" to be specified.  Jamie just put this in the global environment, so tdsavg should just work like normal again.

Also, the rest of the LSCoffsets script (really the subcommand offset2) was tsch syntax, so I created offset3 which is bash syntax.

Now we can use LSCoffsets again.

  1655   Fri Jun 5 02:59:03 2009 pete, albertoUpdateLockingtdsavg failure in cm_step script

the command

tdsavg 5 C1:LSC-PD4_DC_IN1

was causing grievous woe in the cm_step script.  It turned out to fail intermittently at the command line, as did other LSC channels.  (But non-LSC channels seem to be OK.)  So we power cycled c1lsc (we couldn't ssh).

Then we noticed that computers were out of sync again (several timing fields said 16383 in the C0DAQ_RFMNETWORK screen).  We restarted c1iscey, c1iscex, c1lsc, c1susvme1, and c1susvme2.  The timing fields went back to 0.  But the tdsavg command still  intermittently said "ERROR: LDAQ - SendRequest - bad NDS status: 13".

The channel C1:LSC-SRM_OUT16 seems to work with tdsavg every time.

Let us know if you know how to fix this. 

 

  1656   Fri Jun 5 13:51:49 2009 robUpdateLockingtdsavg failure in cm_step script

Quote:

the command

tdsavg 5 C1:LSC-PD4_DC_IN1

was causing grievous woe in the cm_step script.  It turned out to fail intermittently at the command line, as did other LSC channels.  (But non-LSC channels seem to be OK.)  So we power cycled c1lsc (we couldn't ssh).

Then we noticed that computers were out of sync again (several timing fields said 16383 in the C0DAQ_RFMNETWORK screen).  We restarted c1iscey, c1iscex, c1lsc, c1susvme1, and c1susvme2.  The timing fields went back to 0.  But the tdsavg command still  intermittently said "ERROR: LDAQ - SendRequest - bad NDS status: 13".

The channel C1:LSC-SRM_OUT16 seems to work with tdsavg every time.

Let us know if you know how to fix this. 

 

 Did you try restarting the framebuilder?

 

What you type is in bold:

op440m> telnet fb40m 8087

daqd> shutdown

 

  1657   Fri Jun 5 16:45:28 2009 rob, peteHowToComputerstdsavg failure in cm_step script

Quote:

Quote:

the command

tdsavg 5 C1:LSC-PD4_DC_IN1

was causing grievous woe in the cm_step script.  It turned out to fail intermittently at the command line, as did other LSC channels.  (But non-LSC channels seem to be OK.)  So we power cycled c1lsc (we couldn't ssh).

Then we noticed that computers were out of sync again (several timing fields said 16383 in the C0DAQ_RFMNETWORK screen).  We restarted c1iscey, c1iscex, c1lsc, c1susvme1, and c1susvme2.  The timing fields went back to 0.  But the tdsavg command still  intermittently said "ERROR: LDAQ - SendRequest - bad NDS status: 13".

The channel C1:LSC-SRM_OUT16 seems to work with tdsavg every time.

Let us know if you know how to fix this. 

 

 Did you try restarting the framebuilder?

 

What you type is in bold:

op440m> telnet fb40m 8087

daqd> shutdown

 

Restarting the framebuilder didn't work, but the problem now appears to be fixed.

Upon reflection, we also decided to try killing all open DTT and Dataviewer windows.  This also involved liberal use of ps -ef to seek out and destroy all diag's, dc3's, framer4's, etc.

 

That may have worked, but it happened simultaneously to killing the tpman process on fb40m, so we can't be sure which is the actual solution.

 

To restart the testpoint manager:

what you type is in bold:

rosalba> ssh fb40m

fb40m~> pkill tpman

The tpman is actually immortal, like Voldemort or the Kurgan or the Cylons in the new BG.  Truly slaying it requires special magic, so the pkill tpman command has the effect of restarting it.

 

In the future, we should make it a matter of policy to close DTTs and Dataviewers when we're done using them, and killing any unattended ones that we encounter.

 

  6803   Tue Jun 12 13:49:32 2012 JamieConfigurationComputer Scripts / Programstconvert

A nicer, better maintained version of tconvert is now supplied by the lalapps package.  It's called lalapps_tconvert.  I installed lalapps on all the workstations and aliased tconvert to point to lalapps_tconvert.

  7324   Thu Aug 30 20:35:09 2012 jamieUpdateSUStarget installed on PRM, temporary earthquake stops in place

We installed beam targets on PRM and BS suspension cages.

On both suspensions one of the screw holes for the target actually houses the set screw for the side OSEM.  This means that the screw on one side of the target only goes in partial way.

The target installed on BS is wrong!  It has a center hole, instead of two 45 deg holes.  I forgot to remove it, but it will obvious it's wrong to the next person who tries to use it.  I believe we're supposed to have a correct target for BS, Steve?

The earthquake stop screws on PRM were too short and were preventing installation of the PRM target.  Therefore, in order to install the target on PRM I had to replace the earthquake stops with ones Jenne and I found in the bake lab clean room that were longer, but have little springs instead of viton inserts at the ends.  This is ok for now, but

WE NEED TO REMEMBER TO REPLACE EARTHQUAKE STOPS ON PRM WHEN WE CLOSE UP.

We checked the beam through PRM and it's a little high to the right (as viewed from behind).  Tomorrow we're going to open ITMX chamber so that we can get a closer look at the spot on PR2.

  7325   Fri Aug 31 07:32:49 2012 SteveUpdateSUStarget for BS

Quote:

We installed beam targets on PRM and BS suspension cages.

On both suspensions one of the screw holes for the target actually houses the set screw for the side OSEM.  This means that the screw on one side of the target only goes in partial way.

The target installed on BS is wrong!  It has a center hole, instead of two 45 deg holes.  I forgot to remove it, but it will obvious it's wrong to the next person who tries to use it.  I believe we're supposed to have a correct target for BS, Steve?

The earthquake stop screws on PRM were too short and were preventing installation of the PRM target.  Therefore, in order to install the target on PRM I had to replace the earthquake stops with ones Jenne and I found in the bake lab clean room that were longer, but have little springs instead of viton inserts at the ends.  This is ok for now, but

WE NEED TO REMEMBER TO REPLACE EARTHQUAKE STOPS ON PRM WHEN WE CLOSE UP.

We checked the beam through PRM and it's a little high to the right (as viewed from behind).  Tomorrow we're going to open ITMX chamber so that we can get a closer look at the spot on PR2.

 The two eye  target for  the BS is in the clean tool box. It actually has irises.

  5691   Wed Oct 19 05:15:44 2011 kiwamuUpdateSUStaking care of SRM

I made some efforts to fix the situation of SRM but it is still bad.

The POS motion wasn't well damped. Something is wrong either (maybe both) sensing part or actuation part.

I am going to check the sensing matrix with the new free swinging spectra (#5690)

 

(Symptom)

 When I was trying to lock SRMI I found that the fringes observed at the AS camera didn't show spatial higher order modes, which is good.

So I thought the SRM suspension became quiet, but it actually wasn't. Because the RMS monitor of the SRM OSEMs already went to about 30 counts.

At the same time the opelev error signals were well suppressed. It means some DOFs which were insensitive to the oplev were ringing up, namely POS and SIDE.

According to the LSC error signal and the ASDC signal, I believe that the POS was going wild (although I didn't check the OSEM spectra).
 

(Some efforts)

 + Readjusted the f2a filters (see the attachment).

 + Tried to eliminate a coupling between the POS and SIDE drives by tweaking the output matrix.

    => In order to eliminate the coupling from the POS drive to SIDE sensor, I had to put a comparable factor into an element.

     So it might be possible that the POS sensor was showing the SIDE signal and vice versa.

      In order to check it I left SRM free swinging (#5690).

Quote from #5684

The main reason why I couldn't lock DRMI was that the suspensions were touchy and especially the SRM suspension wasn't good.

Attachment 1: f2pSRM.png
f2pSRM.png
  5699   Wed Oct 19 15:46:49 2011 kiwamuUpdateSUStaking care of SRM

Quote from #5691

I am going to check the sensing matrix with the new free swinging spectra (#5690)

 

The SRM input matrix has been readjusted.

However still there is the unwanted coupling from the POS drive to SIDE signal and from the SIDE drive to POS signal.

      BADNESS
  SRM  SRM.png       pit     yaw     pos     side    butt
UL    0.871   0.975   1.115  -0.295   1.096  
UR    1.015  -1.025   1.128  -0.140  -1.053  
LR   -0.985  -0.984   0.885  -0.088   0.831  
LL   -1.129   1.016   0.872  -0.243  -1.020  
SD    0.084   0.061   3.534   1.000  -0.018  
 
 4.24965

 

  2601   Fri Feb 12 18:58:46 2010 kiwamuUpdateGreen Lockingtake some optics away from the ETM end table

In the last two days Steve and I took some optics away from the both ETM end table.

This is because we need an enough space to set up the green locking stuff into the end table, and also need to know how much space is available.

Optics we took away are : Alberto's RF stuff, fiber stuff and some optics obviously not in used.

The picture taken after the removing is attached. Attachment1:ETMX, Attachment2:ETMY

And the pictures taken before the removing are on the wiki, so you can check how they are changed.

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

Attachment 1: DSC_1164.JPG
DSC_1164.JPG
Attachment 2: DSC_1172.JPG
DSC_1172.JPG
  2604   Tue Feb 16 09:51:22 2010 AlbertoUpdateGreen Lockingtake some optics away from the ETM end table

Quote:

In the last two days Steve and I took some optics away from the both ETM end table.

This is because we need an enough space to set up the green locking stuff into the end table, and also need to know how much space is available.

Optics we took away are : Alberto's RF stuff, fiber stuff and some optics obviously not in used.

The picture taken after the removing is attached. Attachment1:ETMX, Attachment2:ETMY

And the pictures taken before the removing are on the wiki, so you can check how they are changed.

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

The PD Kiwamu removed from the Y table was TRY, which we still need.

My bad if he took that. By mistake I told him that was the one I installed on the table for the length measurement and we didn't need it anymore.

I'm going to ask Kiwamu if he can kindly put it back.

  8285   Wed Mar 13 11:34:24 2013 SteveUpdateoptical tablestable covers moved to CES

The two acrylic optical table enclosures were moved from the carpenter shop to CES. I need to order windows. The latest quotes from Laseroptik  are posted at the wiki / aux_optics page.

Things to do: order windows, draw and order window flange, install surgical tubing seals, buy and line enclosures with IR shield films.

Attachment 1: acrylicEnclosure.jpg
acrylicEnclosure.jpg
  16287   Mon Aug 23 10:17:21 2021 PacoSummaryComputerssystem reboot glitch

[paco]

At 09:34 PST I noted a glitch in the controls room as the machines went down except for c1ioo. Briefly, the video feeds disappeared from the screens, though the screens themselves didn't lose power. At first I though this was some kind of power glitch, but upon checking with Jordan, it most likely was related to some system crash. Coming back to the controls room, I could see the MC reflection beam swinging, but unfortunately all the FE models came down. I noticed that the DAQ status channels were blank.

I ssh into c1ioo no problem and ran "rtcds stop c1ioo c1als c1omc", then "rtcds restart c1x03" to do a soft restart. This worked, but the DAQ status was still blank. I then tried to ssh into c1sus and c1lsc without success, similarly c1iscex and c1iscey were unreachable. I went and did a hard restart on c1iscex by switching it off, then its extension chassis, then unplugging the power cords, then inverting these steps, and could ssh into it from rossa. I ran "rtcds start c1x01" and saw the same blank DAQ status. I noticed the elog was also down... so nodus was also affected?

[paco, anchal]

Anchal got on zoom to offer some assistance. We discovered that the fb1 and nodus were subject to some kind of system reboot at precisely 09:34. The "systemctl --failed" command on fb1 displayed both the daqd_dc.service and rc-local.service as loaded but failed (inactive). Is it a good idea to try and reboot the fb1 machine? ... Anchal was able to bring elog back up from nodus (ergo, this post).

[paco]

Although it probably needs the DAQ service from the fb1 machine to be up and running, I tried running the scripts/cds/rebootC1LSC.sh script. This didn't work. I tried running sudo systemctl restart daqd_dc from the fb1 machine without success. Running systemctl reset-failed "worked" for daqd_dc and rc-local services on fb1 in the sense that they were no longer output from systemctl --failed, but they remained inactive (dead) when running systemctl status on them. Following from  15303   I succeeded in restarting the daqd services. Turned out I needed to manually start the open-mx and mx services in fb1. I rerun the restartC1LSC script without success. The script fails because some machines need to be rebooted by hand.
 

  10627   Tue Oct 21 00:38:40 2014 ericqUpdateLSCsweep + RMS as uncertainty

Quote:

BUT, what we really need (instead of just the DC sweeps) is the DC sweep with the uncertainty/noise displayed as a shaded area on the plot, as Nic did for us in the pre-CESAR modelling.

I've taken a first stab at this. Through various means, I've made an estimation of the total noise RMS of each error signal, and plotted a shaded region that shows the range of values the error signal is likely to take, when the IFO is statically sitting at one CARM offset. 

I have not included any effects that would change the RMS of these signals in a CARM-offset dependent way. Since this is just a rough first pass, I didn't want to get carried away just yet. 


For the transmission PDs, I measured the RMS on single arm lock. I also measured the incident power on the QPDs and thorlabs PDs for an estimate of shot noise, but this was ridiculously smaller than the in-loop RIN. I had originally though of just plotting sensing noise for the traces (i.e. dark+shot), because the amount of seismic and frequency noise in the in-loop signal obviously depends on the loop, but this gives a very misleading, tiny value. In reality we have RIN from the PRC due to seismic noise, angular motion of the optics, etc., which I have not quantified at this time. 

So: for this first, rough, pass, I am simply multiplying the single transmission noise RMSs by a factor of 10 for the coupled RMS. If nothing else, this makes the SqrtInv signal look plausible when we actually practically find it to be plausible. 


For the REFL PDs, I misaligned the ITMs for a prompt PRM reflection for a worst-case shot noise situation, and took the RMS of the spectra. (Also wrote down the dark RMSs, which are about a factor of 2 lower). I then also multiplied these by ten, to be consistent with the transmission PDs. In reality, the shot noise component will go down as we approach zero CARM offset, but if other effects dominate, that won't matter. 


Enough blathering, here's the plot:

dcCARMSweep_uncertainties.png

Now, in addition to the region of linearity/validity of the different signals, we can hopefully see the amount of error relative to the desired CARM offset. (Or, at least, how that error qualitatively changes over the range of offsets)


This suggests that we MAY be able to hop over to a normalized RF signal; but this is a pretty big maybe. This signal has the response of the quotient of two nontrivial optical plants, which I have not yet given much thought to; it is probably the right time to do so...

  10631   Wed Oct 22 06:32:29 2014 ranaUpdateLSCsweep + RMS as uncertainty

 

 This is looking very useful. It will be useful if you can upload some python code somewhere so that I can muck with it.

I would guess that the right way to determine the trans RMS is just to use the single arm lock RIN and then apply that as RIN (not pure TR RMS) to the TR signals before doing the sqrt operation.

  3988   Mon Nov 29 11:51:41 2010 kiwamuUpdateIOOswaped in-vac PZT mirrors

This morning I opened the chambers and started some in-vac works.

As explained in this entry, I swapped pzt mirror (A) and (C) successfully.

The chambers are still open, so don't be surprised.

 

(today's missions for IOO)

 - cabling for the pzt mirrors

 - energizing the pzt mirrors and slide them to their midpoint.

 - locking and alignment of the MC

 - realignment of the pzt mirrors and other optics.

 - letting the beam go down to the arm cavity

 

  3992   Tue Nov 30 04:22:52 2010 kiwamuUpdateIOOswaped in-vac PZT mirrors

As a result of the vacuum work, now the IR beam is hitting ETMX.

The spot of the transmitted beam from the cavity can be found at the end table by using an IR viewer.

Quote: #3988

(today's missions for IOO)

 - cabling for the pzt mirrors

 - energizing the pzt mirrors and slide them to their midpoint.

 - locking and alignment of the MC

 - realignment of the pzt mirrors and other optics.

 - letting the beam go down to the arm cavity

 

 

  9182   Tue Oct 1 14:12:22 2013 ranaSummaryCDSsvndumpfilter on linux1 makes NFS slow

 Yesterday and this morning's slow NFS disk access was caused by 'svndumpfilter' being run at linux1 to carve out the Noise Budget directory. It is being moved to another server; I think the disk access is back to normal speed now.

  2891   Thu May 6 19:23:54 2010 FrankSummaryComputerssvn problems

i tried to commit something this afternoon and got the following error message:

Command: Commit 
Adding: C:\Caltech\Documents\40m-svn\nodus\frank 
Error: Commit failed (details follow): 
Error: Server sent unexpected return value (405 Method Not Allowed) in response to  
Error: MKCOL request for '/svn/!svn/wrk/d2523f8e-eda2-d847-b8e5-59c020170cec/trunk/frank' 
Finished!:  

anyone had this before? what's wrong?

  508   Fri May 30 21:30:15 2008 tobinConfigurationComputerssvn on solaris
I installed svn on op440m.  This involved installing the following packages from sunfreeware:

apache-2.2.6-sol9-sparc-local  libiconv-1.11-sol9-sparc-local   subversion-1.4.5-sol9-sparc-local
db-4.2.52.NC-sol9-sparc-local  libxml2-2.6.31-sol9-sparc-local  swig-1.3.29-sol9-sparc-local
expat-2.0.1-sol9-sparc-local   neon-0.25.5-sol9-sparc-local     zlib-1.2.3-sol9-sparc-local
gdbm-1.8.3-sol9-sparc-local    openssl-0.9.8g-sol9-sparc-local

The packages are located in /cvs/cds/caltech/apps/solaris/packages.  The command line to install
a package is "pkgadd -d " followed by the package name.  This can be repeated on nodus to get
svn over there.  (Kind of egregious to require an apache installation for the svn _client_, I 
know.)
  969   Fri Sep 19 00:18:14 2008 ranaUpdateComputerssvn is old
linux2:mDV>ssh nodus
Password:
Last login: Fri Sep 19 00:11:44 2008 from gwave-69.ligo.c
Sun Microsystems Inc.   SunOS 5.9       Generic May 2002
nodus:~>c
nodus:caltech>cd apps/
nodus:apps>cd mDV
nodus:mDV>svn update
svn: This client is too old to work with working copy '.'; please get a newer Subversion client
nodus:mDV>whoami
controls
nodus:mDV>uname -a
SunOS nodus 5.9 Generic_118558-39 sun4u sparc SUNW,A70 Solaris
nodus:mDV>pwd
/cvs/cds/caltech/apps/mDV
nodus:mDV>
Frown
  972   Fri Sep 19 09:49:42 2008 YoichiUpdateComputerssvn is old
The problem below is fixed now.
The cause was .svn/entries and .svn/format had wrong version number "9" where it had to be "8".
I changed those files in all the sub-directories. Now svn up runs fine.
I don't know how this version discrepancy happened.



Quote:
linux2:mDV>ssh nodus
Password:
Last login: Fri Sep 19 00:11:44 2008 from gwave-69.ligo.c
Sun Microsystems Inc.   SunOS 5.9       Generic May 2002
nodus:~>c
nodus:caltech>cd apps/
nodus:apps>cd mDV
nodus:mDV>svn update
svn: This client is too old to work with working copy '.'; please get a newer Subversion client
nodus:mDV>whoami
controls
nodus:mDV>uname -a
SunOS nodus 5.9 Generic_118558-39 sun4u sparc SUNW,A70 Solaris
nodus:mDV>pwd
/cvs/cds/caltech/apps/mDV
nodus:mDV>
Frown
  7296   Tue Aug 28 17:02:16 2012 jamieUpdateGeneralsvn commit changes

I just spent the last hour checking in a bunch of uncommitted changes to stuff in the SVN.  We need to be MUCH BETTER about this.  We must commit changes after we make them.  When multiple changes get mixed together there's no way to recover from one bad one.

  654   Thu Jul 10 13:47:12 2008 YoichiHowToComputerssvn access via https
Now you can access to the svn repository on nodus by https.
To perform a checkout, you can use the following command

svn co --username svn40m https://nodus.ligo.caltech.edu:30889/svn/trunk/chans

This will check out "chans" directory.
The password for svn40m is written in the usual place.
You can also access the URL by a web browser to see the repository in a very primitive way.
A nice web interface for browsing the repository is planed but not yet implemented.
  2031   Thu Oct 1 08:37:43 2009 steveUpdateSUSsuspention damping restored and MZ HV stuck

Earthquake  of magnitude 5.0  shakes ETMY loose.

MC2 lost it's damping later.

Attachment 1: eq5oct1.jpg
eq5oct1.jpg
ELOG V3.1.3-