<!-- Title: 10:48:58  Mon Nov 26 2007 -->
<!-- Crewchief: Juan Pablo (MPC) -->
<!-- Op1: Ignacio (SPL) -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>The cell phone number this week (Juan Pablo's cell) is  
630 531 1218</pre>


<!-- Date: Mon Nov 26 11:02:41 2007 -->
KC: 
<pre> 
I exchanged SVX vacuum pump 1A with a rebuilt pump that read 1.2psia on the bench.  
</pre>
<!-- Author: Ignacio -->


<!-- Date: Mon Nov 26 11:23:14 2007 -->
Warren just informed Bill and me on the result of his work with the spare chiller controller. We had the problem that it would not read remote set points so we had to run it on local set point. It turns out that the new controller, sold to us as the replacement product for the current controller model, is not capable of working with remote set points... We need to work out something. 
<!-- Author: Ulrich -->


<!-- Date: Mon Nov 26 12:51:29 2007 -->
 Fib03 error. Recovered after sheparding .  
 See this <a href= 
'/cgi/elog/elog.pl?nb=2007&action=view&page=923&frame=2&anchor=12:45:25.784'> 
 CDF elog </a>  entry
<!-- Author: Juan Pablo -->


<!-- Date: Mon Nov 26 14:09:47 2007 -->
I spoke with Bill today about the leaking flowmeter in the SVX DI circuit.  He tells me the glycol attacked the polycarbonate plastic the flowmeter is made out of, and that he has ordered new acrylic ones. 
<p> 
Only about a cup or two of glycolic fluid appaered in the bucket under the flowmeter as of this morning. 
  
<!-- Author: Tom -->


<!-- Date: Mon Nov 26 20:35:32 2007 -->
<pre>Auto hockerization of PS crate #2 . 
No problems.</pre>
<!-- Author: Juan Pablo -->


<!-- Date: Mon Nov 26 22:15:58 2007 -->
Trigger test done without any harm. Details <a href= 
'/cgi/elog/elog.pl?nb=2007&action=view&page=924&frame=2&anchor=21:14:39.222'> 
here </a> 
<!-- Author: Juan Pablo -->


<!-- Date: Mon Nov 26 22:41:12 2007 -->
<pre>Closed the PS GUI ,rebooted svxinter , logged out 
from b0svxda01 and came back. 
The system came back in a funny state indicating a problem 
with the graphics display (very large appearance of icons 
and not even able to see the bar at the bottom). 
 
 Did a control+alt+backspace and restarted again the log in. 
This time it came back fine ( normal size of icons and  
everything showing up )  
 
 Restarted the PS GUI. 
 
 ISL B4 W0 L1 reported off but reading above 50mA. Tried  
hockerizing but did not work. Surprisingly enough this 
ladder is out of the HWDB.</pre>
<!-- Author: Juan Pablo -->


<!-- Date: Tue Nov 27 00:04:50 2007 -->
<pre>Store 5751, Init Lumi 155; Lostp 11.5kHz, Lostpb 5.0kHz. 
Will start the run with silicon.</pre>
<!-- Author: Juan Pablo -->


<!-- Date: Tue Nov 27 00:20:25 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12103&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12103  width='300' align='top'></a></td><td> </td></tr></table>
<!-- Author: Juan Pablo -->
<!-- Comment: Tue Nov 27 00;21;33 comment by...Juan Pablo. -->
<pre>SVT spy plot is shown above.
SVXMon seems fine.</pre>


<!-- Date: Tue Nov 27 01:31:11 2007 -->
<pre>I put the pre- and post-shutdown current studies plots into a webpage, to more easily view them. It is located at helen.pha.jhu.edu/~mmathis/SiPS/ . As I mentioned before, a couple plots need to be remade, I will try and do them while sitting in the control room tonight</pre>
<!-- Author: Mark -->


<!-- Date: Tue Nov 27 05:58:02 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12104&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12105  width='300' align='top'></a></td><td> Just going over the VBIAS limit. 
Slow rise, not indicating any problem other than 
radiation.</td></tr></table>
<!-- Author:  Juan Pablo -->


<!-- Date: Tue Nov 27 06:09:14 2007 -->
<pre>Got several resonances separated by 2-3 minutes in a row. 
Could look at the trace. I am not able to setup properly 
the LA. Since things are in normal state now I will  
until the 8 am meeting.</pre>
<!-- Author: Juan Pablo. -->


<!-- Date: Tue Nov 27 08:33:21 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12106&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12106  width='300' align='top'></a></td><td>We had 2 clock glitches tonigth (~00:30, ~5:45). The trace of the first one was recorded. It shows a long glitch in the SVX clock (100 mus) after the SRC error. There is a short glitch (~1 mus) before. ISL was fine. Both times BME SE 156 tripped. The only connection Phill sees is the fact that the trips makes RC go to halt. A clock glitch should not trip the BMU. The second glitch and subsequent resonances were not recorded because of the windows update that reboots the machine.</td></tr></table>
<!-- Author: Juan Pablo/Ignacio -->
<!-- Comment: Tue Nov 27 08;35;02 comment by...Ignacio -->
<table border=0><td><tr><td bgcolor=#e0e030>Please use the last version of the LA code if you restart it  (to include the clock synck).</td></tr></td></table>

<!-- Comment: Tue Nov 27 09;09;43 comment by...Ignacio/JP/Sasha/Sebastian -->
<a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12108&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12108' width='300'></a>
<br>
<br>
This trace shows the same error as the first trace above. There was a small (about 0.5us) glitch in CDFCLK (aka sync) which caused an SRC error in SVX and 100us later the SRC lost the BS signals. There was no error reported by the CDFCLK crate and no trigger in the osciloscope downstairs. I think this is the most common clk glitch we are facing, the one from yesterday - where we lost the input cdfclk for a long time and the cdflck crate reported an error (see <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=380&frame=2&anchor=15:24:32'>here</a>) - being a rare one. 

<!-- Comment: Tue Nov 27 09;16;16 comment by...s/s -->
A closer look at the traces shows that there was also a small glitch in the ISL clk signals at the time of the small glitch on SVX (the trace for this incident is tmp271107.ala).

<!-- Date: Tue Nov 27 13:24:39 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W3L4 
<li>problem n: 1216 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: fernand 
<li>description is: raising limits this ladders is increasing current steadly lately<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>2416</td><td>2716</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>2750</td><td>3050</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W3&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Nov 27 13:32:55 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W6L4 
<li>problem n: 2463 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: fernand 
<li>description is: Raising bias limits<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>38</td><td>58</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>100</td><td>120</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W6&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Nov 27 13:36:05 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W7L2 
<li>problem n: 1882 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: fernand 
<li>description is: Raising limits (stable current lately; it' s time to unmark and see)<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>332</td><td>362</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>362</td><td>392</td></tr></table> 
<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: Tue Nov 27 13:39:08 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W9L4 
<li>problem n: 1881 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: fernand 
<li>description is: raising bias limits<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>120</td><td>140</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>145</td><td>165</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W9&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Nov 27 13:41:36 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W11L4 
<li>problem n: 2464 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: fernand 
<li>description is: Raising bias limits (steadly increasing)<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>43.8</td><td>63.8</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>100</td><td>120</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W11&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Nov 27 13:58:10 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W0L0 
<li>problem n: 2357 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: fernand 
<li>description is: raising bias limits<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>42.9</td><td>62.9</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>130</td><td>150</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W0&layer=L0">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Nov 27 14:54:25 2007 -->
<pre>Beam aborted. No need to but instructed aces to do  
post-quench checkout for training purposes.</pre>
<!-- Author: Juan Pablo. -->


<!-- Date: Tue Nov 27 15:35:52 2007 -->
<h3>SVXIICON Program Changes</h3> 
We have updated two of the standalone programs on SVXIICON today: We fixed a bug in PSMon.exe with a lost file pointer. Now the program will try again and open an alternative log file. Should both fail, PSMon.exe will give up but not crash. In Alarms.exe we took out all human e-mail addresses from the mail notification and just left svx-messages@b0sili01.fnal.gov (for both alarms and warnings) and the alphanumeric pager (only for alarms). Those will be relayed by svx-messages in the future.
<!-- Author: Tom & Ulrich -->
<!-- Comment: Tue Nov 27 17;17;48 comment by...Tom & Ulrich -->
<pre>Turns out that the .forward file Ricardo added to the svx-messages account on b0sili01 breaks the script that parses the mail and puts iFix alarms on the web. So that's not working at the moment. We'll figure something out.</pre>


<!-- Comment: Thu Nov 29 15;40;28 comment by...Ricardo -->
This is fixed now. We forward and copy simultaneously, so the script can run, and we get the emails as well. The fix was provided by SashaS.
<!-- Date: Tue Nov 27 17:43:48 2007 -->
After talking to JDL I am now sending the tstsvx1 bs signals to 
a NIM "clk translator" and the nim output to an oscilloscope that is triggering on the LA on the 1st floor. The idea is to try to see if cdfclk glitches in the teststand as well (it might take some time to catch the glitch, because the LA downstairs is triggering on SRC error, not on clkclk glitch).
<!-- Author: Sebastian -->


<!-- Date: Tue Nov 27 20:17:04 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12109&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12109  width='300' align='top'></a></td><td> What we see is IB4W0L1 IV curve 
 The red dots correspond to the period when it was working 
 The balck dots correspond to the period after it failed</td></tr></table>
<!-- Author:  Juan Pablo -->
<!-- Comment: Tue Nov 27 20;18;33 comment by...Juan Pablo e Ignacio -->
<pre>After the period it failed, the change of the current is
due to the temperature (we think the bias voltage is always
the same and the changes are due to temperature changes on 
the sensor)</pre>


<!-- Comment: Wed Nov 28 12;37;37 comment by...SashaS/Ignacio/Ricardo -->
We finished an 1.5 hrs access to try to understand the behavior of f401 (connected to caen #16, slot 5) which shows voltage and current even when the ladder is off (see this <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=381&frame=2&anchor=20:17:04'>
entry</a>). <br>
We should notice that all f40 channels are in the HDB except for channel 3. <br>
First we try connect PS in slot 5 to the load box to see if we spot something weird. <br>
<b>When PS was connected to the loadbox</b>
<ul>
  <li>with wedge in stand by<br>
		the Loadbox reads V=1.9 for channels 0,2,4. Channels 1,3 read 0V.<br>
		the PS gui reads V0=1.9V for all of them, except channel 3 (?)<br>
  </li>
  <li>with wedge fully on:<br>
		loadbox reads V0=45,99.6,44.6,0,54.4 for channels 0 to 4 respectively <br>
		the PS gui reads similar values.<br>
  </li>
</ul>
<b>When ladder f40 is connected to PS of f41 (slot 7)</b>
<ul>
  <li> with wedge in stand by:<br>
		the PS gui reads for channel 1, 0 current  and 0Volts.<br>
</li></ul>

<b>when everything is back in their original position. ladder f40 with PS f40 (slot5) and ladder f41 with PS f41 (slot7)</b>
<ul>
	<li>wedge in stand-by <br>
		the ps-gui reads 40v and I=100ua.<br>
        </li>
</ul>
The conclusion is not clear. From the loadbox test we do not see any bad behavior associated with the PS. However, when we use another PS to power the f40 ladder we see that the current and voltage readings for channel 1 are normal. We should try and replace the PS in Caen#16, slot 5 when we have time and enough spares.

<!-- Comment: Wed Nov 28 15;16;53 comment by...Satyajit -->
Since layer 3 is out of HDB you are not powering it. So it is 
expected to read 0 V. To definitely rule out the PS of having any
problem one needs to turn layer 1 ON w/o any load. This can be
done by jumpering J29 on the front panel and removing the
front panel cables. If you still see a weird voltage then the PS is
at fault. Otherwise it is just a "simple" case of the PS and the
detector not liking each other :-)

<!-- Date: Wed Nov 28 09:50:38 2007 -->
<pre>We are in a four hour controlled access. 
 
</pre>
<!-- Author: Ricardo -->
<!-- Comment: Wed Nov 28 12;18;18 comment by...Ricardo -->
We are out. Comments to follow.-


<!-- Date: Wed Nov 28 14:21:07 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W2L4 
<li>problem n: 1243 
<li>Status: needs_observation
<li>Type: DVDD
<li>Action: Change_last_chip
<li>entered by: ignacio 
<li>description is: In 11/02/07 e124 was taken out because it  was tripping on DVDD (while taking data). It has only two z chips left which give bit errors. We have chopped out this last two chips
and tested the rphi side. It has succesfully  run without tripping. It is now in the HWDB. We have also noticed that the previous chop did not set the rdriver for the chooped chips to 0.  If this works we could try to reinclude the last 2 chopped chips.  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W2&layer=L4">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Wed Nov 28 19:05:56 2007 -->
L00 switched OFF for 150 separator scan.
<!-- Author: Ignacio -->


<!-- Date: Thu Nov 29 05:36:52 2007 -->
<pre>L00 is on stby along with the rest of the silicon system</pre>
<!-- Author:   Juan Pablo  -->
<!-- Comment: Thu Nov 29 05;39;43 comment by...Juan Pablo. -->
<pre>Bring it up wedge by wedge.
Only one TRIP: L00  WEST  W4 DVDD2 OverCurrent</pre>


<!-- Date: Thu Nov 29 13:21:25 2007 -->
<!-- Author:  Juan Pablo -->
<!-- Comment: Thu Nov 29 13;36;47 comment by... Juan Pablo -->
<pre>Unfortunately e124 has 0 % occupancy.</pre>
<!-- Comment: Thu Nov 29 15;28;42 comment by...Ricardo -->
I got scared for a moment.
<!-- Comment: Thu Nov 29 16;04;41 comment by...Juan Pablo -->
<pre>When dumping the raw data, we see
garbage in e124.
 e124 03fc 8818 8718 4c07 4d13 4e05 
3156:7f04 c1c1 
 This is a L4 and should start with chip id 8d (1st chip
1st channel) and starts with chip id 88

 another one
 e124 44fc 881e 1e03 2010 871e 6f07 
1700:700a 710f 7201 7f04 c1c1

 third one
 e124 70fe 8820 8720 5bf3 5c0c 5d0e 5e25 
3904:5f0c 6002 7f06 c1c1</pre>
<!-- Date: Thu Nov 29 13:25:49 2007 -->
<pre>B1W3L4 bias current going over the limit at the begginning 
of the store. 
AVDD for B1W2L4 current going high ( the jump was up to about 1 chip,i.e. 80 mA ; anyhow, it was not a step but rather a gradual 
trend). 
</pre>
<!-- Author: Juan Pablo -->



<!-- Date: Thu Nov 29 14:09:49 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12111&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12111  width='300' align='top'></a></td><td>I put the svtspy plot too early. Sorry. Here is 
the plot with more stats.</td></tr></table>
<!-- Author:  Juan Pablo -->


<!-- Date: Thu Nov 29 15:04:09 2007 -->
<pre>ISL PS create 3 lost communication. Hockerized. Back working </pre>
<!-- Author: Juan Pablo and Ignacio -->




<!-- Date: Thu Nov 29 16:52:24 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB3W0L3 
<li>problem n: 2465 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: fernand 
<li>description is:  This ladder has started (since 26 of Nov) to develop the following bit errors : Unknown Channel, Unknown Chip error. This only is affecting the z side (low occupancy).  The rphi side is normal in SvxMon. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B3W0&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Nov 29 17:53:50 2007 -->
We worked on the program that makes distributions (like RBSY) from the LA. It turns out that if trying to save a LA program overwriting an existing file, that file will not work properly. Before writing the file it's needed to erase the old one. You think this is weird ?, call Agilent and complain about it. <br> 
Anyway, the code is fixed now and we could in principle see the distributions. Just follow the instructions Sebastian left in the twiki page  <a href="http://b0sili01.fnal.gov/cgi-bin/TWiki/bin/view/Silicon/RunningHistogramLogic"> here</a>.
<!-- Author: Ricardo & SebastianC -->

<!-- Date: Thu Nov 29 17:59:14 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W2L4 
<li>problem n: 1243 
<li>Status: svxmon_ignore
<li>Type: DVDD
<li>Action: Change_last_chip
<li>entered by: fernand 
<li>description is: Though this ladder gives no data in the run daq, it  does give data in the svxdaq. We would like to make sure the chip parameters are the same. We still keep this ladder in the database. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W2&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Nov 30 05:03:34 2007 -->
<pre>Looking at svxmon from the current store  
5761 : fine but 
 IB4W5L2 - bit errors : missing bit # 3 and last four chips 
 IB1W4L2 - bit errors : missing last bit 
 Losses are fine : 6 KHz for protons, 7 KHz for antiprotons 
 Initial lumi : 180 E30</pre>
<!-- Author: Juan Pablo -->


<!-- Date: Fri Nov 30 05:06:43 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12112&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12112  width='300' align='top'></a></td><td> SVTspy Mon</td></tr></table>
<!-- Author:  Juan Pablo -->


<!-- Date: Fri Nov 30 06:37:33 2007 -->
<table border=0><td><tr><td bgcolor=#e0e030>LOGIC ANALYZER USERS: CAN WHOEVER MAXIMIZE THE IFIX WINDOW IN VNODE 2 (IFIX)  STOP DOING IT, LEAVE IFIX IN ITS ORIGINAL STATE? I am tired of going behind cleaning up the mess to find that when trips happend the MPC does not have in front of his eyes the silicon inhibits window or the autohocker.</td></tr></td></table>
<!-- Author: Ignacio -->


<!-- Date: Fri Nov 30 07:19:37 2007 -->
<pre>Sequence of events (and failures) this morning 
[it is important to mention that they are ordered in time] : 
 
 1 ) B0W5L0 trips on DVDD overcurrent 
 2 ) aces think the trip is recovered  
but in fact it is not 
 3 ) I appear in the scene and just take a look at the  
PS GIU display. Since the wedge seems all green then  
I ask for a recover - run [my fault here is not to read 
what happened in the log and the tex window and just rely on the display - pressure to try to run a.s.a.p.] 
 
 ========>  the L0 on the GUY is so small that we all did not 
realize it was still red <=========================== 
 [again I say it is my fault because I should have read the 
text the 1st time and also do a "Full status" - I am refering to the bottom of the PS GUI] 
  
 4) since the ladder has not recovered we still have an inhibit 
but since we have not realized we try to move on 
 5) disable the inhibit 
 6) a few seconds later we have a problem with another wedge 
that trips (B5W8) 
 7) after succeding putting the system on halt we recover 
that new problem but still have the B0W5L0 off and the 
inhibit 
 8) realize the problem about B0W5L0 still being of 
 9) recover that ladder, reset trips and inmediately enable the inhibit 
     
 10) B0W5L0 keeps tripping on DVDD overcurrent 
 11) keep recovering , reseting trips and run 
 12) after several tries, I decide to take it out of the DB 
 13) the rc goes to the START state and a refresh for HWDB is issued 
 14) we start running smoothly (silicon wise) 
 
 
 Ignacio (SPL on call) was on the phone most of the time advising me. 
 Thank you very much Ignacio ! ! ! 
 
P.D. : I say it once more. It was my fault because I should have read the text the 1st time and also do a "Full status". Also to 
read what ladder was giving the Silicon Inhibit would have helped 
but I could not see that. So please, next time do not scroll up 
the ifix window in the vnode2 (HBM).</pre>
<!-- Author: Juan Pablo. -->


<!-- Date: Fri Nov 30 07:45:34 2007 -->
<pre>Just noticed in SVXMon that 
B3W9L3 is giving bit errors : bit 3 is missing</pre>
<!-- Author: Juan Pablo -->

<!-- Date: Fri Nov 30 08:24:18 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W5L0 
<li>problem n: 2466 
<li>Status: needs_work
<li>Type: DVDD
<li>Action: Incident
<li>entered by: fernand 
<li>description is:   Tripping on DVDD overcurrent several times on the morning of the 30th Nov07. Decided to took it out of the HWDB. Should study it during quiet time. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W5&layer=L0">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Nov 30 09:02:21 2007 -->
<pre>f452 is showing bit errors . Missing bit # 3.</pre>
<!-- Author: Juan Pablo -->
<!-- Comment: Fri Nov 30 09;15;26 comment by...Juan Pablo -->
<pre>I said that before. at 5 am (beginning of store). Umm. </pre>


<!-- Date: Fri Nov 30 11:29:54 2007 -->
A dmode calibration was taken, the job was submitted but there is no automatic entry in the e-log. 
<!-- Author: Ignacio -->

<!-- Date: Fri Nov 30 12:02:30 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W5L0 
<li>problem n: 2466 
<li>Status: svxmon_ignore
<li>Type: DVDD
<li>Action: Incident
<li>entered by: ignacio 
<li>description is: Mask it in SVXMON. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W5&layer=L0">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Nov 30 14:03:04 2007 -->
There will be doing Tev studies. Some ladders we have to investigate are: 
<ul> 
<li> <b>e050:</b>Tripped in DVDD overcurrent this morning. Reincluded it. Try usual wedge power cycle/hockerization.</li> 
<li> <b>e124:</b> Quit time studies.  Either reinclude one of z chopped chips or just put rdriver of the z side chips  equal to 3</li> 
<li> <b>f452:</b> bit 3 low is an roccuring problem since march this year reappearing. Go in to clean the fiber?</li> 
</ul>
<!-- Author: Ignacio -->
<!-- Comment: Fri Nov 30 15;49;42 comment by...Ignacio -->
e122: is it correctly chopped?
<!-- Comment: Fri Nov 30 17;18;58 comment by...Juan Pablo -->
<pre>e122 is correctly chopped.
According to the database all z side is chopped.
On top of that we have chips 85 and 86 chopped.
The last chip is then chip id 87 and what I see
in the cardEditor is 7 (that is what it should 
be written if we want the last chip id to be 87)</pre>
<!-- Comment: Fri Nov 30 17;57;05 comment by...Juan Pablo -->
<pre>e124 : it seems that we can run with no "intermitet
errors" (similar to those we see on the real daq) by choping two more chips in the rphi side (of course setting the rdriver and bias ratio to 0). I suggest to chop chip ids 88 and 89 (i.e.
set the last chip to a).</pre>
<!-- Comment: Fri Nov 30 18;22;26 comment by... Juan Pablo -->
<pre>f542 has been cleaned (the optimal fiber I mean)
on svxdaq it runs normally</pre>
<!-- Comment: Fri Nov 30 21;53;37 comment by...Juan Pablo -->
<pre>e124 : chip ids 87, 88 and 89 chopped in HWDB</pre>
<!-- Date: Fri Nov 30 14:06:10 2007 -->
<table border=0><td><tr><td bgcolor=#e0e030>Let me advertise that  Jose has made public his new PDB <a href='http://b0sili01.fnal.gov/pdb/PDB.php'> look</a>.  I love the IMON look!</td></tr></td></table>
<!-- Author: Ignacio -->



<!-- Date: Fri Nov 30 16:09:08 2007 -->
<pre>Put B0W5L0 back on the HWDB. 
Power cicled the wedge. DVDD is holding so far at 280 mA. 
Will monitor during quiet time studies.</pre>
<!-- Author:  Juan Pablo -->


<!-- Date: Fri Nov 30 16:41:30 2007 -->
<pre>L00 is now on stby</pre>
<!-- Author: Juan Pablo -->





<!-- Date: Fri Nov 30 22:01:18 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W2L4 
<li>problem n: 1243 
<li>Status: fixed
<li>Type: DVDD
<li>Action: Change_last_chip
<li>entered by: fernand 
<li>description is: Chopped three more chips (87,88 and 89) It seems to hold in svxdaq in such a configuration (rdriver and bias resistors set to 0) 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W2&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Nov 30 22:03:07 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W2L4 
<li>problem n: 1243 
<li>Status: fixed
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: fernand 
<li>description is: adjusting the limits on AVDD since we have 3 less chips<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>1300</td><td>1180</td></tr>
<tr><td><b>Lower</b></td><td>1260</td><td>1140</td></tr>
<tr><td><b>Upper</b></td><td>1360</td><td>1240</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W2&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Nov 30 22:06:19 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W5L0 
<li>problem n: 2466 
<li>Status: fixed
<li>Type: DVDD
<li>Action: Diagnosis_update
<li>entered by: fernand 
<li>description is: power cicled the wedge the ladders holds 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W5&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Nov 30 22:07:43 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W5L2 
<li>problem n: 1972 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: fernand 
<li>description is: Cleaned optical fiber. No bit errors in svxdaq 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W5&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Nov 30 22:24:30 2007 -->
<h3>HWDB screw up</h3> 
 
Well, I do not know how but I managed to delete the chipchains of two ladders (e123 and e121) using the ChipEditor. I was chopping the chips of e124 that Juan Pablo had suggested but could not get any chip in the HDI appear as last chip. The cardEditor had been edited beforehand. After openning and closing the chipEditor  few times  I forced chip 10 to be last chip and wrote to database.  
to my surprise I not only change what I intended but also wrote 0 as the bitstream of e123!  After Jose patiently helped me to rewrite the parameters of the chips in e123, a third  ladder (e121) went blanck as I wrote to  the database. Apparently the  ChipEditor losses tabs (~ladders) in memory., we saw tha happening in front of our eyes. A third interation with Juan Pablo checking that all the HDIs of the fib were present 
worked well. We have run the detector in a cold start but we cannot be 100 % sure the parameters are the same as before so we would like to revert the changes as soon as possible since the information is stored in the database. I have send Bill Badget a mail, he must know how to do that.   
<!-- Author: Ignacio -->
<!-- Comment: Fri Nov 30 22;25;08 comment by...Ignacio -->
<pre>The 2 changes to revert are
USER:  redondo
Crate: FIB_SVX_00
        CC_CARD_CARDNAME: FIB_04 (slot 15)
                CC_FIBCHANNEL: 1
                UPDATETIME: 2007-11-30 20:52:15.0
                FIELD: BITSTREAM
        CC_CARD_CARDNAME: FIB_04 (slot 15)
                CC_FIBCHANNEL: 3
                UPDATETIME: 2007-11-30 20:06:03.0
                FIELD: BITSTREAM
</pre>

<!-- Comment: Fri Nov 30 22;45;16 comment by...Ignacio -->
Run cosmics SILICON_TAPE. SVXMon looks good. The AVDD/DVDDD of e121 and e123 look as before.

<!-- Comment: Fri Nov 30 22;51;37 comment by...Jose -->
We could probably check with the old version of java 1.5 (<i>setup jdk v1_5_0 </i>) if the ChipEditor is working better.


<!-- Comment: Sat Dec  1 12;16;36 comment by...Ricardo -->
This sounds serious. Let's do checks only during very controlled circumstances.

<!-- Comment: Mon Dec  3 12;24;00 comment by...Ignacio -->
Today, Bill Badget replaced the Bitstreams of e121 and e123 by its original values. The only actual change was in the rdriver for e123, which we set to 4 on Friday and it was 3 originally. Looking at the cardEditor, <b>there are  4 other instances of the same error but they are only present in cardboard FIB_04! </b> Dates were 2004-6-15,2005-2-13 and 2005-1-25, 2005-3-14.
<!-- Date: Sat Dec 1 10:03:19 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12113&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12113  width='300' align='top'></a></td><td>Clock glitch at 2 am</td></tr></table>
<!-- Author: Juan Pablo -->


<!-- Date: Sat Dec 1 10:05:38 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12114&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12114  width='300' align='top'></a></td><td> zoom in of previous clock glitch (at 2 am) 
 Ricardo points that the source might be the board 
in the crate that send the cdf_clock to the src 
(since the cdf_clock that goes to the LA in the 1st floor 
did not see the glitch)</td></tr></table>
<!-- Author:  Juan Pablo -->
<!-- Comment: Sat Dec  1 10;12;08 comment by...Ricardo -->
The clock happened at 2:42 am. The BMU 156 tripped as well. 
The traces clearly show the corruption of the SYNC clock signal. 
For the scope in the second floor I have saved the trace of channel 1 in Ref 1 and  channel 4 (trigger from LA) in Ref 3.  I should mention that the trigger signal does not look very healthy in the scope, and i couldn't find where the time stamp was. If this was the LA trigger then we do not see the SYNC glitch in the scope above and we have to conclude that this could be related to some problem related to the clock fanout board.



<!-- Comment: Sat Dec  1 13;14;14 comment by...Ignacio -->
I think this is the first time it happens without any beam in the Tevatron. The coincidence of the BMU trip in this circustance is really puzzling.  I am surprised nothing tripped since there was no coldstart or HRR (nobody could have realized since we were out the rc configuration). I wonder if the LA sould send a mail to the alphanumeric pager...

<!-- Comment: Sat Dec  1 19;38;02 comment by...Sebastian -->
<b>No, this is not the first time it happens with no beam</b>. This same kind of glitch has been seen before. Did we pull SRC error? Otherwise we are just seeing it now because the LA is triggering on "SRC ERROR" OR "no CDFCLK for 200ns". I am not convinced (yet..) that the other CLK FOs don't have the problem. 


<!-- Comment: Sun Dec  2 11;28;29 comment by...Ignacio -->
I think Sebastian meant that there have been clock glitches without beam before. I meant this is the first time   <b>BMU 156 trips without beam</b> and  in coincidence with a clock glitch seen by the LA.
<!-- Comment: Sun Dec  2 12;29;37 comment by...Ricardo -->
We know the SYNC is not behaving properly period. Whether the SRC pulled an error or not is another story, and has nothing to do with the proven <b>failure of the SYNC clock</b> as it reaches the SRC.<br> The clock people should fix that. We can not delay this anymore; let's just connect the LA in the 2nd floor (as opposed to the scope) to triger in the LA signal of the 1st floor one, while looking at the SYNC obtained from the NIM crate Sebastian installed. Both LA's will tell the time stamp. If both LAs show a lack of signal it's the central clock, if only one does it then it's the clock fanout board, and at least we'll ask for it to be replaced.
<!-- Date: Sun Dec 2 03:28:03 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12115&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12115  width='300' align='top'></a></td><td>Store 5768 : Init lumi 190 E30 
</td></tr></table>
<!-- Author:  Juan Pablo -->


<!-- Date: Sun Dec 2 03:31:05 2007 -->
<pre>Store 5768 : Init lumi 190 E30 
Losses started high for protons , 15KHz, but going down smoothly 
(now at 11 KHz and going down). 
Antiprotons losses ok , 5 KHz. 
SVXMon :  
 e124 is giving data ! ! ! (Contratulations guys !) 
 [the 4 chips we left are there and the intermitent errors are gone] 
 e121 and e123 give reasnable occupancies and strip mean charge 
 e050 is green and happy (current wise) and looks also fine in SVXMon 
 f452 is not showing bit errors (Congratulations again !) 
but this ladder has very big wings 
 f303 shows data in the z side</pre>
<!-- Author: Juan Pablo -->


<!-- Date: Sun Dec 2 03:39:33 2007 -->
<pre>Pinky on several bias lines that gradualy cleared up 
(the current is stabilizing after the starting of the store 
and the ramping up of the bias voltage). 
 The only pinly left (set to ignore) is on AVDD on the ladder 
e124 (we changed the configuration on the access and should 
adjust the limits properly; will watch a few days and will 
adjust on Monday).</pre>
<!-- Author:  Juan Pablo -->

<!-- Date: Sun Dec 2 03:47:20 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W5L2 
<li>problem n: 1972 
<li>Status: fixed
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: fernand 
<li>description is: Also working fine in real data taking  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W5&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sun Dec 2 07:10:09 2007 -->
<pre>There was a clk glitch at about 6:40am, together with an SRC error which did not caused problems in the CR.</pre>
<!-- Author: Sebastian -->
<!-- Comment: Sun Dec  2 11;33;36 comment by...Ignacio -->
This was again in coincidence with BMU SE 156 tripping.
<!-- Date: Sun Dec 2 08:02:11 2007 -->
<pre>another <a href='/cgi/elog/elog.pl?nb=2007&action=view&page=940&frame=2&anchor=06:47:32.225'> 
clock glitch </a>  
Will paste it into the elog later.</pre>
<!-- Author: Juan Pablo -->


<!-- Date: Sun Dec 2 08:07:15 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12116&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12116  width='300' align='top'></a></td><td>SRC_Error on ISL</td></tr></table>
<!-- Author:  Juan Pablo -->


<!-- Date: Sun Dec 2 08:10:41 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12117&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12117  width='300' align='top'></a></td><td> zoom in</td></tr></table>
<!-- Author:  JP -->





<!-- Date: Sun Dec 2 14:30:01 2007 -->
<pre>Just to mention that I was training Tino about autohockerizations 
we just had one (it was great for him to see what I was explaining). It is not difficult for aces (just a few steps). 
 
 Also an AVDD when pink (B3W7L2) and HHR solved it. 
Good work of the scico ! 
 
 Once during the evenining shift yestarday and once during 
the owl (while I was there) there was a voice alarm ("Silicon 
alarm") but everything was fine. Do not what caused it. The 
system was happy and running (no inhibits, no sing whatsoever 
on any monitoring program, nothing)</pre>
<!-- Author: Juan Pablo -->


<!-- Date: Sun Dec 2 15:43:02 2007 -->
<table><tr><td><a href=/elog/notebooks/silicon/Sun_Dec__2_2007_154257.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12120  align='top'></a></td><td>S/N ratio vs integ. lumi</td></tr></table>
<!-- Author: Tino / Juan Pablo -->
<!-- Comment: Sun Dec  2 16;13;51 comment by...Tino / Juan Pablo -->
<pre>We have put it in the twiki :
http://b0sili01.fnal.gov/cgi-bin/TWiki/bin/view/Silicon/SignaltoNoise</pre>


<!-- Date: Sun Dec 2 19:34:30 2007 -->
<pre>Rebooted svxiicon</pre>
<!-- Author: Tom Junk -->


<!-- Date: Mon Dec 3 01:22:05 2007 -->
<pre>Store 5770 
Initial inst. lumi 190 E30, losses for antiproton 5K but 
for protons 30 K . 
I ask them to wait until ~18 KHz and then included the silicon 
(I saw the proton losses were steadly going down). I will stay 
for a while watching the losses. 
Init. inst. lum when including silicon 178 E 30. 
Svt spy mon later and svxmon report later...</pre>
<!-- Author:  Juan Pablo -->


<!-- Date: Mon Dec 3 02:33:16 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12121&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12121  width='300' align='top'></a></td><td>SvxMon is ok (e124 still giving good data)</td></tr></table>
<!-- Author:  JP -->
<!-- Comment: Mon Dec  3 02;34;27 comment by...Juan Pablo -->
<pre>Proton losses are now on the 7KHz</pre>


<!-- Date: Mon Dec 3 07:57:57 2007 -->
<pre>Summary of the week 
 
 +) Monday, November 26, 2007     
    inherit store from Sasha's week 
 
 +) Tuesday, November 27, 2007 
    Store 5751 @ 155 E30 ; Lostp 11.5kHz, Lostpb 5.0kHz. 
    Two clock glitches not tripping the silicon system 
    Windows update rebooting the machine (every month ?) 
    changes on SVXIICON Program  
 +) Wednesday, November 28, 2007 
    acess  
       IB4W0L1 gives current and shows 40 V in the bias line though it  
    is not supposed to be biased. Connected to another PS it reads 0 Volts 
    (should try to exchange this PS when a spear is available but another 
    check should be done 1st power it on and measuring the voltage) 
 
 +) Thursday, November 29, 2007 
    New Store , low losses , lumi 169 E 10 
    IB3W0L3 : started developing bit errors (only affecting z side). To   
    keep an eye during monitoring. Rphi side is normal 
    worked on a program to make distributions like RBSY 
  
 +) Friday, November 30, 2007 
    Store 5761 : 6 KHz for protons, 7 KHz for antiprotons  
    Initial lumi : 180 E30  
    Probably know at monitoring : 
    IB4W5L2 - bit errors : missing bit # 3 and last four chips  
    IB1W4L2 - bit errors : missing last bit  
 
    T h e    F r i d a y    m o r n i n g :  
    A ladder tripped ; tried to recover ========&gt;  the L0 on the GUY is so  
   small that we all did not  realize it was still red &lt;===========================  
    [I did not scroll down and look in the PS GUI because I thought the aces did the recover 
     ok] To put more confusion, the initialization was masked so it did not fail config but there  
   was a trigger inhibit (of course). We bypassed the inhibit for a few minutes until 
   looking at "Full status" on the PS guy we realized L0 was off. 
    Another issue : as MPC I encourage everybody to double check whatever the aces 
   do (if you ask to put a fib on HALT do a vxcom and make sure) 
    I am not blaming the aces here. I say that cross checking is good as I am sure will save lots of  
   time. 
 
    T h e    F r i d a y       e v e n i n g   (  a c c e s s ):  
      1 - e050 : put again in the hardware database 
      2 - e124 : performed changes to this ladder configuration to avoid intermitent errors seen in the past 
      3 - f452 : cleaned the optical fiber 
      4 - e121, e123 : minimal undesired changes on their configuration  
      (java is not our friend anymore )  
      [ this is the typical example for the spanish expresion  
                "Virgencita, virgencita, que me quede como estoy ! "] 
 
 +) Saturday, December 1, 2007 
    waiting all the day for the store !  
 
 +) Sunday, December 2, 2007 
    Store 5768 : Init lumi 190 E30  
    Losses started high for protons , 15KHz, but going down smoothly  
    (now at 11 KHz and going down).  
    Antiprotons losses ok , 5 KHz.  
    e124 is giving data ! ! ! (Contratulations guys !)  
    [the 4 chips we left are there and the intermitent errors are gone]  
    e121 and e123 give reasonable occupancies and strip mean charge  
    e050 is green and happy (current wise) and looks also fine in SVXMon  
    f452 is not showing bit errors (Congratulations again !)  
    but this ladder has very big wings  
 
  +) Monday, December 3, 2007 
    Store 5770  
    Initial inst. lumi 190 E30, losses for antiproton 5K but  
 for protons 30 K .  
    I asked them to wait until ~18 KHz and then included the silicon (I saw the proton losses were steadly going down). 
Init. inst. lum when including silicon 178 E 30.  
    Losse went down to 7 KHz after 1 h.</pre>
<!-- Author: Juan Pablo -->


<!-- Date: Mon Dec 3 08:54:59 2007 -->
<h3> ADC Monitering Summary (Run254341-254662) </h3> 
I have checked ADCMon plots during this week from run254341 to 254662. 
<br> 
I will report the ladders which have a issue and intersting work. 
The other ladders look fine. 
<br><br> 
<table border="2" bgcolor> 
<tr> 
<td></td> 
<!-- 1--><td align="center"> 254341 </td> 
<!-- 2--><td align="center"> 254389 </td> 
<!-- 3--><td align="center"> 254550 </td> 
<!-- 4--><td align="center"> 254553 </td> 
<!-- 5--><td align="center"> 254558 </td> 
<!-- 6--><td align="center"> 254572 </td> 
<!-- 7--><td align="center"> 254573 </td> 
<!-- 8--><td align="center"> 254662 </td> 
</tr> 
 
<!--- IB3W0L3 ---------------------------------------------------------------> 
<tr><td align="center"> IB3W0L3(f303) </td> 
<!-- 1--><td bgcolor="orange" align="center"> 6% errors </td> 
<!-- 2--><td bgcolor="orange" align="center"> 100% </td> 
<!-- 3--><td bgcolor="orange" align="center"> 100% </td> 
<!-- 4--><td bgcolor="orange" align="center"> 100% </td> 
<!-- 5--><td bgcolor="orange" align="center"> 100% </td> 
<!-- 6--><td bgcolor="orange" align="center"> 100% </td> 
<!-- 7--><td bgcolor="orange" align="center"> 100% </td> 
<!-- 8--><td bgcolor="orange" align="center"> 100% </td> 
</tr> 
 
</table>  
<!-- Author: Taka -->