<!-- Title: 13:36:08  Tue Jan 15 2002 -->
<!-- Crewchief: M. Convery -->
<!-- Op1: M. Gallinaro -->
<!-- Op2: K. Terashi -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>page 2!!!</pre>


<!-- Date: Tue Jan 15 13:42:28 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-37&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-37  width='300' align='top'></td><td>ACNET pot postion readings from 0am, December 31, 2001 to  0am, January 11, 2002</a></td></tr></table>
<!-- Author: Koji -->
<!-- Comment: Tue Jan 15 13;43;17 comment by...Koji -->
<pre>Mistake!!
This is until 0am, January 1, 2002 for 24 hours.</pre>


<!-- Date: Tue Jan 15 13:44:18 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-38&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-38  width='300' align='top'></td><td>ACNET pot position readings from November 1, 2001 to  December 1, 2001</a></td></tr></table>
<!-- Author: Koji -->


<!-- Date: Tue Jan 15 13:45:36 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-39&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-39  width='300' align='top'></td><td>ACNET pot position readings from December 1, 2001 to  January 1, 2002</a></td></tr></table>
<!-- Author: Koji -->


<!-- Date: Tue Jan 15 13:46:33 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-40&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-40  width='300' align='top'></td><td>ACNET pot position readings from January 1, 2002 to  January 11, 2002</a></td></tr></table>
<!-- Author: Koji -->


<!-- Date: Wed Jan 16 08:44:26 2002 -->
<pre>Date: Tue, 15 Jan 2002 17:47:07 -0600 
From: Craig Moore &lt;cmoore@fnal.gov&gt; 
Subject: Re: pot moves draft agreement 
To: Mike Albrow &lt;albrow@fnal.gov&gt; 
Cc: Konstantin Goulianos &lt;dino@fnal.gov&gt;, 
   michele gallinaro &lt;michgall@fnal.gov&gt;, koji terashi &lt;terashi@fnal.gov&gt;, 
   convery@fnal.gov, hatake@fnal.gov, Craig Moore &lt;damon@fnal.gov&gt; 
 
Fellow Potters, 
 
    The pot readbacks have been restored on all the pots from working on 
the upstairs instrumentation.  Since the downstream pot is also working 
this makes my explanation about the bad cable suspect.  The readings are 
not exactly the same so I am not sure about the calibration. 
 
Craig 
</pre>
<!-- Author: convery -->
<!-- Comment: Wed Jan 16 08;47;30 comment by...convery -->
<pre>See &lt;a href= 
'/cgi/internal/elog/det-system-elog.pl?nb=roman_pots&action=view&page=1&frame=2&anchor=18:34:37'&gt; here &lt;/a&gt;
for Koji's initial report of this problem.</pre>

<!-- Comment: Wed Jan 16 08;49;09 comment by...convery -->
<a href=
/cgi/internal/elog/det-system-elog.pl?nb=roman_pots&action=view&page=1&frame=2&anchor=18:34:37> try again </a>


<!-- Date: Wed Jan 16 15:47:07 2002 -->
<pre>I believe I have successfully calibrated the Roman pots and wrote  
the constants to the lookup table and FRAM.  If this is true,  
then data from the pots should be reliable now. 
 
The run is 137235, and by sheer luck was taken during quiet time 
(shortly after a quench which I didn't know about at the time). 
 
Slopes, offsets, pedestals, rms's look ok.  There is one channel 
with a slightly high rms (1.8 counts) relative to the others and 
to what is seen in the plug smx which has similar electronics. 
 
I am still looking into why the original fer calibration code 
didn't work while my hacked up version does.</pre>
<!-- Author: convery -->


<!-- Date: Thu Jan 17 10:59:39 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-41&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-41  width='300' align='top'></td><td>pre-lookup pedestals and rms from yesterday's calibration</a></td></tr></table>
<!-- Author: convery -->
<!-- Comment: Thu Jan 17 11;05;22 comment by...convery -->
The channel with the large rms is RP1y fiber 17 = smxr channel 1,
smd (qie) channel 35.


<!-- Date: Thu Jan 17 15:49:05 2002 -->
The solution to the problem I've been having with calibrations 
is apparently very simple: two parameters, dacstart and  
dacincrement, were never set in the hardware database (as CRATE 
properties rather than CARD properties).  AARGH!!! 
They are now set to 32767 and 4, respectively. 
I'll test this the next chance I get with quiet time.
<!-- Author: convery -->
<!-- Comment: Wed Jan 23 09;08;04 comment by...convery -->
<pre>forgot to note that this was tested and is fine</pre>
<!-- Date: Tue Jan 22 09:42:15 2002 -->
Koji and I just took a calibration run (to test that we could 
combine consumers and calibrate BSC, MP, and RP all in one run). 
That part of the test was probably successful, but the RP  
calibration failed.  We are getting data transfer errors from 
SMXR channel 4 (RP3x).  When I tried taking standalone pedestals, 
I got ped=31, range=7 for all qies in this SMXR channel. 
Maybe this is a loose cable, though I dodn't know of any work 
in the area since Friday when I calibrated successfully. 
I will check with the shower max experts for possible causes.  
<!-- Author: convery -->
<!-- Comment: Fri Mar 22 10;13;00 comment by...convery -->
Note: RP calibration is type SMQIE while miniplug and BSC are
type QIE.  They CANNOT be combined into one run configuration.
<!-- Date: Wed Jan 23 09:06:47 2002 -->
Koji, Michele, Mike Albrow, and Chuck Brown tested inserting the  
pots early this morning.  Runs taken were <a href=/java/cdfdb/servlet/RunSummary?RUN_NUMBER=137729>137729</a> and <a href=/java/cdfdb/servlet/RunSummary?RUN_NUMBER=137730>137730</a> 
<P><a href=http://www-bd.fnal.gov/cgi-mcr/elog.pl?nb=2002&action=view&page=61&frame=2&anchor=07:22:54>MCR log entry 07:22:54</a>
<!-- Author: convery -->
<!-- Comment: Wed Jan 23 11;02;06 comment by...Koji -->
<pre>Mike Albrow, Michele Gallinaro, Koji Terashi and Chuck Brown  
(Beams Division) moved the CDF Roman Pots (A48) closer to the  
beam and checked the followings; 

- 3 pots coincidence rate 
- beam losses at CDF (LOSTP, LOSTPB) and D0 (D0PHTL, D0AHTL) 
- B0 luminosity, p and pbar beam intensities 

At the same time we took data with TEST_BSC trigger table for 
offline analysis and check of coincidence rate.  

We moved the pots from the garage position (LVDT=-850) all the 
way up to inner limits (LVDT=+200) backed up by mechanical stop, 
but we didn't see any changes on beam losses at both CDF and D0. 
We also saw that the pot coincidence rate went up from 0.2KHz up 
to 20KHz smoothly as the pots were moved closer to the beam. 

In the summary, probably LVDT=+150 will be a good standard  
position of the pots.
</pre>


<!-- Date: Thu Jan 24 09:35:28 2002 -->
<pre>Access to alcove crates:  
Michele and I went in and checked if there is a loose cable for  
Roman Pot SMXR in FCAL00, which was suspected from the error   
that happened in SMXR readout test. Apparently there was no loose  
cable, and it could mean something is not good in SMD crate which  
is in the tunnel.   
</pre>
<!-- Author: Koji -->


<!-- Date: Fri Jan 25 08:59:32 2002 -->
<pre>Last night, we has access to the SMD crate in the tunnel. 
There were no obvious loose cables.  We swapped the cables 
and the problem followed the cable rather than the SMD board. 
We returned the cables to their original configuration except we 
connected the spare cable to the smd board for RP3x.  We were not 
able to access the collision hall to connect this spare to an 
SMXR channel. 
 
The results of an SMD ID check (~cdf_smx/jpUTIL/SMCcal48 -g4) 
before and after the cable swap are: 
 
output from before we saw readout problems: 
 
pot SMXRch  id 
1x    0     391 
1y    1     390 
2x    2     39c 
2y    3     395 
3x    4     39b 
3y    5     392 
 
since something went bad: 
 
1x    0     391 
1y    1     390 
2x    2     39c 
2y    3     395 
3x    4     junk 
3y    5     junk (note for 1 Ccl the id is 392) 
 
when we swapped cables at the SMD side yesterday 
 
1x    4     junk (1 Ccl has 391) 
1y    5     junk (2 Ccl's have 390) 
2x    2     39c 
2y    3     395 
3x    0     39b 
3y    1     392 
 
So the problem stayed with the cable/SMXR channel rather than 
the board. 
 
</pre>
<!-- Author: convery, terashi -->


<!-- Date: Fri Jan 25 13:43:45 2002 -->
RP readout code is now in the official FER code 
<a href=/cgi/elog/elog.pl?nb=2002&action=view&page=72&frame=2&anchor=17:40:51>shift elog 17:40</a>
<!-- Author: convery -->


<!-- Date: Mon Jan 28 12:55:59 2002 -->
SMXR is marked offline in the hardware database (onlineflag=0) 
until readout problems are fixed.  If we want to use it in test  
runs, we will have to temporarily mark it online ourselves.
<!-- Author: convery -->


<!-- Date: Mon Jan 28 12:58:00 2002 -->
<pre>Date: Mon, 28 Jan 2002 07:20:43 -0600 (CST) 
From: Gary Drake &lt;drake@fnal.gov&gt; 
To: Mary Convery &lt;convery@cdfsga.fnal.gov&gt; 
cc: &lt;mlindgre@fnal.gov&gt;, &lt;byrum@fnal.gov&gt;, &lt;jxp@fnal.gov&gt;, &lt;michgall@fnal.gov&gt;, 
   &lt;terashi@fnal.gov&gt;, &lt;drake@fnal.gov&gt; 
Subject: Re: RP readout problems 
In-Reply-To: &lt;200201252209.QAA25569@cdfsga.fnal.gov&gt; 
Message-ID: &lt;Pine.GSO.4.31.0201280651430.19219-100000@fsui02.fnal.gov&gt; 
MIME-Version: 1.0 
Content-Type: TEXT/PLAIN; charset=US-ASCII 
Status: RO 
 
Mary, 
 
The modification to the plug SMXRs puts a termination on the data header 
bit, for the data cable coming from the SMD boards.  It turns out that 
the LVDS receivers can spontaneously change state if they are not actively 
driven by an SMD board.  The header bit is the most important, because if 
it is set, the SMXR begins a readout operation for the unused channel, and 
when it is done, advances the L1A queue.  The latter is done as an OR of 
all channels.  This definitely screws up the readout operation of normal 
channels.  On the SMXR that you have, I believe that the receivers were 
replaced with RS422.  However, they may have the same problem, or maybe 
are more sensitive than the LVDS.  If you are having readout problems and 
have unused inputs, this could be why.  At the next opportunity, pull the 
SMXR and I will have the modification made to channel 6.  I would do this 
before going to the trouble of swapping cables.  Best to address known or 
highly likely problems first. 
 
Working SMDTerm modules are very scarce right now.  You may be aware that 
there is a problem with the B&B modules breaking.  I am trying to address 
the problem, but we are not on top of it yet.  I have no working spares 
here.  You should talk to Karen to see if she has any.  Again, if you are 
wanting to swap it to address the same readout problem, I suggest trying 
the fix on the SMXR first.  Also, Karen & Mike have an SMD backplane 
monitor card, that is useful for looking at SMD backplane signals.  If you 
are having a problem in the SMD crate, I recommend looking at signals 
before swapping the card. 
 
As for spare SMXRs, you should talk to Mike and Karen to see if they are 
willing to dedicate one more.  As you know, electronics for the miniplug 
was not counted when we produced the SMX electronics.  Without making 
more, those needs come right out of the SMX spares, which are in short 
supply almost across the board.  We could do a small run of SMXRs, making 
2-4 more.  The assembly would be done in-house.  I don't have cost figures 
handy for the entire SMXR, but the fab would be around $3K.  You should 
talk to Mike and/or Dino to see if the finances can be arranged.  I 
recommend that you do this so to ensure that both the miniplug and SMX 
have a healthy spare pool. 
 
As for the SQUIDs, the production is in the works.  Parts are ordered, and 
boards are about to be fabricated.  The chips have been fabricated, but 
are not packaged yet.  The wafers are due in early Feb., and then they 
must be packaged and tested.  I am guessing that all this will take a 
minimum of 6 weeks yet.  The assembly can't start until we get the chips. 
It is looking that we will not have SQUIDs coming off the production line 
until the end of April. 
 
                                                Regards, 
 
                                                Gary 
-- 
**************************** 
Gary Drake 
Argonne National Laboratory 
High Energy Physics Division 
HEP 362 
9700 S. Cass Ave 
Argonne, IL  60439  USA 
Tel. (630) 252-1568 
Fax  (630) 252-5047 
**************************** 
 
On Fri, 25 Jan 2002, Mary Convery wrote: 
 
&gt; Hi, as you may know, we have yet a new problem reading out the 
&gt; Roman pots.  (You can see what we've tried so far to find the 
&gt; problem in the Roman-pot elog.)  Anyway, what we have gathered 
&gt; from talking to some of you experts is 
&gt; 
&gt; 1. There is another simple test we can try swapping cables into 
&gt;    the SMXR, so we will try this the next chance we get. 
&gt; 
&gt; 2. We should get a spare SMTerm board (are these relatively abundant?) 
&gt;    and install it in the SMD crate when we get a chance and screw it in. 
&gt; 
&gt; 3. Karen says that the difference between plug and central SMXR's is a 
&gt;    modification related to the fact the SMXR ch 7 is not used in the plug. 
&gt;    Does anyone remember what problems occurred without this modification? 
&gt;    We also have channel 6 empty. 
&gt; 
&gt; 4. We really could use a spare SMXR.  (I know, so could you.)  But if we 
&gt;    would have to modify channel 6, why not take a central SMXR and modify 
&gt;    channels 6 and 7, since spare central boards are more abundant. 
&gt;    Maybe we could do this at the same time as we bastardize the drivers, 
&gt;    as some of you would say. 
&gt; 
&gt; 5. I'm sure I'm forgetting other things, but while I'm at it... 
&gt;    Mike, have you checked on the status of the production of new squids recent 
ly? 
&gt;    If not, could you? 
&gt; 
&gt; 
&gt; OK, as always, thanks for your help! 
&gt; 
&gt; best regards 
&gt; Mary 
&gt; 
 
</pre>
<!-- Author: convery -->


<!-- Date: Wed Jan 30 11:34:08 2002 -->
<pre>Access work: 
 
We tried the spare cable in smxr channel 4.  Still same problem. 
Then we swapped 0,1&lt;-&gt;4,5, and the problem stayed in channels 
4,5 rather than moving with the cable. 
 
Then Mike Lindgren lifted some pins on the smxr to disable  
channels 6 and 7 since they are unused.  (For the plug smx 
they disable channel 7 thought this had not been previously 
done on our board.) 
 
That seemed to solve the problem.  SMCcal48 reads board id's 
for all 6 smd boards.  I took 2 calibrations in run control 
(downloaded the second one) and a daq test run 138165. 
I saw no errors in run control.</pre>
<!-- Author: convery, terashi -->
<!-- Comment: Wed Jan 30 11;41;08 comment by...convery -->
forgot to mention that all cables were returned to their original
configuration except that smxr ch 4 (RP3x) now uses the spare
cable since we didn't have the chance to swap the cable in the 
tunnel
<!-- Date: Wed Jan 30 11:37:08 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-42&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-42  width='300' align='top'></td><td>pedestals and rms</a></td></tr></table>
<!-- Author: convery -->
<!-- Comment: Wed Jan 30 11;39;15 comment by...convery -->
Pedestals and rms's after the access for the calibration which 
was downloaded to FlashRAM on the SMXR.  RP3x is now using the
spare cable.


<!-- Comment: Thu Jan 31 08;50;16 comment by...convery -->
Another note, these are "pre-lookup" pedestals, so don't expect 
them to make sense.  The distribution here is similar to what is
seen for the plug smx.  The rms's are actual rms's in ADC counts
and are also similar to what is seen for the plug smx.


<!-- Date: Tue Feb 5 14:10:29 2002 -->
Last week we tried to include the RP SMXR in regular running. 
It worked fine at first.  The run was stopped and during  
coldstart, fcal00 hung and was unpingable, and required a  
reset_crate.  This type of hang has happened to fcal00 many 
times before.  Another run was started and things were fine until 
fcal00 gave a done timeout due to bunch counter mismatch between 
slot 4 (SMXR) and 6 (ADMEM).  The rc errorlog (run 138277) has 
 
<pre> 
(RC)   11:38:3 Halt -> HALTED 
(RC)   11:38:12 Recover -> RECOVERED 
(RC)   11:38:16 Run -> ACTIVE 
(MLE) b0fcal00:Messenger:11:38:20 AM->Event 148238: Bunchcounters in slot 6 and slot 4 disagree (at least) 
(MLE) b0fcal00:Messenger:11:38:20 AM->Runtime Error 1, Event 148238: Bunch counter mismatch, mismatch count = 1 
(MLE) b0fcal00:Messenger:11:38:20 AM->Event 148239: Bunchcounters in slot 6 and slot 4 disagree (at least) 
(MLE) b0fcal00:Messenger:11:38:20 AM->Runtime Error 3, Event 148239: Bunch counter mismatch, mismatch count = 1 
38'24" 1 crate/s: b0fcal00(26),  Done TO.[RXPT] 
(MLE) b0tsi02:Messenger:11:38:22 AM->DONE timeout 
</pre> 
 
and immediately gave a DTO following HRR 3 more times. 
<P> 
I thought this was due to an incorrect value of the card property SMXRBUNCHCOUNTER which we had set to 38 as in the smx.  But Arnd 
said that if this were the case, the bunch counter mismatch  
should occur on the first event. 
<P> 
Today Koji and I took a daq test run with both fcal crates. 
We didn't see any errors.  Then we tried changing  
SMXRBUNCHCOUNTER to 39.  When we started running again we  
immediately got a DTO and Arnd's FER_setVerbose command on the 
b0fcal00 processor indicated that the bunch counters were off by 
1.  So 38 appears to be the correct value after all. 
<P> 
After setting it back to 38, we took a million events (with both 
the software and hardware event builder deselected).  We didn't 
get any errors.  Which is good, but doesn't explain what went 
wrong last week. 
<P> 
Arnd suspects a problem with the crate (because of this and also 
because of the way b0fcal00 hangs and has to be reset).  He  
suggested we look for bent pins, reseat the tracer, etc.  
<!-- Author: convery -->
<!-- Comment: Tue Feb  5 14;19;06 comment by...convery -->
<a href=/cgi/elog/elog.pl?nb=2002&action=view&page=95&frame=2&anchor=10:22:29>link to last Friday's shift elog</a>

<!-- Comment: Fri Feb  8 08;04;34 comment by...convery -->
The card has been included in running since Tuesday evening with
no problems.


<!-- Date: Fri Feb 8 08:13:34 2002 -->
Yesterday we conducted a second test of inserting the pots. 
As before, there was no significant change in losses and the 
trigger coincidence rate was much higher than we expect for 
triggering only on diffractive pbars.  The beam was cleaned up 
somewhat which reduced the rate a bit. 
<a href=/cgi/elog/elog.pl?nb=2002&action=view&page=113&frame=2&anchor=13:29:38>entry in shift elog</a> 
Runs taken were 138613, 138614, 138616. 
The fibers were read out and prior to beginning the test, the 
HV for the mcpmts was turned on and it remains on.  Runs before 
138613 did not have the HV on.
<!-- Author: convery, terashi, albrow -->


<!-- Date: Fri Feb 15 10:48:35 2002 -->
<pre>Forgot to note before now that we are not getting data from 
SMXR channel 5.  It has been this way for at least a week. 
Koji first noticed it as a fixed value of 176 for all channels of  
RP3y in the data.  Luckily this does not prevent us from reading  
out the other channels.  When logged into the b0fcal00 processor  
while taking a calibration run, messages appear like 
 
Runtime Error XXXX, event 1: ShowerMax FE board has stopped sending data, slot 4, header 0x39c04XX 
 
The first thing to try is powercycling the crate(s).  If that  
doesn't help, we try to determine whether the problem is on the 
smxr or smd end.</pre>
<!-- Author: convery -->
<!-- Comment: Fri Feb 15 11;11;55 comment by...convery -->
Note, if all is well, the header should be 39804XX.  The c
indicates a problem with smxr channel 5.  A note on header words
is <a href=/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=1&frame=2&anchor=13:26:52>here</a>.
<!-- Date: Fri Feb 15 10:52:19 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-43&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-43  width='300' align='top'></td><td>RP coincidence rates from Koji</a></td></tr></table>
<!-- Author: convery -->
<!-- Comment: Fri Feb 15 10;53;25 comment by...convery -->
<pre>From: Koji Terashi &lt;terashi@fnal.gov&gt;
Subject: timing in proton beam
Sender: terashi@fnal.gov
To: Mike Albrow &lt;albrow@fnal.gov&gt;,
   Mary Convery &lt;convery@rock16.rockefeller.edu&gt;,
   Michele Gallinaro &lt;michgall@fnal.gov&gt;
Message-id: &lt;3C6B26BA.130EF7B1@fnal.gov&gt;
Organization: Rockefeller University
MIME-version: 1.0
X-Mailer: Mozilla 4.77 [en] (X11; U; IRIX 6.3 IP32)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en
Status: RO

Hi all,

We had proton only store with 36 coalesced bunches from 6:30pm, so
I tried timing scan. Todd moved the pots fully in . I could vary timing
(CAFEDELAY) from 0 up to 165 nsec by 10 nsec step. For the pbar store,
the rate dropped sharply at 100 nsec and there was a plateau below 100
(lower edge could not be observed due to change in beam condition). For
the p store, the upper and lower edges could be observed at 130 and
about 35 nsec, respectively, but the rate didn't drop to zero even
outside the edge. So, the result for p store is not as clear as pbar
case. Also, the rate jumped up and down in the plateau region (so
actually it's hard to find where the plateau is). When I tried to
measure some suspecious points, the beam was lost.

We know somehow that there may be some protons outside nominal bunches
in the Tevatron. It seems we are seeing the same thing in this result.
This will be good for beam loss study, but may not be good for RP timing
because it seems not so easy to find out where the real proton bunch is.

Anyway, I will make a plot from this result tomorrow, and I will show
you.

regards,
Koji
</pre>

<!-- Comment: Fri Feb 15 10;55;06 comment by...convery -->
<pre>Date: Thu, 14 Feb 2002 09:00:39 -0600
From: Mike Albrow &lt;albrow@fnal.gov&gt;
Subject: Re: timing in proton beam
To: Michele Gallinaro &lt;michgall@fnal.gov&gt;,
   Mary Convery &lt;convery@rock16.rockefeller.edu&gt;,
   Koji Terashi &lt;terashi@fnal.gov&gt;
Cc: Konstantin Goulianos &lt;dino@fnal.gov&gt;, mike albrow &lt;albrow@fnal.gov&gt;
Message-id: &lt;000901c1b568$5e1698d0$4635e183@fnal.gov&gt;
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
X-Priority: 3
X-MSMail-priority: Normal
References: &lt;3C6B26BA.130EF7B1@fnal.gov&gt;
Status: RO

The p-only scan that Koji and Todd did last night was very informative, even though
conditions were not very stable. Looking at the numbers one can try to estimate
what fraction of the triggers, during a colliding beam run, are from backgrounds
from the p beam and pbar beam. I don't have the numbers at hand, they are in Koji's
office, but the conclusion is that nearly all the triggers are from the p-beam halo.
And it does not seem possible to eliminate these simply by shifting the gate timing
(CAFEDELAY). We need to have a much narrower gate (~20ns?), and maybe
the best way is with external NIM logic.
        I am also concerned about the effective gate on the fiber trackers, and how
much background junk they will see.
                                            Mike
</pre>



<!-- Date: Thu Feb 21 13:41:05 2002 -->
The problem with SMXR channel 5 was solved by powercycling  
the fcal00 crate.  Further problems due to changes in run control 
code (for showermax reces trigger stuff) were seen but Arnd  
fixed it and after a reboot I was able to take calibrations.
<!-- Author: convery, gallinaro -->


<!-- Date: Thu Mar 7 09:37:18 2002 -->
Since last weekend, smxr channel 1 was failing calibrations. 
In a calibration taken last night, all smxr channels failed. 
Koji powercycled the crate during the access today.  Then I 
took a calibration and all appears back to normal.
<!-- Author: convery -->


<!-- Date: Thu Mar 21 22:44:44 2002 -->
<pre>Roman Pot SMXR timing scan: 
 
Timing scan for SMXR readout delay has been done with colliding 
beams. The first scan was done on 3/1/02, the second done on 
3/21/02 with the pots fully moved in. We used FCAL_00, CLC_00 and 
_01, LEVEL1_GLOBAL and TRIGGER_SCALER crates under Myron Mode L1 
early (Ignore BC, Ignore Inhibit) with MINIMUM_BIAS_1[5,232] 
trigger table. We took short runs with different SMXRDELAY  
settings for the SMXR in slot 4 of FCAL_00, as follows; 
 
1st Scan (3/1/02) 
================= 
Run#    SMXRDELAY                               #Evts 
        (decimal)  (hex)        (timing) 
------------------------------------------------------- 
140136         0   0 00 00 00   0   0   0   0   12K   
140137  33554432   2 00 00 00   2   0   0   0   14K   
140138  36449324   2 2c 2c 2c   2  44  44  44   12K 
140139  39344216   2 58 58 58   2  88  88  88   12K  
140140  42239103   2 84 84 84   2 132 132 132   13K 
 
2nd Scan (3/21/02) 
================== 
Run#    SMXRDELAY                               #Evts  Comment 
        (decimal)  (hex)        (timing) 
----------------------------------------------------------------- 
141460   1447446   0 16 16 16   0  22  22  22   25K 
141459   2894892   0 2c 2c 2c   0  44  44  44   25K 
141458   4342338   0 42 42 42   0  66  66  66   25K 
141457   5789784   0 58 58 58   0  88  88  88   28K 
141456   7237230   0 6e 6e 6e   0 110 110 110   26K 
141455   8684676   0 84 84 84   0 132 132 132   27K 
 
141448  16777216   1 00 00 00   1   0   0   0   28K 
141451  18224662   1 16 16 16   1  22  22  22   27K 
141452  19672108   1 2c 2c 2c   1  44  44  44   28K 
141449  21119554   1 42 42 42   1  66  66  66   24K 
141453  22567000   1 58 58 58   1  88  88  88   27K 
141454  24014446   1 6e 6e 6e   1 110 110 110   26K 
141450  25461892   1 84 84 84   1 132 132 132   24K 
 
</pre>
<!-- Author: Michele, Koji -->



<!-- Date: Wed Mar 27 09:28:34 2002 -->
<pre>Date: Tue, 26 Mar 2002 11:42:53 -0600 (CST) 
From: Gary Drake &lt;drake@fnal.gov&gt; 
To: Mary Convery &lt;convery@cdfsga.fnal.gov&gt; 
cc: &lt;mlindgre@fnal.gov&gt;, &lt;drake@fnal.gov&gt; 
Subject: Re: squid production? 
In-Reply-To: &lt;200203261735.LAA24047@cdfsga.fnal.gov&gt; 
Message-ID: &lt;Pine.GSO.4.31.0203261139410.13530-100000@fsui02.fnal.gov&gt; 
MIME-Version: 1.0 
Content-Type: TEXT/PLAIN; charset=US-ASCII 
Status: RO 
 
Hi Mary, 
 
The printed circuit boards are fabricated, and all parts in hand except 
the SMQIEs.  One wafer has been packaged and is being tested.  Once we 
determine that the chips are good, we will proceed with the assembly.  be 
aware that it is going slowly, as it is hard to obtain priority in 
competition with other projects.  Still, I expect that we will begin to 
have SQUIDs early to mid summer as my best guess at the moment. 
 
                                                Cheers, 
 
                                                Gary 
</pre>
<!-- Author: convery -->


<!-- Date: Wed Mar 27 12:27:20 2002 -->
Yesterday the following errors were seen: 
<PRE> 
Runtime Error 87000, event 87000: ShowerMax FE board has stopped sending data, 
   slot 4, header 0x3988402 
</PRE> 
This header error refers to an smxr channel for pot 2 which is  
not instrumented yet anyway. 
<P> 
This morning Rob Roser powercycled the fcal00 crate from the cryo 
room (select crate, hit "rack off" then "reset").  I took a  
calibration run and everything seems ok now.
<!-- Author: convery -->


<!-- Date: Wed Mar 27 12:43:33 2002 -->
There is some concern that a spike in the missing ET phi distribution 
for recent runs is caused by the Roman pots being in.  (The problem was  
first observed beginning at the same time as the RP auto insertion began.)   
More information is being collected. 
<P>We were asked about when the pots have been in up until now. 
This is the summary of what I have found in the elogs regarding 
pot insertion and/or diffractive trigger table tests. 
Unless otherwise noted, the pots were in, the run was marked as physics, 
beam data, but not good run. 
<PRE> 
Jan 23 137729, 137730 
Feb  7 138613, 138614, 138616 
Feb 12,13,20 pbar and p only stores 
Feb 17 139297  failed test of diffractive trigger table, pots were not in (Koji confirmed from ACNET) 
Feb 17 139305, 139306 
Mar  1 140136-140140 DataType DAQTesting (timing studies) 
Mar 18 test of automatic insertion of pots by MCR, ~run 141191, this is marked as a good run 
Mar 21 141448-141460 DataType DAQTesting (timing studies) 
auto insertion Mar 21 - Mar 25 day, out for store 1128, in and out during studies Mar 26, 
hopefully will go back to auto insertion with next store 
</PRE>  
<!-- Author: convery -->


<!-- Date: Wed Mar 27 13:12:03 2002 -->
Last week we did further timing studies  
(<a href=http://www-cdf.fnal.gov/internal/people/links/MaryConvery/rptiming.html>results</a>) and set the SMXRDELAY parameter to 
25461892 corresponding to delaying the L1A by 1 clock cycle and 
delaying the L1A, CDFReset, and CDFClock signals sent to the  
SMD crate by 132 ns.  (See  
<a  href=/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=1&frame=2&anchor=14:05:29>note</a> 
on timing parameters.) 
<P> 
I'm not sure when this took effect.  It looks like the hardware  
database was updated on Fri Mar 22 at 12:50 and that the next  
coldstart (is this what is needed to pick up changes from the 
hardware database?) was for run 141518.
<!-- Author: convery -->


<!-- Date: Thu Apr 4 09:47:35 2002 -->
Done timeouts from the SMXR last night... shift crew removed 
whole crate.  Presumably this will be fixed by a powercycle in 
the course of the access today.
<!-- Author: convery -->


<!-- Date: Mon Apr 8 14:56:45 2002 -->
<table><tr><td><a href=/elog/notebooks/roman_pots/Mon_Apr__8_2002_145625.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-49  align='top'></td><td>I see a total of 8/160 (=5%) dead channels. This is the occupancy plot. Dead channels appear to be  RP-1y (ch.4,20,23,31); RP-3x (channels 0,2,39); RP-3y (channel 13).</a></td></tr></table>
<!-- Author: M. Gallinaro -->
<!-- Comment: Mon Apr  8 15;53;37 comment by...Michele -->
<pre>Where channels go from 0 to 39.</pre>
<!-- Comment: Tue Apr  9 07;52;13 comment by...convery -->
Channels 1y 4,20 and 3x 39 consistently fail calibrations in the
lowest range (range 0) since about Feb 27.  New squids may solve
these problems.
<!-- Date: Mon Apr 8 15:51:54 2002 -->
<pre>A few Runs were taken with the Roman Pots at  
their IN position with the approapriate timing,  
starting from March 21, 2002. 
The position of the Roman Pots apparently disturbs 
the beam and generates MET spikes in the central  
calorimeter. 
Nonetheless, these Runs are extremely useful and 
can be used to study and debug the Roman Pots. 
 
Run# 141461 through Run# 141660.</pre>
<!-- Author: M. Gallinaro -->
<!-- Comment: Wed Apr 10 13;43;42 comment by...convery -->
141660 (store 1128) had pots OUT
<!-- Date: Wed Apr 10 13:31:47 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-50&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-50  width='300' align='top'></td><td>map between squid and smd channel</a></td></tr></table>
<!-- Author: convery -->



<!-- Date: Wed Apr 10 14:47:22 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-51&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-51  width='300' align='top'></td><td>bad channels from latest calibration run 142840</a></td></tr></table>
<!-- Author: convery -->
<!-- Comment: Wed Apr 10 14;48;22 comment by...convery -->
This looks very strange.  Hopefully it will be fixed by 
powercycling the crate during tomorrow's access.


<!-- Date: Thu Apr 11 14:23:55 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-52&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-52  width='300' align='top'></td><td>calibration run 142971 downloaded</a></td></tr></table>
<!-- Author: convery -->
<!-- Comment: Thu Apr 11 14;29;16 comment by...convery -->
We are now reading out pots 1 and 2 (to look for dead channels in 
pot 2).  Transition boards in the tunnel and smd-smxr cables
at the smxr (in the collision hall) were swapped during today's
access.  The above calibration was downloaded to fram.


<!-- Date: Thu Apr 11 16:45:47 2002 -->
<pre>Access work in the tunnel: 
 
Alignment people + Koji went in the tunnel to re-survey the roman 
pot positions. The positions were measured at OUT (LVDT ~ -900) 
and IN (~ +200) limits, and 2 intermediate points (-500 and 
-200). Also, the Z positions of the pots were measured. The 
results will be put here soon. 
 
Also, I swapped a few squids to study some suspecious (maybe 
dead) channels. Swapped squids are as follows; 
 
RP1Y SMD (slot 4): squid  #1 &lt;--&gt; #2 
                   squid #12 &lt;--&gt; #9 
 
From Mary's plot for the last SMQIE calibration (142971), it  
turns out that a bad channel moved from RP1Y fiber #4 (1st QIE in 
squid #1) to the fiber #2 (1st QIE in squid #2), that means the 
QIE has a problem. Another suspecious channel (RP1Y fiber #20 
corresponding to the 2nd QIE in squid #1) was masked because the 
2nd QIE in squid #2 is not used for fiber readout.  
 
To find any bad channels in RP-2, the transition boards for the  
RP-2 were swapped with them for the RP-3. Also, the SMD-SMXR  
connections were swapped in order for the SMXR ch 2 and 3 to read 
out the RP-2. Some suspicious channels can be seen in above plot, 
but we need to check real data.</pre>
<!-- Author: Koji -->


<!-- Date: Fri Apr 12 15:17:02 2002 -->
<pre>Just for reference: 
SMD-SMXR cable connection to the front of SMXR board 
 
Until April 11 
-------------- 
 SMD 01   --&gt; SMXR Ch 0 = RP1-X 
     02   --&gt;         1 = RP1-Y 
     03   --&gt;         2 = RP2-X 
     04   --&gt;         3 = RP2-Y 
     07SP --&gt;         4 = RP3-X 
     06   --&gt;         5 = RP3-Y 
 
Since April 11 
-------------- 
 SMD 01   --&gt; SMXR Ch 0 = RP1-X 
     02   --&gt;         1 = RP1-Y 
     07SP --&gt;         2 = RP2-X 
     06   --&gt;         3 = RP2-Y 
     03   --&gt;         4 = RP3-X 
     04   --&gt;         5 = RP3-Y 
</pre>
<!-- Author: Koji -->


<!-- Date: Fri Apr 12 15:28:30 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-53&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-53  width='300' align='top'></td><td>calibration run 143147 downloaded</a></td></tr></table>
<!-- Author: convery -->
<!-- Comment: Fri Apr 12 15;32;27 comment by...convery -->
We realized that our channel mapping was wrong!  We thought we 
were using smd channels 0-19,24-43 but in fact we are using 0-39.
(Dead/low occupancy channels in ymon plot correspond to these
wrong channels!)
<P>
The map has been changed in the fer code by Koji and in the
calibration database code by me.  The above calibration was taken
after the changes.
<P>
Can/should we mark previous runs in the database to note the map
error?


<!-- Date: Mon Apr 15 08:55:59 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-54&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-54  width='300' align='top'></td><td>YMon plots for the Roman Pot in run 143257 (after swapping the transition boards between RP-2 and RP-3, and swapping the squids in RP-1Y (see above for detail). It looks all RP fibers in RP-1 and RP-2 have similar occupancy except the  fiber #2 in RP-1Y which is known to be due to a bad QIE.</a></td></tr></table>
<!-- Author: Koji -->


<!-- Date: Mon Apr 22 10:26:05 2002 -->
<pre>----- Original Message ----- 
From: "Todd Johnson" &lt;tjohnson@fnal.gov&gt; 
To: "albrow" &lt;albrow@fnal.gov&gt; 
Cc: &lt;spalding@fnal.gov&gt; 
Sent: Friday, April 12, 2002 11:37 AM 
Subject: Re: new pots positions. 
 
 
&gt; Mike, 
&gt; 
&gt;     Yes, the sequencer file is now set to insert  the pots to -16, -7, and +10 
&gt; mils. This has been tested and appears to be able to put the pots in within +- 
&gt; 1mil of the desired position. 
 
&gt; The "real" stepper motor sequencer commands seem to be broken, so the original 
&gt; simple file sets  initially used to insert all the way to the limits were 
&gt; edited to insert the pots using raw motor steps scaled to yield a specific 
&gt; position.  There is no feedback on the motion, so if for some reason the 
&gt; command were to get sent twice, or the start positions were not at the limit 
&gt; switches, the pots will overshoot the desired positions.  Controls people are 
&gt; looking into the problem with the stepper sequencer commands, and once we hear 
&gt; that they have fixed them, we may switch to that method eventually. 
&gt; 
&gt;    I have also edited the database scaling for the motors such that if for 
&gt; example one requests a change of 100 mils, one actually gets 100 mils.  The 
&gt; scaling for each pot was different, which was very surprising and somewhat 
&gt; inexplicable unless one imagines that the LVDT gains are not matched.  Since we 
&gt; choose to believe the LVDTs and since all measurements to date have been made 
&gt; using their measured positions, I chose to edit the motor control scaling.  The 
&gt; actual physical positions will still correspond to the historical LVDT 
&gt; positions. 
&gt; 
&gt; -Todd 
&gt; 
&gt; albrow wrote: 
&gt; 
&gt; &gt; Hi Todd, Could you please confirm to me that the sequencer is now updated 
&gt; &gt; with the new positions, or is it still being done manually? See note below: 
&gt; &gt; Thanks, Mike 
&gt; &gt; 
&gt; &gt; Hi Mike, 
&gt; &gt; 
&gt; &gt; Bill Orejudos would like you to send him email 
(cdf-ops-managers@fnal.gov) 
&gt; &gt; confirming that the MCR scripts for inserting the pots have been updated 
&gt; &gt; with the intermediate position.  You should probably send it to Jeff 
&gt; &gt; Spalding 
&gt; &gt; too. 
&gt; &gt; 
&gt; &gt; thanks 
&gt; &gt; Mary 
 
</pre>
<!-- Author: convery -->
<!-- Comment: Mon Apr 22 10;27;30 comment by...convery -->
Pots again inserted routinely (to intermediate position) since 
Apr 12.


<!-- Date: Fri May 3 09:06:39 2002 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-55&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-55' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-56&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-56' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-57&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-57' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-58&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-58' width='300'></a></center>
<!-- Author: convery -->
<!-- Comment: Fri May  3 09;13;35 comment by...convery -->
bad channels as seen in calibration runs 144038, 144245:
<BR> (left) since run 143970 (Apr 28) smxr channel 0, 
qie 32-39 (actually 32-47 I think, but we don't use 40-47)
were failing calibrations.  Powercycling fcal00 from the cryo
room on May 1 fixed this problem (right).



<!-- Date: Mon May 6 09:13:50 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-59&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-59  width='300' align='top'></td><td>updated ymon reference plot put in CO binder</a></td></tr></table>
<!-- Author: convery -->


<!-- Date: Tue May 7 12:43:31 2002 -->
<PRE> 
Date: Mon, 06 May 2002 11:09:25 -0500 
From: Todd Johnson <tjohnson@fnal.gov> 
Subject: Re: RP position calibration 
To: Mary Convery <convery@cdfsga.fnal.gov> 
Cc: albrow@fnal.gov, michgall@fnal.gov, terashi@fnal.gov 
 
Specifically, pot 2 did not reach its limit switch even when the LVDT 
position read as much as 250 mils. Previously the LVDT would read about 220 
mils when the limit switch was reached.  The operators had gingerly moved the 
pot in further than 220 but gave up at about 250 mils.  I'm concerned that 
either the limit switch isn't functioning or the LVDT has a mechanical offset 
and the pot may not actually be at the expected position. 
 
regards, 
 
-Todd Johnson 
 
 
Mary Convery wrote: 
 
> Arnd Meyer (ops manager) just told me that there was a question at 
> the 9am meeting regarding the calibration of the CDF roman pot positions. 
> The pots were moved to the inner limit during a <a href=/cgi/elog/elog.pl?nb=2002&action=view&page=374&frame=2&anchor=09:11:09>test</a> Sunday and I guess 
> the positions read out were not exactly what MCR expected(?) 
> 
> I know the pots were recently resurveyed... have the new calibrations 
> been relayed to the appropriate places? 
> 
> thanks 
> Mary 
</PRE>
<!-- Author: convery -->
<!-- Comment: Tue May  7 12;47;02 comment by...convery -->
<pre>MCR elog &lt;a href=http://www-bd.fnal.gov/cgi-mcr/elog.pl?nb=2002&action=view&page=339&frame=2&anchor=09:34:18&gt;entry&lt;/a&gt;

09:34:18-  CDF called and asked to have the tokyo pots moved into the beam. Two
of the pots, C:TPOT1M and C:TPOT3M hit their limit switch at 176.2 mils and 203.8
mils respectively. However C;TPOT2M had not hit its liimit switch at 230 mils. We
called Todd Johnson and asked him for advice to see if we should move the pot farther
into the beam. We tried to move the pot about 20 more mils at 5 mil steps, but had yet
to hit a limit switch. We stoped here and called CDF. They said that they just needed
the pot at 220 mils so we moved the pot bsck out to 220 mils. Data logging
C;TPOT2M shows that on April 11th, on the day shift, the pot was at 280 mils, but
this was a shutdown day so we are going to assume we might have a bad limit switch
on that pot. - Joel </pre>


<!-- Date: Wed May 8 10:46:32 2002 -->
Noticed calibration failures in smxr channel 3 (RP2y) in 
yesterday's calibration run 144467.  Cycled power on west alcove 
rack from the cryo room.  New calibration run 144501 looks fine.
<!-- Author: convery -->


<!-- Date: Wed May 8 12:47:38 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-60&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-60  width='300' align='top'></td><td>RP survey</a></td></tr></table>
<!-- Author: convery -->
<!-- Comment: Wed May  8 12;49;25 comment by...convery -->
<pre>Date: Wed, 08 May 2002 12:25:14 -0500
From: Koji Terashi &lt;terashi@fnal.gov&gt;
Subject: Re: RP position calibration
Sender: terashi@heffalump.fnal.gov
To: Todd Johnson &lt;tjohnson@fnal.gov&gt;
Cc: Mary Convery &lt;convery@cdfsga.fnal.gov&gt;, albrow@fnal.gov, michgall@fnal.gov

Hi Todd,

If this issue has no progress since this Monday, I would like to comment on
that. As Mary montioned, we had a resurvey on April 12. This survey results were
summarized in the text file and plotted in a ps file (they are attached in this
mail). In the text file, you see several columns and "LVDT" shows the
LVDT readings for 4 different pot positions including inner and outer limits.
Actually the inner limit for the pot 2 is about +288. As you may see, the
LVDT reading values at limit switches look changed since the previous survey,
but the linearlity between the LVDT and actual pot positions is still looking
good in the plot. As far as we trust this recent survey, the LVDT values for
inner limits are +177 for pot 1, +288 for pot 2 and +241 for pot 3. I guess the
operation points for data taking would be at -1.2cm from the beam pipe center
(right, Mike?).

regards,
Koji


====================================================================
 Roman Pot Survey Results  (4/12/02)
====================================================================
            Survey(inch)             LVDT(count)  D/LVDT(inch/count)
            wrt 1)  wrt 2)   wrt 3)
--------------------------------------------------------------------
RP-1 (p downstream)
  up-top    14.005  -12.520  -1.524  -866.9(L)
  up-top    14.462  -12.063  -1.067  -500.4       1.247E-3
  up-top    14.830  -11.695  -0.699  -200.4       1.227E-3
  up-top    15.288  -11.237  -0.241  +176.5(T)    1.215E-3
--------------------------------------------------------------------
RP-2 (middle)
  up-top    14.052  -12.473  -1.477  -900.4(L)
  up-top    14.470  -12.055  -1.059  -500.9       1.046E-3
  up-top    14.777  -11.748  -0.752  -200.4       1.022E-3
  up-top    15.280  -11.245  -0.249  +287.8(T)    1.030E-3
--------------------------------------------------------------------
RP-3 (p upstream)
  up-top    14.000  -12.525  -1.529  -856.3(L)
  up-top    14.460  -12.065  -1.069  -500.9       1.294E-3
  up-top    14.830  -11.695  -0.699  -200.5       1.232E-3
  up-top    15.380  -11.145  -0.149  +240.8(T)    1.246E-3
--------------------------------------------------------------------
 Survey values are the distances between
   1) Murphy Line (26.525" offset from beam pipe center) and
      the RP back plate,
   2) beam pipe center and the RP back plate,
   3) beam pipe center and the top of the RP.


</pre>

<!-- Comment: Wed May  8 13;53;08 comment by...convery -->
<pre>Date: Wed, 08 May 2002 13:37:50 -0500
From: Todd Johnson &lt;tjohnson@fnal.gov&gt;
Subject: Re: RP position calibration
To: Koji Terashi &lt;terashi@fnal.gov&gt;
Cc: Mary Convery &lt;convery@cdfsga.fnal.gov&gt;, albrow@fnal.gov, michgall@fnal.gov

Hi Koji.

   As I understand this then, the LVDT positions from the last survey appear to be correct, but
the IN limits are different.  This means that when the pots are put in all the way to the original
positions, they will not all reach their limit switch.  If  the pots are to be inserted closer
than the sequencer now does, the operators should simply be provided with desired position
readings and they will manually move them to those positions.

Thanks for clearing this up.  Perhaps we will verify those limit switch positions before this
evening's store.

 regards,
-Todd
</pre>


<!-- Date: Tue May 21 13:56:42 2002 -->
Swapped a trigger panel for BSC-3/4 and RP from newer panel (with  
circuit board) to old panel (without board, colored short cables) 
to see what happens on RP-3 counter.
<!-- Author: Koji -->