<!-- Title: 11:36:19  Mon Aug  2 2004 -->
<!-- Crewchief: Rainer(supposed to be pager carrier) -->
<!-- Op1: Rong-Shyang -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>Let's be cool!</pre>


<!-- Date: Mon Aug 2 11:39:14 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4793&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4794  width='300' align='top'></a></td><td>Example of IMon plot for one ladder when PS1 was gone.</td></tr></table>
<!-- Author: Ben and Rong-Shyang -->
<!-- Comment: Mon Aug  2 11;47;11 comment by...Ben and Rong-Shyang -->
<pre>So, suddently, we saw IMon shows blue and then several wedges show grey in PSGui. They correspond to PS crate 1. Had Ace hockerized the crate. At the time we powered up the wedges, two wedges refused to be powered, and I got error messages in SVXInter like : 

--------------

Sending Request for e016
Sending Request for e0b6
Sending Request for e0a6
Sending Request for e116
Timeout
ERROR: not all Fibs are initialized
ERROR: FIB does not respond to Request for handshake, ps_n = 13setPSStatus,err = -1, detector = 1, ps_n = 13
Sending Request for e1b6
Timeout
ERROR: not all Fibs are initialized
ERROR: FIB does not respond to Request for handshake, ps_n = 23setPSStatus,err = -1, detector = 1, ps_n = 23
Sending Request for e1a6
Module is busy, sending code = 16
-----------------

I rebooted b0fib00, powered up the rest of wedges and did a coldstart. 


</pre>
<!-- Comment: Mon Aug  2 12;40;53 comment by...Corrinne and Rong-Shyang -->
<pre>Crate 16 went off it self later. It came back red and we could communictate with all wedges. So no hockerization needed.</pre>
<!-- Date: Mon Aug 2 11:40:46 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4795&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4795  width='300' align='top'></a></td><td>Kick distribution</td></tr></table>
<!-- Author: Marcel -->
<!-- Comment: Mon Aug  2 11;41;14 comment by...Marcel -->
This is the kick distribution for several delta_t, as requested by Gino




<!-- Date: Mon Aug 2 12:41:53 2004 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4796&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4797' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4798&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4799' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4800&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4801' ></a></center>
<!-- Author: Corrinne and Rong-Shyang -->
<!-- Comment: Mon Aug  2 12;47;42 comment by...Corrinne and Rong-Shyang -->
We saw for e084 with
<li> SVXMon yellow on this ladder
<li> Pinky on both AVDD and DVDD. AVDD got higher current and DVDD had 0 current.
<li> On PSGui, it draw normal voltage but zero current on DVDD in the 'full status' page. It still got biased, so no trigger inhibit was pulled.
<br>
Then we tried 
<li> turn off the ladder and bring it back to standby. Didn't help
<li> hockerized crate 6. As in the upper plots, the DVDD current got back for a second but went gone again.

I paged PS and Matt got back said that there is nothing we can do at this point. Will need an access to check the power supply. Maybe the connecter is a problem. We took this ladder out of HWDB due to large current draw in AVDD.
 


<!-- Comment: Thu Aug  5 14;01;06 comment by...Gino and Rong -->
<pre>
Data taken at Monday. In the begining of the run, we still have data back from e084, but at some point we lost DVDD and then only got c2c2 from it.


-----------------------------
> od -h /cdf/data08/look/dphysr/dr02d5f7.0001phys | grep -e 'c1c1 e084' 
3557000 12f3 130a 1408 a01f 7f01 c1c1 e084 06fc
5546120 c1c1 e084 6afd 8d0b 00f3 1805 192a 1a03
1004100 c1c1 e084 4dfc 8d0c 00f3 41f3 428f 4307
6331420 7a1b 7b0e 7c0f 7d0f 7e10 7f0b c1c1 e084
2616360 2f0a 3009 31f3 7ff3 c1c1 e084 8bfd 8d26
6270740 c1c1 e084 6afe 8d07 00f3 3803 390e 3a0e
4217460 7ff3 c1c1 e084 06fc c2c2 0000 e090 06fc   <---- here got c2c2
4007520 2906 7f06 c1c1 e084 7cfc c2c2 0000 e090
6554060 580c 5913 5af3 a00f 7f02 c1c1 e084 79fe
5336700 7411 751b 7603 a027 7ff3 c1c1 e084 7cfd
0602600 2c0b 2d21 2e20 2f09 30f3 7f02 c1c1 e084
7001740 c1c1 e084 21fc c2c2 0000 e090 21fc 8322
4327720 7ff3 c1c1 e084 6dfc c2c2 0000 e090 6dfc
6302060 7e0c 7f12 c1c1 e084 44fd c2c2 0000 e090
0252000 051c 0616 0705 7f03 c1c1 e084 03fc c2c2
2217240 3608 3784 3897 390a 3a06 7ff3 c1c1 e084
7305340 7a07 7b21 7c16 7d0c 7e02 7f02 c1c1 e084
0605320 7913 7a10 7b0b 7c06 7ef3 7f0a c1c1 e084
6371500 a00a 7ff3 c1c1 e084 53fc c2c2 0000 e090
7655120 a328 a228 a128 a028 7e08 7f10 c1c1 e084
6714700 75f3 a32a a22a a12a a02a 7f04 c1c1 e084
4506620 340c 35e7 36e6 3711 3804 7f03 c1c1 e084
7562460 3718 381c 3903 a02a 7ff3 c1c1 e084 35fc
5305440 7ff3 c1c1 e084 03fc c2c2 0000 e090 03fc
1313040 c1c1 e084 88fc c2c2 0000 e090 88fc 8302
</pre>
<!-- Date: Mon Aug 2 13:02:02 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4802&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4802  width='300' align='top'></a></td><td>AVDD current for SB0W3L2.</td></tr></table>
<!-- Author: Corrinne and Rong-Shyang -->

<!-- Date: Mon Aug 2 13:04:51 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W3L2 
<li>problem n: 860 
<li>Status: needs_observation
<li>Type: Unknown
<li>Action: IMON_limits
<li>entered by: rong 
<li>description is: Change high end to avoid pinky.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>720</td><td>720</td></tr>
<tr><td><b>Lower</b></td><td>640</td><td>640</td></tr>
<tr><td><b>Upper</b></td><td>725</td><td>735</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W3&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Aug 2 13:09:28 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4803&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4804  width='300' align='top'></a></td><td>SVT spymon plot for Store 3699/run 185848</td></tr></table>
<!-- Author: Corrinne and Rong-Shyang -->
<!-- Comment: Mon Aug  2 13;21;13 comment by...Corrinne and Rong -->
<pre>SVXMon restarted and now is blue on e084.</pre>

<!-- Date: Mon Aug 2 13:23:44 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W8L4 
<li>problem n: 1287 
<li>Status: needs_access
<li>Type: DVDD
<li>Action: Removed_hdwdb
<li>entered by: rong 
<li>description is: DVDD draw 0 current with higher AVDD current. Didn't get fixed after hocerization. <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=207&frame=2&anchor=12:41:53'> See here</a> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W8&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Aug 2 14:28:35 2004 -->
<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 362 finished successfully.

Job info
--------
Calibration type : standard
DPS-off run      : 185799
DPS-on run       : 185798
Requested by     : Jason Nielsen
Submitted        : 2004-08-02 09:39:34
Completed        : 2004-08-02 14:28:33
Status           : SUCCESS
Comment          : resubmit after k5login fix
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->



<!-- Date: Mon Aug 2 14:51:35 2004 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4808&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4809' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4807&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4807' width='300'></a></center>
<!-- Author: Rong-Shyang -->
<!-- Comment: Mon Aug  2 14;53;14 comment by...Rong-Shyang -->
<pre>AVDD current for e184. Everytime the DAQ halted, it got pinky.
Adjust the limit accordingly.</pre>

<!-- Date: Mon Aug 2 14:58:26 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W8L4 
<li>problem n: 1235 
<li>Status: needs_observation
<li>Type: Other
<li>Action: IMON_limits
<li>entered by: rong 
<li>description is: AGAIN<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>1100</td><td>1105</td></tr>
<tr><td><b>Lower</b></td><td>1065</td><td>1090</td></tr>
<tr><td><b>Upper</b></td><td>1110</td><td>1120</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W8&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Aug 2 16:50:54 2004 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4810&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4810' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4811&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4811' width='300'></a></center>
<!-- Author: reid and gino -->
<!-- Comment: Mon Aug  2 16;54;28 comment by...Reid and Gino -->
<h3>Crowbar Studies</h3>
Spent some time on the bench trying to understand the current spikes in L00 supplies that keep killing crowbars.  We borrowed a current probe from our friends at FCC to measure the current being drawn from the supply directly.  We modified a L00 HV cable adaptor so that it could be used with the current probe.  <p>
The supply was turned on without a load attached.  We would then attach a small resistor (12k Ohm - 5k Ohm) and measure the current spike that we could produce<p>
The max current setting in the L00 supply is 3000 uAmps.  In the first picture, the yellow trace is at 13 or so volts with about a 5k resistor.  The current drawn is just under 3000uAmps in this case.  The other traces are for larger voltages.  The upper-most curve is for a voltage of 137 Volts.  The trace shows current.  Each 10mV division corresponds to about 4.7mA as measured by the current probe.  So, in the case of the 137V trace, we measure a current spike of more than 23mA!<p>
There is a kink in each of the current plots.  I believe that after about 5 or 6 mSec, the supply realizes that there is an Over Current situation and it tries to clamp the voltage to a value such that the current is kept below the maximum allowed value.  If the OvC situation persists for longer than about two seconds, then the supply trips.  All of the traces in the above picture caused an OvC trip except for the yellow trace where the currents were under the 3000uA max current setting.<p>
The second picture is a blow-up of the first.  The reference trace is once again the 137V setting. The yellow trace shows us blowing a crowbar fuse.  The spec sheet says that the fuse should blow in about 1 mSec at these currents and sure enough, the fuse behaves as expected.


<!-- Date: Tue Aug 3 17:15:03 2004 -->
<h3>Silicon Access Report</h3> 
3 crowbars were replaced during this access: 
<ul> 
<li>LB0W0L31 
<li>LB0W1L30 
<li>LB1W0L31 
</ul> 
 
We also inspected the recent DVDD problem with SB0W8L4 which started drawing zero current a day or so ago.  There is no data from this ladder.  We swapped the cable from SB0W8 with the supply from SB0W9 (the neighboring supply) and still saw zero current draw.  Since the problem stayed with the detector, we probed the low voltage cables and saw nothing abnormal as compared to other layers in the wedge and compared to the same layer in the neighboring wedge.   
 
<ul> 
<li>SB0W8 DVDD L4 - 3/1.9MOhms 
<li>SB0W8 DVDD L3 - 2.7/1.8MOhms 
<li>SB0W8 DVDD L2 - 3.1/1.9MOhms 
<li>SB0W9 DVDD L4 - 3.0/1.9MOhms 
</ul>
<!-- Author: reid, jennifer, matt, rainer -->


<!-- Date: Tue Aug 3 18:25:39 2004 -->
<h4> L1A rate dependent I_DVDD</h4> 
I tried to extract the DVDD current drawn by a chip depending on the L1A rate.  
I did the following : 
<ul> 
<li> Select good wedges (all ladders are healthy) </li> 
<li> Select a long run from around 25 kHz down to maybe 16 khZ L1A rate 
<li> For each ladder, normalize to the number of chips. </li> 
<li> Fit a line, assuming a linear dependence </li> 
<li> Repeat this exercise with another run </li> 
</ul> 
 
<p> 
I end up with the following expression: 
I_DVVD_Chip=10.71 +/- 0.05  +  0.13 +/- 0.003 * L1A_Rate (Khz) 
</p> 
This value is preliminary and can be improved by using more run. The other problem is of course the spread of the data points, i think, there is also room for improvement there. 
It should be clearly said, that the offset is pretty stable, but the rate term is quite sensitive and really move a lot from run to run. 
The values obtained by this method are not completely incompatible with Rainer's <a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=201&frame=2&anchor=09:11:25'> 
measurement </a>. So we have at least an Idea, what to expect at 30 kHz L1A rate. 
I 'll add a plot to show the method. 
 
 
 
  
<!-- Author: Marcel -->


<!-- Date: Tue Aug 3 18:27:34 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4812&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4812  width='300' align='top'></a></td><td>The plots for the DVDD fitter, showing the current per chip and per layer and the 5 fitted lines in lower right plot. 
The spread is nicely visible here. </td></tr></table>
<!-- Author: Marcel -->


<!-- Date: Tue Aug 3 22:36:01 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4813&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4813  width='300' align='top'></a></td><td>Snapshot of PS gui after 1st reset of trips (that seemed to be caused by lightening.</td></tr></table>
<!-- Author: Adam Scott -->


<!-- Date: Tue Aug 3 23:09:35 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4814&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4814  width='300' align='top'></a></td><td>Snapshot of PS gui while there were red crates in RunControl.     Note there are no red ladders in the gui.</td></tr></table>
<!-- Author: Adam Scott -->


<!-- Date: Tue Aug 3 23:32:45 2004 -->
<pre>I was paged because several ladders had tripped (probably due to the thunderstorm). The SciCo asked for permission to turn the silicon OFF. I told him not to do that but rather to try to bring the tripped ladders back to STDBY. It seems that that was successful.</pre>
<!-- Author: Petra -->
<!-- Comment: Tue Aug  3 23;55;11 comment by...rainer -->
<pre>not at all - I was paged too and walked the ace to reset SVX which was mostly tripped off. on L00, the PSGui died, imon went haywire and I needed to come in. after resetting the PC, restarting the power supply gui, overcoming some rc odditity, all trips were reset. The ace reported trustworthily that there was no clock glitch reported by the PCC. either this was a mini clock glitch or a mini power supply glitch. now the silicon went through a coldstart ok and all trips are reset (and all programs restarted)
</pre>


<!-- Date: Tue Aug 3 23:56:17 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4815&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4815  width='300' align='top'></a></td><td>this is slightly unsettling.</td></tr></table>
<!-- Author: rainer -->


<!-- Date: Wed Aug 4 16:00:12 2004 -->
<H3>L00 IMON BIAS CURRENT LIMITS CHANGED</h3> 
I changed the lower IMON bias current limit on all L00 ladders that are known to draw current when biased. The previous limit was set to 0.5 with a variance of 0.5, which meant that it would only turn pink when it goes to 0 which seems to be interpreted as OFF or STDBY, not as biased but 0 current. So I changed the limit to 1.0 leaving the variance at 0.5 and tested with one ladder that it actually turns pink when current is below 0.5. <br> 
This should help us spot immediately when a crowbar blows. <br> 
The list of ladders that does not draw any current yet even when fully biased, is given here:<br> 
LB0W0L0, LB0W0L1, LB0W2L3/0, LB0W2L3/1, LB0W4L0, LB0W4L3/0, LB1W0L0, LB1W0L1, LB1W0L2, LB1W0L3/0, LB1W3L3/0, LB1W5L2, LB1W5L3/0<br> 
so for these we still need input from David in order to decide on blown crowbars.
<!-- Author: Petra -->


<!-- Date: Wed Aug 4 18:12:28 2004 -->
I took out e171 to avoid possible disaster could happen at Steve mentioned <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=206&frame=2&anchor=15:47:35'> 
here</a>. After regenerating CAEN files, I first maually edit powerset.dat to put in SB1W7 then try to restart PSGUI. 
Below is the message in SVXInter 
<pre> 
--------------------- 
Connection 127.0.0.1:1024 aborted, status is -1 
Conf file is /mnt/autofs/cdf/people2/svxii/daq/PSanywhere/PS.conf  
$CAENCONTROL_DIR 
Mapping file is $CAENCONTROL_DIR/CAEN.map 
Voltage file is $CAENCONTROL_DIR/CAENvolts.dat 
PowerSet file is $CAENCONTROL_DIR/powerset.dat 
LV Currents file is $CAENCONTROL_DIR/CAENLVcurrent.dat 
Using local rtlm  
---------------------</pre> 
PSGui still looks for powerset.dat which is different than I thought. But anyway the file has the SB1W7 in. 
For the coming store, we should make sure the SOC is biased  
when the SVX is up. 
 
At the same time, David Stuart will talk to Andrew and Eva to find the other way to initiate SB1W7 directly by enable f231. 
  
<!-- Author: Rong-Shyang -->

<!-- Date: Thu Aug 5 10:33:11 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W8L4 
<li>problem n: 1287 
<li>Status: needs_work
<li>Type: DVDD
<li>Action: Diagnosis_update
<li>entered by: rong 
<li>description is: The access, see <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=207&frame=2&anchor=17:15:03'> here</a>, didn't fix it.    
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W8&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Aug 5 12:22:39 2004 -->
<table><tr><td><a href=/elog/notebooks/silicon/Thu_Aug__5_2004_122218.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4817  align='top'></a></td><td>SVT plot for 3711. 
 
</td></tr></table>
<!-- Author: corinne,rainer -->


<!-- Date: Thu Aug 5 13:31:38 2004 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4818&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4819' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4820&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4821' ></a></center>
<!-- Author: Rong-Shyang -->
<!-- Comment: Thu Aug  5 13;34;39 comment by...Rong-Shyang -->
<pre>Bias line for f802 showed pinky in the begining of the store.
Somehow it got slow response after the bias was turned on.
I also put the plot for his neighbor (f803, same PS), so you can
see at the time stamp of 12:06:54, f803 has been on for a while but f802 showed 0 current.</pre>



<!-- Date: Thu Aug 5 14:12:25 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4823&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4823  width='300' align='top'></a></td><td>current of AVDD of e1a1 for recent days.</td></tr></table>
<!-- Author: Rong-Shyang  -->

<!-- Date: Thu Aug 5 14:15:36 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W10L1 
<li>problem n: 1326 
<li>Status: needs_observation
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: rong 
<li>description is: Change IMon limit to avoid pinky.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>470</td><td>473</td></tr>
<tr><td><b>Lower</b></td><td>460</td><td>463</td></tr>
<tr><td><b>Upper</b></td><td>475</td><td>478</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W10&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Aug 5 14:17:30 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W10L1 
<li>problem n: 1326 
<li>Status: needs_observation
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: rong 
<li>description is: Plot is <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=207&frame=2&anchor=14:12:25'> here</a><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>??</td><td>??</td></tr>
<tr><td><b>Lower</b></td><td>??</td><td>??</td></tr>
<tr><td><b>Upper</b></td><td>??</td><td>??</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W10&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Aug 5 14:47:07 2004 -->
<pre>practiced some pager carrier diagnosis for bad ladders. were reminded that looking at raw data now only makes sense on uncompressed stream D since stream A appears to be compressed now. 
</pre>
<!-- Author: corinne, rainer -->
<!-- Comment: Fri Aug  6 08;13;04 comment by...SCN -->
I think the <a href="http://www-cdf.fnal.gov/internal/silicon/silicon_commission/daq/sidaq_sop.html#sidaq_evDump">Event Dumping tools</a> already handle the compressed/uncompressed banks (i.e. they run SvxqModule) but I won't guarentee it.  They do not
handle the short-swapping issues... 

<!-- Date: Fri Aug 6 11:16:21 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W7L1 
<li>problem n: 1286 
<li>Status: fixed
<li>Type: Other
<li>Action: Removed_hdwdb
<li>entered by: rong 
<li>description is: Removed to avoid disaster. See also <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=207&frame=2&anchor=18:12:28'> here</a> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W7&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Aug 6 12:37:00 2004 -->
<center><a href='/elog/notebooks/silicon/Fri_Aug__6_2004_123608.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4825' ></a><a href='/elog/notebooks/silicon/Fri_Aug__6_2004_123634.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4827' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4828&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4829' ></a></center>
<!-- Author: Rong-Shyang -->
<!-- Comment: Fri Aug  6 12;39;30 comment by...Rong-Shyang -->
<pre>Quiet time on e254.
By changing Rdriver, I can manage to have some data back for many chips. But it still tripped a lot everytime I change setting, see the current history. At one point I increased the current limit to 550-450 (default is 450-350) on DVDD, but it still tripped.
So ladder still out of HWDB.</pre>

<!-- Date: Fri Aug 6 12:41:16 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W5L4 
<li>problem n: 85 
<li>Status: needs_study_time
<li>Type: DVDD
<li>Action: Diagnosis_update
<li>entered by: rong 
<li>description is: Could manage to have some data back, but ladder still kept tripping.See <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=207&frame=2&anchor=12:37:00'> here</a>. Ladder still out of HWDB.    
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W5&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Aug 6 15:53:58 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W6L2 
<li>problem n: 739 
<li>Status: unfixable
<li>Type: BIAS
<li>Action: Diagnosis_update
<li>entered by: rong 
<li>description is: Ladder used to perment Doim light level measurement. See thread 1219. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W6&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Aug 6 16:03:09 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: IB2W2L0 
<li>problem n: 581 
<li>Status: unfixable
<li>Type: AVDD
<li>Action: LV_cable
<li>entered by: rong 
<li>description is: Portcard failure, See <a href='http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B2W2&layer=All'> here </a> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B2W2&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Aug 6 16:26:30 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W5L4 
<li>problem n: 1138 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: Diagnosis_update
<li>entered by: bbrau 
<li>description is: SB1W5 IBias0L4 indicates that since about DSDay 1275 (June 2004) there is bias current drawn, and ADCMon run 2d670 (taken early August 2004) also looks like there is physics.  Keep an eye on this one until shutdown and again after shutdown for a couple of weeks. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W5&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sat Aug 7 07:36:40 2004 -->
<b> SB5W2L2 DVDD trip </b>  
<p> 
wedgewide power cycle did not work so aces paged me. ramping the ladders one by one did the job. DVDD history to follow. 
<p> 
<pre> 
 
 at Aug 07 07:22:08 CDT 2004     TRIP: SVX  B5  W2 DVDD2 OverCurrent 
Sat Aug 07 07:23:03 CDT 2004     success: Resetting trips 
Sat Aug 07 07:23:45 CDT 2004     success: Channel2 SVX B5 W2 ON 
Sat Aug 07 07:23:52 CDT 2004     TRIP: SVX  B5  W2 DVDD2 OverCurrent 
Sat Aug 07 07:24:52 CDT 2004     success: Power Supply SVX B5 W2 OFF 
Sat Aug 07 07:24:58 CDT 2004     TRIP: SVX  B5  W2 DVDD0 OverCurrent 
Sat Aug 07 07:24:58 CDT 2004     TRIP: SVX  B5  W2 DVDD3 OverCurrent 
Sat Aug 07 07:25:05 CDT 2004     ERROR: Power Supply SVX B5 W2 Handshake - Could 
 not turn on power - checked 10 times 
Sat Aug 07 07:25:12 CDT 2004     TRIP: SVX  B5  W2 DVDD0 OverCurrent 
Sat Aug 07 07:25:12 CDT 2004     TRIP: SVX  B5  W2 DVDD3 OverCurrent 
Sat Aug 07 07:30:31 CDT 2004     success: Port Card SVX B5 W2 ON 
Sat Aug 07 07:30:48 CDT 2004     success: Channel2 SVX B5 W2 to STANDBY 
Sat Aug 07 07:30:57 CDT 2004     success: Channel0 SVX B5 W2 to STANDBY 
Sat Aug 07 07:31:00 CDT 2004     success: Channel1 SVX B5 W2 to STANDBY 
Sat Aug 07 07:31:03 CDT 2004     TRIP: SVX  B5  W2 DVDD1 OverCurrent 
Sat Aug 07 07:31:05 CDT 2004     success: Channel3 SVX B5 W2 to STANDBY 
at Aug 07 07:31:08 CDT 2004     success: Channel4 SVX B5 W2 to STANDBY 
Sat Aug 07 07:31:12 CDT 2004     TRIP: SVX  B5  W2 DVDD3 OverCurrent 
Sat Aug 07 07:31:12 CDT 2004     TRIP: SVX  B5  W2 DVDD4 OverCurrent 
Sat Aug 07 07:31:33 CDT 2004     success: Channel1 SVX B5 W2 to STANDBY 
Sat Aug 07 07:31:36 CDT 2004     success: Channel3 SVX B5 W2 to STANDBY 
Sat Aug 07 07:31:40 CDT 2004     success: Channel4 SVX B5 W2 to STANDBY 
Sat Aug 07 07:31:52 CDT 2004     success: Channel0 SVX B5 W2 ON 
Sat Aug 07 07:31:59 CDT 2004     success: Power Supply SVX B5 W2 ON 
</pre> 
  
<!-- Author: rainer -->


<!-- Date: Sat Aug 7 07:44:13 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4830&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4830  width='300' align='top'></a></td><td>DVDD history for B5W2L2 trip described by Reiner above.</td></tr></table>
<!-- Author: Steve -->
<!-- Comment: Sat Aug  7 07;48;11 comment by...steve -->
<pre>There was an 80kHz LostP spike at 07:10 correlated with a jump
in C:BQUAKE.  This trip occurred 12 minutes later.</pre>


<!-- Date: Sat Aug 7 08:06:31 2004 -->
<table><tr><td><a href=/elog/notebooks/silicon/Sat_Aug__7_2004_080554.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4832  align='top'></a></td><td> </td></tr></table>
<!-- Author: corrinne -->
<!-- Comment: Sat Aug  7 08;09;15 comment by...Rainer and corrinne -->
<pre>SVT SPYMON plot for store 3715</pre>


<!-- Date: Sat Aug 7 10:07:54 2004 -->
<b> trigger table test of PHYSICS_TEST_2_05 [34,530,483] </b> 
this morning, a trigger table test was performed without and with silicon. 
the table has fractional prescales enabled as well as UPS on two 
individual triggers, #40 L1_TEST_TWO_TRK2_DPHI90_UPS and #41 
L1_TEST_TWO_TRK2_OPPQ_DPHI135_SUMPT5.5_FPS [1], see run 186043. the rates 
chnged from about 16 kHz to 23 kHz after the UPS change which is well 
below the current handbrake limit of 30 kHz fred l1 rate. 
 
this table will be made default for the next shot. 
<!-- Author: corinne, rainer -->


<!-- Date: Sat Aug 7 15:37:09 2004 -->
<b> SB5W2L2 DVDD trips again </b> and cannot be reset by ace. dropping the ladder from home I cannot write the CAENvolts.dat from the traceSilicon program, getting  
<pre> 
 
SQL*Plus: Release 8.1.7.0.0 - Production on Sat Aug 7 15:20:06 2004 
 
(c) Copyright 2000 Oracle Corporation.  All rights reserved. 
 
oration.  All rights reserveERROR: 
ORA-00020: maximum number of processes () exceeded 
 
 
Enter user-name:  () exceeded 
 
 
</pre> 
I mark the ladder by hand in the existing CAENvolts.dat and re-read the CAENvolts.dat which is now not a link but a real file so don't delete this until I can fix this when the database is available again.
<!-- Author: rainer -->
<!-- Comment: Mon Aug  9 10;31;58 comment by...rainer -->
CAENvolts.dat re-written so everything back to normal now.
<!-- Date: Sun Aug 8 09:14:41 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W2L2 
<li>problem n: 383 
<li>Status: needs_quiet_time
<li>Type: DVDD
<li>Action: Command_signal
<li>entered by: rainer 
<li>description is: persistently tripped on DVDD OC and OV. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W2&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sun Aug 8 10:42:08 2004 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 363
Calibration type  : standard
Run period tag    : Aug_2004
DPS-off run       : 186051
DPS-on run        : 186050
Requested by      : Regis Lefevre
Main process id   : 21071024
Comment           : B0Lum ~ 10.7E30
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->


<!-- Date: Sun Aug 8 15:52:19 2004 -->
<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 363 finished successfully.

Job info
--------
Calibration type : standard
DPS-off run      : 186051
DPS-on run       : 186050
Requested by     : Regis Lefevre
Submitted        : 2004-08-08 10:36:18
Completed        : 2004-08-08 15:51:19
Status           : SUCCESS
Comment          : B0Lum ~ 10.7E30
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->



<!-- Date: Sun Aug 8 21:54:14 2004 -->
This store (3717) went in very cleanly with initial lumi of 80e30 and low, stable losses.   
<br><br> 
This run (186081, and very briefly 186080 which ended quickly due to L3 problems) is the first one to be done with the new trigger table PHYSICS_2_05 [17,531,484], which has fractional prescale and uber prescale included.   
<br><br> 
The L1 accept rate started out at about 20 kHz.  There are no pinkies in IMON (masked the known AVDD high-trigger-rate pinkies described June 7 19:24), and no resonance errors reported.  Everything looks fine in SVXMon, too.   
<br><br> 
Waiting to see if everything stays fine through the fractional/uber prescales coming on.  Run so far has been plagued  by L2 decision timeouts and CMX trips.  Will also post SVT plot at that point.
<!-- Author: corrinne -->
<!-- Comment: Sun Aug  8 22;09;08 comment by...corrinne -->
One odd thing is that we keep getting "stuck cellid" errors in Run Control from IB3W1L4, particularly C4-7 and C8-11.  This causes and HRR every few minutes (see 
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2004&action=view&page=586&frame=2&anchor=20:58:34.829'>
here </a>).  Problem DB says this is a troubled ladder anyways (bit 6 stuck low).

<!-- Comment: Sun Aug  8 22;11;27 comment by...c -->
On the bright side <b> the fractional and uber prescales just kicked in and everything looks just fine.</b>


<!-- Date: Sun Aug 8 22:15:31 2004 -->
<table><tr><td><a href=/elog/notebooks/silicon/Sun_Aug__8_2004_221457.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4834  align='top'></a></td><td> </td></tr></table>
<!-- Author: corrinne -->
<!-- Comment: Sun Aug  8 22;16;03 comment by...corrinne -->
<pre>SVT plot for store 3717</pre>


<!-- Date: Sun Aug 8 22:33:37 2004 -->
<table><tr><td><a href=/elog/notebooks/silicon/Sun_Aug__8_2004_223331.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4836  align='top'></a></td><td> </td></tr></table>
<!-- Author: corrinne -->
<!-- Comment: Sun Aug  8 22;34;59 comment by...corrinne -->
This is the occupancy for the chip reporting stuck cellid's.  Rainer advised me to try to powercycle this ladder off and back on again when we restart the run, which will be soon.  

<!-- Comment: Sun Aug  8 22;53;20 comment by...c -->
<pre>Just did the power cycle now, between runs.  We will see if it helps.</pre>

<!-- Comment: Sun Aug  8 22;57;12 comment by...Marcel -->
in a similar situation, also restarting SVXMON helped ...

<!-- Comment: Mon Aug  9 00;38;54 comment by...corinne,rainer -->
...which is voodoo and did not help this time. anyway, we masked chips C4-C11 in the file<pre>/cdf/svx/svxmon/SvxMonConfig/stuckChips.txt </pre>
as the stuck cell id error is not life threating.
</pre>


<!-- Comment: Mon Aug  9 00;52;58 comment by...rainer -->
sure enough, C12-15 acted up as well. taken out as well relentless. 
<!-- Comment: Mon Aug  9 02;35;13 comment by...rainer -->
f142 C12-15 was acting up as well. chips masked in svxmon (look ok in occupancy plot).
<!-- Date: Mon Aug 9 00:43:42 2004 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4837&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4837' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4838&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4838' width='300'></a></center>
<!-- Author: rainer -->
<!-- Comment: Mon Aug  9 00;45;37 comment by...corinne, rainer -->
<pre>e273 avdd started drawing 16mA current instead of >800mA. voltage was 88 V which was obviously nonsense. hockerizing SW Bot Bot crate 6 brought it back to normal. SVXMon occupancies looked fine  all the time. another incident of power supply madness.
</pre>




<!-- Date: Mon Aug 9 02:40:35 2004 -->
e122 is suddenly drawing  higher AVDD current, see main  <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2004&action=view&page=587&frame=2&anchor=02:20:19.130'> 
elog </a>. data appears to be ok on the phi side. the z side was lost due to avdd2 earlier.
<!-- Author: rainer -->


<!-- Date: Mon Aug 9 09:21:13 2004 -->
<center><a href='/elog/notebooks/silicon/Mon_Aug__9_2004_092049.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4842' ></a><a href='/elog/notebooks/silicon/Mon_Aug__9_2004_092057.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4844' ></a></center>
<!-- Author: corinne, rainer -->
<!-- Comment: Mon Aug  9 09;22;03 comment by...rainer -->
AVDD and DVDD history of SB5W2L2. no conspicuous behavior. suggest hockerizing the power supply at earliest convenience.


<!-- Date: Mon Aug 9 10:35:18 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: IB3W1L4 
<li>problem n: 1089 
<li>Status: unfixable
<li>Type: Chip_bit_error
<li>Action: Incident
<li>entered by: mystery-guest 
<li>description is: gave stuck cell ID errors C04-15 so were masked in SVXMon stuckChip.txt file. (corrinne) 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B3W1&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Aug 9 10:35:18 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: IB3W1L4 
<li>problem n: 1089 
<li>Status: unfixable
<li>Type: Chip_bit_error
<li>Action: Incident
<li>entered by: mystery-guest 
<li>description is: gave stuck cell ID errors C04-15 so were masked in SVXMon stuckChip.txt file. (corrinne) 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B3W1&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Aug 9 10:37:46 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W4L2 
<li>problem n: 188 
<li>Status: unfixable
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: mystery-guest 
<li>description is: gave rise on stuck cell id errors in SVXMon from chips C12-15. masked in stuckChip.txt file (corrinne) 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B1W4&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Aug 9 10:41:54 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W3L3 
<li>problem n: 1267 
<li>Status: fixed
<li>Type: Unknown
<li>Action: Diagnosis_update
<li>entered by: bbrau 
<li>description is: Not seen through run 186083.  Fixed. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W3&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Aug 9 10:48:20 2004 -->
Last night on the owl shift we had two instances of a CAEN ps spontaneously quitting.  At different times,  
<a href= 
'/cgi/elog/elog.pl?nb=2004&action=view&page=587&frame=2&anchor=02:23:30.291'>all of the wedges powered by ps 12 quit</a>,  
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2004&action=view&page=587&frame=2&anchor=06:22:44.422'> 
and then all of the wedges in ps 8 quit</a>.   
(Links are to main e-log entries)
<!-- Author: corrinne -->
<!-- Comment: Mon Aug  9 10;50;56 comment by...rainer, corrinne, julia -->
exerpt from svxinter garble
<pre>
Group Name: "GROUP00"
 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
WARNING: found a power supply in the crate, which is not connected to a wedge in the detector, or absent in CAEN.map,  cr_n = 12, bd_n = 2
 Caenet_write: Error number -253 received

cr = 12, bd = 2,Errcode 10
WARNING: found a power supply in the crate, which is not connected to a wedge in the detector, or absent in CAEN.map,  cr_n = 12, bd_n = 6
 Caenet_write: Error number -253 received

cr = 12, bd = 6,Errcode 10
</pre>