<!-- Title: 17:31:27  Thu May 30 2002 -->
<!-- Crewchief: The Silicon group -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>Waiting for the access. 
Getting ready for it. 
Hopefully a good store tonight.</pre>


<!-- Date: Fri May 31 00:22:29 2002 -->
Well, the store is pretty good tonight, but the CDF DAQ is having  
some problems.  There is really no point yet in integrating  
silicon until the general problems are fixed.
<!-- Author: Jason -->


<!-- Date: Fri May 31 01:11:55 2002 -->
<pre>Silicon is integrated after the DAQ problems were fixed (see  
main E-log).  No spikes in any of the relevant ACNet variables. 
The B0PLOS and B0ALOS variables are broken in ACNet, but we are 
using LOSTP and LOSTPB.  Don't want MCR to reset their crate to 
recover B0PLOS and B0ALOS because we would lose all monitoring. 
</pre>
<!-- Author: Jason -->

<!-- Date: Fri May 31 06:44:54 2002 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 158
Calibration type  : standard
Run period tag    : May_2002
DPS-off run       : 145539
DPS-on run        : 145538
Requested by      : Sungwon
Main process id   : 6016160
Comment           : magnet on
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->


<!-- Date: Fri May 31 12:06:11 2002 -->
<p><font size=+1> D-mode Calibration Job Finished </font>
<p><pre>
This is a computer-generated silicon D-mode calibration status report.
Silicon D-mode calibration job 158 finished successfully.

Job info
--------
Calibration type : standard
DPS-off run      : 145539
DPS-on run       : 145538
Requested by     : Sungwon
Submitted        : 2002-05-31 04:44:37
Completed        : 2002-05-31 10:05:21
Status           : SUCCESS
Comment          : magnet on
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->



<!-- Date: Fri May 31 20:11:43 2002 -->
<h3>Ack!</h3> <a href= 
'/cgi/elog/elog.pl?nb=2002&action=view&page=453&frame=2&anchor=19:46:57'>Done Timeouts</a>!  This indicates a problem with the VRB.  Seems it recovered this time, but<B>if it persists at an intolerable frequency</b> we'll need to either remove the wedges e120/e130 and.or replace the Vrb.  I would suggest the former until I can get there and perform the latter.  We will also very soon need to rectify the spare VRB  
situation (there are 4 "unknown problem" VRBs at FCC).
<!-- Author: SCN -->


<!-- Date: Fri May 31 20:48:34 2002 -->
<B>Ack!  Power problems!</B> 
<BR> 
Portcard was found in OFF state on LB1W3, so ladder was turned off as well by GUI.  At the same time IB4W4,5 were off.  I tried to have the ace turn these back on, but he got a handshake error.   
Steve says this was probably because DAQ was not in HALT, START, or IDLE state. 
<BR> 
Everything seems OK now.  
<!-- Author: Jason -->


<!-- Date: Sat Jun 1 07:07:31 2002 -->
<b>Ack Ack</b><br> 
<a href= 
'/cgi/elog/elog.pl?nb=2002&action=view&page=454&frame=2&anchor=07:00:00'>Fibs crashed</a> when Marco 
started trying to download pedestals.  I'll need to look at 
this in more detail, so they'll page me when they turn off the HV (thus ending physics). 
<!-- Author: SCN -->


<!-- Date: Sat Jun 1 10:19:15 2002 -->
 Caenet_write: Error number -1 ffffffff received 
group_info:cr_n = 12, response = -1 
 Caenet_write: Error number -1 ffffffff received 
group_info:cr_n = 12, response = -1 
 Caenet_write: Error number -2 fffffffe received 
group_info:cr_n = 12, response = -2 
 
Then all ladder listed below had the following message. 
 
L00 B1W2L5 spontaneously turned off 
turning it back on 
Sending Request for fa25 
Timeout 
ERROR: not all Fibs are initialized 
ERROR: FIB initialization, ps_n = 8SetChannelStatus, err = -1 
checkSt[0][8][5] = 1 
 
List fo ladders that went OFF: 
 
Ladders			  CAEN CRATE	SLOT 
LB1W2L5-3-2-1-0		  12		9 
LB1W3L5-3-2-1-0		  12		7 
IB4W4L5-4-2-0		  12		1 
IB4W5L5-4-2		  12		3 
IB5W2L5-4-3-2-1-0	  12		5 
 
There is nothing else on crate 12. 
I believe that crate 12 went OFF and then in a ladder by ladder  
basis the GUI tried to bring it back to ON but the status of RC  
was such that the Handshake failed. 
 
This once again sounds like a failure correlated with the CAEN  
CRATEs Interlock system that was implemented to protect us  
against the MICREL failure mode of the PS modules. 
 
Here is a list of correlated entries 
<a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=107&frame=2&anchor=05:29:24'> 
other entry about crate 12 </a>  
 
One more 
<a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=109&frame=2&anchor=09:50:43'> 
One more about crate 12 </a>  
 
One more 
 
 
<a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=98&frame=2&anchor=19:14:00'> 
Another Simila Entry </a>  
 
One more 
<a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=100&frame=2&anchor=00:42:16'> 
One more </a>  
 
One more 
 
<a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=109&frame=2&anchor=11:48:55'> 
One more </a>  
 
 
One more 
 
<a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=101&frame=2&anchor=18:28:18'> 
Installation of CAEN crates interlock was on Mar 7 </a>   
<!-- Author: Gino -->


<!-- Date: Sat Jun 1 10:20:49 2002 -->
<pre>Same entry as above without the link but in a mor readable format. 
This is a follow up of the power problems that Jason had last night. 
 
 Caenet_write: Error number -1 ffffffff received 
group_info:cr_n = 12, response = -1 
 Caenet_write: Error number -1 ffffffff received 
group_info:cr_n = 12, response = -1 
 Caenet_write: Error number -2 fffffffe received 
group_info:cr_n = 12, response = -2 
 
Then all ladder listed below had the following message. 
 
L00 B1W2L5 spontaneously turned off 
turning it back on 
Sending Request for fa25 
Timeout 
ERROR: not all Fibs are initialized 
ERROR: FIB initialization, ps_n = 8SetChannelStatus, err = -1 
checkSt[0][8][5] = 1 
 
List fo ladders that went OFF: 
 
Ladders			  CAEN CRATE	SLOT 
LB1W2L5-3-2-1-0		  12		9 
LB1W3L5-3-2-1-0		  12		7 
IB4W4L5-4-2-0		  12		1 
IB4W5L5-4-2		  12		3 
IB5W2L5-4-3-2-1-0	  12		5 
 
There is nothing else on crate 12. 
I believe that crate 12 went OFF and then in a ladder by ladder  
basis the GUI tried to bring it back to ON but the status of RC  
was such that the Handshake failed. 
 
This once again sounds like a failure correlated with the CAEN  
CRATEs Interlock system that was implemented to protect us  
against the MICREL failure mode of the PS modules. 
</pre>
<!-- Author: Gino -->


<!-- Date: Sat Jun 1 16:52:48 2002 -->
Spent awfully way to much time looking into the Broker Memory 
issues which caused  
<a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=111&frame=2&anchor=07:07:31'> 
Crashing Fibs</a>.  It seems that when using the broker, smartsockets eats some memory which is never returned 
<li> in the call to read the large message, you loose about 1 MB 
<li> Subsequently in the calls to put the HDI sub messages in 
the Fib Message (for each Fib in the crate) you loose 350 kB/Fib, 
which with 9 Fibs is another 3 MB and change. 
If this happens twice, well, the fib is bye bye!</ul> 
 
The odd thing is that when you do not download pedestals (and even sometimes when you do) the second effect does not occur.  To me it seems like some internal smartsockets stuff is not properly 
freeing memory from incoming binary data (the peds) and subsequently screws up the freeing of the  
outgoing submessage data.  I will seek help from the experts.  
<!-- Author: SCN -->


<!-- Date: Sun Jun 2 15:19:56 2002 -->
<pre>Store 1401 was dumped at 14:58. 
Silicon still COLD-START and ACITVATE OK. 
We now have 2 OPTIONS: 
1. A LOW LUMINOSITY STORE starting at 5:00 pm  
2. NO more stores untill the end of the access in the middle of JUne. 
For both of this scenarios the Silicon Will be OFF. 
We are trying to do Silicon D-mode Calibrations with BEAM OFF 
but there is NOT YET GUARANTEE of QUIET TIME for the necessary 40 minutes. 
 
</pre>
<!-- Author: Gino -->
<!-- Comment: Sun Jun  2 15;21;21 comment by...Gino -->
<pre>Arndt and Rob Roser will be here shortely to decide on what to do.
</pre>

<!-- Comment: Sun Jun  2 16;19;44 comment by...Gino -->
<pre>DRIVEN BY THE BEAM DIVISION there is NOT going to be another 
store Untill the end of the access.
I'm taking D-MODE calibration with BEAM OFF and MAGNET OFF.
(This is what I can do)
Eva will be in at 5:00 pm to warm up the Silicon.
This task should be finished by 8:00 pm.
</pre>

<!-- Date: Sun Jun 2 16:41:53 2002 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 159
Calibration type  : standard
Run period tag    : Jun_2002
DPS-off run       : 145682
DPS-on run        : 145681
Requested by      : Turgun, Ming, Minsuk
Main process id   : 15117304
Comment           : Beam off, magnet off
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->



<!-- Date: Sun Jun 2 16:49:27 2002 -->
<pre>D-mode Calibrations finished. 
I just turned the Silicon OFF. 
</pre>
<!-- Author: Gino -->


<!-- Date: Sun Jun 2 19:49:19 2002 -->
<pre>Warming up the Silicon we did some test with 2 AVDD2 ladders  
without any outcome. 
Now even those 2 wedges are OFF. 
I turned OFF the 2 switches for the 5V enable. 
Steve is coming in tonight to test SB2 before the FIB swap. 
</pre>
<!-- Author: Gino and Eva -->


<!-- Date: Sun Jun 2 20:19:46 2002 -->
<h3>Pre Access Stuff</h3> 
CAENvolts file before we start messing with things is:<BR> /cdf/code-common/cdfonline/caencontrol/devel/caenvoltsfiles/CAENvolts_06022002_0546PM.dat<BR> 
Now I am going to mess with things.
<!-- Author: SCN -->

<!-- Date: Sun Jun 2 21:24:19 2002 -->
<p><font size=+1> D-mode Calibration Job Finished </font>
<p><pre>
This is a computer-generated silicon D-mode calibration status report.
Silicon D-mode calibration job 159 FAILED.

Job info
--------
Calibration type : standard
DPS-off run      : 145682
DPS-on run       : 145681
Requested by     : Turgun, Ming, Minsuk
Submitted        : 2002-06-02 14:41:05
Completed        : 2002-06-02 19:22:36
Status           : FAILURE
Comment          : Beam off, magnet off

Last processing stage reported : comparing to the reference calibration
Failure diagnostics :
The calibration failed the following reference comparison criteria:

             Cut Name    Sensor Set   Cut Value   Data Value
---------------------    ----------   ---------   ----------
       config abs max    L00          0.25        1         
  dps_off_ped abs max    SVX_PHI      0.5         2.85047   
  dps_off_ped abs max    SVX_Z        0.5         2.51683   
dps_off_noise rel max    SVX_PHI      0.025       0.032376  
dps_off_noise rel max    SVX_Z        0.025       0.031033  
 dps_on_noise rel max    SVX_PHI      0.02        0.024538  
     bad_chan rel max    SVX_Z        0.25        0.5193    

Reference calibration runs are 144554 (DPS off) and 144555 (DPS on)
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->



<!-- Date: Sun Jun 2 21:48:56 2002 -->
<pre>Began warm up of the silicon at ~6:30pm. 
We were running at 6C and are now at 16C. 
 
Changed trip limits to: 
	SVX		ISL		L00 
BH	15->25		CC	18->25	SIL	15->25 
DOIMs	20->25		CPC	15->25	Hybs	15->25 
PCW1A_2 28->30		blocked	33->35 
DDRs	20->25		CC's 
 
By the way, the SVX PT_COT_PCW (pressure at COT face) dropped a  
little to 5.7 psia since they are flushing the COT (low warning is at 6 psia).   
Roser and I increased the flow from 80% to 82% for now.   
Didn't make much of a difference, although it seems  
to be stable at 5.7 now.</pre>
<!-- Author: Eva H. -->
<!-- Comment: Mon Jun  3 11;17;46 comment by...Everybody -->
<h1>June 2002 Access Starts Here</h1> for future e-log clarity and searches
<!-- Date: Mon Jun 3 01:33:19 2002 -->
<h1>SVXII Bulkhead 2 Survey</h1> 
We want to swap the Fibs in SVXII BH 2 with new  
uberFibs with <ul> 
<li> an elongated front end Clock, ala ISL, to help tripping 
<li> a more tolerant view toward wayward OBDV duty cycles 
</ul> 
Before we did this, we wanted to run through this bulkhead and see what tests succeed and what fail, so we can compare 
before cooling down after the access.Here's what we got: 
    <h3>Turned online</h3> 
    <table>  
      <tr> <th>Ladder <th> Reason </tr> 
      <tr> <td>SB2W5L0 <td> OBDV/RF </tr> 
      <tr> <td>SB2W5L4 <td> ???? </tr> 
      <tr> <td>SB2W9L4 <td> AVDD2 </tr> 
      <tr> <td>SB2W6L4 <td> OBDV </tr> 
      <tr> <td>SB2W7L4 <td> OBDV </tr> 
      <tr> <td>SB2WAL1 <td> DVDD OVC </tr> 
      <tr> <td>SB2WAL2 <td> DVDD OVC</tr> 
      <tr> <td>SB2WAL3 <td> DVDD OVC</tr> 
    </table> 
    <h3>Fib to Vrb</h3> 
    Tested all Links, 10000 events x 4 kB/chan OK 
    <h3>Fib by Fib</h3> 
    <ul> 
      <li> SB2W0/W1- b0fib00 SL 17  S/N 148 <ul> 
	  <li> All Init OK 
	  <li> Took some runs (2133, 2134) with readout length 32 (whoops) 
	  <li> Run 2135 STBY, DPS ON, NN thresh 8.  Saw <ol> 
	      <li> SB2W0L3 Chip 1 Cap ID bit 3 high 
	      <li> SB2W1L1 Chan Out of Sequence bit 2 
	      <li> SB2W1L4 Illegal Chan 237 = 0xee 
	    </ol> 
	  <li> Turned on Bias ok but <BR><B><FONT COLOR=RED>SB3W0L2  
		reads back 7.8 V on Bias, no current, GUI gives alarm</FONT></B> 
		Remember in the back of my head that this may be "touching" SB2W0L2, 
		as it goes away when I turn off Bias.  HAve to restart GUI, too. 
	  <li> HST, 100k Events no Error 
	  <li> Run 2140 to file, RA, STBY, DPS ON 1k events no error 
	  <li> Run 2141 to file, NN thr=3, STBY, DPS ON, 1k events saw<ol> 
	      <li> SB2W0L3 Chip 1,3 Cap ID bit 3 high 
	      <li> SB2W1L1 OO Seq Bit 2 
	      <li> SB2W1L3 OO Seq Bit 5  
	      <li> Not Chip ID a few times on 
		SB2W0L1,SB2W0L3,SB2W0L4,SB2W1L0,SB2W1L4 
	    </ol> 
	</ul> 
      <li> SB2W2/W3- b0fib00 SL 18  S/N 135 <ul> 
	  <li> SB2W3L1 Fails to read back, all 0s, The rest are OK 
	  <li> Run 2142 RA STBY DPS ON to file<ol> 
	      <li> SB2W3L1 Screws up data after Chip a2 (Chip a2 all 0s) Suspect 
		AVDD2 
	    </ol> 
	  <li> Run 2143 NN thr=2 STBY DPS ON to file<ol> 
	      <li> SB2W2L3 Lots of "Not Chip ID"  
	      <li> SB2W3L1 Screws up data after Chip a2 (Chip a2 all 0s) Suspect 
		AVDD2 
	    </ol> 
	  <li> <B>dealing with FILE SPACE issues takes a long time</b> 
	  <li> Attempt HST, but several ladders (Chan 0, Chan 1 at least) show 
	    "00f3" problem 
	   <li>  Notice that temp is getting high (23 deg.) so turn off ladders 
	    for a bit (after restarting GUI once) 
	  <li> Reattempt HST, get "00f3" on all ladders 
	  <li> DAQ  Run 2147 like 2143 see 00f3 on SB2W3L1. 
	  <li> Temp is high again (22) so I turn off these guys and go on 
	</ul> 
      <li>SB2W4/W5- b0fib02 Sl 17 S/N 156 <ul> 
	  <li>All init OK 
	  <li>Run 2151 RA DPS ON <ol> 
	      <li> SB2W5L0 OO Seq/CAP ID Bit 2 stuck 
	      <li> A few "Not Chip ID" errors on SB2W4L1,2,3 
	    </ol> 
	  <li>Run 2152 NN Thr=5 DPS ON<ol> 
	      <li> SB2W5L0 OO Seq/CAP ID Bit 2 stuck 
	      <li> SB2W4L4 CAP ID errors Chip 1 only (off by random amount) 
	    </ol> 
	  <li>HST <ol> 
	      <li> SB2W5L0 NOT SUBJECTED TO TEST 
	      <li> 00f3 on Chan 0 immediately, infrequently on Chan 1 
	      <li> Problems on rest as well, again temp is 22 C 
	    </ol> 
	</ul> 
      <li>SB2W6/W7- b0fib02 Sl 18 S/N 118 <ul> 
	  <li>All init OK 
	  <li> Run 2154 RA STBY DPS ON <ol> 
	      <li> SB2W6L4 OO Seq/CAP ID  (Maybe OBDV swaps Chan and Data) 
	      <li> SB2W7L1 OO Seq Bit 1 
	    </ol> 
	  <li> Run 2155 NN thr=5 STBY DPS ON <ol> 
	      <li> SB2W6L4 OO Seq/CAP ID  (Maybe OBDV swaps Chan and Data) 
	      <li> SB2W7L1 OO Seq Bit 1 
	      <li> SB2W6L3 Occassional 00f3 
	      <li> SB2W7L4 Random OO Seq, "d0d0"  
	    </ol> 
	  <li> Won't attempt HST 
	</ul> 
      <li>SB2W8/W9- b0fib02 Sl 19 S/N 140 <ul> 
	  <li>All init OK 
	  <li> Run 2158 RA STBY DPS ON-All ok 
	  <li> Run 2159  NN thr=5 STBY DPS ON Saw very rare but interesting errors <ol> 
	      <li> Not Chip ID SB2W8L1, SB2W9L0, SB2W9L1 
	      <li> c1c4 instead of Fib ID SB2W9L0, SB2W9L1 
	    </ol> 
	  <li> Temp was at 28.5, Trips at 30, so I turned them off briefly  
	  <li> HST gives lots and lots of 00f3. Temp at 22.9. 
	</ul> 
      <li>SB2WA/WB- b0fib00 Sl 19 S/N 129 <ul> 
	  <li>SB2WBL0 reads back 00s on init-All others OK 
	  <li> Run  2161 RA STBY DPS ON- All OK 
	  <li> Run  2162  NN thr=5 STBY DPS ON-All OK 
	</ul> 
    </ul> 
All these runs and error logs are saved in /cdf/svx/data1/daq/anywhere/data 
so that we can go back and look again, perhaps run them through daqana for 
digitial errors, etc. 
 
<P> 
All PS are now disabled in IFIX and the kill switches are 
thrown.  Time to sleep.
<!-- Author: SCN -->


<!-- Date: Mon Jun 3 09:17:49 2002 -->
<h1>Power outage from 0700 to 0730</h1> 
<p> 
Chiller backup pumps kicked in as designed (finally).  Power 
outages perturb the system enough to cause a flow trip, so 
the detector supply valves closed.  All that needed to be 
done to get flow to the detector again was to acknowledge the 
trips and re-open the valves.  Once power returned, the chillers 
were restarted in normal operation mode.</p> 
<p> 
GUI and all monitoring programs restarted on dap42/43 once 
online cluster was back.  Silicon is still OFF.</p>
<!-- Author: Andy H., Eva H. -->


<!-- Date: Mon Jun 3 09:47:13 2002 -->
<pre>Change made to interlock code: 
 
For ISL blocked cooling lines only, while lasering 
is going on the next two weeks. 
 
"Uber-trip" limits for these RTD's changed to: 
 if(max_blocked_temp > settable_limit + 15 OR 
    max_blocked_temp > 50) then trip  
 
BEFORE it was: 
if(max_blocked_temp > settable_limit + 2 OR 
    max_blocked_temp > 35) then trip  
 
In other words, since the max allowed settable limit is 
35C,  the uber-trip is essentially set to 50C while 
laser work is going on. 
 
</pre>
<!-- Author: Eva H. -->


<!-- Date: Mon Jun 3 10:13:45 2002 -->
<pre>5 V Enables fro SVXII and ISL turned ON from OFF. 
</pre>
<!-- Author: Gino -->


<!-- Date: Mon Jun 3 11:16:37 2002 -->
<h3>Fibs Removed, Map algorithm altered</h3> 
Removed Bulkhead 2 Fibs from crates for uberFib modifications.  I also turned off these fibs in the HDWDB and 
<B>I modified the BootLoading procedure to mind all HDWDB flags, which means if at time of boot your HDI/Fib/Crate is OFFLINE, 
you will not get a handshake for it.</B>  This is because some 
Fibs are no longer present.  It is my understanding we were going 
to flip all HDIs online for the access.  <B>If you do not 
get a handshake:<ul> 
<li> Edit the HDWDB to turn your object online 
<li> execute: setup fer; java si_ss.CrateLoader FIB_(ISL/SVX)_(00-07) 
</ul></B> 
This redownloads maps appropriately (or it should). 
<table> 
<tr> <th> Crate <th> Slot <th> Wedges <th> PREP <th> SN </tr> 
<tr> <td> b0fib00 <td> 17 <td> SB2W0W1 <td> 550972 <td> 148 </tr> 
<tr> <td> b0fib00 <td> 18 <td> SB2W2W3 <td> 560620 <td> 135 </tr> 
<tr> <td> b0fib00 <td> 19 <td> SB2WAWB <td> 560614 <td> 129 </tr> 
<tr> <td> b0fib02 <td> 17 <td> SB2W4W5 <td> 550965 <td> 156 </tr> 
<tr> <td> b0fib02 <td> 18 <td> SB2W6W7 <td> 560602 <td> 118 </tr> 
<tr> <td> b0fib02 <td> 19 <td> SB2W8W9 <td> 560625 <td> 140 </tr> 
</table>
<!-- Author: SCN -->
<!-- Comment: Mon Jun  3 12;14;28 comment by...SCN -->
<h3>Fine already</h3>
Due to complaints, I modified this behaviour somewhat.  The
Bootloader will now not download for <B>Fibs or Crates</B> marked
OFFLINE in the hdwdb, but it will ignore the ONLINE flag
for HDIS.  So you might have to turn flags back on for Fibs or
Crates, but not for HDIs, to get the maps right.
<!-- Date: Mon Jun 3 11:30:57 2002 -->
<pre>The WEST side Silicon racks (CAEN and FIB CRATES) will be POWERED ON not sooner than 3:00 pm. 
</pre>
<!-- Author: Gino -->


<!-- Date: Mon Jun 3 12:09:33 2002 -->
<pre>I've just returned to the B0 silicon cabinet (in the assembly 
hall), the articulating borescope we use to inspect juntion 
cards.  We share it w/ several other groups at FNAL, so I just 
got it back last week.  At any rate, you'll find it in it's  
usual spot downstairs. 
 
</pre>
<!-- Author: - Doug -->



<!-- Date: Mon Jun 3 14:43:10 2002 -->
<pre>Examining LB1W1L1.  This channel initializes  
correctly, but all readouts give c2c2.   
Re-verified this behavior and verified that 
LB1W1L0 initializes and runs perfectly. 
Swapped L0 and L1 (HDI 5,6) at FTM.  After 
swap, problem stays in pipe 6.  Conclude problem 
is in FTM (likely RX?) </pre>
<!-- Author: ADF -->
<!-- Comment: Mon Jun  3 14;47;07 comment by...ADF -->
<pre>Lester promised to swap them back, hopefully he'll make an
entry when he does.</pre>
<!-- Date: Mon Jun 3 14:46:19 2002 -->
<pre>PS GUI idiosyncracy (sp?) 
 
 If a wedge has several ladders turned on, but not 
all of them, then if you turn off the wedge using 
PSXX to OFF, it turns off the ladders but not the 
Portcard.</pre>
<!-- Author: ADF -->
<!-- Comment: Mon Jun  3 15;30;34 comment by...SCN -->
Yes, welcome back!


<!-- Date: Mon Jun 3 15:31:26 2002 -->
As Bore Access has been accelerated, we defer splitting the 
DAQ into an EAST and WEST side until tomorrow morning.
<!-- Author: SCN -->


<!-- Date: Mon Jun 3 16:38:39 2002 -->
<h3>Download Maps change</h3> 
I changed the way "Download Maps" works so that it ignores which 
channels are enabled/disabled and just downloads the maps for all 
HDIS defined for that FIB.  This is more in line with decoupling 
"what is attached to what" with "what we want to read out".
<!-- Author: SCN -->

<!-- Date: Mon Jun 3 16:59:19 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W1 L4 
<li>problem n: 83 
<li>Action: LV_cable
<li>entered by: bolla 
<li>description is: <pre>Measured resistance on AVDD4=1040 Ohms, AVDD3=1040 Ohms and AVDD2=1040 Ohms.</pre> </ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Jun 3 17:03:57 2002 -->
Probably should've mentioned earlier this morning that the 
supply valves for ISL CCE1 and SVX PCW were increased to 70% 
and 90%, respectively (default values: 65% and 80%).  This 
keeps flows and pressures at a healthy level when running warmer.
<!-- Author: Andy H. -->


<!-- Date: Mon Jun 3 18:06:37 2002 -->
<pre>Installed and LB tested a PS in IB3W0.  Also LB tested IB3W1, IB3W2, and IB2W2.  All are good-to-go.</pre>
<!-- Author: Napora, Herndon, and Hill -->

<!-- Date: Mon Jun 3 18:40:19 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W3 All 
<li>problem n: 452 
<li>Action: Bore_work
<li>entered by: bolla 
<li>description is: <pre>Pushed in the JC (it moved by 1 mm) but the symptoms stay the same.</pre> </ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Jun 3 18:52:16 2002 -->
<pre>East Bore Access to fix JC problems: 
 
Slit baggy. 
 
IB5W4: 
 
Examined JC, 90 pin connection found with 
boroscope to be intact. 
Pushed on JC, connection felt solid. 
Examined other connectors optically and could not detect any 
problems. 
Did not test electrically due to cooling work. 
 
Conclusion: LV cable damage? Gino should add this to his list. 
 
SB3W3: 
 
Examined JC, 90 pin connection found with 
boroscope to be intact. 
Pushed on JC, moved ~ 1mm. 
Examined other connectors optically, pushed on sense cable a bit. 
Tested electrically, 2VDOIM trips as before. 
 
Conclusion: Gino should add this to top of his list. 
 
Told Rob to resume gas purge. 
Told Rich Stanek to begin draining ISL cooling on East. 
Called Doug to let him know lasering should begin @ 12:00AM. 
Turned ISL/L00 interlocks inactive. 
Turned off ISL/L00 5V enable.</pre>
<!-- Author: Chris Hill -->


<!-- Date: Mon Jun 3 19:19:15 2002 -->
<pre>5V enables (ISL and SVXII) turned OFF 
Interlock (SVXII, ISL and L00) DISABLED. 
THE ISL COOLING IS BEING DRAINED. 
</pre>
<!-- Author: Gino -->


<!-- Date: Mon Jun 3 20:22:51 2002 -->
ISL E is drained.  All relevant iFix alarms have been silenced. 
<br><br> 
ISL W, L00 W, and all of SVX are still at your disposal.
<!-- Author: Andy H. -->

<!-- Date: Mon Jun 3 21:13:41 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: LB1W1 L1 
<li>problem n: 259 
<li>Action: Light_investigated
<li>entered by: lmiller 
<li>description is: Looked at light output. OBDV was ~150uA through one extension  cable (uncalibrated loss there), duty cycle seemed within  50+/-5%. These are not incredibly accurate measurements. Saw  other bits that looked reasonable if not all low (in the 50-150 range). Removed the FTM and tried measuring RX +5V pin resistance, saw only 0.1-0.2 ohms. Reseated RX and ran out of time to  retest. Needs to be run and retested. </ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Jun 3 21:13:42 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: LB1W1 L1 
<li>problem n: 259 
<li>Action: Light_investigated
<li>entered by: lmiller 
<li>description is: Looked at light output. OBDV was ~150uA through one extension  cable (uncalibrated loss there), duty cycle seemed within  50+/-5%. These are not incredibly accurate measurements. Saw  other bits that looked reasonable if not all low (in the 50-150 range). Removed the FTM and tried measuring RX +5V pin resistance, saw only 0.1-0.2 ohms. Reseated RX and ran out of time to  retest. Needs to be run and retested. </ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Jun 3 21:17:35 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W5 L4 
<li>problem n: 408 
<li>Action: Light_investigated
<li>entered by: lmiller 
<li>description is: Tried swapping to neighboring pipe (pipe 8) and problem followed DOIM cable. Found no light on any bit at FTM end of DOIM cable. Need to look at light at bore DOIM cable. Likely a broken DOIM cable?  </ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Jun 4 08:56:21 2002 -->
<pre>at about 0200 this morning we could begin targetting epoxy 
in the ISL east.  we spent the next 3.5 hours working on 
a line whose partner, we think, is open.  we could not find 
an epoxy target though.  we think we either were not in the elbow 
or that the prism performance deteriatored before we found 
the target.  just as the shift ended, we had targetted epoxy in 
a 2nd line.  they're pressuring testing that line now. 
 
hopefully things begin to progress a bit more smoothly now. 
we will run 3 shifts/day through Friday.  we'll make a decision 
later this week as to how many shifts to run after that. 
 
</pre>
<!-- Author: Doug -->


<!-- Date: Tue Jun 4 10:55:51 2002 -->
<h3>Split DAQ</h3> 
I have split the DAQ into "east" and "west" as follows: 
<ul> 
<li> SVXII and ISL Bulkheads 0,1,2 are on West with Real SRC 
<li> SVXII and ISL Bulkheads 3,4,5 and L00 are on East with 
SRC currently known as "Prince", in Slot 6 of b0svx03. 
</ul> 
There is some question as to whether Prince really is a prince 
of an SRC, so we may have to swap it out.  I also 
tried to make the files in the standard directory structure 
~svxii/daq/svx(isl)/ne(nw/se/sw)/ correct.
<!-- Author: SCN -->
<!-- Comment: Tue Jun  4 11;24;13 comment by...SCN -->
<h3>East SRC is down</h3> pending some PROM decisions.

<!-- Comment: Tue Jun  4 12;16;16 comment by...SCN -->
<h3>East is back up</h3> with different SRC which is blessed by
Pope Lester

<!-- Date: Tue Jun 4 14:45:01 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W0 L4 
<li>problem n: 130 
<li>Action: Light_investigated
<li>entered by: stuart 
<li>description is: Light measurement showed NO light at all on OBDV. Need to do flashlight test when we have bore access. </ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Jun 4 16:43:36 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W3 L4 
<li>problem n: 86 
<li>Action: Diagnosis
<li>entered by: bolla 
<li>description is: <pre>WITH THE POWER SUPPLY IN THE CART WE CAN RUN IT BY SETTING THE 
CURRENT LIMIT IN DVDD HIGH ENOUGH (2000 A). IN THIS CONDITIONS
WE READ OUT THE PHI SIDE PERFECTLY.
WE WILL NEED TO CHANGE THE CAEN GUI IN SUCH A WAY THAT FOR THIS 
LADDER IT IS POSSIBLE TO SET A IdvddMAX to 2000 mA.
FURTHERMORE IT IS SAFER TO SET THE VMAX for DVDD4 to 9V instead 
of 8 BEACUSE RARELY THE DEVICE TRIP IN OVERVOLTAGE (STILL DUE 
TO THE HIGH CURRENT) </pre> </ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Jun 4 16:51:13 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W3 All 
<li>problem n: 452 
<li>Action: PS_work
<li>entered by: bolla 
<li>description is: <pre>PLugged this wedge to the PS in the cart and rumped up the 2VDOIM
without any problem. THIS IMPLIES THE PROBLEM IS in the POWER 
SUPPLY ITSELF. INFORMED ROB NAPORA. HE WILL TAKE CARE OF IT.</pre> </ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Jun 4 21:29:37 2002 -->
<pre>We tested succesfully all the 6 FIBs that have been mofified. 
1 of them was giving problem initializing the BOARD. 
Later ON we replugged and the board did not plug well  
(visible gap on the top of the board) By replugging it right  
everything worked well. 
Tomorrow morning Andy is going to test the questionable board one  
more time and make the decision about it. 
While I (gino) was working on DAQ3 I was able to blow the fuse  
for the 5V on the FTM. I replaced it with a 10 A fuse (originally 5A)  
because I did NOT find a 5 A fuse and 
Lester should review this modification. 
</pre>
<!-- Author: Gino, John and Andy -->


<!-- Date: Tue Jun 4 22:14:40 2002 -->
There was a leftover trip on SB3W5 port card from 
20:00 this evening.  I reset the trip so as to clear the iFix 
alarm.
<!-- Author: Andy H. -->


<!-- Date: Wed Jun 5 08:53:18 2002 -->
<pre><pre>ISL Cooling Update 
-------------------------------------------------- 
  over last three shifts we: 
    > opened another elbow, which yielded an open line 
      on the east 
 
    > targetted epoxy on an elbow, but do not think we 
      got through 
 
    > spent a shift trying to get to a very difficult elbow, 
      whose partner is thought to be open 
 
  the pace is about 1 elbow/shift, which was my pre-access 
  guess.  however, i think we might be able to improve a 
  bit so that we're targetting 4-5 elbows/day. 
 
  we've so far targetted 4 elbows.  We observed distinctive 
  epoxy signals on 3 of those.  We think we're through 2 of 
  those.  We think we understand why we didn't see a signal 
  on the one of them and we'll revisit it. 
</pre></pre>
<!-- Author: Doug -->


<!-- Date: Wed Jun 5 15:05:25 2002 -->
<h3>West back up</h3> 
Reinstalled "super duper Fibs" according to <a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=111&frame=2&anchor=11:16:37'>former positions</a> and brought the 
West DAQ back to life.  Did a glink check to be sure that I  
plugged them in the right places (and I did).  Back at 9 PM  
to test ladders.   
<!-- Author: SCN -->


<!-- Date: Wed Jun 5 15:10:13 2002 -->
<h3>Elog internal cross links are busted</h3> 
When I try to use a link I copied off by clicking the date field like this<pre> 
An HTML Link to this entry might look like: 
 
<a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=111&frame=2&anchor=15:05:25'> 
user link text </a>  
</pre> 
 I get 
<pre> 
Internal Server Error 
 
The server encountered an internal error or misconfiguration and was unable to complete your request. 
 
Please contact the server administrator, webmaster@b0dap61.fnal.gov and inform them of the time the error occurred, and anything you might have done that 
may have caused the error. 
 
More information about this error may be available in the server error log. 
</pre>
<!-- Author: SCN -->
<!-- Comment: Wed Jun  5 20;46;41 comment by...SCN -->
<a href=
'/cgi/elog/elog.pl?nb=2002&action=view&page=467&frame=2&anchor=15:13:11'>fixed</a> maybe (try it!)



<!-- Date: Wed Jun 5 23:08:31 2002 -->
    <h3>Executive Summary</h3>  
    <ul> 
      <li> No Change seen in tripping ladders, but ladders may not be left on long enough to 
incur Software Protection Trips.  Thus, no decision on Stretched FE CLK fix 
      <li> One potential OBDV problem on SB2W6L4 disappeared, so perhaps OBDV tolerance helped, but 
      <li> Three brand new bit 6 100% stuck problems appeared<ol> 
	  <li> SB2W3L4 (Stuck low) 
	  <li> SB2W5L0 (Stuck low) 
	  <li> SB2W9L4 (Stuck high) 
	</ol> 
	Might want to swap these fibs around a little and see if the OBDV mod is to blame.  Jury is still 
	out on this mod, in my mind. 
    </ul> 
<h3>Details</h3> 
    <h3>Fib to Vrb</h3> 
    Tested all Links, 1000 events x 4 kB/chan OK 
    <h3>Fib by Fib</h3> 
    Comparison With <a href= 
      '/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=111&frame=2&anchor=01:33:19'> 
      June 01</a> tests, Key<ul> 
      <li> <FONT COLOR=GREEN>Green = Old Serious Problem which went away </FONT> 
      <li> <FONT COLOR=RED>Red = New Serious Problem </FONT> 
      <li> <FONT COLOR=YELLOW>Yellow = New but not fatal problem, or very possibly there before but swamped by 
	  higher rate problems and as such went unnoticed.</FONT> 
      <li> <FONT COLOR=PURPLE>Old Problem is still there</FONT> 
    </ul> 
    <ul> 
      <li> SB2W0/W1- b0fib00 SL 17  S/N 148 <ul> 
	  <li> All Init OK 
	  <li> Run 2178 STBY, DPS ON, NN thresh 5 to file  Saw <ol> 
	      <li> <FONT COLOR=PURPLE>SB2W0L3 Chip 1 Cap ID bit 3 high</FONT> 
	      <li> <FONT COLOR=PURPLE>SB2W1L1 Chan Out of Sequence bit 2</FONT> 
	      <li> <FONT COLOR=PURPLE>SB2W1L4 Illegal Chan</FONT> 
	      <li> <FONT COLOR=YELLOW>SB2W0L0 Illegal Chan</FONT> Not overwhelming amount  
	    </ol> 
	</ul> 
      <li> SB2W2/W3- b0fib00 Sl 18  S/N 135 <ul> 
	  <li> <FONT COLOR=PURPLE>SB2W3L1 Fails to read back, all 0s, The rest are OK</FONT> 
	  <li> Run 2179 RA STBY DPS OFF to file<ol> 
	      <li> <FONT COLOR=PURPLE>SB2W3L1 Screws up data after Chip a2 (Chip a2 all 0s) Suspect 
		AVDD2</FONT> 
	      <li><FONT COLOR=RED>SB2W3L4 Bit 6 Stuck Low (OO Seq 63,00...)</FONT> 
	    </ol> 
	  <li> Run 2180 NN STBY DPS ON THR 5 to file<ol> 
		<li> Same as 2179 
	    </ol> 
	</ul> 
      <li>SB2W4/W5- b0fib02 Sl 17 S/N 156 <ul> 
	  <li>All init OK 
	  <li>Run 2181 RA DPS OFF to file <ol> 
	      <li> <FONT COLOR=GREEN>Not Seen: SB2W5L0 OO Seq/CAP ID Bit 2 stuck</FONT> 
	      <li> <FONT COLOR=RED>SB2W5L0 OO Seq Bit 6 Stuck Low (OO Seq 63,00...)</FONT> 
	      <li> <FONT COLOR=PURPLE>SB2W4L4 CAP ID errors Chip 1 only (off by random amount)</FONT> 
	    </ol> 
	  <li>Run 2183 NN Thr=5 DPS ON<ol> 
	      <li> Same as 2181 
	    </ol> 
	</ul> 
      <li>SB2W6/W7- b0fib02 Sl 18 S/N 118 <ul> 
	  <li>All init OK 
	  <li> Run 2184 RA STBY DPS Off <ol> 
	      <li> <FONT COLOR=GREEN> Not Seen!! SB2W6L4 OO Seq/CAP ID  (Maybe OBDV swaps Chan and Data)</FONT> 
	      <li> <FONT COLOR=PURPLE>SB2W7L1 OO Seq Bit 1</FONT> 
	    </ol> 
	  <li> Run 2185 RA STBY DPS Off without SB2W7L1 <ol> 
	      <li> <FONT COLOR=GREEN> Not Seen!! SB2W6L4 OO Seq/CAP ID  (Maybe OBDV swaps Chan and Data)</FONT> 
	      <li> <FONT COLOR=YELLOW>Not Chip ID SB2W2L0 </FONT> a few times 
	    </ol> 
 
	  <li> Run 2186 NN thr=5 STBY DPS ON <ol> 
	      <li> <FONT COLOR=GREEN>SB2W6L4 OO Seq/CAP ID  (Maybe OBDV swaps Chan and Data)</FONT> 
	      <li> <FONT COLOR=PURPLE>SB2W7L1 OO Seq Bit 1</FONT> 
 
	    </ol> 
	  <li> Run 2187 NN thr=5 STBY DPS ON without SB2W7L1<ol> 
	      <li> <FONT COLOR=GREEN>SB2W6L4 OO Seq/CAP ID  (Maybe OBDV swaps Chan and Data)</FONT> 
	      <li> <FONT COLOR=YELLOW>SB2W6L4 Illegal Chan (0xe9), c1c4</FONT> low rate 
	      <li> <FONT COLOR=YELLOW>SB2W7L4 c1c4</FONT> low rate 
	      <li> <FONT COLOR=PURPLE>SB2W6L3 Occassional 00f3</FONT> low rate 
	    </ol> 
	</ul> 
      <li>SB2W8/W9- b0fib02 Sl 19 S/N 140 <ul> 
	  <li>All init OK 
	  <li> Run 2188 RA STBY DPS OFF <ol> 
	      <li> <FONT COLOR=RED>SB2W9L4 Not Chip ID 0xcd00 -> Bit 6 Stuck High</FONT> 
	    </ol> 
	  <li> Run 2189 RA STBY DPS OFF without SB2W9L4-All ok 
	  <li> Run 2190  NN thr=5 STBY DPS ON  <ol> 
	      <li> <FONT COLOR=RED>SB2W9L4 Not Chip ID 0xcd00 -> Bit 6 Stuck High</FONT> 
	    </ol> 
	  <li> Run 2191  NN thr=5 STBY DPS ON  Saw very rare but interesting errors <ol> 
	      <li> <FONT COLOR=YELLOW>c1c4 SB2W9L2, SB2W9L3</FONT> 
	    </ol> 
	</ul> 
      <li>SB2WA/WB- b0fib00 Sl 19 S/N 129 <ul> 
	  <li><FONT COLOR=PURPLE>SB2WBL0 reads back 00s on init-All others OK</FONT> 
	  <li> Run  2192 RA STBY DPS OFF- <FONT COLOR=PURPLE>All OK </FONT> 
	  <li> Run  2193  NN thr=5 STBY DPS ON<ol> 
	      <li> <FONT COLOR=YELLOW>c1c4 SB2WBL1</FONT> low rate 
	    </ol> 
	</ul> 
    </ul> 
    All these runs and error logs are saved in /cdf/svx/data1/daq/anywhere/data 
    so that we can go back and look again, perhaps run them through daqana for 
    digitial errors, etc.  
<!-- Author: SCN -->
<!-- Comment: Thu Jun  6 10;06;10 comment by...David -->
I ran these runs through the DEM in case you want to see the errors. The results are <A HREF="http://nucsb03.fnal.gov/~stuart/steve/steve.html">here</A>.
<!-- Comment: Thu Jun  6 10;56;17 comment by...SCN -->
<FONT COLOR=GREEN>Lester makes a good point.  SB2W7L4 did not
give the same degree of Errors with the super duper FIB</FONT>
<!-- Comment: Thu Jun  6 17;20;05 comment by...SCN -->
<h3>More on SuperDuper FIBs</h3>
I did several experiments in Fib and DOIM swapping to try to
see if the bit 6 problem is really induced by "SuperDuperFib"ness.  <ul>
<li> SB2W3L4 (b0fib00 Slot 18)  bit 6 low <ol>
<li> Swapped Fib 560620/135 with spare SuperDuper Fib 560610/110- Problem remained
<li> Swapped spare SuperDuper Fib 560610/110 with just normal old Fib 550967- Problem remained
<li> Put back SuperDuper Fib 560620/135
</ol>
<li> SB2W5L0 (b0fib02 Sl 17) bit 6 low <ol>
<li> Swapped Fib with SuperDuper Fib from Sl 19 (has bit high Chan 9 SB2W9L4) Problem remained
<li> Swapped DOIM in Chan 5 with Doim in Chan 6-Problem Followed
DOIM, so I conclude it is a DOIM problem (with the TX)
<B>NOTE:THESE DOIMS ARE STILL SWAPPED AND WE NEED TO 
UNSWAP THEM BEFORE ACCESS ENDS</B>
</ol>
<li> SB2W9L4 (b0fib02 Sl 19) bit 6 high<ol>
<li> Verified bit high in all Chip IDs, Channels, Data via VRB WYSIWYG mode
<li> Swapped Fib with SuperDuper Fib from Sl 17 (SB2W5L0 bit low)- Problem Remained
<li> Swapped DOIM Chan 8 with DOIM Chan 9-all problems disappeared
<li> Cleaned and Greased DOIMS and swapped back-all problems
remain disappeared.
<li> Conclude it was a DOIM connector problem
</ol>
</ul>
In conclusion, no problems seem to depend on the Fib, two were
positively identified as depending on DOIM, and one of these
was even "fixed" by cleaning and regreasing.<h3>SuperDuper Fibs
are OK!!</h3>

<!-- Date: Thu Jun 6 09:47:41 2002 -->
<pre>L00 ramp ped adjustments finalized on a chip by chip basis. 
Please do not change these settings for any reason. 
 
This completes L00 commissioning!</pre>
<!-- Author: Chris Hill -->
<!-- Comment: Thu Jun  6 09;48;14 comment by...CH -->
<pre>Obviously, we will need a new calibration.</pre>






<!-- Date: Fri Jun 7 08:33:25 2002 -->
<pre> ISL Cooling Update 
 ============================================== 
 
  > wednesday ended with 3 prisms stuck in elbows - two 
    of which we had extracted and 1 which was particularly 
    stubborn; we'd also targetted epoxy in a couple more 
    elbows 
 
  > thursday ended with the last stuck prism removed and 
    a more stringent inspection of which prisms to use 
    in the lines;  we also opened a another line and targetted 
    some additional elbows 
 
  With the two open lines, plus previous work, most of the 
  ambiguities are resolved so that we can identify a small 
  number of elbows (4) whose opening ought yield open lines. 
  Thus, we have decided to continue working on the East side 
  through Tuesday (in the hopes of opening an additional 2 line). 
 
  Our plan then is to re-establish ISL cooling on the east 
  and tear-down our set-up starting 0800 wednesday.  This gives 
  a couple days inspect/test junction cards, etc on the east.</pre>
<!-- Author: Doug -->


<!-- Date: Fri Jun 7 20:47:43 2002 -->
I was here and looking for anyone but noone seems to be here 
except the "Cool People" so I am going home.  Looks like  
grounding bulkheads 4 and 5 solved all the "DAQ" problems ;) 
  
<!-- Author: SCN -->


<!-- Date: Sat Jun 8 09:44:50 2002 -->
<pre> ISL Cooling Update 
 =========================== 
 
  > another line was opened yesterday - the flow looks to 
    be a bit limited, so we'll continue to work on this one 
 
  > we have 3 lines left blocked on the east, each have one 
    elbow which is uniquely challanging... we'll beat on 
    these 
 
  > the open lines are: 
               - 6-in-1 
               - 6-in-2 
               - 6-c-1 
 
  according to rob roser, they could pull the west plug wednesday 
  morning.  it only makes sense for us to move to the west 
  if we have 12 shifts plus two for set-up.  so if the access 
  is extended to tuesday (ie. by tuesday a.m. CDF has to be all 
  buttoned-up), we could consider moving ISL work to the west 
  side. 
 
 
 
</pre>
<!-- Author: Doug -->


<!-- Date: Sat Jun 8 10:07:23 2002 -->
<pre> 
  ISL Update 
 ======================== 
 
  > the line which was only a little open is now 
    opened nicely - that make 3 "fully" recovered lines 
</pre>
<!-- Author: Doug -->


<!-- Date: Sat Jun 8 13:46:25 2002 -->
<pre>Swapped fibers (SB3W9 to SB4W5) back to correct positions.</pre>
<!-- Author: Chris Hill -->


<!-- Date: Sat Jun 8 14:07:40 2002 -->
<pre>Tested FTMs where Lester installed a gold-pinned replacement Rx. 
 
1) SB3W4,5 (SB3W5L0 where Rx was replaced) 
   Inits ok. 
   Take data (laser1016.svx) with errors (00 sequence, pipe 5) 
   HST, 4% errors, hst_sb3w4-5.log 
   Letser seems to have introduced a bit error, he will follow 
   up. 
 
2) SB3W6,7 (SB3W6L3 where Rx was replaced) 
   init ok, data ok (laser1017.svx), HST no errors in 500K. 
 
3) SB4W4,5 (SB4W5L4 where Rx was replaced) 
   Inits ok, except SB4W5L3 which has an internal OBDV problem. 
   Excluding this ladder, data ok (laser1018.svx), HST 100K ok.   
    
4) SB4W6,7 (SB4W7L2 where Rx was replaced) 
   SB4W6L2,3 do not init, both are masked. 
   SB4W6L2 is AVDD2, SB4W6L3 has bit 3 stuck low. 
   Excluding these ladders, take data with errors (laser1019.svx) 
   HST, 4% errors, hst_sb3w6-7.log 
   Errors are in SB4W7L2, OBDV (repeated chan). 
 
5) SB5W6,7 (???? where Rx was replaced) 
   Init ok, data ok (laser1021.svx), HST 100K ok. 
 
6) SB5W8,9 (SB5W8L2, SB5W9L2 where Rx was replaced) 
   Init ok, data ok (laser1022.svx), HST 100K ok. 
 
Conclusion:  Gold pinned Rx do not introduce major systematic  
problems, whether they fix anything remains to be seen.  Lester 
should continue to insert these on as a test on the west. 
 
SB3W5L0 and SB4W7L2 need follow up optical work at crate. </pre>
<!-- Author: Chris Hill -->


<!-- Date: Sat Jun 8 14:12:10 2002 -->
<pre>Investigate SB4W5L3, OBDV problem: 
Can it be effected and/or fixed by changing resistor driver bits? 
 
No, changing Rdriver from 0 to 7 has no effect on data which is a 
string of (nearly the same) characters for a few words before 
truncation.  There is not even a chip id. 
 
Next step, Gino will use CAEN cart to adjust VDOIM in hopes of 
effecting OBDV. </pre>
<!-- Author: Chris Hill -->


<!-- Date: Sun Jun 9 20:41:24 2002 -->
<pre>I dismounted the BLM's in the West side today, preparing for the opening of the plug tomorrow. 
</pre>
<!-- Author: Ricardo  -->


<!-- Date: Mon Jun 10 08:43:15 2002 -->
<pre> ISL Update 
 ========================== 
 
  > opened a fourth line on the east;  the remaining two 
    are quite difficult 
 
  > we're moving to the west this morning (monday) 
 
  > we'll try to argue to extend the access through the 
    weekend</pre>
<!-- Author: Doug -->


<!-- Date: Mon Jun 10 10:18:40 2002 -->
<h3>DAQ re-split</h3> Almost...<BR> 
Due to popular SPL demand I moved the SRC from b0svx03 to b0svx07, thereby splitting the Si DAQ into "ISL East" and  
"Other".  However, so as not to disturb Lester's work on the 
West<ul> 
<li>  I did not hook up the SVXII East VRB crates 
into the "Other" daisy chain yet. 
<li> <B>NB L00 VRB crate is in "Other", so no running L00 on East</B> 
<li> I did not change the configuration files in ~svxii/daq/svx/nw or .../sw 
</ul> 
All other config files are changed such that things should run 
as smooth as silk, as always.
<!-- Author: SCN -->


<!-- Date: Mon Jun 10 10:42:09 2002 -->
<pre>Working on SB4W9L4. 
Working with the CART we get the PHI side to work reliably 
without any trip with AVDD=6.00 V and DVDD=5.6 V. 
From the Z side I see some chip ID with correct capID and  
sometimes channel 0 and its data. 
A possibility is that the DVDD connection got broken on the  
Jumper and so the Z chips get DVDD power parasitically from the AVDD. 
THIS ipotesys should be checked on the BENCH.</pre>
<!-- Author: Gino -->


<!-- Date: Mon Jun 10 16:09:45 2002 -->
<h3>DAQ omlette</h3> 
Or maybe scrambled, perhaps sunny-side up?<BR> 
Due to popular demand, I swapped the DAQ back 
to "East" and "West", with L00 Vrbs still on the west. 
This time I left the rogue SRC in b0svx07 and just brought cables 
under the floor etc.  I am told this will be the situation until 
later tonight when we will revert back to "ISL East" and "Other" or maybe try something completely new.  All files are updated.
<!-- Author: SCN -->


<!-- Date: Mon Jun 10 16:12:45 2002 -->
<h3><a href= 
'/cgi/elog/elog.pl?nb=2002&action=view&page=482&frame=2&anchor=15:27:17'>SVXII Cooling trip</a></h3> on SVXII dew point = 19 deg C. 
Called Hocker, he said wait and see if it goes down, it doesn't, 
so called him again, he's coming...
<!-- Author: SCN -->


<!-- Date: Mon Jun 10 18:06:41 2002 -->
<pre>Went down to bore to check out dew point trip.  Andy H. will 
write a summary of what we found, dew-point wise.  To access 
the readout sensor cable, we had to touch / move the following 
cables: 
 
SB3W9 DOIMs 
SB3W9 Power 
IB4W5 DOIMs 
IB4W5 Power 
SB4W8 DOIMs 
SB5W8 DOIMs</pre>
<!-- Author: ADF, Hocker -->
<!-- Comment: Mon Jun 10 18;21;47 comment by...Andy H. -->
SVX dew point sensor has historically been very fragile.  As
usual the RTD part of the DP sensor seemed to be giving strange
values.  Poking at the connections fixed it.