<!-- Title: 10:28:06  Mon Jun 27 2005 -->
<!-- Crewchief: Jared (Main) -->
<!-- Op1: Rong-Shyang (SPL) -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>happyness is a warm gun</pre>


<!-- Date: Mon Jun 27 13:22:35 2005 -->
<h3> Has anyone seen this entry from the MCR E-Log</h3> 
 
<pre> 
09:48:18-  
FESS reports that the A/C unit for the A0 kicker room is dirty and needs to be cleaned at the next available time. Please page the duty mechanic between stores for this. 
 - amanda 
</pre> 
 
<em>Can I kick it...</em>
<!-- Author: Ankush -->
<!-- Comment: Mon Jun 27 15;48;45 comment by...Platoon Leader SVX -->
I like the smell of burning Silicon in the morning, smells like ....
Victory


<!-- Comment: Tue Jun 28 16;21;41 comment by...silicon monkey -->
<pre>smells like.... freedom</pre>
<!-- Date: Mon Jun 27 17:04:05 2005 -->
<h3>FCC Fun</h3> 
 
<p>During the afternoon, Sasha, Sebastian and I returned to FCC.  We checked the SVX WIB was still working and then hooked up the ISL  WIB to the SVX portcard.  The ISL failed to initialise but we could data out of it, albeit lots of CAP-ID and bunch-crossing errors.</p> 
 
<p>We then transferred the ISL wedge to the ISL WIB.  Couldn&#39t it to work.  We probed the ISL wedge and the only signal getting through was Pre-Amp Reset (PARST).</p> 
 
<p>So we&#39ve reached the stage where we really need some experts to guide us to a working port-card.</p>
<!-- Author: Ankush, Sebastian and Sasha -->


<!-- Date: Mon Jun 27 18:23:55 2005 -->
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=254&frame=2&anchor=18:19:56'> 
<h4>Added summary of last week&#39s entires</h4></a> 
  
<!-- Author: Ankush -->


<!-- Date: Tue Jun 28 10:19:39 2005 -->
<pre>Store Quenched... as predicted by Marcel.</pre>
<!-- Author: Jared -->

<!-- Date: Tue Jun 28 10:28:59 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB3W0L2 
<li>problem n: 1486 
<li>Status: needs_observation
<li>Type: DVDD
<li>Action: Monitoring
<li>entered by: yamaoka 
<li>description is: DVDD jumping around (328-488) causing pinkie.  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B3W0&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Jun 28 10:45:36 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W6L0 
<li>problem n: 1487 
<li>Status: needs_observation
<li>Type: DRO_00F3
<li>Action: Monitoring
<li>entered by: boveia 
<li>description is: DSEM reports 'e1600cfd 00f300f3 00f300f3 00c2c2c4' for a small number of recent events, and ADCMon has no data.  Given that independent tools (bitreporter) see no problem, this is probably a fluke in the ADCMon machinery.  If this is not the case, pass to Detector (RX?) 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W6&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Jun 28 10:50:13 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W6L0 
<li>problem n: 1487 
<li>Status: needs_observation
<li>Type: DRO_00F3
<li>Action: Monitoring
<li>entered by: boveia 
<li>description is: Whoops.  Changed to Monitoring. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W6&layer=L0">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Jun 28 15:25:26 2005 -->
<br><b>BERT teststand</b><br> 
Thanks to Rong, the BERT testsatnd is working again in FCC. The cooling for the TXs is missing, the request has been made to Bob Forster. We are ready to for the bitbooster...<br>  
<!-- Author: Ankush, Rong, Sebastian -->



<!-- Date: Tue Jun 28 17:41:13 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6913&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6914  width='300' align='top'></a></td><td>LB0W2L3 tripped twice on DVDD overcurrent. Recovered and did a coldstart. Now looks fine.</td></tr></table>
<!-- Author: Sebastian -->


<!-- Date: Wed Jun 29 02:10:19 2005 -->
<table><tr><td><a href=https://www-cdfonline.fnal.gov:443/cgi-bin/nph-MCRproxy_res.pl/000/http/www-cdfonline.fnal.gov/cgi-bin/det-system-elog.pl?nb=silicon&action=view&page=-6915&button=yes target='xxx' onclick='jswindow()'; align=top><img src=https://www-cdfonline.fnal.gov:443/cgi-bin/nph-MCRproxy_res.pl/000/http/www-cdfonline.fnal.gov/cgi-bin/det-system-elog.pl?nb=silicon&action=view&page=-6916  width='300' align='top'></a></td><td>SVT SpyMon (Store 4241)</td></tr></table>
<!-- Author: Jared -->
<!-- Comment: Wed Jun 29 02;26;28 comment by...Marcel -->
everything looks good, seems like we survived the Event builder Test


<!-- Date: Wed Jun 29 08:18:21 2005 -->
<pre>While I was sitting at b0dasvx01, wedge sb2w2 tripped. Sorta strange, but it came back on ok.  </pre>
<!-- Author: Jared -->
<!-- Comment: Wed Jun 29 08;26;36 comment by...Jared -->
<pre>Actually not so strange:  5VDOIM Overcurrent.</pre>
<!-- Date: Wed Jun 29 08:23:20 2005 -->
From last night:<br> 
 
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2005&action=view&page=538&frame=2&anchor=05:46:55.744'> 
Two pinkies in S_2VDOIM_B2W2L5 and S_5VDOIM_B2W2L5. After unmarking them, they turned green again.</a> 
<br>
<!-- Author: Jared -->



<!-- Date: Wed Jun 29 08:28:57 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6917&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6918  width='300' align='top'></a></td><td>SB2W2 5vDOIM</td></tr></table>
<!-- Author: Jared -->

<!-- Date: Wed Jun 29 12:26:44 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB3W0L2 
<li>problem n: 1486 
<li>Status: needs_observation
<li>Type: DVDD
<li>Action: Diagnosis_update
<li>entered by: marcel 
<li>description is: this is consistent with cap  id problems during the last few runs, let see, whether powercycling the wedge fixed this or not  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B3W0&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jun 29 12:30:53 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W5L4 
<li>problem n: 1252 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Monitoring
<li>entered by: marcel 
<li>description is: the problem with bit 5 is coming back. We should try the standard procedure on this guy just to nail it down, what is causing this. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B1W5&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jun 29 12:38:23 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W2L1 
<li>problem n: 784 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: marcel 
<li>description is: interesting, the problem is mainly affecting the chip ids on the Z side. Should be investigated during quiet time to see, if it is really internal, as I suspect 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W2&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Jun 29 13:57:00 2005 -->
<pre>Electron lens tripped.</pre>
<!-- Author: Jared -->
<!-- Comment: Wed Jun 29 13;58;09 comment by...Jared -->
<br>
<b>FROM CDF ELOG</b><br>
<table><tr><td><a href=/cgi/elog/elog.pl?nb=2005&action=view&page=-11034&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/elog.pl?nb=2005&action=view&page=-11034 width='300' align='top'></a></td><td>Electron lens tripped twice; had to put silicon in standby</td></tr></table>

<!-- Comment: Wed Jun 29 14;00;12 comment by...Jared -->
<b>FROM MCR ELOG</b><br>
<pre>
12:49:17-   Tel solonoid, Booster West Anode, RR 40 house corr Elem all tripped off. - Aria
-- Wed Jun 29 12:54:13 comment by...prk --  TEL solenoid is back on. It tripped again with the same PS2 overcurrent status shown on the first trip, likely caused by the glitch noticed elsewhere. It seems to be holding now.
-- Wed Jun 29 12:57:46 comment by...amanda --  CHL noted their lights flicker.
-- Wed Jun 29 12:57:58 comment by...marty --  We contacted Mike Nunez and he spoke with ComEd dispatcher who told him that there was a "bump in the system." There are no trips at the Master substation. We are turning on affected systems. Recycler lost about 33 E10 of its pbars as a result of the tripped correctors.
</pre>


<!-- Date: Wed Jun 29 16:15:00 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6919&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6919' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6920&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6920' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6921&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6921' width='300'></a></center>
<!-- Author: SCN -->
<!-- Comment: Wed Jun 29 16;25;19 comment by...SCN -->
<h1> Too much ISL information</h1>
As I was going about updating the Vrb Balancing project with more
recent data (see <a href="http://www-cdf.fnal.gov/htbin/twiki/bin/view/Main/VrbBalancing">work in progress</a>) I noticed that the average byte count/event in each of the ISL Vrbs <B>exploded</B> for two runs, <a href="http://www-cdfonline.fnal.gov/java/cdfdb/servlet/RunSummary?RUN_NUMBER=193023">193023</a> and <a href="http://www-cdfonline.fnal.gov/java/cdfdb/servlet/RunSummary?RUN_NUMBER=198644">198644</a>.
The above plots overlays the average byte count/event in each of the 58 Vrbs as a function of "consecutive run number" (time, if you like) where Black is SVXII, Red is L00, and Blue is ISL.  For the two sections around the run numbers indicated, I blew up the x axis and you can see that <b>ALL the ISL Vrb byte counts are off by a factor of 3 to 10</b>.  I think both of these runs were cosmic ray or "DAQ Testing" with low L1A and short duration, but it is curious so I thought I should document it.  Anyone have an explanation?


<!-- Comment: Fri Jul  1 09;43;16 comment by...MArcel -->
No, there seems to be nothing particulary wrong with these runs 
<!-- Date: Wed Jun 29 17:16:08 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W0L0 
<li>problem n: 1019 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Monitoring
<li>entered by: amitra 
<li>description is: <p>The bit 3 problem is back again.  However the bit itself isn'nrt stuck.  It just seems to give the wrong value.  Need to studyt this ladder during quiet time.</p>. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W0&layer=L0">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Jun 29 17:22:14 2005 -->
<pre>While doing trigger table test w/o silicon, the IB3W0, IB3W1, IB4W2, IB4W4 and IB5W3 (CAEN11) decided to take a break and turn themself off. Brought them back with coldstart w/o problem.</pre>
<!-- Author: Rong -->

<!-- Date: Wed Jun 29 17:37:30 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W7L2 
<li>problem n: 1488 
<li>Status: needs_work
<li>Type: Chip_capid
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>First chip read out (87) always gives 17 for the CAPID.  Need to investigate during quiet time to see if this can be fixed.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W7&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Jun 29 17:54:40 2005 -->
<pre>Trigger table test with - PHYSICS_HIGHLUM_3_04 [1,671,577] and PHYSICS_3_04 [1,670,576] was done w/o and w/ silicon. Everything is fine and the new table will become default.</pre>
<!-- Author: Rong -->


<!-- Date: Thu Jun 30 00:07:49 2005 -->
<h2>Power Supply Access Report: SB2W2</h2> 
Tried swapping out the power supply for SB2W2, which has been tripping frequently on 2V and 5V DOIM for the last week.  Before pulling the SB2W2 supply, tried checking all the cables - they appeared to be attached securely.  The new supply loadbox tested fine, and everything in crate 2 is now back to standby.  Now we just have to see if it stops tripping (while trying to reproduce the behavior with the old SB2W2 supply on the teststand)...<br>
<!-- Author: Jen, Jared, Sebastian, Marcel -->


<!-- Date: Thu Jun 30 01:02:23 2005 -->
<h4>Funny trip of e3a4  </h4> 
This guy tripped twice, btoh times on DVDD. We did not really understand why. At the ned, I have rebooted Fib04 due to anecdotal evidence, that this fixes things sometimes. It stopped tripping then. However the only reason, why rebooting a fib crate might help would be memory corruption. 
Anyway ...
<!-- Author: Sebastian, Marcel -->


<!-- Date: Thu Jun 30 01:02:56 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6922&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6923' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6924&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6925' ></a></center>
<!-- Author: Marcel -->
<!-- Comment: Thu Jun 30 01;03;18 comment by...Marcel -->
AVDD and DVDD of e3a4


<!-- Date: Thu Jun 30 04:56:40 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6928&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6929  width='300' align='top'></a></td><td>SVT SpyMon Plot (Store 4243)</td></tr></table>
<!-- Author: Jared -->


<!-- Date: Thu Jun 30 06:49:55 2005 -->
<pre>Thursday morning shot setup report: 
 
Silicon was fine at the start of the run.  There was a trigger issue unrelated to us (hot tower in the cal).  The weather alarm went off, and since we weren't taking good data the silicon was put to standby.  A few minutes later we had a TEL warning, and all the high voltages were taken down till after the thunder storm passed. 
 
We are now running with the si in. 
 
 
  </pre>
<!-- Author: Jared -->
<!-- Comment: Thu Jun 30 06;55;10 comment by...Jared -->
<br>
<b>comment from MCR:</b> 
<br>
<pre>
05:13:42-   Thunderstorm is flexing it's muscle. Lightning strikes are numerous. PAK1-3 are showing PS limit faults, Anti-mater containment alarm sounded (no beam lost).  - dln
-- Thu Jun 30 05:14:36 comment by...dln --  TEL went out for tolerance.
</pre>

<!-- Date: Thu Jun 30 10:02:30 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W2L4 
<li>problem n: 1423 
<li>Status: needs_observation
<li>Type: DRO_00F3
<li>Action: Monitoring
<li>entered by: boveia 
<li>description is: Chip 89 was dropping the readout again at a low rate in runs around 200026.  Keep an eye on it. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W2&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Jun 30 10:19:28 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W7L2 
<li>problem n: 1488 
<li>Status: fixed
<li>Type: Chip_capid
<li>Action: Monitoring
<li>entered by: boveia 
<li>description is: First chip (chip 89) is sparsed out.  See thread 1046. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W7&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Jun 30 10:22:05 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W7L2 
<li>problem n: 1046 
<li>Status: needs_work
<li>Type: AVDD2
<li>Action: Monitoring
<li>entered by: boveia 
<li>description is: Chip 89 still has the wrong cap id for 100% of events in recent runs. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W7&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Jun 30 10:34:36 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W1L2 
<li>problem n: 1445 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: marcel 
<li>description is: ok, the error is back on the chip ids for chi0 86 and 85. Should investigated during quiet time to see, if there is anything we can do. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W1&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Jun 30 13:07:31 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W2All 
<li>problem n: 1485 
<li>Status: needs_observation
<li>Type: VDOIM
<li>Action: PS_work
<li>entered by: sebastian 
<li>description is: The PS for this wedge was swapped last night. No DOIM trips since then. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W2&layer=All">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Jun 30 22:33:20 2005 -->
<table><tr><td><a href=/cgi/elog/elog.pl?nb=2005&action=view&page=-11158&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/elog.pl?nb=2005&action=view&page=-11159 width='300' align='top'></a></td><td>SB1W4L4 AVDD</td></tr></table> <BR> 
<cite>-- Thu Jun 30 22:27:44 comment by...Jared --  </cite><pre>Had a lot of trouble getting SB1W4L4 AVDD to go green. Tried to power cycled the wedge, but had to restart svxinter and the PS Gui first. Eventually the power cycle seemed to work.</pre>
<!-- Author: Jared -->


<!-- Date: Thu Jun 30 22:33:59 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6930&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6931  width='300' align='top'></a></td><td>IB1W5 Trip</td></tr></table>
<!-- Author: Jared -->
<!-- Comment: Thu Jun 30 22;34;46 comment by...Jared -->
<pre>IB1W5 Tripped: Right after fixing SB1W4L4, IB1W5 tripped.  I had some problem turing it back on as a wedge, but tuning on each channel separately worked.</pre>

<!-- Date: Fri Jul 1 05:48:26 2005 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 415
Calibration type  : standard
Run period tag    : Jul_2005
DPS-off run       : 200286
DPS-on run        : 200285
Requested by      : Junji Naganoma
Main process id   : 20094
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->




<!-- Date: Fri Jul 1 10:10:51 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6934&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6935  width='300' align='top'></a></td><td>Access lunch, courtesy of Dr. Grinstein </td></tr></table>
<!-- Author: Marcel -->


<!-- Date: Fri Jul 1 13:26:45 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6936&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6937  width='300' align='top'></a></td><td>SVT SpyMon (STORE 4246)</td></tr></table>
<!-- Author: Jared -->


<!-- Date: Fri Jul 1 13:37:02 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6939&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6939' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6940&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6940' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6941&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6941' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6942&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6942' width='300'></a></center>
<!-- Author: Jared -->
<!-- Comment: Fri Jul  1 13;38;25 comment by...Jared -->
<pre>It looks like SVXMon isn't picking up the correct configuration from the database.</pre>

<!-- Comment: Fri Jul  1 13;51;42 comment by...Marcel -->
It looks  like the chopped chip chain configuration does not make it into svxmon, the database itself looks consistent


<!-- Comment: Fri Jul  1 14;10;09 comment by...Marcel -->
ok, actually the disk was full, where svxmon tries to dump the database information. cleaning up a bit fixed the problems


<!-- Date: Fri Jul 1 14:55:29 2005 -->
<h3> Readout time studies </h3> 
I did some studies on the readout time by looking on David Stuarts Occupancy plotter files. The basic idea was to see, how big the impact would be, if we remove some of the noisy ladders. So I ran over two files proved by David (Stream H and A) of Run  
200051 (initial lumi 87E30). The readout time is determined after the last ladder has dropped READBUSY. <br> 
To see the impact of removing some of our noisy friends 
(e314 e1a4 e2a4 e1b4), I masked them off. Results are shown below, first conclusions: 
<ul> 
<li> The READBUSY is physics driven, noisy ladders may have a larger mean occupancy, but the READBUSY time is not affected by them</li> 
<li> Masking off the worst offenders does not really affect the readout time much (1 % on the mean), while leaving the shape basically unchanged. </li> 
<li> The choice of streams does not really have a big impact as well </li> 
</ul> 
 
  
<!-- Author: Marcel and David S. -->


<!-- Date: Fri Jul 1 14:56:26 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6943&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6943' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6944&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6944' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6945&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6945' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6946&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6946' width='300'></a></center>
<!-- Author: Marcel -->
<!-- Comment: Fri Jul  1 14;58;02 comment by...Marcel -->
From left to right:
<ul>
<li>Stream A masked/not masked</li>
<li>Stream H masked/not masked</li>
<li>Stream A/H not masked</li>
<li>Stream A/H masked</li>
</ul>



<!-- Date: Fri Jul 1 15:20:03 2005 -->
<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 415 FAILED.

Job info
--------
Calibration type : standard
DPS-off run      : 200286
DPS-on run       : 200285
Requested by     : Junji Naganoma
Submitted        : 2005-07-01 05:47:54
Completed        : 2005-07-01 15:19:58
Status           : FAILURE

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
----------------    ----------   ---------   ----------
bad_chan rel max    SVX_Z        0.3         0.440348  

Reference calibration runs are 190801 (DPS off) and 190793 (DPS on)
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->
<!-- Comment: Sun Jul  3 13;28;50 comment by...Jason Nielsen -->
These reference runs are very old (Dec_2004), so it's not too surprising that the number of bad SVX Z channels has changed relative to those old runs.  I did a few things to help:
<UL>
<LI>Checked this calibration and set its status to SUCCESS so that it can be assigned to new beam-off data runs.</LI>
<LI>Updated the reference beam-off calibration runs to be these runs 200286/200285.</LI>
<LI>Added a beam conditions line to the Job Info printed out in the e-log: should be either ON or OFF, and that will make it easier for us to keep track.</LI>
</UL>
<!-- Date: Fri Jul 1 16:51:43 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6947&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6947  width='300' align='top'></a></td><td>The ten ladders, that are last one most often</td></tr></table>
<!-- Author: Marcel -->

<!-- Date: Sat Jul 2 15:55:13 2005 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 416
Calibration type  : standard
Run period tag    : Jul_2005
DPS-off run       : 200329
DPS-on run        : 200328
Requested by      : Collin Wolfe
Main process id   : 18099
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->


<!-- Date: Sun Jul 3 01:09:18 2005 -->
<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 416 finished successfully.

Job info
--------
Calibration type : standard
DPS-off run      : 200329
DPS-on run       : 200328
Requested by     : Collin Wolfe
Submitted        : 2005-07-02 15:55:06
Completed        : 2005-07-03 01:07:40
Status           : SUCCESS
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->



<!-- Date: Sun Jul 3 13:06:50 2005 -->
<h3> Event Builder tests </h3> 
today is Event builder test fest ... <br> 
We did the following things: 
<ul> 
<li> First tihng was , we reproduced the Bus errors, Ron took a VMETRO trace, we'll have a look at it offline. Anyway, it always happens in the  HALT transition. Theory is, that the EVB stills polls, while the svx cpu runs the diagnostics code.</li> 
<li> Bill made a quick work around, which sends the EVB to HALT before the SVX crates go to HALT. that fixed this problem. </li> 
<li> We swapped the SCPUS in svx07/08 from slot 21 to slot 4 just to see, if we are running more stable. </li> 
<li> then we pllaned to use SVx as well, but first found out, that the new EVB couldn't run with 15 SCPUS,  this was tracked down by Markus. One of the message Buffers was too small. Quickly fixed.</li> 
<li> Since two hours we are fighting strange problems with L2/EVB/TSI ..... </li> 
</ul>  
<!-- Author: Markus & Marcel  -->
<!-- Comment: Mon Jul  4 17;26;34 comment by...SCN -->
Question:  The point of reproducing the "Hanging in HALT" error was
because it appeared that the EVB hung in the middle of a DMA transfer <i>during ACTIVE</i> in slot 21 butnot in slot 5.  That the Si CPU hung at HALT time was a secondary effect.  The idea was that either <ol>
<li> Indeed it was a slot dependent problem-the peculiarities of the bus meant only some subset of slots could be used for the SCPU, and this varied by crate- slot 21 is ok for b0svx07 and b0svx08, but not b0svx06.  This is very disconcerting if not down right ugly.
<li> There was an insertion problem with slot 21 the first time, i.e. the board was not fully connected to the backplane.  When it went to slot 4, it was better connected.
</ol>
 Was the entire problem (including the DMA hang as seen by the VMEtro) reproduced?  In principle, since the original problem occured in <i>ACTIVE</i> the order of who got HALT first shouldn't have mattered (we confirmed this when the problem was occuring, the SCPU couldn't access the bus either).  I could imagine if the  problem were due to #2 above, you'd get Bus errors in HALT but not the full hang until the sequences were figured out. <P>  Anyway, sorry to be picky, but it would be good to understand if the problem were really #1 or #2 above, for future planning.
<!-- Comment: Tue Jul  5 18;17;16 comment by...Marcel -->
no this problem has already been adressed. Now, we see BUS errors in the EVB CPU, when in HALT. Which is probably due to the SVX CPU accessing the boards and the event builder still polling. I have to look at the trace in detail. Putting the eVB to HALT first circumvents this problem, which should not happen in the first place. I agree, it would be nice to figure everything out, but our amount of quiet time is very limited. <br>
Anyway, SVX is untouched in order to see, if we see the same kind of problem there, or if it is really a bad connection problem. The boards in svx07/08 where moved in order to figure out the bus errors (not complete hangs ...). And yes, there a probably some very ugly things going on, since extender cards are not part of the VME spec in the first place (according to Ron). We have now three of them in ... 
<!-- Date: Sun Jul 3 18:17:05 2005 -->
I did another noise vs bias scan today (run 200468.)  Details to follow.
<!-- Author: boveia -->
<!-- Comment: Sun Jul  3 19;10;11 comment by...Marcel -->
good job


<!-- Comment: Mon Jul  4 12;25;14 comment by...boveia -->
<pre>
vbias run   iev   fev    lum
-90  200468 0     528    1087
-80  200468 529   1450   1087
-70  200468 1451  2170   1087
-60  200468 2171  2943   1087
-50  200468 2944  3783   1087
-40  200468 3784  4374   1087
-30  200468 4375  5314   1087
-20  200468 5315  6081   1087
-10  200468 6082  7033   1087
0    200468 7034  8038   1087
-75  200468 8039  9183   1087
-65  200468 9184  9650   1087
-55  200468 9651  10617  1087
-45  200468 10618 11097  1087
-37  200468 11098 12023  1087
-33  200468 12024 12902  1087
-15  200468 13800 14428  1087
-8   200468 14429 15110  1087
-4   200468 15111 15623  1087
-35  200468 15624 16469  1087
-25  200468 16470 17472  1087
-17  200468 17473 18829  1087
-12  200468 18830 18889  1087
</pre>

<!-- Comment: Mon Jul  4 12;37;48 comment by...boveia -->
<pre>For the record, I set the voltages back to their June 20th nominal configuration, CAENvolts_06202005_0357PM.dat</pre>
<!-- Comment: Wed Jul  6 22;20;51 comment by...boveia -->
<pre>That last point, -12, should start at 18330, not 18830.  Then -17 stops at 18329, not 18829.</pre>
<!-- Date: Sun Jul 3 19:54:27 2005 -->
<br><b>Quiet time studies</b><br> 
<ul> 
<li> 
SB3W2L0 could   
<a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W2&layer=L0"> 
reproduce</a> 
errors with svxdaq. Candidate 
for fiber swapping, but I doubt we'll learn anything useful. 
<li>  
<a 
href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W11&layer=L3"> 
SB3WBL3:</a> is marked as needing access. But can not reproduce problems with svxdaq.  
<li>  
<a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W11&layer=L3"> 
SB0WBL3:</a> could reproduce CAP ID errors. Could try swap fibers. 
</ul>
<!-- Author: Sebastian -->
<!-- Comment: Sun Jul  3 19;57;01 comment by...s -->
<pre>Did a cold start, everything OK.</pre>


<!-- Date: Mon Jul 4 09:27:20 2005 -->
<br> 
<b>Week Summary</b> 
<br> 
<br>  
  <ul><li>Store 4240 
<ul> 
      <li>Quenched during shot setup</li> 
</ul>     
</li> 
  </ul> 
 
 
  <ul><li>Store 4241 
      <ul>  
        <li>SB2W2 trip on 5VDOIM: Known problem from last week</li> 
        <li>The electron lens tripped twice: ACE put to standby</li> 
        <li>During no si trigger test, CAEN11 turned off all its wedges.  Brought back with coldstart.</li> 
        <li>Successful Trigger Test (w/o and w/ si): New table PHYSICS_HIGHLUM_3_04[1,671,577]</li> 
      </ul> 
    </li> 
  </ul> 
   
  <ul><li>Between Stores 
      <ul> 
	<li>Access to swap PS for SB2W2 (no problems since swap)</li> 
	<li>SB3W10L4 tripped on DVDD: required rebooting FIB04</li> 
      </ul> 
    </li> 
  </ul> 
 
  <ul><li>Store 4243 
      <ul> 
	<li>Si included at start of run but removed because of thunderstorm:</li> 
	<ul> 
	  <li>Trigger problem cause by CAL ment we weren't taking good data</li> 
	  <li>Tunderstorm caused TEL warning</li> 
	</ul> 
	<li>After the thunderstorm passed included back into run</li> 
	<li>SB1W4L4 AVDD: Pinkie, power cycling the wedge fixed.  But had to reboot svxinter and restart PSGui.</li> 
	<li>IB1W5: Whole wedge tripped.  Had to power one channel at a time to recover.</li> 
      </ul> 
    </li> 
  </ul> 
 
  <ul><li>Between Stores 
      <ul> 
	<li>Though we asked for a beam on calibration, the shift crew took D-Mode without beam.</li> 
      </ul> 
    </li> 
  </ul> 
 
  <ul><li>Store 4246 
      <ul> 
	<li>SVXMon had many yellow cells, it wasn't picking up the correct confuration from the database.  The problem was the disk was full so the proper files couldn't be copied.  Marcel freed up some disk space.</li> 
	<li>Beam on D-Mode calibration</li> 
      </ul> 
    </li> 
  </ul> 
 
 
 
	<ul><li>Misc. Work 
	    <ul>  
	      <li>ISL WIB: Still need portcard</li> 
	      <li>BERT teststand working</li> 
	      <li>Readout time studies</li> 
	      <li>EVB tests (supervised by Marcel)</li> 
	      <li>Noise bias scan (by Antonio)</li> 
	      <li>Quiet time studies</li> 
	    </ul> 
	  </li></ul>
<!-- Author: Jared -->




<!-- Date: Mon Jul 4 14:32:20 2005 -->
<pre>Monitoring Summary 
=================== 
 
Old problems that needed monitoring: 
 
e1a0 - This ladder flakes out from time to time.  No bit errors or garbage data today, so we'll try again in a couple of weeks. 
e212 - Observed rate of illegal channel error is about 2%, lower than in the past.  We should continue to monitoring this. 
e223 - The bit 5 error is now gone. 
e144 - Back after AVDD and bias problems.  So far, the ADC and bit error distributions look fine.  We should monitoring this for one more round. 
f112 - This ladder has a pinhole.  The previous attempt at bias splitting didn't help.  I passed it back to the detector group. 
f853 - Chip 2 still looks unbiased.  Investigation is waiting on the final signal bias scan results. 
e2a4 - Long readout times and general Micron grassiness.  We'll take a look at yesterday's noise bias scan results when they are available.  Last time I looked, I think this guy had a weird IV curve that we should try to understand. 
 
New problems: 
 
e160 - Flaky readout for one run.  This was probably a hiccup in the monitoring tools, but we'll watch it to make sure. 
e224 - Chip 89 drops the readout at a very low rate.  Keep an eye on it. 
e372 - Chip 89 has the wrong cap ID for 100% of events. 
 
Other activities: 
 
Noise bias scan 
</pre>
<!-- Author: boveia -->