<!-- Title: 13:11:19  Fri May  4 2001 -->
<!-- Crewchief: Dino Goulianos -->
<!-- Op1: Michele Gallinaro -->
<!-- Op2: Koji Terashi -->
<!-- Op3: Mary Convery -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>First Roman Pot E-log</pre>


<!-- Date: Tue May 8 20:46:43 2001 -->
<pre>Switched ON Roman Pot 6U crate. 
Connection to SMD/SMXR cables is as follows: 
 
Cable	Detector 
SMD01	RPS 1-X 
SMD02	RPS 1-Y 
SMD03	RPS 2-X 
SMD04	RPS 2-Y 
SMD05	RPS 3-X 
SMD06	RPS 3-Y</pre>
<!-- Author: A. Bocci, M. Gallinaro -->


<!-- Date: Fri May 18 12:05:06 2001 -->
<pre>Set the HV for the RPS `Signal' PMT (i.e. the 80-channel PMTs). 
 
Use a separate distributor box since the HV is somewhat 
higher than other PMTs in CAEN HV board Slot#7. 
 
Distributor is set at -2100 Volts 
RPS Signal PMTs are set at a value of -1800 Volts. 
 
</pre>
<!-- Author: M. Gallinaro -->


<!-- Date: Thu Jun 14 11:14:25 2001 -->
<pre>Attempting to take pedestals. 
 
From b0dau30: 
&gt;setenv FISION_DIR /cdf/code-common/products/fision/v2_15 
&gt;setenv VISION_SERVER b0fcal00.fnal.gov 
&gt;~cdf_smx/smx pedcal48 -s0 -g4 -r2 
(e = number of events = 250 by default 
 s = smxr channel 
 g = slot containing smxr [wrong slot gives FISSION error] 
 r = slot containing tracer) 
 
I tried this for all smxr channels since I don't know which are 
connected to smd's with squids and got equally bad results for 
all!  The output is pedestals (Val) for the first event for all 
smd channels, then pedestals averaged over all events. 
The output for the first few channels looks like: 
 
 
SMX 0 Ch  0 Cap 1 Ran 3 Val 23   Hex ed77 Word Count 1 Capid 1  Parity 1  
SMX 0 Ch  1 Cap 1 Ran 6 Val  6   Hex b1c6 Word Count 1 Capid 0  Parity 1  
SMX 0 Ch  2 Cap 0 Ran 0 Val  8   Hex    8 Word Count 0 Capid 0  Parity 0  
SMX 0 Ch  3 Cap 1 Ran 0 Val 11   Hex 210b Word Count 0 Capid 0  Parity 1  
 
... 
 
SMX 0 DCh  0 Cap 1 Valave 23.0 Valrms  0.0 Rangeave 3.0 Rangerms 0.0 Nev   250  
SMX 0 DCh  1 Cap 1 Valave  6.0 Valrms  0.0 Rangeave 6.0 Rangerms 0.0 Nev   250  
SMX 0 DCh  2 Cap 0 Valave  8.0 Valrms  0.0 Rangeave 0.0 Rangerms 0.0 Nev   250  
SMX 0 DCh  3 Cap 1 Valave 11.0 Valrms  0.0 Rangeave 0.0 Rangerms 0.0 Nev   250  
 
 
Note that for pedestals, the range should always be 0, which it  
is nothere.  Also many error bits (Word Count, Capid, Parity)  
are set.  This is what I would expect to see if the power to the  
smd crate were turned off, though since this is our first  
attempt it could be anything. 
 
...access to the collision hall today but not to the tunnel</pre>
<!-- Author: Mary -->
<!-- Comment: Fri Jun 29 16;14;58 comment by...Mary -->
<pre>correction to above procedure for taking pedestals:

From b0dau30: 
&gt;setenv FISION_DIR /cdf/code-common/products/fision/v2_15 
&gt;setenv LD_LIBRARY_PATH /cdf/code-common/products/fision/v2_12a/IRIX-6.5/mips
&gt;setenv VISION_SERVER b0fcal00.fnal.gov 
&gt;~cdf_smx/smx/pedcal48 -s0 -g4 -r2</pre>
<!-- Date: Wed Jun 27 11:20:51 2001 -->
<pre>Tunnel: controlled access 
 
6U crate 
 
Fuses	PowerSupply 
8A    	  +7.5V 
2A	  -7.5V 
.25A	  +15V 
 
Found a blown fuse on the -7.5Volts: 
replace with a 3A fuse. 
 
Switch ON crate: lights are now blinking again.</pre>
<!-- Author: M.Gallinaro, M.Albrow -->


<!-- Date: Fri Jun 29 16:12:01 2001 -->
<pre>Made contact with the smd crate (6U) for the first time 
(apparently fuse was blown when I last tried). 
Note also that the IP address for b0fcal00 was apparently  
entered incorrectly somewhere which prevented me from connecting 
via rlogin.  This is now fixed. 
 
I deduce that smxr channels 4 and 5 (RP 3) read out the smd's  
which are populated with squids since these give no error bits 
when taking pedestals while channels 0-3 do.  (Am I right???) 
 
Tried running pedcal48, setdac, daccal48, and readlook48 
from the ~cdf_smx/smx area.  Don't understand output yet 
but will report further after consulting with Steve Kuhlmann.</pre>
<!-- Author: Mary -->



<!-- Date: Tue Jul 3 13:01:44 2001 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-1&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-2' ></a><a href='/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-3&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-4' ></a></center>
<!-- Author: convery -->
<!-- Comment: Tue Jul  3 13;10;53 comment by...Mary -->
<pre>Above plots are average pedestals and rms over 250 events for 
SMXR channels 4 and 5 for 3 runs taken between 8:30 and 9:15 this morning. Range should always be 0 for pedestals; average range&gt;1 
may indicate noise.  Note that for all 3 runs, range&gt;1 occurs in 
the same detector/SMD channels.  (Also note that only SMD 
channels 0-39 are connected to roman pot channels.)</pre>


<!-- Comment: Wed Aug 22 09;21;43 comment by...convery -->
<pre>actually the qie channels connected to rp channels are 0-19,24-43</pre>
<!-- Date: Fri Jul 13 09:56:19 2001 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-5&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-6' ></a><a href='/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-7&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-8' ></a></center>
<!-- Author: convery -->
<!-- Comment: Mon Jul 16 15;48;25 comment by...Mary -->
<pre>Above are mean pedestals over 250 events taken Thursday 7/12/01.
The two SMD boards with squids were moved around to read out
pots 1 and 2, then back to 3.
Pedestals are about the same in all cases.
Are they dominated by noise?
Note that some pedestal values are above the limit of range 0,
about 32, and appear as having range=1 and ped=0 when in fact
ped=32.
</pre>


<!-- Date: Mon Jul 16 15:50:13 2001 -->
<pre>I ran pedestals for all channels again this morning. 
SMXR channels 4 and 5, which are connected to the 
SMD boards with squids, have no error bits set. 
SMXR channels 6 and 7, which are not connected to 
anything, have random error bits set for Word Count, 
Capid, and Parity, as expected. 
Channels 0,2,3 have all Parity errors for all channels, 
which probably makes sense since their SMD's have no 
squids.  Channel 1 had parity errors only in some 
channels.  Maybe this indicates a problem, but I don't 
really know.  It would be good if we can test these 
cables again connected to the SMD boards with squids.</pre>
<!-- Author: Mary -->


<!-- Date: Thu Aug 9 15:17:08 2001 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-9&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-10' ></a><a href='/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-11&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-12' ></a></center>
<!-- Author: convery -->
<!-- Comment: Thu Aug  9 15;19;39 comment by...mary -->
<pre>finally made plots from July 17 study of effect of high voltage
(off, 1800V, 2000V) on pedestals -- no significant effect</pre>


<!-- Date: Fri Aug 17 14:05:29 2001 -->
<pre>Note on timing: 
 
The two parameters are SMXRDELAY and SMXRBUNCHCOUNTER. 
 
The latter is set to 38, which is explained in the log entry: 
 
   Tue Feb 27 10:04:29 
 
  Late entry from yesterday.  Gary Drake, Karen Byrum, Mike 
  Lindgren and I studied shower max timing.  The first check 
  we did was of general interest to all calorimeter people. 
  Using Greg's Bzero_trigger (which only triggers on bunch 
  zero crossing) we measured the arrival of L1A on the 
  backplanes in both central and plug.  If one counts the 
  leading edge of clock after the bunch zero signal as 
  clock ZERO,  then L1A arrived before the leading 
  edge of the 38th Clock cycle, in both central and plug. 
  This agrees with the setting of the shower max bunch latency 
  register of 38. 
 
  In addition to this we studied internal shower max timing 
  based on these signals. 
 
   - Steve Kuhlmann 
 
--------------------------------------------------------- 
The Bunchcounter is a basically adhoc register that does 
not affect timing.  But if it's not set correctly 
you'll get mismatch errors and run_control will stop. 
        Steve 
---------------------------------------------------------- 
 
 
SMXRDELAY is set to 37896770 for the plug and 50331648 for 
the central shower max.  Converting these to hex gives 
2 42 42 42 and 3 00 00 00.  The first of the four bit fields 
ie 2(3) is the number of clock cycles that L1A is delayed: 
"...the SMQIE has a FIXED pipeline length of 42.  Therefore 
3 bits of relative latency are provided to adjust this to 
the true latency..." 
The others are the the delays in ns of the following signals 
sent to the SMD crate: L1A, CDFReset, CDFClock. 
42 converted from hex to decimal is 66 ns, 00 -&gt; 0 ns. 
</pre>
<!-- Author: convery -->


<!-- Date: Fri Aug 17 14:38:08 2001 -->
<pre>Changed SMXRDELAY from 50331648 to 0</pre>
<!-- Author: convery,terashi -->


<!-- Date: Fri Aug 17 16:26:27 2001 -->
<pre>Set HV to 2000 V and turned on for all 3 RP signals.</pre>
<!-- Author: convery,terashi -->



<!-- Date: Tue Aug 28 10:48:53 2001 -->
<pre>Changed HV settings for Roman Pot trigger counters at 0:15pm 
on 8/23. 
 
HV ch   Counter   OLD    NEW 
------------------------------- 
  18    RP-TRG1   1500   1500 
  19    RP-TRG2   1600   1200 
  20    RP-TRG3   1150   1350 
------------------------------- 
 
Also, put the cables from RP trigger counters back to the ADMEM 
#2 (slot 17) 
 
RPS W PMT01 TRG  --&gt;  Ch 12 
      PMT02 TRG  --&gt;  Ch 16 
      PMT03 TRG  --&gt;  Ch 17</pre>
<!-- Author: Koji -->


<!-- Date: Fri Aug 31 14:13:03 2001 -->
<pre>Calibration consumer is now available in run control: 
POTQIEPED 
 
This accesses the script 
/cdf/people1/cdfdaq/consumers/RunRomanPotQiePed 
 
The calibration consumer code is in 
/cdf/people1/cdfdaq/consumers/code/QiePed_fwd/pro</pre>
<!-- Author: convery -->
<!-- Comment: Fri Aug 31 14;30;08 comment by...convery -->
<pre>I meant runRomanPotQiePed (not RunRomanPotQiePed)

this will create banks RPAP and RPAC

log files will be created in 
/cdf/people1/cdfdaq/consumers/log/runRomanPotQiePed*</pre>


<!-- Date: Wed Oct 17 14:22:07 2001 -->
<pre>Yesterday Koji and I removed the SMXR from b0fcal00 to have  
it taken to Argonne for minor fixes that were previously made  
to other SMXRs. 
 
The power supply for this crate was removed some time ago for 
repairs.  Similar problems have been observed in power supplies 
for other systems, and no supply will likely be installed in 
this crate until these problems are fully understood.</pre>
<!-- Author: convery -->


<!-- Date: Tue Oct 23 13:50:02 2001 -->
<pre>Date: Tue, 23 Oct 2001 12:16:41 -0500 (CDT) 
From: Gary Drake &lt;drake@fnal.gov&gt; 
To: Mary Convery &lt;convery@cdfsga.fnal.gov&gt; 
cc: kuhlmann@fnal.gov, byrum@fnal.gov, mlindgre@fnal.gov, 
        drake@fnal.gov 
Subject: Re: smxr for roman pots 
In-Reply-To: &lt;200110222037.PAA00676@cdfsga.fnal.gov&gt; 
Message-ID: &lt;Pine.GSO.4.31.0110231215150.21059-100000@fsui02.fnal.gov&gt; 
MIME-Version: 1.0 
Content-Type: TEXT/PLAIN; charset=US-ASCII 
Status: RO 
 
Hi Mary, 
 
It turns out that you did have a production version of the SMXR.  I 
believe that everything was up to date already.  We did not test it, as we 
have no way to do that with the change of drivers, but visually it looked 
OK. 
 
                                                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 
**************************** 
</pre>
<!-- Author: convery -->


<!-- Date: Tue Oct 23 13:51:21 2001 -->
<pre>SMXR back in fcal00</pre>
<!-- Author: convery -->


<!-- Date: Tue Oct 23 13:56:15 2001 -->
<pre>This morning we had surveyors begin measuring the position 
of the pots relative to (I think) the nominal beam position. 
When trying to move the pots from the MCR under the control  
of Craig Moore, it was found that the LVDT for pot 1 sticks 
and needs to be replaced.  Once it is replaced, we will try 
the survey again.</pre>
<!-- Author: convery, K Terashi, M Albrow -->


<!-- Date: Fri Oct 26 11:10:30 2001 -->
<pre>New power supply was installed in fcal00 a few days ago. 
Could not communicate with crate after yesterday's power  
outage but is ok now (?)</pre>
<!-- Author: convery -->


<!-- Date: Mon Oct 29 09:52:26 2001 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-13&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-13' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-14&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-14' width='300'></a></center>
<!-- Author: convery -->
<!-- Comment: Mon Oct 29 09;57;41 comment by...convery -->
<pre>On Friday, we swapped SMD-SMXR cables and took pedestals with
the cables attached to the instrumented SMDs.  In the plots 
above, recall that pedestals&gt;31 appear as range=1, ped=0.

Swapped cables to read out the instrumented SMD boards (which 
are connected to RP 3).  SMD boards for RP1, RP2 have no squids.

Pre-swap: RP3x -&gt; SMXR 4
          RP3y -&gt; SMXR 5
         (  1x         0
            1y         1
            2x         2
            2y         3 )

SMXR channels 0,2,3 have parity errors for all channels, range==7, ped==31
SMXR channel 1 has parity errors for some channels, range=6-7
SMXR channels 4,5 have no error bits set and have range 0-1

Swap 1: "3x" and "3y" cables going to SMXR 4,5 are disconnected
        "2x" cable (SMXR 2) connected to SMD from RP3x
        "2y" cable (SMXR 3) connected to SMD from RP3y
        "1x","1y" unchanged

SMXR channels 2,3 have parity errors for all channels, range==7, ped==31
SMXR channels 0,1 have no error bits set and have range 0-1
SMXR channels 4,5 have no error bits set and report the same ped for all
                  250 events (= ped of last event in previous run?)

Swap 2: "3x" and "3y" cables going to SMXR 4,5 are disconnected
        "1x" cable (SMXR 0) connected to SMD from RP3x
        "1y" cable (SMXR 1) connected to SMD from RP3y
        "2x","2y" back to SMD from RP2x,2y

SMXR channel 0 has parity errors for all channels, range==7, ped==31
SMXR channel 1 has parity errors for some channels, range=6-7
SMXR channels 2,3 have no error bits set and have range 0-1
SMXR channels 4,5 have no error bits set and report the same ped for all
                  250 events, identical to previous run

Spare: We tried the spare cable, but it was not connected to any SMXR channel!

Post-swap: back to original configuration
</pre>


<!-- Date: Thu Nov 8 08:53:42 2001 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-15&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-15' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-16&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-16' width='300'></a></center>
<!-- Author: convery -->
<!-- Comment: Thu Nov  8 08;55;51 comment by...convery -->
Pedestals taken last night after all tracer connections were
connected!!!!!

<!-- Comment: Thu Nov  8 09;09;41 comment by...convery -->
By the way, there is also a different cpu in this crate because
of some problem with the original one.


<!-- Date: Fri Nov 9 15:25:43 2001 -->
Tested the movement of the pots today with Mike Albrow and 
Craig Moore in the MCR, Ken and I in the tunnel.  The new LVDT  
for pot 1 seems fine.
<!-- Author: convery -->
<!-- Comment: Tue Nov 13 12;48;00 comment by...convery -->
<pre>From Mike Albrow:

We tested that all pots move with the LVDT's looking
sensible. Here are my notes:
Go to ACNET page S4, go to subpage 4.  One types the desired
position in the brackets &lt;-100&gt; and hits ENTER or left click, 
and it should go there.

           Outer Limit ("garage")(L)          Inner Limit (T)
TPOT1M      -919.9          L                    178.7    T
TPOT2M      -905.4          L                    188.1    T
TPOT3M      -906.9          L                    209.7    T
</pre>


<!-- Date: Wed Nov 14 10:08:04 2001 -->
Yesterday we had the pots surveyed with the help of Craig Moore. 
Mike and Koji observed how to move the pots from the control room 
and Ken and I were in the tunnel. 
<!-- Author: convery -->


<!-- Date: Fri Nov 16 18:10:14 2001 -->
<table><tr><td><a href=/elog/notebooks/roman_pots/Fri_Nov_16_2001_181000.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-26  align='top'></td><td>Here is the result of the Roman Pot survey.</a></td></tr></table>
<!-- Author: Ken -->


<!-- Date: Fri Nov 16 18:12:06 2001 -->
<pre> 
 Here is the result of the Roman Pot survey. For each Roman Pot, surveyers  
measured the position of 2 points (points A&B shown below) located on the back 
plane horizontally relative to the beam pipe center. We observed nice linear  
correlations between LVDT readouts and the measured positions. The chi-square 
values of the linear fits are about 0.4 - 1.3, assuming that errors of the  
measured positions are 0.005 (inch) (Surveyers told me that the repeatability 
on their measurements should be +/- 0.005").   
 I will try to find out the distance between the back plane and the fiber 
detector inside of the pots so that we can get to know the correlation between 
the LVDT readout and the position of the fiber detector. 
 
- Ken 
 
 Top View 
 ========  
                                                                        ^ 
        ------------         ------------         ------------          | X    
       |____________|       |____________|       |____________|         |     
         |        |           |        |           |        |           |     
  --------------------------------------------------------------------  |     
                                                          --&gt; CDF       +  
  --------------------------------------------------------------------  |    
         |        |           |        |           |        |           |   
        ------------         ------------         ------------          |    
       |    POT3    |       |    POT2    |       |    POT3    |          
        ------------         ------------         ------------            
         |========|           |========|           |========|            
         |========|           |========|           |========|            
         |========|           |========|           |========|            
        ------------         ------------         ------------           
       |            |       |            |       |            |          
        ------------         ------------         ------------   &lt;-- back plane 
         |--------|           |--------|           |--------| 
 
 Side View 
 ========= 
             __                   __                   __ 
           --  --               --  --               --  --  
         ----------           ----------           ---------- 
        -        A -         -        A -         -        A - 
       |            |       |            |       |            | 
       |            |       |            |       |            | 
        - B        -         - B        -         - B        -       
         ----------           ----------           ---------- 
           --  --               --  --               --  -- 
             
</pre>
<!-- Author: Ken -->


<!-- Date: Mon Nov 19 15:03:39 2001 -->
Santa came early this year with squids for the 2 smd boards  
for RP1.  Installed them today, pedestals look ok, will make 
plots soon.
<!-- Author: convery,terashi,snihur -->


<!-- Date: Tue Nov 20 11:55:21 2001 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-27&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-27' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-28&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-28' width='300'></a></center>
<!-- Author: convery -->
<!-- Comment: Tue Nov 20 12;02;09 comment by...convery -->
<pre>pedestals for RP1, smxr channels 0,1</pre>
<!-- Date: Tue Nov 20 11:56:39 2001 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-29&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-29' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-30&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-30' width='300'></a></center>
<!-- Author: convery -->
<!-- Comment: Tue Nov 20 12;03;21 comment by...convery -->
<pre>pedestals and rms for smxr channels 0,1,4,5 with hv off and on
(hv does not appear to affect these significantly)</pre>
<!-- Date: Tue Nov 20 11:58:09 2001 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-31&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-31' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-32&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-32' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-33&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=roman_pots&action=view&page=-33' width='300'></a></center>
<!-- Author: convery -->
<!-- Comment: Tue Nov 20 12;01;10 comment by...convery -->
<pre>from Ken:

Koji found out that the distance between the Roman Pot back 
plane used for the survey and the top of the tracking detector 
is 279.3mm.  So, now we know the relation between the LVDT
reading and the position of the top of the tracking detector
(relative to the center of the beam pipe).

At the point of LVDT=0, the top of the detector is about 1.2cm 
away from the center of the beam pipe. This is consistent with 
the value we have for Run 1C.


 P-Orbit  ---------------------------------------------------------------&gt;   B0


  Center of ----- - ----- - ----- - ----- - ----- - -----+------ - ---
a beam pipe                                              A
 _                                                       |
 P-Orbit  &lt;----------------------------------------------|-----------        B0
                                                         |
                                                         | RP1 : 1.15  cm
                                                         | RP2 : 1.18  cm
 8mm thick                                               | RP3 : 1.23  cm
 Scinti.                                                 |
   |                       (EVEN)                        |
   V                                                     V(Top of
                                          ++-------------+ the detector)
  +-+ - - - - - - - -- - - - - - - - - -  |              |
  | |      bin#:                          |              |
  | |  1 (Not effective)                  | Fib#: 1      |
  | |      -----       +--------------+   |              |
  | |  2               |              |   |              |
  | |      -----       |              |   +--------------+
  | |  3               |      2       |
  | |      -----       |              |   +--------------+
  | |  4               |              |   |              |
  | |      -----       +--------------+   |              |
  | |  5                                  |      3       |
  | |      -----       +--------------+   |              |


</pre>




<!-- Date: Tue Nov 20 15:07:39 2001 -->
<pre>Replaced 3A fuse in the smd crate which had apparently blown. 
For future reference, fuse is 3A, 250 V, stock # 1120-048000. 
I have one spare in my office. 
 
Symptoms were that error bits were set for all channels when I 
took pedestals using the standalone pedcal48.</pre>
<!-- Author: convery,terashi -->


<!-- Date: Tue Nov 27 15:12:09 2001 -->
<pre>seem to have lost power to the smd crate again... 
another blown fuse? 
presumably this is the cause of the done timeouts for the smxr 
in run control 
 
no access to the tevatron at this time or planned in the future</pre>
<!-- Author: convery -->


<!-- Date: Thu Nov 29 16:00:16 2001 -->
During the supervised access today, Koji and I power-cycled the 
fcal00 crate in the hope of recovering roman-pot readout. 
This solution was found for similar problems in the plug 
shower max crates: <A HREF=/cgi/elog/elog.pl?nb=2001&action=view&page=854>elog Tue Nov 27 17:34</A> 
<BR>But it did not do any good for us.  Problem is likely with  
the smd crate as surmised in the previous entry.
<!-- Author: convery -->


<!-- Date: Mon Dec 3 13:22:36 2001 -->
3A fuse was replaced last Friday by Koji and Mike Albrow. 
<P> 
According to Mike Lindgren, the plug smx smd crates which have 
7 smds with 12 squids each draw about 19A from the 7.5V power. 
Our crate uses different power supplies since there is no 400Hz 
power in the tunnel (we use 60Hz), but we should expect similar 
current draw which would be about 11A for the 4 smds we have 
instrumented now, and 16A for our future setup of 6 smds. 
<P> 
So it makes sense that the fuse has blown twice since we went 
from 2 to 4 smds full of squids. 
<P> 
The plan is to make sure that the wires connecting the power 
supply (through the fuse) to the crate have diameter at least  
as big as 12AWG.  If not, we should pull the newly populated smds 
out until the wires can be replaced.  Otherwise we should be able  
to use a larger fuse. 
<P> 
<BR> 
There appears to be a separate problem with the smxr in fcal00. 
Everything in calibrate mode (eg standalone pedestals using  
pedcal48) seems to work fine.  But results using data mode 
(where the ADC values are operated on using a lookup table on the 
smxr) are nonsense.  As far as I can tell, there seems to be a 
problem with loading or reading the lookup table. 
<P> 
We plan to pull the smxr when we get access to the collision hall 
and look at it in a teststand at Argonne.
<!-- Author: convery -->


<!-- Date: Mon Dec 3 13:26:52 2001 -->
<pre>note to self on smxr header words which are reported eg when  
running pedcal48: 
 
header words are reported as hex, the bits are as follows 
 
39804XX = 0000 0011 1001 1000 0000 0100 xxxx xxxx 
          -----------  ----------       --------- 
          board type   smd bits          bunch id 
                     ^           ------ 
       end cycle (EOC)           address 
                      ^  
                      data transfer (DTR) 
 
board type = 7 (smxr) 
address = 4 (slot) 
 
smd bits are set to 1 for each channel not sending data 
channels refer to smxr channel that smd is connected to and are  
  numbered 76543210 
we have no input to channels 6 and 7, so these bits should be 1,  
  but others should be 0 
 
when we lose power in the smd crate (eg blown fuse), all smd 
bits get set to 1, plus the end cycle bit gets set, so we see 
header works like  
3dfe4XX = 0000 0011 1101 1111 1110 0100 xxxx xxxx 
 
 
other notes from Steve: 
 
3d..4XX =&gt; DTR received but no EOC indicates problem with smd 
 
3b..4XX =&gt; no DTR indicates likely smxr problem, but could be 
  due to no smd end cycle from previous event 
</pre>
<!-- Author: convery -->


<!-- Date: Wed Dec 5 10:26:19 2001 -->
It appears that the fuse on the smd crate has probably blown  
again... no big surprise.
<!-- Author: convery -->


<!-- Date: Fri Dec 7 10:17:58 2001 -->
Last night, Koji and Rick Tesarek removed the SMXR from fcal00 
for repair.
<!-- Author: convery -->


<!-- Date: Thu Dec 13 08:17:43 2001 -->
Yesterday Koji and Michele made an access to the smd crate in the 
tunnel.  The gauge of the wires looks ok.  They replaced the 3A 
fuse with a 5A fuse and pulled out the 2 smd's for RP1.   
Eventually we will have 6 smd's in that crate which should draw 
>16A so we still have to replace the 5A fuse with a 20A one. 
<P> 
Our smxr was checked out at Argonne.  There appears to be nothing 
wrong with it.  It must be that I am completely inept at getting 
the damn thing to load a pass through lookup table and then read 
out in data mode.  
<!-- Author: convery -->


<!-- Date: Thu Dec 13 13:44:06 2001 -->
<pre>Yesterday we had a meeting with CDF operations guys regarding 
the procedure, testing, etc of inserting the roman pot detectors 
in close to the beam during collisions.  Present were Michele, 
Koji, Mary, Mike Albrow, Craig Moore, Nigel Lockyer, Jeff 
Spalding, Mike Lindgren, and Keith Schuh. 
 
Craig described the procedure used in Run I.  Once inserting 
the pots became routine, there was a script executed from the 
MCR which moved the pots to a given position after scraping at 
the beginning of each store. 
 
 
The following requests were made: 
 
1. Find out the location of the pbar beam (relative to the 
   position of the pots when they are moved in as far as 
   possible, also on the survey plot ie in LVDT position 
   coordinates). 
 
2. Figure out what is necessary for RP triggers.  Note that 
   any requirements at Level 2 (eg combining RP+jet cluster) 
   is likely impossible due to problems with L2. 
 
3. We should have some means (eg a script for ACNET) to quickly 
   pull out the pots from the CDF control room. 
 
   Also, we should have the pot positions in the data stream so 
   that when analyzing the data, we know exactly where the pots 
   were. 
 
4. We need a written procedure for inserting the pots. 
   Keith will obtain the procedure used by D0. 
 
 
In order to request a special run to test inserting the pots we 
need to: 
 
 -have a written plan (eg 1 hr at the end of a store to measure...) 
 
 -present this to CDF at a Thursday noon meeting 
 
 -there should also be some presentation/agreement with beams 
  division, and they and D0 should monitor losses, etc, during 
  our test 
 
 
Michele was going to present something at the noon meeting today.</pre>
<!-- Author: convery -->


<!-- Date: Fri Dec 14 09:23:44 2001 -->
<pre>From michgall@fnal.gov Fri Dec 14 10:10:01 2001 
Date: Fri, 14 Dec 2001 09:09:59 -0600 
From: Michele Gallinaro &lt;michgall@fnal.gov&gt; 
Subject: FW: roman pots (fwd) 
To: Konstantin Goulianos &lt;dino@rock16.rockefeller.edu&gt; 
Cc: Koji Terashi &lt;terashi@fnal.gov&gt;, Mary Convery &lt;convery@fnal.gov&gt;, 
   Michael Albrow &lt;albrow@fnal.gov&gt; 
MIME-version: 1.0 
Content-type: TEXT/PLAIN; charset=US-ASCII 
X-Authentication-warning: cdfsga.fnal.gov: michgall owned process doing -bs 
 
Hello, 
here below is attached the procedure D0 uses for moving the Pots. 
At this point we need to determine our `safe position'. 
 
At yesterday's meeting I asked for a special run. 
I asked for about one hour of colliding beams. 
 
At the meeting it was agreed we are going to move 
the Pots at the end of the store. 
As the RP move closer to the pbar beam we measure 
LOSTP,LOSTPB (both at CDF and at D0) and the rates 
in our counters. 
This can happen anytime in the next few days. 
Koji and I setup counters at the first floor in order to 
count rates from our PMTs. 
 
Please let me know if I forgot anything. 
 
Michele 
 
 
 
 
---------- Forwarded message ---------- 
Date: Fri, 14 Dec 2001 07:49:44 -0600 
From: schuh &lt;schuh@fnal.gov&gt; 
To: Michele Gallinaro &lt;michgall@fnal.gov&gt; 
Subject: FW: roman pots 
 
 
 
-----Original Message-----From: Andrew Brandt [mailto:brandta@fnal.gov] 
Sent: Thursday, December 13, 2001 6:13 PM 
To: schuh@fnal.gov 
Subject: roman pots 
 
 
Keith, 
Sorry for delay. Here is previous agreement, we will have a similar 
one in place for post shutdown any day--we have been reestablishing 
safe positions. As you probably know Mike Martens is in charge, 
and he is involved in D0 FPD project so is quite sympathetic towards 
pot motion and quite knowledgeable as well. 
Andrew 
 
************************ 
 
This agreement applies to Roman pot insertion from the period 9/14/2001 
to 10/8/2001. 
 
D0 plans to move the Roman pots in to standard positions most stores 
not earlier than one hour after the beginning of the store. 
The MCR and CDF will be notified before pot motion and when it is 
concluded. The initial positions would be  A1U=31.5 mm A1D=33.5 
P1U=26 P1D=26.5 with A1=A2 and P1=P2 (previously determined as safe 
positions), with the beampipe axis roughly at 45mm. Pot insertion 
will be done cautiously while monitoring losses allowing time to 
react to an unanticipated change in beam orbit. D0 should be notified 
of any planned changes in beam position. The pots will remain at these 
positions for most/all of the store retracting the pots prior to the 
beam being aborted or machine studies. 
 
Towards the end of the second store (t-4 hours) and some subsequent 
stores we plan to do studies to attempt to define closer operating 
positions (including initial dipole pot operating positions), 
since our acceptance is critically dependence on this. 
We would like to do these before any BD studies, which will require 
us to have the pots out and would render our default pot positions 
unreliable. Approval from BD run coordinator will be obtained 
prior to these studies. An acceptable new position for now is defined 
as one that does not increase the D0 losses by more than 10% and the 
pots will be retracted if CDF complains about high losses related 
to pot motion. 
 
 
</pre>
<!-- Author: convery -->


<!-- Date: Tue Dec 18 07:48:44 2001 -->
<pre>From albrow@fnal.gov Mon Dec 17 19:14:26 2001 
Date: Mon, 17 Dec 2001 17:32:31 -0600 
From: Mike Albrow &lt;albrow@fnal.gov&gt; 
Subject: Beams Division contact 
To: koji terashi &lt;terashi@fnal.gov&gt;, michele gallinaro &lt;michgall@fnal.gov&gt;, Mary Convery &lt;convery@cdfsga.fnal.gov&gt;, hatake@fnal.gov 
Cc: Craig Moore &lt;damon@fnal.gov&gt;, mike albrow &lt;albrow@fnal.gov&gt;, chuckb &lt;chuckb@fnal.gov&gt; 
As you know, Craig Moore of Beams Division has been part of the "roman pot team" in Run 1 
and his collaboration has been highly valued. He now has major new  
reponsibilities for external beams including NUMI, MiniBoone etc and he  
cannot continue to spend any significant time on the pots. (I'm sure  
he'll be willing to answer questions if the answer is to hand). We owe Craig a great 
deal for his support. Chuck Brown 
chuckb@fnal.gov  3202 also of Beams Division has kindly agreed to  
provide some help with beams related issues. But he is also involved in  
several projects and is very busy, so please take that into account! 
                   Mike 
 
</pre>
<!-- Author: convery -->


<!-- Date: Fri Dec 21 13:28:08 2001 -->
Last night, Koji and I reinstalled the SMXR.  The board is very 
hard to push all the way into its slot, but the lights came on 
so presumably it is seated properly.  I didn't have time to test 
it last night... it will have to wail till I am back from 
vacation I guess.
<!-- Author: convery -->


<!-- Date: Wed Jan 9 12:41:20 2002 -->
Replaced fuse in smd crate with 15A fuse and reinserted the 
smd boards for pot 1.  We will still need a larger fuse (20A)  
when we have the smd's for pot 2 instrumented with squids. 
<P> 
Also, Paul Czarapata from Beams Division accompanied us and 
verified that power to the pot motors is delivered safely with 
fuses, etc.  He said it is a standard setup.  By the way, the 
crate containing the power supply for the motors is in the 
A4 building, through the door to the right of the tunnel  
entrance.  The crate is clearly labeled.
<!-- Author: convery, terashi -->
<!-- Comment: Wed Jan  9 15;04;19 comment by...convery -->
Also, when taking standalone pedestals earlier this morning, I 
was seeing different numbers of events reported for the different
capacitors.  All cap0's had the same number of events reported,
etc, but this number was not the same as for the cap1's, and
none were the expected number.
This is fixed now, either due to power-cycling the SMXR crate,
which we did first, or power-cycling the SMD crate in the tunnel
when we replaced the fuse and reinserted the boards.
I didn't have a chance to take pedestals in between.  I would
guess that it was probably the SMXR crate that did the trick.
<!-- Date: Wed Jan 9 14:42:30 2002 -->
<pre>From pcceed@fnal.gov Wed Jan  9 15:32:24 2002 
From: pcceed@fnal.gov 
Date: Wed, 09 Jan 2002 14:31:06 -0600 
Subject: Inspection of CDF Roman Pots 
To: Schuh@fnal.gov, Winslow Baker &lt;winbaker@fnal.gov&gt;, Convery@cdfsga.fnal.gov 
MIME-version: 1.0 
Content-type: text/plain; charset=US-ASCII 
Content-transfer-encoding: 7BIT 
Content-description: Mail message body 
Priority: normal 
 
Dear All; 
        I inspected the installation of the CDF Roman Pots this morning  
with Mary Convery and Koji Terashi of CDF.  The installation meets all  
Fermilab electrical safety requirements.  I would recommend that ORC  
approval be granted for this system. 
                                        Paul Czarapata - Beams Div. 
</pre>
<!-- Author: convery -->



<!-- Date: Thu Jan 10 18:34:37 2002 -->
<pre>This afternoon I checked the RP positions in ACNET because I was 
asked by a guy in Beams Division to verify that the pots are in 
the home positions. But, the ACNET reading positions were 
different for all three pots from what we should have at the home 
positions. They should be around -900 mils but they were about 0 
mils. A strange fact was that ACNET also showed that all three 
pots were at the outside limits (marked as "L"), although their 
readings were not what they should be.  
 
Anyway, Mike Albrow and I went in the MCR and tried to move the 
pots but they didn't move. We called Craig and we three went in 
the tunnel to inspect the pots. All three pots were actually in 
the home positions (outside limits), but we found that a cable 
for the LVDT is damaged at the connector to the pot #1 (closest 
pot to B0). 
 
Now we cannot move all three pots for some reason. Craig 
suspects that the damage on this cable could have affected LVDT 
readings for all three pots, but we are not sure.</pre>
<!-- Author: Koji -->


<!-- Date: Mon Jan 14 14:01:33 2002 -->
Work last week on RP readout: 
<P> 
I was having the same problems as before until Jimmy Proudfoot stepped into my 
office.  Then, magically, <i>dd48bypass</i> loaded and read back a by-pass 
lookup table instead of all zeros.  No explanation as to why I get zeros 
every other damn time I run it.  Either Jimmy is blessed, or our SMXR doesn't 
like me.  I suspect the latter.  (Note, I accidentally ran <i>dd48bypass</i> 
without the <i>-g4</i> slot info immediately before it worked correctly.   
I'm not saying this had any effect, but I record it here just in case, since  
the whole deal doesn't make any sense.) 
<P> 
We then ran <i>calib-smsquid</i>, which returned something other than all 
zeros, but we got range=7 for everything.  I don't remember why Jimmy said  
this was. 
<P> 
<i>peddat48</i> still gave huge pedestals (eg 300) but Jimmy says this makes 
sense: peddat wants correct values (from a calibration) in the LUT, not a 
bypass table. 
<P> 
<i>SMCcal48</i> looks ok.  My understanding is that this means the SMXR-SMC 
communication is ok. 
<P> 
Then we modified <i>pedcal48</i> (<i>pedcal48_test</i>) to enable the dac. 
(This is calib mode (no LUT), looks at ADC, range, channel, rather than value.) 
We ran <i>pedcal48_test</i> after setting the dac to 32767 and then 34000, 
and the results look ok. 
<P> 
The conclusion from the above is that the electronics seem to be fine. 
That is, not just the boards, but our whole setup.  I think. 
<P> 
So..... we need to successfully calibrate using the front-end readout code, 
which puts the correct calibration constants into the LUT. 
<P> 
Tried this, then ran <i>fstore32_smxr_lut</i> to dump the LUT contents into 
a file.  Got zeros, which usually means the fits failed. 
<P> 
The diagnostic file which was supposed to get written to 
/cdf/code-common/cdfonline/smx_calib/smcalibb0fcal00.txt 
did not get written.  Apparently, run control was unable to open the file. 
Arnd will look into this when there is no beam and he can use the crate.
<!-- Author: convery -->


<!-- Date: Tue Jan 15 13:34:16 2002 -->
<pre>Let's go to next page, OK Mary?</pre>
<!-- Author: Koji -->
<!-- Comment: Thu Jan 17 10;39;23 comment by...convery -->
yes!