40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 335 of 344  Not logged in ELOG logo
New entries since:Wed Dec 31 16:00:00 1969
ID Date Author Type Category Subjectup
  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
  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.

  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

 

  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.

  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.

  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.

  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.

 

  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.

  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 *

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

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

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

 

 

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

  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.

  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.

 

  13285   Fri Sep 1 15:46:12 2017 KiraUpdatePEMtemp sensor update

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.

Attachment 1: IMG_20170901_144729.jpg
IMG_20170901_144729.jpg
  13295   Tue Sep 5 17:18:17 2017 KiraUpdatePEMtemp sensor update

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.

 

Attachment 1: IMG_20170905_144924.jpg
IMG_20170905_144924.jpg
Attachment 2: IMG_20170905_165042.jpg
IMG_20170905_165042.jpg
  13296   Tue Sep 5 17:52:06 2017 KiraUpdatePEMtemp sensor update

to get the sensors to read the same values they have to be in direct thermal contact with the metal block - there can't be any adapter board in-between

for the 2nd attempt, I also recommend encasing it in a metal block rather than just one side. You can drill some 7-10 mm diameter holes in an aluminum or copper block. Then put the sensors in there and plug it up with some thermal paste.

  13303   Fri Sep 8 10:22:30 2017 SteveUpdatePEMtemp sensor update

The weight of SS can with copper liner  is 12.2 kg

Is 1 Amp for the heating jacket going to be enough? We should have some headroom.

Quote:

to get the sensors to read the same values they have to be in direct thermal contact with the metal block - there can't be any adapter board in-between

for the 2nd attempt, I also recommend encasing it in a metal block rather than just one side. You can drill some 7-10 mm diameter holes in an aluminum or copper block. Then put the sensors in there and plug it up with some thermal paste.

 

  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.

 

 

  1161   Mon Nov 24 19:15:16 2008 rana, alberto, johnConfigurationEnvironmenttemperature
The PSL Room Temperature was alarming because it had gone above 23 C. This set off an unfortunate chain of events:

We found that the PSL HEPA was set low (20%). This is a fine setting for when no one is working in there but it
does raise the temperature since there are heat sources inside the blue box.

We tried to change the office area temperature to compensate and also the westmost sensor inside the lab area by 2 deg F.

The office area one was problematic - there was so much dust in it that the gas valve nipple was clogged. So we've
now blown it all clean with a compressed air can. We're now tuning the calibration screw to make our new
digital sensor agree with the setpoint on the controller.

Expect wild temperature swings of the office area for a couple days while Alberto and I tune the servo.
  1163   Tue Nov 25 19:29:15 2008 rana, alberto, johnConfigurationEnvironmenttemperature

Quote:
The PSL Room Temperature was alarming because it had gone above 23 C. This set off an unfortunate chain of events:

We found that the PSL HEPA was set low (20%). This is a fine setting for when no one is working in there but it
does raise the temperature since there are heat sources inside the blue box.

We tried to change the office area temperature to compensate and also the westmost sensor inside the lab area by 2 deg F.

The office area one was problematic - there was so much dust in it that the gas valve nipple was clogged. So we've
now blown it all clean with a compressed air can. We're now tuning the calibration screw to make our new
digital sensor agree with the setpoint on the controller.

Expect wild temperature swings of the office area for a couple days while Alberto and I tune the servo.


This morning Bob found 92F in the office area and in the control room of the lab. He turned down the thermostat and when I got in at about 9 I found 65. After a few hours of adjustment of the thermostat's calibration, I could stabilize the room temperature to about 72F. I also turned down the thermostats inside the lab of a couple of degrees F.
  1164   Thu Nov 27 22:56:42 2008 ranaConfigurationEnvironmenttemperature
8-)
Attachment 1: mc.png
mc.png
  13611   Tue Feb 6 16:58:19 2018 KiraUpdatePEMtemperature measurements

I decided to plot the temperatures measured over two days for the sensor inside the can and inside the lab just to see if there was any significant difference between the two, and obtained the following plot. This shows that there is a difference in measurements of a few 0.01 C. The insulated seismometer can didn't change temperature as much as the lab did, which is as expected. I'll work on properly calibrating the sensors sometime in the future so that we can use the sensor that's just in the lab as an accurate thermometer.

Attachment 1: temps.png
temps.png
  1331   Sun Feb 22 23:43:07 2009 carynSummaryGeneraltemperature sensor

Comparing  PSL-FSS-RMTEMP and PEM-MC1-TEMPS

So, to compare temp channels, I made a plot of PSL-FSS_RMTEMP and PEM-MC1_TEMPS(the test temp sensor channel after converting from cts to degC). This plot begins about 2 months ago t_initial=911805130. The temperature channels look kinda similar but MC1-TEMPS (the temp sensor clamped to MC1,3 chamber) is consistently higher in temperature than FSS_RMTEMP. See compare_temperature_channels.png.

MC1-TEMPS isn't exactly consistent with FSS-RMTEMP. I attached a few plots where I've zoomed in on a few hours or a few days. See compare_temperature_channels_zoom1.pdf & compare_temperature_channels_zoom2.pdf

Change the room temperature, see what happens to the chamber temperature

A while ago, somebody was fiddling around with the room temperature.  See compare_temperature_channels_zoom4.pdf.  This is a plot of PEM-MC1_TEMPS and PSL-FSS_RMTEMP at t0=911805130. You can see the chamber heating up and cooling down in happy-capacitory-fashion. Although, the PSL-FSS_RMTEMP and the PEM-MC1_TEMPS don't really line up so well. Maybe, the air in the location of the MC1,3 chamber is just warmer than the air in the PSL or maybe there's an offset in my calibration equation.

Calibration equation for PEM-MC1-TEMPS

For the calibration (cts to degC) I used the following equation based on the data-sheet for the LM34 and some measurements of the circuit:

TEMPERATURE[degC]=5/9*(((-CTS/16384/451.9/1.04094)-(.0499*10^-3))/(20*10^-6)-35);

How does the chamber temperature compare with the air temperature?

It looks like the chamber may be warmer than the air around it sometimes.

I wanted to check the temperature of the air and compare it with the temperature the sensor had been measuring. So, at t=918855087 gps, I took the temp sensor off of the mc1-mc3 chamber and let it hang freely, close to the chamber but not touching anything. See compare_temperature_chamber_air.png. MC1_TEMPS increases in temperature when I am handling the temp-sensor and then cools down to below the chamber temperature, close to FSS_RMTEMP, indicating the air temperature was less than the chamber temperature.

 When, I reattached temp sensor to the chamber at t=919011131 gps, the the temperature of the chamber was again higher than the temperature of the air. See compare_temperature_air2chamber.pdf.

Also, as one might expect, when the temp-sensor is clamped to the chamber, the temperature varies less, & when it's detached from the chamber, the temperature varies more. See compare_temperature_air_1day.pdf & compare_temperature_chamber_1day.pdf.

New temp-sensor power supply vs old temp-sensor power supply

The new temp-sensor is less noisy and seems to work OK. It's not completely consistent with PSL-FSS_RMTEMP, but neither was the old temp-sensor. And even the air just outside the chamber isn't the same temperature as the chamber. So, the channels shouldn't line up perfectly anyways.

I unplugged the 'old' temp-sensor power supply for a few hours and plugged in the 'new' one, which doesn't have a box but has some capacitors and and 2 more voltage regulators. The MC1_TEMPS channel became less noisy. See noisetime.png & noisefreq.pdf. For that time, the minute trend shows that with the old temp-sensor power supply the temp sensor varies +/-30cts and with the new power supply, it is more like +/-5cts (and Volt/16,384cts * 1degF/10mV -->  apprx +/-0.03degF). So, it's less noisy. 

I kept the new temp-sensor power supply plugged in for about 8 hours, checking if new temp sensor power supply worked ok. Compared it with PSL-FSS_RMTEMP after applying an approximate calibration equation. See ver2_mc1_rmtemp_8hr_appxcal.png.

Just for kicks

Measuring time constant of temp sensor when detached from chamber. At 918858981, I heated up the temp sensor on of the mc1-mc3 chamber with my hand. Took hand off sensor at  918859253 and let it cool down to the room temperature. See temperature_sensor_tau.pdf. 

Attachment 1: compare_temperature_channels.png
compare_temperature_channels.png
Attachment 2: compare_temperature_channels_zoom1.pdf
compare_temperature_channels_zoom1.pdf
Attachment 3: compare_temperature_channels_zoom2.pdf
compare_temperature_channels_zoom2.pdf
Attachment 4: compare_temperature_channels_zoom4.pdf
compare_temperature_channels_zoom4.pdf
Attachment 5: compare_temperature_chamber_air.png
compare_temperature_chamber_air.png
Attachment 6: compare_temperature_air2chamber.pdf
compare_temperature_air2chamber.pdf
Attachment 7: compare_temperature_air_1day.pdf
compare_temperature_air_1day.pdf
Attachment 8: compare_temperature_chamber_1day.pdf
compare_temperature_chamber_1day.pdf
Attachment 9: noisetime.pdf
noisetime.pdf
Attachment 10: noisefreq.pdf
noisefreq.pdf
Attachment 11: ver2_mc1_rmtemp_8hr_appxcal.pdf
ver2_mc1_rmtemp_8hr_appxcal.pdf
Attachment 12: temperature_sensor_tau.pdf
temperature_sensor_tau.pdf
  13183   Thu Aug 10 14:13:23 2017 KiraSummaryPEMtemperature sensor

Goal is to build a temperature sensor accurate to 1 mK. Schematic is shown below. This does not take into account the DC gain that occurs.

Parts that would be used for this: LM317 regulator, AD592 temperature transducer, OP amp (low input noise and high impedance), 100K (or maybe 10k) resistor. This is what is currently proposed, but the exact parts we use could be changed to better fit the sensor. The resistor and the OP amp will be decided depending on the output of the AD592.

Once this is built, I would like to create a few copies of it and put them into an insulated container and measure the output from each one. This would allow us to calculate the temperature noise of the circuit, as we can take out the variations due to temperature changes inside the container by comparing the outputs.

I can also model the noise in the circuit to see how much noise there is before building it. There are three terms to the noise that we have, and we need to decide which one dominates at low frequencies.

Our final goal is to create an additional circuit that could cancel out the DC gain. I have attached an additional schematic proposed by Rana that would help with this issue. I will leave this second half for when the first part works.

Attachment 1: IMG_20170810_121637~2.jpg
IMG_20170810_121637~2.jpg
Attachment 2: IMG_20170810_134422~2.jpg
IMG_20170810_134422~2.jpg
  13188   Thu Aug 10 21:22:06 2017 ranaSummaryPEMtemperature sensor
  • Should we use the AD590 or the AD592? They're sort of the same, but have slightly different packages and specs.
  • Given the sensitivity of the AD590 to power supply drift, I would recommend using a precision voltage reference like the AD581 or AD587. Take a look at the datasheets and order a few different varieties so we can see what works best for us. I believe that the voltage regulators have too much drift to use for precision temperature control.
  • The AD590 datasheet has a few example circuits showing how we can subtract off the offset which comes the 1 uA/K coefficient of the AD590 (i.e. we would have 295 uA at room temperature, trying to stabilize to +/- 0.1 K)
  • For the first prototypes its fine to use some solderable protoboard assembly, but we will eventually have to figure out how to package this thing and interface it with our Acromag slow controls system.

also, I've attached some temperature noise spectra from the LISA group at the AEI in Hannover. It will be interesting to see if we get the same results.

Attachment 1: tempsensnoise2.pdf
tempsensnoise2.pdf
Attachment 2: tempnoise_final.pdf
tempnoise_final.pdf
  13190   Fri Aug 11 10:27:49 2017 KiraUpdatePEMtemperature sensor

Since there seems to be little difference between AD590 and AD592, I guess we could just go with the AD590. The temperature noise spectrum in the first graph are for the AD590, so if we want to reproduce those results, we should use AD590.

For the AD581/AD587, we could go with a few varieties that have the least output voltage drift, although I am not sure what precision we will need. So maybe we could try AD587U and AD581L. We could also try AD587K and AD581K and see if those work as well.

We will also need to calibrate the sensor, as it takes an input of 5V, but the AD581/AD587 provides 10V, which will give about a 1 degree error according to the datasheet. It does state that this is only a calibration error, so it shouldn't be too much of an issue.

I will figure out the packaging once I construct the sensor and verify that it works. Maybe we could use a box similar to the existing sensor, but it depends on the size of the finished circuit.

  13191   Fri Aug 11 10:48:39 2017 KiraUpdatePEMtemperature sensor

Quick update: we actually have AD587KRZ and AD592, so we could start by using that and seeing how it works.

ELOG V3.1.3-